1с сутз что это
Обновлено: 07.07.2024
Коллеги, начинаем серию статей, посвященных технологическому журналу.
Другие статьи из серии «Технологический журнал»:
«ТЖ: Настройка»
«ТЖ: Анализ логов»
«ТЖ: События и фильтры»
Описание и включение технологического журнала
Что Вы узнаете из этой статьи?
- Описание и предназначение инструмента Технологический журнал
- Как включить Технологический журнал в 1С:Предприятие 8
- Принцип формирования и сохранения логов и дампов
Описание ТЖ
Технологический журнал (далее ТЖ) – это средство для логирования работы платформы на низком уровне.
ТЖ предназначен для расследования ошибок, анализа и диагностики различных проблем в работе платформы 1С:Предприятие.
С помощью ТЖ можно выяснить, какие запросы работают медленно и откуда они вызываются, при выполнении какого кода «падают» рабочие процессы сервера, куда «утекает» память и многое, многое другое.
Все инструменты анализа производительности платформы используют ТЖ для получения информации. При желании и доскональном изучении вопроса с помощью ТЖ вы можете написать свой инструмент анализа производительности.
ТЖ можно собирать как для процессов сервера 1С, так и для клиентских приложений. Соответственно, и набор событий, которые можно фиксировать в ТЖ, будет отличаться.
Клиентские логи и дампы крайне редко вызывают интерес, поэтому в статье мы будем рассматривать ТЖ исключительно с точки зрения сервера. Тем не менее все, что здесь написано, также подходит и для клиентских логов.
С помощью ТЖ можно собирать логи и настраивать формирование дампов в случае аварийного завершения работы процесса.
Логи – это файлы с расширением .log, где информация хранится в текстовом виде.
Включение ТЖ
По умолчанию технологический журнал включен и работает, но собирает очень ограниченный объем данных.
Под минимальным объемом данных подразумеваются 2 вещи:
1) Формирование дампов минимального размера в случае аварийного завершения работы процессов кластера 1С (ragent, rmngr или rphost).
По умолчанию дамп создается в каталоге:
Если вы используете Windows Vista и выше, то будет использоваться каталог:
Для 8.3 вместо каталога 1Cv82 используется 1Cv8.
2) Для 8.3 в минимальный ТЖ входит формирование логов с одним событием SYSTEM с уровнем Error.
Логи сохраняются в каталоге:
Для Windows Vista и старше используется каталог:
Данные логи по умолчанию будут хранится 24 часа, после чего платформа будет удалять файлы логов, которые превышают этот порог.
Чаще всего информации из ТЖ по умолчанию недостаточно, и необходимо его настраивать вручную.
Чтобы произвести тонкую настройку ТЖ, необходимо создать файл logcfg.xml с определенной структурой в определенном месте.
Данный файл необходимо разместить в каталоге:
В этом случае настройки ТЖ будут действовать для всех версий 1С, которые установлены на данном компьютере, и для всех пользователей. Этот вариант используется чаще всего, и именно его рекомендуем применять.
При настройках ЦУПа, облачных сервисов контроля производительности и прочих инструментов, где надо указывать путь к logcfg, также лучше использовать именно этот каталог, иначе при обновлении платформы или изменении имени пользователя, под которым запущена служба сервера 1С, описанные инструменты перестанут работать и придется менять настройку.
Тем не менее есть и другие варианты, хотя и используются они гораздо реже. Опишу лишь то, что с наибольшей вероятностью вам может понадобится.
Чтобы настроить ТЖ только для одной версии платформы, размещаем logcfg.xml в каталоге:
Где 8.2.19.106 – это номер нужной вам версии.
Крайне редко, но все же, может возникнуть необходимость настроить ТЖ отдельно для каждого пользователя, под которым запущена служба сервера 1С.
Тогда размещаем logcfg в каталоге:
Для ОС Windows Vista и старше:
Это может потребоваться, если у вас, например, 1 служба сервера 1С используется как рабочая, а вторая для отладки. При необходимости можно запустить службы под разными пользователями и собирать ТЖ только для одной из них, чтобы не загружать второй сервер и не собирать в логах лишние данные, либо сделать для каждой из служб свои настройки ТЖ.
Настройки из logcfg считываются не моментально, а каждые 60 секунд, причем каждый из процессов кластера считывает файл настроек независимо от других процессов. Например, сначала могут появиться логи процесса rmngr и только через 45 секунды логи rphost.
Для выключения ТЖ достаточно удалить или переименовать файл logcfg.xml.
Бурмистров Андрей
В следующих статьях рассмотрим нюансы настройки ТЖ и практику использования.
А пока закрепите полученный материал на своей тестовой информационной базе :)
PDF-версия статьи для участников группы ВКонтакте
Статья в PDF-формате
Вы можете скачать эту статью в формате PDF по следующей ссылке:
Если вы хотите узнать больше об оптимизации 1С и быть экспертом в этой области – пройдите наш новый курс «Оптимизация производительности 1С:Предприятие».
Комментарии / обсуждение (18):
2. Периодически появляется ошибка блокировки HRESULT=80040E31
На самом деле для расследования этой проблемы исследовать логи ТЖ вам не нужно. Это проблема ожидания на блокировках причем на уровне СУБД, а для ее исследования вам нужен инструмента анализа ожиданий на блокировках. Вы можете для этих целей использовать платный ЦУП (Центр управления производительностью) или бесплатный сервис анализа блокировок от Гилева. С помощью одного из этих инструментов вы сможете определить причину ожиданий и если есть нужные знания решить проблему.
В самом ТЖ вы лишь увидите текст ошибки по таймауту из-за блокировки, хотя этот текст проще вам будет посмотреть в журнале регистрации (если он конечно включен).
Благодарю за Ваш ответ!
Пожалуйста!
Интересного обучения!
Подскажите, можно ли отловить в ТЖ изменения настроек Журнала регистрации, например, отключение записи событий?
Специального такого события нет, но можно посмотреть что настройки ЖР были изменены, хотя и нельзя определить что именно там было изменено.
В случае измерения настроек в ТЖ будет вот такая строка:
Вы можете сделать фильтр на свойства t:applicationName=Designer и MName=changeLogMngrInfo
Наберусь наглости задать еще один вопрос по журналу регистрации.
Если в кластере два центральных сервера, то как идет запись в ЖР?
Если ничего не настраивать, то журналы регистрации для одной и той же ИБ на серверах разные? Или дублируются? Как сделать так, чтобы все писалось только в одну папку в служебном каталоге кластера одного из серверов? Если помощью требований назначения функциональности запретить одному серверу работать с журналом регистрации, то события будут писаться в папку другого сервера или вообще не будут для сеансов на данном сервере?
>Если в кластере два центральных сервера, то как идет запись в ЖР?
Если ничего не настраивать, то журналы регистрации для одной и той же ИБ на серверах разные?
Журнал пишется только на одном из серверов если ничего дополнительно не настравивать.
>Или дублируются?
Нет, журнал не дублируется.
>Как сделать так, чтобы все писалось только в одну папку в служебном каталоге кластера одного из серверов?
Для этого необходимо с помощью требований назначения функциональности перенести сервис ЖР на какой-то один сервер.
>Если помощью требований назначения функциональности запретить одному серверу работать с журналом регистрации, то события будут писаться в папку другого сервера или вообще не будут для сеансов на данном сервере?
Будут писаться в папку другого сервера.
Рекомендуется закрепить ЖР за каким-то одним из серверов, что бы не получилась нижеописанная ситуация.
Допустим с помощью требований назначения функциональности указано что одна база работает на отдельном сервере, другие на другом. В этом случае ЖР действий по этой базе будет вестись на отдельном сервере, ЖР по другим базам будет на другом сервере, и это нужно учитывать при резервном копировании. Так же возможна ситуация когда работы с отдельной базой или рег. заданием вынесли на отдельный сервер, а потом вернули обработно. Тогда всей действия в этой базе или в этом рег. задании которые были за период пока они выполнялись на отдельном сервере, будут только в ЖР на этом отдельном сервере. С другими серверами кластера эта информация не синхронизируется. Поэтому что бы не рисковать, рекомендуется сделаять явное указание где хранить ЖР, в таком случае ЖР всегда будет храниться в одном месте при любых условиях.
Продукт "1С:MES Оперативное управление производством" предназначен для оперативного планирования и диспетчеризации производственных процессов, а также контроля качества выпускаемой продукции. Решение относится к классу MES-систем (англ. Manufacturing Execution System – система управления производственными процессами). Продукт позволяет с учетом ограничений и исходя из текущей производственной ситуации гибко формировать оптимизированный по заданным критериям оперативный план производства.
Встроенные в 1С:MES механизмы интеграции позволяют применять его совместно с 1С:ERP и 1С:PDM 4 (PLM). В этом случае объемно-календарное планирование, выполнение экономических расчетов и регламентированный учет ведутся в 1С:ERP, конструкторско-технологическая подготовка производства и управление информацией об изделии осуществляются в 1С:PDM 4 (PLM), а пооперационная оптимизация плана производства и управление производственными процессами происходят в 1С:MES.
Продукт позволяет:
- Специалистам планово-экономического отдела – планировать объемы производства, контролировать сроки исполнения плана, контролировать объемы сдельной заработной платы рабочих.
- Специалистам производственно-диспетчерского отдела – формировать этапы производства, осуществлять оперативный контроль производства, контролировать сроки выполнения технологических операций.
- Специалистам отдела материально-технического обеспечения – получать графики потребности в материалах и полуфабрикатах, фиксировать отпуск материалов в производство.
- Специалистам отдела технического контроля – вести учет брака в процессе производства, контролировать показатели качества и их изменение на всех этапах производства.
- Менеджерам по продажам – получать информацию об исполнимости заказа в заданные покупателем сроки.
- Руководителям производственных подразделений – получать информацию о запланированных операциях, назначать исполнителей, контролировать исполнение технологических операций.
- Рабочим – оперативно получать план работ на смену, отражать исполнение операций.
При разработке редакции 1.3 был учтен опыт, накопленный при внедрении и эксплуатации "1С:MES Оперативное управление производством" более чем на 60 предприятиях различных отраслей и форм собственности, среди которых: ООО "УК Татнефть-Нефтехим", ООО "ХОЛДИНГ ЛЕНПОЛИГРАФМАШ", АО "НПО автоматики имени академика Н.А.Семихатова", ООО "Завод "Краски КВИЛ", АО "Саратовский агрегатный завод", ООО "ФЛИМ", ООО "Стил Продактс", ООО "Эметал" и другие.
Сегментом особого внимания особенно в крупных производственных и промышленных организациях является учет спецодежды и спецоснастки с необходимостью оперативного получения информации об их наличии и состоянии, не только в суммовом, но и в количественном выражении.
Беря во внимание количество подразделений и входящих в них сотрудников, производство или закупка спецодежды составляют немалую статью расходов. Соответственно, некорректный учет негативно сказывается на финансовом состоянии компании.
В типовом функционале ERP существует ряд ограничений:
Отсутствуют инструменты по инвентаризации ТМЦ в эксплуатации, что для крупных компаний является обязательной процедурой.
В системе в принципе нет возможности сформировать документы для проведения инвентаризации ТМЦ в эксплуатации. Из-за этого бухгалтеру приходится формировать ведомости в xls, из-за чего растет вероятность ошибок, а также увеличивается время на подготовку необходимой информации.
Нет единого отчета, который бы аккумулировал в себе все сводные данные по учету спецодежды.
Количественные и суммовые данные разбросаны по нескольким отчетам. Например, чтобы получить информацию о количестве и стоимости ТМЦ в эксплуатации, нужно сформировать ОСВ (оборотно-сальдовую ведомость) по счету и типовой отчет "ТМЦ в эксплуатации", а затем сопоставить данные отчета в единый. При больших объемах данных такой процесс, естественно, усложняет работу пользователям и влияет на рост количества ошибок.
Кроме того, в типовом отчете "ТМЦ в эксплуатации" не отражаются те ТМЦ, по которым срок службы закончился, но сам ТМЦ еще не списан, что в свою очередь влияет на полноту отражения данных по учету.
Не отражается движение спецодежды по счетам МЦ и 10.11 в рамках одного месяца, если она была передана в эксплуатацию в этом же месяце.
В ведении учета есть своя специфика. Представим, что в апреле была передана в эксплуатацию спецодежда. Работник несколько дней ей попользовался и передал другому. Либо другая часто встречающаяся ситуация - в одежде обнаружился брак и ее нужно было списать. И все это произошло в рамках одного месяца.
Ограничение типового функционала 1С:ERP заключается в данном случае в том, что по счетам МЦ и 10.11 не будет отображаться движение спецодежды в том же месяце, в котором произошла передача и было сделано списание или перемещение. Пользователи не смогут получить полные сведения по эксплуатации одежды в апреле, в котором она и была передана, данные будут отображены только в мае. Такой формат противоречит полноте отображения данных.
Расчет остаточной стоимости ТМЦ, стоимость которых была погашена при передаче в эксплуатацию.
Помимо недостающей информации для корректного учета многие компании сталкиваются с необходимостью определения остаточной стоимости, которая возникает при списании ТМЦ из эксплуатации при реализации или другим причинам.
Сейчас в типовой системе 1С:ERP вся спецодежда и спецоснастка (согласно ФСБУ 5), которая передается в эксплуатацию, списывается на расходы сразу, независимо от срока службы. Проблема заключается в том, что при полном списании, когда не учитывается реальный срок службы спецодежды (в учете 2021 в системе не заложены такие документы), нельзя автоматически рассчитать остаточную стоимость, которая важна для формирования возврата средств за спецодежду и финансового результата при реализации.
Может ли автоматизация процессов в 1С решить насущные проблемы учета?
В нашей работе мы сталкиваемся с абсолютно разными отраслями, масштабами организаций, отношением сотрудников к внедрению новых механизмов и правил. Но 90% компаний схожи в двух моментах: бухгалтерии нужны максимальное удобство и экономия времени при аврале задач, а руководству - полная и прозрачная финансовая картина по процессам производства и контроль состояния активов.
Рассматривая данные цели в разрезе учета спецодежды в 1С:ERP, для их достижения необходима автоматизация учета ТМЦ. Для решения вопроса оперативности, полноты и достоверности данных о ТМЦ в эксплуатации был разработан отчет "ТМЦ в эксплуатации" на базе типового отчета 1С:ERP.
Данный отчет позволяет:
увидеть суммовые и количественные показатели в одном отчете, в разрезе всей необходимой аналитики;
работать без ограничений по отражению ТМЦ, срок службы у которых закончился. В отчете отражаются все ТМЦ, числящиеся в учете, но с помощью настроек пользователь может сам установить отбор, показывать ему такие ТМЦ или нет;
увидеть суммовые показатели по перемещениям и списаниям ТМЦ в том периоде, в котором они отражены по документам, независимо от даты передачи их в эксплуатацию;
работать с полной детализацией до первичного документа, что позволяет открывать документы сразу из отчёта и вносить в него при необходимости корректировки.
Важный момент: отчет подключается к 1С как внешний инструмент и не рушит текущие процессы системы, в которой работает компания.
Разбираемся с инвентаризацией
Чуть выше мы говорили о том, что 1С:ERP в принципе нет документов по инвентаризации. Но данный процесс нельзя обходить стороной. Удачной альтернативой ручному труду будет является проведение доработки самой системы 1С, учитывая нюансы самой компании, так как тут все индивидуально.
В нашей практики в рамках процесса автоматизации учета была доработана система, где мы создали документы, которые отражают инвентаризацию, что облегчило ввод данных и исключило ошибки, которые появляются при ручном вмешательстве.
Документ "Инвентаризационная ведомость для ТМЦ в эксплуатации" заполняется автоматически по данным забалансового счета МЦ по сумме и количеству с учетом данных оперативного контура, что позволяет получать актуальные данные после проведения документов перемещения и списания, независимо от формирования проводок в БУ. При этом в документе есть возможность формирования печатных форм ИНВ-3 и ИНВЕ-19.
Автоматическое заполнение реквизитов в документах по учету ТМЦ в эксплуатации
В рамках разработки отчета были доработаны механизмы, позволяющие автоматизировать:
заполнение стоимости ТМЦ при возврате из эксплуатации, если на момент возврата не вышел срок службы или в принципе есть остаточная стоимость на счете 10.11;
заполнение реквизитов “Физическое лицо получатель” при перемещении.
Разумеется, можно рассматривать альтернативные решения автоматизации. Например, если компания будет формировать оборотку, а затем загружать заполненный excel-файл в свою систему. Но учитывая объемы работ, с уверенностью можно сказать, что такой способ повлияет на рост количества ошибок.
В данном случае автоматизация учета ТМЦ станет действенным методом, который убережет компанию от ошибок, влияющих на финансовое состояние организации, а также поможет оперативно принимать взвешенные управленческие решения, основанные на корректной и актуальной информации по учету спецодежды и спецоснастки.
Если у вас появятся вопросы - оставляйте заявку, мы подробно проконсультируем по функционалу!
Читайте также: