Как правильно разделить документ реализации на несколько накладных в 1С:Бухгалтерии 3.0?

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

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

Почему возникает необходимость дробления реализации

Проанализируем типовые сценарии, при которых требуется разделение одной большой накладной на несколько меньших документов:

1. Требования торговых сетей и EDI: ритейлеры нередко направляют один общий заказ (ORDERS), однако требуют раздельные электронные накладные (DESADV, УПД) под разные точки выгрузки (GLN), временные слоты доставки либо с жестким лимитом по весу или числу позиций.
2. Специфика товарных групп: регуляторные правила часто запрещают объединять в одном документе маркированную продукцию (ГИС МТ «Честный ЗНАК»), подконтрольные ветнадзору товары («Меркурий») и обычную бакалею.
3. Складские ограничения программы: в 1С:Бухгалтерии 3.0 склад списания выбирается в шапке документа реализации. Если товар отгружается с разных физических мест хранения, списать его одной накладной без предварительного внутреннего перемещения невозможно.

Вариант 1. Ручное разделение через копирование документов

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

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

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

Вариант 2. Загрузка через промежуточный документ «Счет покупателю»

Проанализируем ситуацию с точки зрения типовой архитектуры программы. В 1С:Бухгалтерии 3.0 нет полноценного справочника или регистра заказов покупателей, как в 1С:Управление торговлей или 1С:ERP. Однако роль заказа в БП штатно выполняет документ Счет покупателю.

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

1. Заказ из внешнего EDI-модуля создается как документ Счет покупателю на полную спецификацию товаров.
2. На основании счета вводим документ Реализация (акт, накладная, УПД). По умолчанию в накладную подтянутся все строки счета.
3. Удаляем из накладной лишние позиции или уменьшаем их количество до фактически отгружаемого объема и проводим реализацию.
4. При создании следующей реализации на основании того же счета программа автоматически отслеживает состояние отгрузки и позволяет корректно отгрузить остаток товаров.

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

Вариант 3. Автоматизация разделения при интеграции

Если объемы поставок велики, ручное удаление строк перестает быть эффективным. В таком случае оптимизируем логику на уровне кода или настроек интеграционного шлюза:

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

Контроль партионного учета и взаиморасчетов

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

Для исключения ошибок себестоимости и некорректного закрытия счетов 62.01 и 62.02 обязательно выполним процедуру Перепроведение документов за месяц в обработке Закрытие месяца.