Как правильно организовать работу с остатками ЕГАИС и устранить технические ошибки обмена в 1С?

Программист 1С v8.3 (Управляемые формы) 1С:Розница Управленческий учет Торговля и дистрибуция
← На главную

Внедрение и сопровождение подсистемы ЕГАИС в типовых и нетиповых конфигурациях 1С требует понимания регламентов обмена через Универсальный транспортный модуль (УТМ), правил списания продукции и внутренней структуры XML-пакетов. Разберем по шагам ключевые аспекты работы с регистрами остатков, порядок списания немаркируемой продукции, а также способы устранения типичных программных ошибок обмена.

1. Регламент перемещения продукции в торговый зал и выравнивание остатков

Рассмотрим логику распределения алкогольной продукции между складом (Регистр 1) и торговым залом (Регистр 2):

  1. Момент передачи в торговый зал: Отправлять документ Передача в торговый зал сразу после отправки акта подтверждения ТТН нельзя. Необходимо дождаться завершения фиксации накладной в ЕГАИС и получения тикетов с регистрационными формами (справками 2). Передавать продукцию в торговый зал можно как сразу после успешного проведения прихода, так и пакетом в конце смены для закрытия возникших отрицательных остатков.
  2. Отрицательные остатки в течение смены: В течение операционного дня допускаются временные минуса по торговому залу при розничных продажах. Однако к закрытию кассовой смены и формированию итоговых отчетов они должны быть закрыты соответствующими перемещениями с первого регистра.
  3. Причины списания и постановки на баланс: При выравнивании остатков используются строго определенные основания. Причина Реализация применяется только для немаркируемой продукции (пиво, сидр) и старых немаркированных остатков. В случае расхождений по маркированному алкоголю применяются основания Недостача, Пересорт или Порча. Для пересорта процедура выполняется парно: сначала формируется списание с причиной «Пересорт», затем — акт постановки на баланс с обязательной ссылкой на первичный акт списания.

2. Особенности учета и списания немаркируемой продукции (пива)

Проанализируем процесс списания пивной продукции в розничном звене:

  1. Розничные продажи в чеках: Передача чеков по немаркируемой продукции в режиме реального времени не формирует журнал розничных продаж на сервере ЕГАИС.
  2. Списание по итогам смены: Корректный порядок учета заключается в формировании документа Акт списания ЕГАИС из торгового зала с основанием Реализация на основании отчета о розничных продажах (Z-отчета). Документ должен быть отправлен не позднее следующего рабочего дня после продажи.
  3. Списание разливного пива: Вскрытие кеги регистрируется актом списания на весь объем тары (в декалитрах) с указанием причины Реализация в момент подключения кеги к разливочному крану.

3. Ошибка уникальности Identity при повторной отправке документов

Выясним причину частой ошибки отказа сервера ЕГАИС: Владелец [FSRAR_ID], накладная [GUID]. Данная ошибка возникает, если отправленный ранее документ (например, ТТН или акт) получил отказ из-за необеспеченного остатка или неверных справок, после чего пользователь пытается отправить исправленный документ с тем же идентификатором.

Сервер ЕГАИС фиксирует уникальность связки даты, номера и тега Identity. Если в 1С значение Identity формируется на основе неизменного ДокументСсылка.УникальныйИдентификатор(), повторная отправка блокируется.

Для решения проблемы переопределим формирование идентификатора пакета, генерируя новый GUID на каждую попытку отправки:


// Неправильно:
// Идентификатор = XMLСтрока(ДокументСсылка.УникальныйИдентификатор());

// Правильно:
Идентификатор = Строка(Новый УникальныйИдентификатор());

4. Исправление ошибок XDTO-пакетов при обновлении схем ЕГАИС

При переходе на новые форматы документов (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С:

  1. Откроем дерево метаданных конфигурации, перейдем в ветку Общие -> Пакеты XDTO.
  2. Найдем соответствующий пакет схемы (например, egais_TTNSingle_v2 или TTNHistoryF2Reg).
  3. В структуре типа найдем реквизит, вызывающий ошибку (например, Transport в заголовке накладной или parentForm2).
  4. В окне свойств реквизита установим параметр Минимальное количество (minOccurs) в значение 0, а свойство Возможно пустое (nillable) — в значение True.
  5. Сохраним конфигурацию базы данных. Теперь при отсутствии блока в XML-файле парсер не будет аварийно прерывать операцию.

5. Механизм распроведения и отмены актов (RequestRepealWB)

Если покупатель ошибочно отправил акт отказа или подтверждения по накладной, закрытый документооборот можно вернуть в исходное состояние с помощью функционала запроса отмены проведения акта:

  1. Грузополучатель отправляет через УТМ документ RequestRepealWB, в котором указывает регистрационный номер накладной WBRegId.
  2. Запрос поступает поставщику в виде входящего уведомления.
  3. Поставщик должен подтвердить запрос на отмену акта (документ ConfirmRepealWB с флагом Accepted).
  4. После согласования сервером ЕГАИС накладная возвращается в статус «Проведена», остатки восстанавливаются, и получатель может отправить повторный корректный акт (согласие, отказ или акт расхождений).

Пример структуры 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>

6. Настройка стабильности криптографических ключей и служб УТМ

Для предотвращения «отвалов» аппаратных ключей JaCarta и Рутокен ЭЦП выполним следующие системные настройки:

  1. В диспетчере устройств операционной системы для всех USB-концентраторов снимем флаг Разрешить отключение этого устройства для экономии энергии.
  2. В настройках текущего плана электропитания Windows отключим Параметр временного отключения USB-портов.
  3. При обновлении транспортного модуля проверяем соответствие криптографических библиотек в папке УТМ рекомендациям разработчиков удостоверяющего центра. При зависании служб перезапуск выполняется в строгой последовательности: сначала служба Transport-Monitoring, затем Transport.
← На главную