При работе с распределенными информационными базами (РИБ) в конфигурации «1С:Управление торговлей 11» специалисты часто сталкиваются с ситуацией, когда стандартные операции, успешно выполняющиеся в головном узле, вызывают критические ошибки в подчиненных (дочерних) узлах. Одной из таких проблем является невозможность удаления отложенных чеков ККМ. Разберем подробно, почему это происходит и как устранить данную коллизию.
Рассмотрим типичный сценарий: в подчиненном узле РИБ при закрытии кассовой смены или попытке ручного удаления отложенного чека система выдает ошибку:
{ОбщийМодуль.РозничныеПродажи.Модуль(3111)}: Ошибка при вызове метода контекста (Удалить): ЧекККМОбъект.Удалить(); по причине: Не удалось записать: "Задания к формированию записей книги покупок/продаж"!
Проанализируем ситуацию. Метод Удалить() инициирует физическое удаление объекта из базы данных. Однако в системе 1С этот процесс не ограничивается простым стиранием записи. Срабатывают механизмы платформы и подписки на события, которые пытаются очистить связанные данные в регистрах. В данном случае система пытается внести изменения в регистры сведений ЗаданияКФормированиюЗаписейКнигиПокупок или ЗаданияКФормированиюЗаписейКнигиПродаж.
Выясним причину отказа: в подчиненных узлах РИБ часто действуют ограничения на изменение объектов, которые напрямую влияют на глобальный налоговый учет. Поскольку формирование книг покупок и продаж обычно делегировано головному узлу, запись в эти регистры в дочерней базе может быть заблокирована на уровне прав доступа или логики самого плана обмена. Возникает замкнутый круг: для удаления чека нужно обновить регистр НДС, а изменять этот регистр в дочернем узле запрещено.
Самым простым и быстрым решением, которое часто помогает в условиях РИБ, является управление регламентными операциями. Если ошибка возникает автоматически при закрытии смены (Z-отчет), это означает, что срабатывает встроенный программный механизм очистки.
Разберем по шагам, как минимизировать негативное влияние этого процесса:
Удалить() локально.Это позволит избежать появления блокирующего окна с ошибкой у кассира. При этом сами чеки останутся в базе до момента синхронизации или ручного вмешательства в головном узле.
В современных версиях УТ 11 (начиная с 11.4.7 и выше) разработчики предусмотрели штатный механизм управления отложенными чеками. Проанализируем настройки РМК:
Рекомендуется устанавливать эти настройки в головном узле и передавать их через синхронизацию. Если очистка будет инициирована в «голове», то в дочерний узел придет уже информация об удалении объекта, что обрабатывается планом обмена гораздо «мягче», чем локальный вызов метода Удалить().
Если нам необходимо программно вмешаться в процесс очистки в дочернем узле (например, через внешнюю обработку), крайне не рекомендуется использовать метод Удалить(). Рассмотрим более безопасный алгоритм:
// Взамен физического удаления используем пометку
ОбъектЧек = ЧекСсылка.ПолучитьОбъект();
Если ОбъектЧек <> Неопределено Тогда
ОбъектЧек.УстановитьПометкуУдаления(Истина);
КонецЕсли;
Почему это работает? При установке пометки на удаление (УстановитьПометкуУдаления) срабатывает другой набор проверок. Система не всегда пытается мгновенно очистить связанные регистры НДС, а лишь маркирует объект. В дальнейшем, при проведении обмена, информация о пометке уйдет в головной узел, где объект будет окончательно удален стандартной процедурой «Удаление помеченных объектов», которая в головной базе отработает корректно.
Проанализируем технические параметры системы. Версии платформы 8.3.13.1644 имеют известные особенности работы с транзакционными блокировками в РИБ. Если вышеперечисленные методы не помогают, стоит рассмотреть следующие шаги:
ЗаданияКФормированиюЗаписейКнигиПродаж. Запуск процедуры «Тестирование и исправление» в режиме проверки логической целостности в подчиненном узле может помочь выявить «битые» записи.Подводя итог, можно сказать, что корень проблемы кроется в попытке 1С выполнить физическое удаление документа, который вовлечен в цепочку формирования налоговой отчетности, внутри ограниченного по правам подчиненного узла РИБ.
Для стабильной работы рекомендуется:
ЧекККМОбъект.Удалить().Такой подход обеспечит бесперебойную работу кассиров в дочерних магазинах и сохранит целостность налоговых данных во всей распределенной системе.