Почему происходят откаты транзакций чеков в 1С и как восстановить данные продаж?

В процессе работы розничной точки пользователи и администраторы могут столкнуться с ситуацией, когда в журнале регистрации за определенный период все документы Чек ККМ переходят в состояние Транзакция отменена, а продажи за полдня или смену исчезают из базы данных. Проанализируем ситуацию, выясним основные причины такого поведения платформы и MS SQL Server, а также рассмотрим варианты восстановления утраченной информации.

Причины пропажи чеков и отмены транзакций

Разберем по шагам, почему записи о продажах могут массово отменяться или пропадать из базы данных:

1. Стандартный механизм закрытия смены: При выполнении процедуры закрытия кассовой смены платформа 1С автоматически сворачивает чеки ККМ за день в итоговый документ ОтчетОРозничныхПродажах. При этом сами чеки ККМ по умолчанию помечаются на удаление или архивируются, а исходные транзакции чеков могут очищаться. Если сводный документ ОтчетОРозничныхПродажах был сформирован, но не проведен, продажи временно «исчезают» из учета до момента проведения отчета.
2. Ошибки в доработанном коде и особенности вложенных транзакций: В платформе 1С отсутствует истинная изолированность вложенных транзакций. Если во внешнем алгоритме была открыта транзакция методом НачатьТранзакцию(), а во внутреннем вызове произошла ошибка или был вызван отказ, платформа помечает всю внешнюю транзакцию как ошибочную. В момент попытки вызова ЗафиксироватьТранзакцию() платформа автоматически откатывает абсолютно все изменения, внесенные с момента начала самой первой транзакции. Если транзакция удерживалась открытой длительное время, откат затронет все документы, созданные за этот период.
3. Зависшие транзакции и обрывы связи: Если из-за логической ошибки в коде транзакция не была зафиксирована вовремя, любая потеря соединения клиентского сеанса с сервером 1С или СУБД (например, завершение процесса rphost, перезапуск службы или обрыв сети) приводит к тому, что MS SQL Server выполняет команду ROLLBACK TRAN для всех незафиксированных данных.
4. Взаимные блокировки (Deadlocks) на уровне СУБД: При высокой интенсивности пробития чеков несколькими кассирами MS SQL Server может зафиксировать блокировку и принудительно завершить сессию одного из пользователей в качестве «жертвы блокировки» (deadlock victim), полностью отменив его активную транзакцию.

Как правильно обрабатывать транзакции в коде 1С

Рассмотрим пример правильного оформления транзакций при проведении торговых документов, предотвращающий зависание и массовый откат данных при ошибках:

НачатьТранзакцию();
Попытка
    // Запись и проведение документа Чек ККМ
    ДокументОбъект = СсылкаНаЧек.ПолучитьОбъект();
    ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
    
    ЗафиксироватьТранзакцию();
Исключение
    ОтменитьТранзакцию();
    ЗаписьЖурналаРегистрации("Ошибка проведения чека", 
        УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
    ВызватьИсключение;
КонецПопытки;

Для предотвращения проблем с пропажей чеков рекомендуется отказаться от их физического удаления при закрытии смены и переключить настройки системы на архивацию чеков ККМ. Это позволит сохранить историю каждого пробитого чека без рисков потери данных при формировании сменного отчета.

Способы восстановления утерянных данных о продажах

Если транзакции чеков были отменены и продажи не попали в базу, проанализируем доступные методы восстановления информации:

1. Загрузка данных с сайта ОФД: Если на кассовой точке используется онлайн-касса, все пробитые фискальные чеки передаются Оператору фискальных данных (ОФД). Из личного кабинета ОФД можно выгрузить полный реестр чеков за требуемый период со списком товаров, суммами и временем операций, после чего повторно загрузить их в 1С.
2. Считывание данных из фискального накопителя (ФН): Все пробитые операции сохраняются в энергонезависимой памяти фискального накопителя ККТ. С помощью сервисных утилит драйвера кассового аппарата можно выгрузить историю смены и восстановить состав проданных товаров.
3. Анализ журнала транзакций MS SQL (LDF): В случае если база данных работает в полной модели восстановления (Full Recovery Model), данные отмененных или удаленных таблиц можно попробовать извлечь из файла журнала транзакций LDF с помощью специализированных утилит анализа логов SQL.
4. Проведение инвентаризации: Если данные фискальных накопителей недоступны, фактический остаток товаров на складе и сумма выручки восстанавливаются путем проведения инвентаризации и оформления документа ОприходованиеТоваров или списания расхождений.