Двусторонний обмен УНФ и «1С:Бухгалтерии»: где вводить оплаты и первичку

УНФ и «1С:Бухгалтерия» могут обмениваться данными в обе стороны. Рабочая схема для проверки: закупки и продажи оформляются в УНФ, а банковские и кассовые операции — в «1С:Бухгалтерии» и передаются обратно. Но двусторонняя синхронизация не означает, что любой документ можно создавать и исправлять в любой базе. Для каждого вида операции нужно определить место первоначального ввода и проверить поддержку нужного направления обмена в установленных версиях.

Материал адресован главному бухгалтеру, финансовому и ИТ-директору компании, где УНФ уже используется для оперативного учета, а «1С:Бухгалтерия» — для бухгалтерского учета и отчетности. Например, такая связка может обслуживать отдельную организацию группы. Задача — согласовать работу двух учетных систем, чтобы сотрудникам не приходилось повторно вводить одну операцию и вручную объяснять расхождения по оплатам.

Почему одного направления обмена может быть недостаточно

Если первичные документы поступают из УНФ в бухгалтерскую базу, а оплаты бухгалтер вводит только в «1С:Бухгалтерии», нужно отдельно обеспечить возврат информации об оплате в оперативный учет. Иначе сотрудник, работающий в УНФ, может видеть задолженность без учета уже зарегистрированного платежа. Повторный ручной ввод оплаты требует дополнительной сверки: две записи нужно не только создать, но и одинаково отнести к контрагенту и расчетам.

В официальном описании синхронизации 1С приведена схема передачи банковских и кассовых документов из бухгалтерской базы в УНФ. Там же объясняется, что состав обмена в направлениях различается. Поэтому просьбу «включить обмен в обе стороны» полезно заменить перечнем операций: что создается в УНФ, что — в бухгалтерии, какие данные должны вернуться и кто проверяет результат.

Сначала распределите места ввода и исправления документов

Для поступлений и реализаций зафиксируйте исходную систему, ответственного за оформление и порядок исправления ошибок. Если документ создается в УНФ, заранее определите, какие бухгалтерские реквизиты сотрудник дополняет в принимающей базе и как проверить их сохранность при следующем обмене. Разрешение редактировать документ не доказывает, что исправление будет передано обратно.

Для денег отдельно опишите загрузку банковской выписки, оформление наличных операций, возвратов и внутренних перемещений. Если исходной системой для выписки выбрана «1С:Бухгалтерия», приемка должна подтвердить, что соответствующие операции появляются в УНФ и правильно отражаются в расчетах. Параллельную загрузку одной выписки в обе базы следует рассматривать как отдельный сценарий с проверкой защиты от дублей, а не включать по умолчанию.

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

Какие ограничения версий нужно проверить

Речь идет о связке УНФ редакции 3.0 и «1С:Бухгалтерии» редакции 3.0. Наличие штатной синхронизации подтверждено официальными материалами 1С; это не гарантия переноса всех объектов на любой паре релизов. Перед изменением настройки зафиксируйте полные номера версий обеих конфигураций, способ размещения баз и доработки, затрагивающие обмен.

Показательный пример ограничения есть в описании УНФ 3.0.9: для корректировок поступления и реализации предусмотрена выгрузка в «1С:Бухгалтерию», а обратная загрузка не предусмотрена. Это характеристика указанной версии. Для более позднего установленного релиза состав и направления передачи корректировок нужно проверить отдельно. Нельзя обещать обратный перенос только потому, что обычные платежные документы уже синхронизируются.

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

Как принять результат вместе с бухгалтерией

Проверку начните на копиях баз с сохраненными исходными настройками. Выберите ограниченный период и согласованный набор примеров: поступление и продажа, оплата покупателя и поставщику, частичная оплата, возврат и исправление документа. Для каждого примера запишите ожидаемые документы в обеих системах и ожидаемое состояние взаиморасчетов. Состав примеров должен соответствовать фактическим операциям компании.

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

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

Подход BSG-IT и следующий шаг

Подход BSG-IT к интеграциям включает определение владельцев данных, правил обработки ошибок, повторной передачи и контрольных сверок. Для связки УНФ и бухгалтерской базы работу целесообразно начинать с карты операций и контрольных примеров. Они позволяют отделить настройку штатного обмена от изменений, которым потребуется самостоятельная оценка и приемка.

Подходящая услуга — интеграции и развитие обменов 1С. Чтобы разобрать задачу с экспертом BSG-IT, подготовьте версии обеих программ, описание текущих направлений синхронизации и обезличенные примеры операций, которые приходится вводить повторно. По ним можно определить границы проверки и ожидаемый результат. Сроки, состав доработок и возможное сокращение ручной работы оцениваются после разбора конкретной схемы учета.