При обмене данными между конфигурациями 1С:Розница (РТ) и 1С:Управление торговлей (УТ) пользователи часто сталкиваются с ситуацией, когда «Отчет о розничных продажах» (ОРП) в базе-приемнике (УТ) значительно отличается от исходного документа в базе-источнике (Розница). Проблема проявляется в «потере» части товаров, несовпадении итоговых сумм или подмене одних позиций другими. Разберем подробно причины такого поведения системы и методы исправления ситуации.
В современных релизах 1С синхронизация чаще всего строится на базе формата EnterpriseData. Рассмотрим важный нюанс: при выгрузке из «Розницы» система далеко не всегда просто копирует табличную часть документа ОтчетОРозничныхПродажах. Зачастую правила обмена инициируют сбор данных заново, обращаясь к первичным документам ЧекККМ.
Проанализируем ситуацию: если в «Рознице» документ ОРП был сформирован или отредактирован вручную, но при этом часть чеков, на основании которых он создан, имеют некорректный статус (например, «Аннулирован», «Отменен» или помечен на удаление), то при обмене эти данные могут быть проигнорированы. Система в УТ получит только те строки, которые подтверждены «пробитыми» чеками в узле обмена. Выясним причину расхождения, сравнив реестр чеков за смену в «Рознице» с итоговым документом в УТ.
Одной из задокументированных особенностей типовых правил обмена между РТ и УТ является разделение типов номенклатуры по разным документам. Посмотрим, как это работает на практике:
ОтчетОРозничныхПродажах в УТ.РеализацияТоваровУслуг (РТУ).Если ваш ОРП в «Рознице» содержит 45 позиций, из которых 13 являются услугами, то в УТ в аналогичном отчете вы увидите только 32 товара. Остальные 13 позиций нужно искать в списке реализаций. Проверим тип номенклатуры для «пропавших» позиций в справочнике Номенклатура.
Рассмотрим сценарий возврата товара, купленного в предыдущие кассовые смены. В «1С:Розница» такие операции часто включаются в текущий ОтчетОРозничныхПродажах с отрицательным количеством или просто уменьшают общую сумму реализации. Однако в «1С:Управление торговлей» логика учета требует, чтобы возврат от клиента за прошлый период оформлялся документом ВозвратТоваровОтКлиента.
При синхронизации правила обмена «выцепляют» такие строки из ОРП и пытаются создать на их основе отдельные документы возврата. В результате в самом ОРП в базе УТ количество товара и итоговая сумма уменьшаются, так как эти данные «переехали» в другой документ. Разберем по шагам: проверьте наличие созданных документов ВозвратТоваровОтКлиента в УТ за ту же дату, что и проблемный отчет.
Проанализируем техническую сторону сопоставления объектов. Расхождения часто возникают, если в «Рознице» включен учет по характеристикам или сериям, а в «УТ» для этой же номенклатуры настройки отличаются. Рассмотрим пример: в РТ продано 5 единиц товара с разными характеристиками (например, разные цвета). Если в УТ учет по характеристикам для этой позиции не настроен, система при загрузке может «схлопнуть» эти строки в одну или вовсе выдать ошибку сопоставления, если ключевые поля поиска (УИД, Артикул, Код) не совпадают.
Также стоит обратить внимание на дубликаты штрихкодов или SKU. Если в «Рознице» под одним штрихкодом числятся разные товары (что является ошибкой учета, но встречается на практике), УТ при загрузке через EnterpriseData может выбрать первый попавшийся объект, что приведет к пересортице в документе.
Выясним, как алгоритмы округления влияют на итоговую сумму. В «Рознице» распределение скидки по чеку может происходить по внутренним алгоритмам фронт-офиса. При передаче в УТ система заново пересчитывает суммы строк. Если после применения скидки цена товара становится нулевой (например, акция «1+1=3» или использование бонусных баллов), некоторые версии правил обмена могут ошибочно идентифицировать такие строки как служебные и не переносить их.
Проверим суммы в проблемных документах: если расхождение составляет копейки, дело в округлении. Если пропадают целые позиции — проверьте, не была ли на них установлена 100% скидка.
С внедрением обязательной маркировки товаров (ИС МП) требования к заполнению документов ужесточились. Проанализируем ситуацию: если в «Рознице» был продан маркированный товар, но в чеке по какой-то причине не зафиксирован код маркировки, УТ при приеме документа может заблокировать проведение или запись конкретной строки, если в настройках программы включен строгий контроль ведения учета маркировки.
В этом случае документ загружается частично. Для решения проблемы следует проверить настройки интеграции с ИС МП в Управлении торговлей и убедиться, что все коды в источнике заполнены корректно.
Посмотрим на настройки самой синхронизации. Часто в «Рознице» в один ОРП попадают продажи с разных складов или даже разных организаций (если используется механизм «Интеркампани» или распределение по отделам). Если в настройках узла обмена (Синхронизация данных) установлены фильтры — например, «Выгружать данные только по Складу №1» — то все строки ОРП, относящиеся к другим складам, будут отсечены в процессе выгрузки.
Проанализируем табличную часть документа в РТ: если в колонке Склад указаны разные значения, это прямой путь к потере данных в УТ при наличии складских фильтров в обмене.
Иногда проблема кроется не в самих данных, а в механизме их регистрации. Если документ ОРП был изменен (перепроведен) в «Рознице» после того, как он уже один раз улетел в УТ, изменения могут не зарегистрироваться для повторной отправки, если возникла коллизия версий. Чтобы исправить это, воспользуемся обработкой «Регистрация изменений для обмена»:
Отчет о розничных продажах.После этого запустим повторную синхронизацию. Это гарантирует, что актуальное состояние табличной части будет передано в базу-приемник.
Для того чтобы точно определить, какой из вышеперечисленных факторов сработал в вашем случае, выполним следующие действия:
<v8:ValueTable> в блоке товаров и пересчитаем количество строк непосредственно в файле обмена.Используя этот системный подход, мы сможем выявить причину расхождений и обеспечить идентичность данных в обеих информационных системах.