← На главную

При работе с программными продуктами 1С, особенно при обновлении конфигураций и настройке обмена данными между ними, пользователи нередко сталкиваются с различными техническими проблемами. Одна из таких ситуаций возникла после обновления 1С:Розница (Р) и последующей синхронизации с 1С:Управление торговлей (УТ), проявившись в ошибках при работе с чеками ККМ. Давайте подробно разберем эту проблему и найдем эффективное решение.

Анализируем исходную проблему: сбой обмена и ошибки в Рознице

Представим ситуацию: мы обновили конфигурацию 1С:Розница с версии 2.3.6.27 до 2.3.8.22 (или 2.3.7.22). После обновления обнаружилось, что нарушился обмен данными с 1С:Управление торговлей версии 11.4.13.85. Для восстановления обмена мы обновили УТ до требуемого релиза 11.4.13.103, а правила конвертации, которые Розница берет из конфигурации, подгрузили в УТ в виде файла "для УТ11.4", предоставленного с Розницей. Обмен данными восстановился, но возникли новые проблемы в главной базе Розницы (которая участвует в обмене с УТ):

1. При попытке пробития чека выпадает ошибка «Отсутствия таблицы», причем этой таблицы фактически нет в Рознице, но такой справочник существует в УТ.
2. При попытке просто просмотреть существующий чек в Рознице выдается ошибка «Метод объекта не обнаружен (ОрганизацияИспользовалаЕНВД)».

Важно отметить, что используемая платформа – 8.3.18.1289, а конфигурации заявлены как типовые. В нашей системе была настроена распределенная информационная база (РИБ) для Розницы. При этом периферийная база Розницы продолжала корректно пробивать и открывать чеки, выгружая данные в главную базу, откуда они затем успешно доходили до УТ. Это указывает на то, что проблема была локализована именно в главной базе Розницы и, возможно, связана с некорректным преобразованием данных или структуры при обновлении и последующем обмене.

Диагностика и поиск корневой причины

Для более глубокого понимания проблемы мы должны рассмотреть следующие аспекты:

1. Проверка обмена данными: Хотя обмен "пошел", это не гарантирует его полную корректность. Иногда данные могут передаваться, но при этом могут происходить ошибки в структуре или типе передаваемых объектов, особенно если правила конвертации не полностью соответствуют изменениям в конфигурациях.
2. Анализ ошибок:
   • Ошибка «Отсутствия таблицы» при пробитии чека, когда справочник существует в УТ, но отсутствует в Рознице, может указывать на то, что код в Рознице пытается обратиться к таблице, которая была переименована, удалена или объединена с другой в результате обновления. Если же эта таблица существует в УТ, это может быть следствием несоответствия структур данных между системами, вызванного неполной адаптацией правил обмена.
   • Ошибка «Метод объекта не обнаружен (ОрганизацияИспользовалаЕНВД)» при просмотре чека, говорит о том, что какой-то участок кода в Рознице, отвечающий за работу с чеками (возможно, для определения налогового режима организации), пытается вызвать метод ОрганизацияИспользовалаЕНВД, которого нет или он был переименован/изменен в обновленной конфигурации. Это также может быть результатом некорректного обновления базы данных или неверного кэширования метаданных.
3. Поведение РИБ: Тот факт, что периферийная база Розницы работает корректно, а главная – нет, подчеркивает, что проблема, скорее всего, не в самих дистрибутивах обновления, а в состоянии главной информационной базы после обновления и последующих обменов.

При создании нового чека в режиме документа ЧекККМ проблема сохранялась, что подтвердило общую природу ошибки, не связанную исключительно с режимом рабочего места кассира (РМК).

Решение основной проблемы: создание новой информационной базы

В ходе дальнейших экспериментов было обнаружено, что при выгрузке данных и создании совершенно новой информационной базы (ИБ) с использованием опции "Это копия ИБ" чеки начинали отлично открываться и пробиваться. Это наблюдение стало ключом к решению. Фактически, перенос информационной базы с созданием новой базы решил проблему.

1. Пошаговое восстановление работоспособности:
   • Шаг 1: Выгрузка информационной базы. Нам необходимо выгрузить данные из текущей нерабочей главной базы 1С:Розница в файл. Для этого обычно используют режим конфигуратора, выбирая "Администрирование" -> "Выгрузить информационную базу...".
   • Шаг 2: Создание новой пустой информационной базы. Мы создаем совершенно новую, пустую информационную базу на том же релизе конфигурации 1С:Розница, который использовался в проблемной базе.
   • Шаг 3: Загрузка данных в новую ИБ с опцией "Это копия ИБ". В режиме конфигуратора новой пустой базы выбираем "Администрирование" -> "Загрузить информационную базу..." и указываем ранее выгруженный файл. При этом критически важно выбрать опцию, которая явно указывает, что это "копия ИБ" или эквивалентную ей. Эта опция сигнализирует системе о необходимости провести дополнительные проверки и преобразования данных, что может исправить внутренние несоответствия.
   • Шаг 4: Повторная настройка РИБ и обмена. После успешной загрузки данных в новую базу и проверки ее работоспособности (открытие/пробитие чеков), мы заново настраиваем распределенную информационную базу, подключая к ней периферийные узлы, а также восстанавливаем обмен данными с 1С:Управление торговлей. Убедитесь, что используются актуальные правила обмена.

Почему это сработало? Вероятнее всего, корневая проблема крылась в повреждении или некорректном преобразовании метаданных или структуры таблиц в самой базе данных при непосредственном обновлении. При создании новой ИБ и загрузке в нее данных, система полностью пересоздает структуру базы данных, корректно применяя все изменения метаданных, предусмотренные новыми релизами конфигурации. Таким образом, внутренние несоответствия, вызывающие ошибки "Отсутствия таблицы" и "Метод объекта не обнаружен", устраняются.

