В процессе интеграции конфигураций «1С:Управление торговлей 11» (УТ) и «1С:Бухгалтерия предприятия 3.0» (БП) специалисты часто сталкиваются с ситуацией, когда в управленческой базе документ «Реализация товаров и услуг» оформляется сразу по нескольким складам. Однако при синхронизации в бухгалтерской базе данные искажаются: склад заполняется только из настроек по умолчанию, а аналитика по фактическим местам отгрузки теряется. Разберем подробно, почему так происходит и какие существуют методы решения этой задачи.
Для начала проанализируем, как устроены метаданные в обеих конфигурациях. В УТ 11 функционал «Реализация с нескольких складов» позволяет указывать склад для каждой строки табличной части «Товары». Это удобно для оперативного учета, так как позволяет выписать одну накладную покупателю, даже если товар физически уезжает из разных зон хранения.
В БП 3.0 архитектура документа «Реализация (акт, накладная, УПД)» иная: реквизит Склад расположен строго в «шапке» документа. В табличной части документа БП колонки «Склад» не существует в типовом решении. Программа 1С:Бухгалтерия спроектирована так, что один первичный документ соответствует одной точке отгрузки. При синхронизации через формат EnterpriseData система пытается сопоставить объекты. Поскольку в БП нет места для хранения информации о нескольких складах в одной реализации, механизм обмена вынужден подставлять одно значение — либо склад из заголовка УТ, либо склад из настроек синхронизации («Склад по умолчанию»).
Рассмотрим вариант, предложенный в обсуждении, который позволяет хотя бы частично сохранить складской учет в бухгалтерской базе. Если нам важно видеть движение по складам на счетах учета (например, на 41 счете), необходимо проверить настройки параметров учета.
Выполним следующие шаги в «1С:Бухгалтерия предприятия»:
Важно понимать: включение этой настройки добавит субконто «Склады» на счета учета ТМЦ, но оно не добавит колонку «Склад» в табличную часть реализации. Это лишь позволит программе списывать остатки с того склада, который указан в шапке документа. Если в реализации УТ было 5 разных складов, в БП документ все равно проведется по одному складу, что приведет к пересортице в бухгалтерском учете.
Часто использование нескольких складов в УТ продиктовано необходимостью разделять продажи по видам деятельности (например, розница на патенте и опт на УСН). В БП 3.0 эта задача решается не через разные склады в документе, а через Счета учета номенклатуры.
Проанализируем алгоритм настройки:
В этом случае, даже если склад в шапке один, выручка и себестоимость распределятся по нужным счетам доходов/расходов корректно. Однако проблема списания количественных остатков с разных складов этим методом не решается.
Если требуется идеальное соответствие остатков между базами без доработки кода, рассмотрим наиболее надежный метод: отказ от использования мультискладских реализаций в УТ.
Рекомендуется настроить бизнес-процесс так, чтобы на каждый склад отгрузки создавался отдельный документ. В УТ 11 для этого предусмотрены механизмы рабочего места «Накладные к оформлению», где можно настроить разбиение создаваемых документов по складам. При таком подходе в БП прилетит несколько документов, каждый со своим складом в шапке, и учет будет абсолютно прозрачным.
Если организационно запретить мультискладские отгрузки невозможно, мы можем прибегнуть к технической доработке правил обмена. Идея заключается в том, чтобы на этапе выгрузки из УТ «расщепить» один документ на несколько.
Рассмотрим пример логики, которую можно реализовать в расширении для УТ 11 в модуле менеджера обмена или через подписку на событие при выгрузке данных в формате EnterpriseData:
// Пример логики разделения (схематично)
Процедура ПередВыгрузкойРеализации(ДанныеИБ, ДанныеВыгрузки)
СкладыВДокументе = ПолучитьСписокУникальныхСкладов(ДанныеИБ.Товары);
Если СкладыВДокументе.Количество() > 1 Тогда
Для Каждого ТекущийСклад Из СкладыВДокументе Цикл
// Создаем структуру, имитирующую отдельный документ для каждого склада
НовыйОбъектВыгрузки = СформироватьВиртуальныйДокумент(ДанныеИБ, ТекущийСклад);
// Регистрируем этот виртуальный объект для отправки в файл обмена
ОтправитьВКаналСвязи(НовыйОбъектВыгрузки);
КонецЦикла;
// Отменяем выгрузку основного (общего) документа
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
При таком подходе БП даже «не узнает», что в УТ это был один документ. Она получит несколько файлов, создаст несколько реализаций, и остатки по счету 41 спишутся корректно с каждого склада.
Посмотрим на ситуацию со стороны бухгалтера. Если мы используем «Склад по умолчанию» (сообщение №2), то в БП 3.0 возникает следующая проблема: Товар числится на «Складе №1», а реализация списывает его со «Склада по умолчанию». В результате на «Складе №1» образуется вечный остаток, а на «Складе по умолчанию» — отрицательное сальдо (краснота). Чтобы этого избежать без перепрограммирования обмена, придется вводить в БП документы «Перемещение товаров» со всех реальных складов на «Склад по умолчанию» перед каждой синхронизацией. Это трудозатратно и повышает риск ошибок.
Подведем итог нашему анализу. Выбор решения зависит от приоритетов компании:
Помните, что типовая синхронизация 1С всегда стремится к упрощению данных при переходе из торговой базы в бухгалтерскую, поэтому детальная аналитика часто требует дополнительной настройки «руками» или программного вмешательства.