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