Разберем классическую и весьма распространенную задачу интеграции между конфигурациями «1С:Управление торговлей» (УТ) и «1С:Бухгалтерия предприятия» (БП). Суть проблемы заключается в том, что в УТ в табличной части (ТЧ) товаров можно указывать разные склады для каждой строки (если в шапке документа выбрана группа складов). Однако в типовой Бухгалтерии предприятия реквизит Склад находится только в шапке документа. Соответственно, при выгрузке данных система не понимает, как распределить товары по разным складам в БП, и возникает необходимость ручного или программного вмешательства.
Давайте проанализируем ситуацию, выясним причины такого поведения и подробно рассмотрим все возможные пути решения этой задачи — от правки кода обмена до изменения методологии учета.
Рассмотрим подробнее типовую логику обмена через универсальный формат (EnterpriseData). Поскольку типовая Бухгалтерия не поддерживает склады в табличных частях, правила конвертации данных (КД 3) опираются на настройки самого узла синхронизации.
Если в документе УТ (например, «Реализация товаров и услуг» или «Поступление товаров и услуг») выбран склад-группа, то при формировании пакета данных для БП система не передает склады из табличной части. Вместо этого в БП подставляется один «обобщенный склад» (склад по умолчанию), который задается в настройках обмена. Таким образом, весь товар валится на один склад.
Посмотрим на пример кода из типового модуля МенеджерОбменаЧерезУниверсальныйФормат, который отвечает за формирование выгружаемых данных:
Процедура ПКО_Документ_РеализацияТоваровУслуг_Отправка_ПриОтправкеДанных(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена, СтекВыгрузки)
Если СтекВыгрузки.Количество() > 1 Тогда
Возврат;
КонецЕсли;
ВидОперацииСтрокой = "";
Если Не ЗначениеЗаполнено(ДанныеИБ.ХозяйственнаяОперация) Тогда
ВидОперацииСтрокой = "РеализацияКлиенту";
ИначеЕсли ДанныеИБ.ХозяйственнаяОперация = Перечисления.ХозяйственныеОперации.РеализацияБезПереходаПраваСобственности Тогда
Если ДанныеИБ.Статус = Перечисления.СтатусыРеализацийТоваровУслуг.ВПути Тогда
ВидОперацииСтрокой = "ОтгрузкаБезПереходаПравСобственности_ВПути";
Иначе
ВидОперацииСтрокой = "ОтгрузкаБезПереходаПравСобственности_Реализовано";
КонецЕсли;
КонецЕсли;
Если ВидОперацииСтрокой <> "" Тогда
ДанныеXDTO.Вставить("ВидОперации", ВидОперацииСтрокой);
КонецЕсли;
СкладДляВыгрузки = СкладДляВыгрузки(ДанныеИБ.Склад, КомпонентыОбмена.ПараметрыКонвертации, Истина);
КонецПроцедуры
А теперь посмотрим на саму функцию СкладДляВыгрузки, которая определяет, какой склад пойдет в XDTO-пакет:
Функция СкладДляВыгрузки(СкладИсходный, ПараметрыКонвертации, ПроверятьНаГруппу = Ложь)
Если ПараметрыКонвертации.ВыгружатьАналитикуПоСкладам = ЛОЖЬ Тогда
// отправляем пустой склад
Возврат Справочники.Склады.ПустаяСсылка();
Иначе
Если ПроверятьНаГруппу И СкладИсходный.ЭтоГруппа Тогда
Возврат Справочники.Склады.ПустаяСсылка();
КонецЕсли;
Возврат СкладИсходный;
КонецЕсли;
КонецФункции
Как мы видим, если исходный склад — это группа (СкладИсходный.ЭтоГруппа), функция принудительно возвращает пустую ссылку. В результате в БП уходит пустое значение склада, и программа подставляет склад по умолчанию из настроек узла обмена.
Если нас не устраивает склад по умолчанию, мы можем вмешаться в этот процесс. Для этого необходимо модифицировать процедуру ПКО (Правило Конвертации Объекта) в модуле МенеджерОбменаЧерезУниверсальныйФормат со стороны УТ.
Находим место, где вызывается СкладДляВыгрузки, и переопределяем логику. Например, мы можем написать свой алгоритм, который будет анализировать первую строку табличной части документа и брать склад оттуда, либо определять склад по нашей собственной сложной бизнес-логике. Разумеется, в БП все равно выгрузится только один склад для всего документа, но мы сможем гибко управлять тем, какой именно это будет склад, а не просто полагаться на статический склад по умолчанию.
Если бизнесу критически важно видеть разные склады для разных строк прямо внутри одного документа в БП, нам придется дорабатывать саму Бухгалтерию. Самый безопасный путь — использование расширений.
Разберем по шагам, как это работает:
Склад в табличную часть Товары документов поступления и реализации. Выводим его на форму.Проанализируем альтернативный подход, который позволяет оставить конфигурацию БП полностью типовой. При выгрузке документа из УТ, который содержит, например, 3 разных склада в табличной части, мы программно разбиваем его на 3 отдельных документа для БП — по количеству уникальных складов.
Плюсы такого подхода очевидны: Бухгалтерия остается нетронутой, все механизмы проведения и закрытия месяца работают штатно. Минус: нарушается принцип «один к одному». В УТ будет один первичный документ, а в БП — несколько. Это может несколько усложнить процесс сверки взаиморасчетов и первичной документации между базами.
Если мы не хотим менять код обмена, можно использовать организационно-методологическое решение. Мы принимаем типовое поведение: все товары из документа падают на один виртуальный склад в БП. Назовем его, например, «Транзитный склад обмена УТ».
Затем, если бухгалтеру действительно нужно распределить остатки по реальным складам, он делает это отдельными документами ПеремещениеТоваров уже внутри Бухгалтерии. Это спасает от доработок конфигурации, но перекладывает работу на плечи пользователей.
Зададимся вопросом: а нужна ли вообще аналитика по складам в регламентированном (бухгалтерском) учете? Очень популярная и правильная методологическая практика — вести детальный партионный учет, адресное хранение (ячейки, помещения) и учет по складам исключительно в управленческой базе (УТ).
В Бухгалтерии же учет по складам либо полностью отключается, либо сводится к одному главному складу организации. В таком случае проблема разных складов в ТЧ отпадает сама собой: в БП важен только суммовой и количественный учет по номенклатуре в целом. Это значительно упрощает сверку и закрытие месяца в БП.
В контексте настройки обмена между УТ и БП часто возникает еще одна проблема — выгрузка лишних сущностей, таких как «Заказ клиента». Документы типа «Счет на оплату» или заказы в бухгалтерской базе часто не нужны и только захламляют ее.
Можно занулить передачу заказа прямо в коде ПКО документа реализации (доработав тот самый МенеджерОбменаЧерезУниверсальныйФормат):
// Если ЗначениеЗаполнено(ДанныеИБ.ЗаказКлиента) ...
// ДанныеXDTO.Вставить("Заказ", ДанныеИБ.ЗаказКлиента);
// Иначе
// ДанныеXDTO.Вставить("Заказ", Неопределено);
// КонецЕсли;
// Жестко очищаем заказ:
ДанныеXDTO.Вставить("Заказ", Неопределено);
Однако мы рекомендуем использовать штатные возможности программы. В современных версиях правил обмена между УТ 11 и БП 3.0 возможность не выгружать «Заказы клиентов» и «Заказы поставщикам» легко настраивается параметрически. В настройках синхронизации (в отборах передаваемых данных) можно просто отключить регистрацию документов определенного типа. Это гораздо безопаснее, так как вы не нарушаете ссылочную целостность и не рискуете сломать обмен при очередном обновлении форматов XDTO поставщиком.