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