Введение
Интеграция 1С с порталом ИС ЭСФ периодически, в начале каждого месяца сопровождается нестабильным поведением сервиса и возникновением дублей документов. Вероятно, вы сталкивались с одной из следующих ситуаций:
• В 1С имеется ЭСФ к отправке, который невозможно отправить, так как на портале уже есть эта ЭСФ с идентичными полями.
• В 1С имеется одна ЭСФ, на портале их две (или более), загруженные в разные дни
• В 1С имеются две копии ЭСФ (или более), хотя пользователь уверяет, что не создавал их
Цель данной публикации - описать технический разбор причин возникновения описанных аномалий. Мы детально рассмотрим логику работы портала ИС ЭСФ при обработке входящих пакетов от 1С, выявим неустойчивые места в механизмах взаимодействия 1С с порталом и опишем методы решения проблемы дублирования.
Для понимания первопричин следует начать с описания алгоритма отправки ЭСФ на портал.
Процесс отправки ЭСФ и обработка ответов в 1С
Если описывать в формате дружеского диалога, интеграция выполнена в таком виде:
Теперь детально:
Мы отправляем ЭСФ на портал пакетом (далее - сообщением), в котором заключены подписанные данные документа, ключа и тикета текущей сессии.
Портал получает сообщение и выполняет следующую последовательность действий:
В ответ мы получаем идентификатор версии отправленного ЭСФ, либо сообщение об ошибке, если что-то не так.
И вот тут находится первая ошибка, которая приводит к дублям: Портал не успевает вернуть ответ с идентификаторами.
Далее наша учетная система выполняет следующую последовательность действий:
1. Присваивает полученный идентификатор объекту документа ЭСФ в базе
2. Присваивает статус и состояние ЭСФ согласно полученному от портала (в очереди на обработку)
3. Если статус с портала получен "В очереди на обработку" или "Обрабатывается сервером" (т.е. почти всегда), то выполняется запрос на портал для получения статуса ЭСФ по переданному идентификатору.
Тут находится вторая ошибка, приводящая к дублям - происходит превышение ожидания ответа сервера, и 1С вываливается в исключение
4. Если новый статус с портала уже изменился, он присваивается объекту документа в 1С
5. Объект документа записывается в БД
Тут находится третья ошибка - 1С не всегда может записать документ по нескольким причинам - взаимные блокировки таблиц, парралельная запись одних и тех же объектов, а также иные ошибки записи в БД.
В счастливом результате мы имеем в базе 1С уже записанный ЭСФ с заполненным идентификатором и статусом "Принят сервером", "В очереди на обработку" либо "Отклонен сервером".
Примечание: я не буду рассматривать отложенное обновление статусов ЭСФ, т.к. эта проблем этой функциональности выявлено не было.
...
Это хорошо, и на этом статью можно было бы заканчивать. Но мы ведь не за этим сюда пришли, верно?
Сбои процесса отправки
В процессе исследования проблем обмена мной были выявлены и решены следующие критические точки отказа:
1. Портал помещает ЭСФ в очередь на обработку, но не возвращает ответ с идентификатором
Причина
Возникает при большой нагрузке на портал в начале месяца. Сервер задерживает ответ, в результате чего 1С получает ошибку Request timeout.
Последствия
1С интерпретирует это как сбой отправки и считает ЭСФ неотправленным. Отсутствие идентификатора в 1С делает невозможной дальнейшую синхронизацию статусов.
Решение
Разработка механизмов автоматического запроса данных с портала о собственных отправленных ЭСФ и их сопоставление с документами в базе.
2. Портал предоставил идентификатор, но запись объекта ЭСФ в БД 1С не удалась
Причина
Коллизии при параллельной работе с документами ЭСФ. Проявляется в моменты обработки больших пакетов: множество объектов длительно обрабатываются в одном вызове, и в этот момент происходит их параллельная перезапись. Попытка записи неактуальной версии данных вызывает исключение.
Последствия
В 1C документ ЭСФ не имеют идентификатора и/или регистрационного номера.
Решение
Внедрение соглашений для распределения редактируемых документов между пользователями, а также оптимизация расписания регламентных заданий.
3. Портал повторно принял отправляемый ЭСФ в другой день (возникновение дубля)
Причина
Портал проверяет уникальность учетного номера ЭСФ в рамках учетного номера, контрагента и дня. Если в 1С не зафиксирован прием документа ранее и пользователем инициируется повторная отправку в другой день, портал принимает такой ЭСФ заново.
Последствия
Формирование дубля на портале, который впоследствии загружается в 1С при выполнении синхронизации регламентным заданием.
Решение
Отзыв избыточных ЭСФ на портале, замена идентификаторов ЭСФ в 1С на корректные по данным портала и принудительная синхронизация регламентным заданием.
4. Идентификатор ЭСФ в 1С отличается от идентификатора на портале
Причина
Документ отправлялся из 1С несколько раз. Одна из отправляемых версий числится принятой сервером (присвоен регистрационный номер), другая находится в списке ошибочных, не отображенных в общем реестре на портале.
Последствия
Рассинхронизация статусов между базами. На портале ЭСФ может иметь статус «Подтвержден получателем», тогда как в 1С он зависает в статусе «Отклонен сервером».
Решение
Программная замена идентификаторов ЭСФ в 1С на корректные данные с портала и принудительная синхронизация.
Методы решения проблем
Мной был предпринят комплекс мер для устранения описанных проблем. Ниже концептуально описаны методы, успешно повлиявшие на проблему.
Создание автоматизации синхронизации данных
Согласно документации API портала ИС ЭСФ, существуют дополнительные методы, не задействованные в типовой конфигурации «1С: Бухгалтерия для Казахстана». Их целесообразно применять для получения данных с портала в объеме, необходимом для анализа и синхронизации. Бизнес-логика автоматизации следующая:
1. Выполняется штатная отправка документов на портал пользователями
2. При фиксации нестабильной работы портала отправка документов пользователями временно приостанавливается
3. С использованием методов API «вычитываются» те версии ЭСФ, которые находятся на портале в списке принятых порталом от нас.
4. Осуществляется программное сопоставление данных портала и 1С по ключевым полям (идентификатор контрагента, учетный номер ЭСФ, дата, сумма и т.д.)
5. При успешном сопоставлении документам в 1С принудительно присваивается актуальный идентификатор базы ИС ЭСФ
6. Выполняется автоматический мониторинг доступности портала до возобновления стабильной работы.
7. Запрет снимается, пользователи продолжают отправку
Разграничение времени работы с порталом
В первые дни месяца портал функционирует в условиях колоссальной нагрузки, что приводит к системным таймаутам. Несмотря на то, что после обновления в конце 2025 года портал ИС ЭСФ стал стабильнее, проблема пиковых нагрузок в начале месяца не устранена полностью из-за объема обрабатываемых данных. На основании этого, массовую фоновую отправку документов необходимо алгоритмически переносить на периоды с пониженной нагрузкой — в нерабочее время или выходные дни.
Доработка конфигурации поставщика
В типовой конфигурации «1С: Бухгалтерия для Казахстана» присутствует ряд участков кода, требующих адаптации. Внесение изменений реализуется без снятия с поддержки, через механизм расширений:
• Результат некоторых REST-запросов к порталу ИС ЭСФ не обрабатывается. В расширении необходимо не только заменить строку вызова, но и скорректировать параметры процедуры для возможности возврата результата по стеку вызовов на два уровня выше. Это обеспечивает корректную обработку ошибок (в частности, при частичном наличии ошибочно заполненных документов в отправляемом пакете)
• В некоторых местах в коде REST-запросы следует обернуть в конструкцию Попытка Исключение КонецПопытки, так как запросы в этом месте часто завершаются с ошибкой превышения времени ожидания ответа сервера, что приводит к программному исключению вызова в целом.
• Выявлена очень редкая ошибка, когда длина значения ключевого поля не проходила валидацию по XSD-схеме на портале, несмотря на корректное заполнение в 1С. Проблема скрывалась на этапе преобразования типов данных. Данная уязвимость устранена внедрением конструкции Попытка Исключение КонецПопытки с последующим логированием текста ошибки. Выявление ошибки позволило точечно скорректировать алгоритм преобразования значения.
Заключение
Решение проблемы дублирования ЭСФ требует системного анализа и глубокого понимания внутренних механизмов взаимодействия между учетной системой 1С и порталом ИС ЭСФ. Большинство коллизий связано с нестабильностью ответов сервера в периоды пиковых нагрузок и отсутствием качественных механизмов повторной валидации отправленных пакетов в конфигурации поставщика.
Проведя детальное исследование процессов интеграции, мне удалось разработать и внедрить отказоустойчивую архитектуру обмена данными, которая программно нивелирует влияние неблагоприятных факторов при взаимодействии с порталом. Подобный подход позволяет стабилизировать работу пользователей и минимизировать риски возникновения дублей. Надеюсь, данный технический разбор и предложенные методы помогут специалистам оптимизировать процессы интеграции и сократить издержки на поддержку систем.
Вступайте в нашу телеграмм-группу Инфостарт