При настройке обмена данными между устаревшими или сильно модифицированными конфигурациями (например, УТ 10.3) и современными решениями (Бухгалтерия предприятия 3.0) разработчики часто сталкиваются с архитектурными различиями в структуре документов. Одной из таких классических проблем является незаполнение поля Склад в документе Приходный кассовый ордер (ПКО) при выгрузке розничной выручки. Рассмотрим подробно, почему это происходит и как правильно настроить правила конвертации свойств (ПКС) для решения этой задачи.
Для начала проанализируем, как реализовано хранение данных в обеих конфигурациях. В УТ 10.3 документ Приходный кассовый ордер имеет достаточно простую структуру: если это розничная выручка, склад обычно указывается в документе-основании (например, Отчет о розничных продажах) или выбирается в соответствующем реквизите, если это предусмотрено доработками.
В БП 3.0 ситуация иная. Физически реквизита Склад в документе Приходный кассовый ордер не существует. Вместо этого используется реквизит Контрагент, который имеет составной тип данных. В зависимости от выбранного вида операции, в этом поле могут храниться:
Когда мы просматриваем форму документа в интерфейсе "1С:Бухгалтерии", система динамически меняет заголовок поля. Если выбрана операция Розничная выручка, поле называется "Склад", но программно данные записываются в Объект.Контрагент. Именно эта особенность становится камнем преткновения при настройке обмена в "Конвертации данных 2.0".
Выясним причину ошибки: если в правилах обмена ПКС настроено по принципу "Контрагент из УТ -> Контрагент в БП", то при выгрузке розничной выручки (где в УТ контрагент может быть не заполнен) поле в БП остается пустым. Даже если в УТ склад заполнен в отдельном поле, загрузчик БП не "догадывается", что его нужно поместить в реквизит Контрагент.
Разберем по шагам, как настроить корректное сопоставление через обработчики событий в Конвертации данных.
Нам необходимо зайти в ПКО (Правило конвертации объектов) для документа ПриходныйКассовыйОрдер. Найдем в списке свойств строку, где приемником является Контрагент. Нам нужно прописать логику в обработчике Перед выгрузкой. Эта логика будет проверять вид операции и подставлять либо контрагента, либо склад, либо банковский счет.
Рассмотрим пример кода, который решает эту проблему:
// В обработчике ПКС "Контрагент" -> "Контрагент", событие "Перед выгрузкой"
Если Источник.ВидОперации = Перечисления.ВидыОперацийПКО.ПолучениеНаличныхДенежныхСредствВБанке Тогда
// Если получаем деньги из банка, подставляем расчетный счет
Значение = Источник.СчетОрганизации;
ИмяПКО = "БанковскиеСчета";
ИначеЕсли Источник.ВидОперации = Перечисления.ВидыОперацийПКО.ПриходДенежныхСредствРозничнаяВыручка Тогда
// Если это розничная выручка, берем склад из документа-основания
// В УТ 10.3 ПКО часто создается на основании Отчета о розничных продажах
Если ЗначениеЗаполнено(Источник.ДокументОснование) Тогда
Попытка
Значение = Источник.ДокументОснование.Склад;
ИмяПКО = "Склады";
Исключение
Значение = Неопределено;
КонецПопытки;
КонецЕсли;
КонецЕсли;
Важный момент: Обратите внимание на переменную ИмяПКО. Так как тип реквизита Контрагент в приемнике составной, загрузчику нужно явно указать, по какому правилу конвертировать объект, переданный в Значение. Если мы передаем Склад, мы должны написать ИмяПКО = "Склады" (при условии, что у вас создано ПКО с таким именем для справочника Склады).
Проанализируем ситуацию, когда ДокументОснование не заполнен. В старых редакциях УТ склад может определяться по кассе. Если в вашей информационной базе касса жестко привязана к торговой точке, мы можем модифицировать код:
Если Источник.ВидОперации = Перечисления.ВидыОперацийПКО.ПриходДенежныхСредствРозничнаяВыручка Тогда
Если ЗначениеЗаполнено(Источник.ДокументОснование) Тогда
Значение = Источник.ДокументОснование.Склад;
ИначеЕсли ЗначениеЗаполнено(Источник.Касса) И Найти(Источник.Касса.Наименование, "Торговая точка") > 0 Тогда
// Пример логики: ищем склад, связанный с кассой
Значение = Источник.Касса.Склад;
КонецЕсли;
ИмяПКО = "Склады";
КонецЕсли;
Многие разработчики считают, что в Конвертации данных нет отладчика. Это не совсем так. Рассмотрим подробнее, как проверить, почему склад не заполняется, в режиме реального времени:
Универсальный обмен данными в формате XML.Этот метод позволит вам увидеть, что именно попадает в переменную Значение в момент формирования XML-файла и почему ИмяПКО может не срабатывать.
Нужно учитывать, что в БП 3.0 в модуле объекта документа ПКО есть встроенная процедура ОбработкаЗаполнения. Она выполняет приведение типов. Если при загрузке вы передали объект типа "Склад", но вид операции документа установился как "Оплата покупателя", встроенная логика БП при записи может просто очистить этот реквизит, так как он не соответствует типу "Контрагент".
Поэтому убедитесь, что в правилах конвертации для свойства ВидОперации также настроено корректное сопоставление перечислений. Если виды операций не совпадут, склад не сохранится в базе данных приемника, даже если он был в XML-файле.
Подведем итог: решение проблемы незаполненного склада в ПКО при обмене УТ 10.3 — БП 3.0 заключается в ручном управлении составным типом реквизита Контрагент в правилах конвертации свойств. Используя обработчик ПередВыгрузкой и явно указывая ИмяПКО, вы обеспечите корректную трансформацию данных из склада источника в "псевдо-контрагента" приемника.