Внедрение и сопровождение подсистемы ЕГАИС в типовых и нетиповых конфигурациях 1С требует понимания регламентов обмена через Универсальный транспортный модуль (УТМ), правил списания продукции и внутренней структуры XML-пакетов. Разберем по шагам ключевые аспекты работы с регистрами остатков, порядок списания немаркируемой продукции, а также способы устранения типичных программных ошибок обмена.
Рассмотрим логику распределения алкогольной продукции между складом (Регистр 1) и торговым залом (Регистр 2):
Передача в торговый зал сразу после отправки акта подтверждения ТТН нельзя. Необходимо дождаться завершения фиксации накладной в ЕГАИС и получения тикетов с регистрационными формами (справками 2). Передавать продукцию в торговый зал можно как сразу после успешного проведения прихода, так и пакетом в конце смены для закрытия возникших отрицательных остатков.Реализация применяется только для немаркируемой продукции (пиво, сидр) и старых немаркированных остатков. В случае расхождений по маркированному алкоголю применяются основания Недостача, Пересорт или Порча. Для пересорта процедура выполняется парно: сначала формируется списание с причиной «Пересорт», затем — акт постановки на баланс с обязательной ссылкой на первичный акт списания.Проанализируем процесс списания пивной продукции в розничном звене:
Акт списания ЕГАИС из торгового зала с основанием Реализация на основании отчета о розничных продажах (Z-отчета). Документ должен быть отправлен не позднее следующего рабочего дня после продажи.Реализация в момент подключения кеги к разливочному крану.Выясним причину частой ошибки отказа сервера ЕГАИС: Владелец [FSRAR_ID], накладная [GUID]. Данная ошибка возникает, если отправленный ранее документ (например, ТТН или акт) получил отказ из-за необеспеченного остатка или неверных справок, после чего пользователь пытается отправить исправленный документ с тем же идентификатором.
Сервер ЕГАИС фиксирует уникальность связки даты, номера и тега Identity. Если в 1С значение Identity формируется на основе неизменного ДокументСсылка.УникальныйИдентификатор(), повторная отправка блокируется.
Для решения проблемы переопределим формирование идентификатора пакета, генерируя новый GUID на каждую попытку отправки:
// Неправильно:
// Идентификатор = XMLСтрока(ДокументСсылка.УникальныйИдентификатор());
// Правильно:
Идентификатор = Строка(Новый УникальныйИдентификатор());
При переходе на новые форматы документов (V2, V3) схемы УТМ часто делают необязательными теги, которые ранее требовались (например, блок Transport в накладной или parentForm2 в истории справок). Если типовой механизм 1С ожидает наличие тега, возникает ошибка разбора XML:
// Ошибка разбора:
// org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element...
Разберем, как исправить пакет XDTO в конфигураторе 1С:
Общие -> Пакеты XDTO.egais_TTNSingle_v2 или TTNHistoryF2Reg).Transport в заголовке накладной или parentForm2).minOccurs) в значение 0, а свойство Возможно пустое (nillable) — в значение True.Если покупатель ошибочно отправил акт отказа или подтверждения по накладной, закрытый документооборот можно вернуть в исходное состояние с помощью функционала запроса отмены проведения акта:
RequestRepealWB, в котором указывает регистрационный номер накладной WBRegId.ConfirmRepealWB с флагом Accepted).Пример структуры XML-запроса на отмену проведения акта:
<ns:Documents xmlns:ns="http://fsrar.ru/WEGAIS/WB_DOC_SINGLE_01" xmlns:qp="http://fsrar.ru/WEGAIS/RequestRepealWB">
<ns:Owner>
<ns:FSRAR_ID>030000123456</ns:FSRAR_ID>
</ns:Owner>
<ns:Document>
<ns:RequestRepealWB>
<qp:ClientId>030000123456</qp:ClientId>
<qp:RequestNumber>УТ-00000123</qp:RequestNumber>
<qp:RequestDate>2023-11-20T12:00:00</qp:RequestDate>
<qp:WBRegId>TTN-0123456789</qp:WBRegId>
</ns:RequestRepealWB>
</ns:Document>
</ns:Documents>
Для предотвращения «отвалов» аппаратных ключей JaCarta и Рутокен ЭЦП выполним следующие системные настройки:
Transport-Monitoring, затем Transport.