Интеграция СЭД с 1С: договоры и первичка без двойного ввода

Почему двойной ввод дороже, чем кажется

Повторный ввод документа выглядит мелочью: пара минут на документ. При сотне договоров в месяц это уже несколько рабочих дней, но главные потери не здесь.

Дороже обходятся ошибки. Опечатка в реквизитах приводит к платежу не туда, расхождение в сумме — к пересогласованию, разные версии контрагента — к неверной аналитике по клиенту. Каждый такой случай разбирают несколько человек.

Интеграция убирает не столько минуты, сколько эти разборы. Именно поэтому её обычно окупает не экономия времени бухгалтера, а отсутствие расхождений при закрытии периода.

Что синхронизировать, а что нет

Соблазн синхронизировать всё подряд возникает у всех. На практике чем больше объектов в обмене, тем выше шанс, что конфликт в одном справочнике остановит остальные передачи.

Мы начинаем с минимально достаточного набора: контрагенты, договоры и сами документы. Аналитику, статьи затрат и подразделения подключаем следующим шагом, когда основной поток стабилен.

Отдельно решаем, что не передавать никогда. Например, черновики и промежуточные версии в учётной системе не нужны — они только засоряют её и усложняют поиск.

Как обмен переживает обновления 1С

Главное опасение заказчика при интеграции звучит так: обновим 1С, и обмен встанет. Опасение обоснованное, но обычно оно относится к решениям, где логика обмена вписана прямо в типовые объекты конфигурации. После такого вмешательства конфигурация перестаёт быть типовой, и каждое обновление превращается в отдельный проект. Мы стараемся этого не делать: обмен живёт в расширении и опирается на штатные механизмы, поэтому типовое обновление накатывается без переписывания интеграции.

Полностью исключить влияние обновлений всё равно нельзя: меняются структуры документов, появляются новые обязательные реквизиты, иногда меняется состав передаваемых данных. Поэтому в регламент закладывается простое правило: обновление сначала ставится на копию базы, на копии прогоняется тестовый обмен по контрольному набору документов, и только после этого обновляется рабочая база. Занимает это часы, а не дни, и снимает основную часть рисков без дополнительных затрат.

Есть и организационная сторона. 1С часто обслуживает отдельная компания, которая про интеграцию узнаёт последней. Мы фиксируем в документации, какие объекты и реквизиты используются обменом и что нельзя менять без предупреждения, и передаём этот список обслуживающей стороне. Дальше спорные ситуации разбираются по документу, а не по переписке: видно, что именно изменилось, кто это сделал и почему обмен перестал находить нужные данные.

Что происходит, когда обмен падает

Обмен между двумя системами падает регулярно, и это нормально: сервер недоступен, база заблокирована на регламентных работах, документ не проходит проверку на приёмной стороне. Важно не отсутствие сбоев, а то, что происходит после них. Передача ставится в очередь и повторяется автоматически с нарастающим интервалом; ответственному она попадает как задача только после нескольких неудачных попыток. Иначе люди быстро привыкают к потоку писем об ошибках и перестают их читать.

Ошибки удобно делить на два типа. Технические, вроде недоступности сервиса или таймаута, лечатся повторной отправкой и человека не касаются вовсе. Содержательные требуют решения: не найден контрагент, не заполнен обязательный реквизит, сумма документа не сходится с суммой строк. Такие случаи видны в журнале с текстом ошибки и ссылкой на документ и не исчезают из списка, пока их не закроют. Это единственный способ не копить тихие расхождения между системами.

Повторные отправки не должны плодить дубликаты. Каждый документ передаётся со своим идентификатором, и приёмная сторона по нему отличает повтор от нового документа: при повторе запись обновляется, а не создаётся заново. Сверх этого имеет смысл держать регулярную сверку количества документов и сумм за период. Она ловит редкий, но неприятный случай, когда обе системы считают, что всё прошло успешно, а данные всё равно разошлись.