← На главную

Рассмотрим частую ситуацию, с которой сталкиваются компании при настройке регулярного обмена данными между конфигурациями 1С:Управление торговлей (УТ) и 1С:Бухгалтерия предприятия (БП). После выполнения синхронизации в Бухгалтерии появляются документы "Счет на оплату покупателю", а также платежные поручения и реализации. Однако статусы счетов остаются в положении "Не оплачен" и "Не отгружен". Документы оплаты и отгрузки не подтягиваются к счету автоматически, из-за чего бухгалтеру приходится заходить в каждый счет и вручную привязывать соответствующие документы. Разберем по шагам, почему возникает эта проблема и как можно автоматизировать данный процесс.

Выясним причину проблемы

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

1. В 1С:Управление торговлей основным документом сделки выступает ЗаказКлиента. Именно вокруг него строится вся работа: к нему привязываются оплаты (банковские выписки) и отгрузки. Документ "Счет на оплату" в УТ часто играет второстепенную роль и используется преимущественно как печатная форма.
2. При синхронизации данных в 1С:Бухгалтерия предприятия документ "Заказ клиента", как правило, трансформируется в "Счет на оплату покупателю".
3. Типовые правила обмена (формат EnterpriseData) не всегда корректно переносят привязку банковской выписки (поступления на расчетный счет) к этому новосозданному счету. Это происходит потому, что в исходной базе (УТ) платеж был привязан к заказу, а не к счету — решить проблему помогут доработанные правила обмена EnterpriseData между УТ и БП.

В результате, документы поступления денежных средств и реализации загружаются в Бухгалтерию сами по себе, без связи со счетом. Статусы счетов не обновляются и требуют ручного вмешательства.

Проанализируем риски ручной корректировки

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

Допустим, менеджер в УТ задним числом изменяет какой-либо реквизит в платежном документе (например, уточняет комментарий) или просто перепроводит его. При следующем сеансе синхронизации этот документ будет зарегистрирован к обмену и выгрузится заново. При загрузке в БП он "перезапишет" существующий документ, и та связь со счетом, которую бухгалтер кропотливо устанавливал руками, будет затерта. Именно поэтому ручной труд в данном случае неэффективен, и нам необходимо найти системное решение.

Посмотрим на варианты решения задачи

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

Вариант 1: Изменение методологии учета (отказ от счетов в БП)

Самое простое и часто самое правильное решение с точки зрения архитектуры системы — это отказ от использования счетов в Бухгалтерии. Рассмотрим, как это работает:

Многие компании приходят к выводу, что контролировать оплату счетов и выполнение заказов удобнее исключительно в управленческой базе (УТ). В УТ для этого есть все необходимые инструменты, отчеты по взаиморасчетам и статусам заказов. В Бухгалтерии документ СчетНаОплатуПокупателю не формирует никаких бухгалтерских или налоговых проводок, он нужен лишь для удобства пользователя.

Если мы настроим взаиморасчеты в БП "По договорам" (или по документам расчетов, но без привязки к счетам), то потребность в постоянной ручной привязке отпадет сама собой. Счета из УТ можно просто исключить из обмена, отключив их выгрузку в правилах синхронизации. Бухгалтерия будет получать только факты хозяйственной жизни: реализации и поступления денег.

Вариант 2: Доработка правил синхронизации (правил обмена)

Если бизнес-процессы компании строго требуют наличия актуальных статусов счетов в Бухгалтерии, нам потребуется вмешательство в механизм обмена. Привлечем программиста 1С для доработки правил конвертации данных.

Логика доработки будет следующей: когда из УТ выгружается документ оплаты (поступление безналичных ДС) или документ реализации, алгоритм при загрузке в БП должен самостоятельно найти нужный СчетНаОплатуПокупателю. Поиск можно осуществлять по уникальному идентификатору заказа-основания или по совпадению ключевых реквизитов (контрагент, договор, сумма). Найдя нужный счет, алгоритм подставляет его в качестве документа расчетов в платежку и накладную. Таким образом, при проведении документов в БП статусы счетов будут обновляться автоматически.

Вариант 3: Создание расширения в Бухгалтерии предприятия

Если мы не хотим или не можем вмешиваться в сложные типовые правила обмена EnterpriseData, создадим специальное расширение конфигурации на стороне 1С:Бухгалтерии. Разберем механику его работы:

1. Расширение добавляет фоновое задание или обработку, которая запускается по кнопке (либо автоматически после успешного завершения сеанса синхронизации) — для этого можно использовать расширение для автоматического разнесения выписки в 1С:БП по правилам.
2. Обработка анализирует новые загруженные документы ПоступлениеНаРасчетныйСчет и РеализацияТоваровУслуг.
3. Далее программа ищет в базе неоплаченные или неотгруженные документы СчетНаОплатуПокупателю, сопоставляя их по реквизитам: Контрагент, Договор, и, например, точная СуммаДокумента — для этого есть автоматическое заполнение реквизитов и счетов при загрузке выписки в 1С:БП.
4. При успешном сопоставлении расширение программно устанавливает связь (заполняет реквизит счет на оплату в строках табличной части расшифровки платежа) и перепроводит документ — её автоматизирует обработка автоматической привязки платежей к счетам в 1С:БП.

Резюмируем: При выборе решения отталкивайтесь от реальных потребностей бизнеса. Если детальный контроль заказов ведется в УТ, лучше исключить счета из обмена и упростить работу в БП (Вариант 1). Если же счета в Бухгалтерии критически важны для работы финансового отдела, используйте расширение или доработку правил синхронизации для автоматического связывания документов (Варианты 2 и 3), чтобы исключить рутинный ручной труд и избежать потери данных при повторных обменах.