Углубляемся в причины: изменения в структуре конфигурации

Для более полного понимания причин, рассмотрим изменения, которые могли произойти между версиями 1С:Розница. В частности, описание релиза Розницы 2.3.7.22 (который предшествует версии 2.3.8.22, или на него переходили с 2.3.6.27) содержит критически важную информацию: "Справочники "Банковские счета контрагентов" и "Банковские счета организаций" были объединены в один справочник "Банковские счета"."

Это очень значительное изменение в структуре данных. Если в коде конфигурации или в правилах обмена все еще присутствовали ссылки на старые, раздельные справочники, а фактически в базе данных они уже были объединены, это могло привести к вышеописанным ошибкам:

• Ошибка «Отсутствия таблицы» могла возникать, когда код пытался обратиться к таблице, соответствующей старому справочнику (например, БанковскиеСчетаКонтрагентов), которая физически уже не существует как отдельная сущность.
• Ошибка «Метод объекта не обнаружен (ОрганизацияИспользовалаЕНВД)» также могла быть косвенно связана с этими структурными изменениями. Функционал, отвечающий за работу с организациями (в том числе для определения ЕНВД), мог быть переработан с учетом новой единой структуры банковских счетов или других связанных объектов. Если старые ссылки на методы или реквизиты сохранялись, это приводило к ошибке.

Такие глубокие изменения в структуре требуют не только обновления конфигурации, но и корректной конвертации данных, а также адаптации правил обмена. Создание новой ИБ с загрузкой данных, по сути, заново запускает процесс преобразования данных, обеспечивая их соответствие новой структуре.

Дополнительная проблема: отсутствие документа "ВыемкаДСИзККМ"

Помимо основной проблемы с чеками, возникла еще одна трудность: на периферийной базе Розницы при закрытии смены автоматически не создавался документ ВыемкаДСИзККМ, хотя в настройках стояла "полная выемка, автоматически". Если вручную сделать выемку через РМК, документ создавался. Это указывает на проблему именно с автоматическим формированием документа при закрытии смены, а не с его функциональностью в целом.

Для диагностики этой проблемы мы рекомендуем:

1. Проверить настройки магазина и кассы ККМ: Удостоверимся, что для данного магазина и конкретной кассы ККМ корректно настроены параметры выемки. Обратим внимание на поле "Настройка выемки" в карточке магазина или рабочего места.
2. Анализировать Журнал регистрации: В момент закрытия смены внимательно изучим журнал регистрации (Конфигуратор -> Администрирование -> Журнал регистрации). Ищем любые ошибки или предупреждения, связанные с операцией закрытия смены или созданием документа ВыемкаДСИзККМ. Возможно, существуют проблемы с соединением с кассовым аппаратом, несовпадение сумм или другие технические сбои, которые препятствуют автоматическому созданию документа.
3. Проверить остатки денежных средств: Иногда автоматическая выемка может не формироваться, если в кассе по данным 1С недостаточно средств для полной выемки или имеются расхождения с фактическими данными ККТ.
4. Обновить драйверы ККТ: Устаревшие или некорректно работающие драйверы контрольно-кассовой техники могут вызывать сбои при взаимодействии 1С с оборудованием, что может влиять на автоматическое создание выемок.

Если ручное создание выемки работает, это свидетельствует о том, что проблема, скорее всего, лежит в логике автоматического процесса закрытия смены или его взаимодействии с кассовым оборудованием, а не в самом документе или его проведении.

Рекомендации по работе со сложными системами и обновлениями

Работа с распределенными информационными базами и обменами между различными конфигурациями 1С, такими как Розница и Управление торговлей, требует особого внимания при обновлениях. Мы можем сформулировать несколько ключевых рекомендаций:

1. Тщательное планирование обновлений: Всегда планируем обновления конфигураций заранее. Изучаем описания изменений в релизах обеих конфигураций, особенно касающиеся структуры данных и правил обмена.
2. Тестирование на тестовой базе: Каждое обновление сначала проводим на копии рабочей базы (тестовой базе). Это позволяет выявить проблемы до того, как они затронут рабочую систему.
3. Актуализация правил обмена: После каждого значительного обновления конфигураций убеждаемся, что правила обмена данными между ними также актуализированы. Загружаем новые типовые правила или проверяем их на совместимость, если использовались модифицированные правила.
4. Контроль за версиями платформы: Удостоверяемся, что используемая версия платформы 1С:Предприятие (в нашем случае 8.3.18.1289) полностью поддерживается новыми релизами конфигураций.
5. Резервное копирование: Перед любыми операциями обновления или значительными изменениями всегда создаем полные резервные копии всех информационных баз.
6. Понимание архитектуры: Чем глубже мы понимаем, как работают РИБ и обмены, тем легче нам диагностировать и решать возникающие проблемы. Особое внимание уделяем тому, как изменения в одной конфигурации могут повлиять на другую.

В случае, когда проблема решается созданием новой информационной базы с загрузкой данных, это является сильным сигналом о том, что существующая база данных имеет внутренние повреждения или несоответствия, которые не были устранены стандартными процедурами обновления. Поэтому, хотя это и является радикальным методом, он зачастую наиболее эффективен в подобных ситуациях.

В целом, столкновение с подобными ошибками подчеркивает важность аккуратного подхода к сопровождению систем 1С, особенно в условиях постоянного развития функционала и изменения требований законодательства (например, в части маркировки товаров), что ведет к глубоким изменениям в структуре конфигураций.