Проблема расхождения данных в документах при обмене между конфигурациями «Управление торговлей 10.3» и «Бухгалтерия предприятия 3.0» является одной из самых трудоемких для диагностики. Часто возникает ситуация, когда в источнике (УТ) документ заполнен корректно, а после выгрузки в приемник (БП) цены «плывут», суммы не сходятся или позиции вовсе объединяются непредсказуемым образом. Разберем детально причины этого явления и способы их устранения.
Самая частая причина ошибок кроется в фундаментальном различии структур метаданных. В УправлениеТорговлей активно используется справочник ХарактеристикиНоменклатуры, позволяющий вести учет одного и того же товара в разрезе цветов, размеров или других параметров. В БухгалтерияПредприятия (типовой конфигурации) учет по характеристикам в документах реализации отсутствует.
Рассмотрим, как работают типовые правила обмена. При выгрузке документа РеализацияТоваровУслуг, если в табличной части УТ присутствуют несколько строк с одной и той же номенклатурой, но разными характеристиками, правила пытаются объединить их в одну строку для БП. Проанализируем, к чему это приводит:
Решение: Если характеристики в УТ критически важны, а в БП они не нужны, необходимо убедиться, что в правилах обмена в событии ПередВыгрузкой или в запросе выгрузки корректно суммируются показатели Количество и Сумма, а цена вычисляется как Сумма / Количество после суммирования.
Как показывает практика (сообщение 23), пользователи часто думают, что используют «типовые» правила, хотя на самом деле они были доработаны. Проанализируем пример кода, который часто встречается в кастомных правилах:
Запросы.ЗапросПродаж_МЭТР.УстановитьПараметр("ДокументСсылка", Источник.Ссылка);
ТабТовары = Запросы.ЗапросПродаж_МЭТР.Выполнить().Выгрузить();
Использование подобных запросов внутри правил обмена говорит о том, что данные берутся не напрямую из табличной части документа, а собираются по определенному алгоритму (возможно, из движений по регистрам). Если в таком запросе допущена логическая ошибка — например, не учитывается склад или неверно настроена группировка по ставке НДС — данные в БП будут отличаться от УТ.
Что нужно сделать:
Проанализируем файл правил обмена (обычно это xml-файл) через конфигурацию «Конвертация данных 2.1». Проверим ПКО (Правила конвертации объектов) для документа РеализацияТоваровУслуг. Обратим внимание на обработчики событий:
ПередВыгрузкойПриВыгрузкеПоляПоискаРазберем ситуацию, когда в УТ товар продается в упаковках, а в БП карточка товара заведена в штуках. В УТ 10.3 у каждой номенклатуры есть базовая единица измерения и набор подчиненных единиц с коэффициентами. Рассмотрим механизм ошибки:
Если в документе УТ указано количество 1 (упаковка) с коэффициентом 10 и ценой 1000 руб., а в БП основной единицей является «шт.», то при переносе система должна либо создать аналогичную упаковку в БП, либо пересчитать данные в штуки (10 шт. по 100 руб.).
Если правила обмена настроены некорректно, может произойти следующее: количество перенесется как 1 (единица измерения просто подставится текстом), а цена останется 1000 руб. В итоге сумма в БП будет в 10 раз меньше или больше реальной.
Как проверить: Проверим в УТ справочник ЕдиницыИзмерения для проблемных позиций. Убедимся, что коэффициент единицы, указанной в реализации, соответствует здравому смыслу. В БП проверим поле ЕдиницаИзмерения в карточке Номенклатура.
Выясним причину расхождений через настройки налогов. В 1С существует два основных режима работы с НДС в документах:
Если в УТ документ оформлен с признаком ЦенаВключаетНДС = Истина, а в БП при загрузке (из-за настроек договора или учетной политики) срабатывает типовой механизм пересчета НДС сверху, то итоговая сумма документа увеличится на 20%.
Проанализируем обработчик ПослеЗагрузки в правилах обмена. Часто там принудительно вызывается процедура пересчета сумм конфигурации-приемника:
Объект.Записать();
// Иногда разработчики добавляют:
// Объект.ЗаполнитьСчетаУчета();
// Объект.РассчитатьЦеныИСумы();
Если в БП не актуализированы типы цен (регистр ЦеныНоменклатуры), то процедура РассчитатьЦеныИСумы() может затереть верные данные, пришедшие из УТ, «мусорными» значениями из базы БП.
Чтобы окончательно решить проблему, пройдем по шагам:
<Свойство Имя="Цена" ...>. Если в файле цена уже неверная — правим правила выгрузки в УТ. Если в файле цена верная, а в БП — нет — ищем ошибку в правилах загрузки или коде БП.ЗапросПродаж_МЭТР), попробуйте скачать актуальный дистрибутив обмена с портала 1С. Помните, что правила должны строго соответствовать версиям ваших конфигураций (например, УТ 10.3.66.x и БП 3.0.88.x).Продажи или ПартииТоваровНаСкладах записано другое значение, и правила обмена берут данные из регистров — вы получите ошибку. В таком случае поможет перепроведение документов или исправление записей регистров обработками.Важный совет: Если вы не планируете глубоко изучать Конвертацию данных, самым простым способом решения проблемы со «схлопыванием» будет объединение одинаковых позиций в УТ перед выгрузкой (если это допустимо бизнес-процессом) или временное отключение использования характеристик для проверки гипотезы.