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

Программист 1С v8.3 (Управляемые формы) 1С:Розница Управленческий учет Торговля и дистрибуция
← На главную

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

Причина 1. Сбитая системная дата на кассовом компьютере (документы записаны «в будущем»)

Самая распространенная и неочевидная причина видимого отсутствия документов — сбитая дата в операционной системе клиентского ПК. Если системное время на кассовом месте случайно или намеренно переведено вперед (например, на два-три дня вперед), создаваемые кассиром документы не исчезают, а записываются будущим числом. При этом в текущем периоде образуется визуальная «дыра» в несколько дней.

Если к кассе подключен фискальный регистратор или АСПД (чекопечатающая машина), работающий в режиме синхронизации времени с компьютером, на печатных чеках и Z-отчете также будет отражена эта ошибочная дата. В результате бухгалтер или администратор ищет документы за фактические даты (например, 10–12 числа), а в информационной базе они уже проведены 13–15 числом.

Для проверки этой гипотезы выполним следующие действия:

  1. Откроем журнал документов Чеки ККМ или Кассовые смены и снимем все отборы по дате и кассе. Проверим наличие записей, дата которых больше текущего реального календарного дня.
  2. Проанализируем системный Журнал регистрации. Установим отбор по событию Данные.Добавление за проблемный период времени, но обратим внимание не на дату события, а на реквизит Дата самого созданного объекта (документа).
  3. Выполним диагностический запрос в Консоли запросов для поиска документов с датой, превышающей текущую рабочую дату.

Посмотрим на пример текста запроса, позволяющего выявить документы в будущем периоде:


ВЫБРАТЬ
    Чеки.Ссылка КАК Документ,
    Чеки.Дата КАК ДатаДокумента,
    Чеки.Номер КАК НомерДокумента,
    Чеки.КассаККМ КАК КассаККМ,
    Чеки.СуммаДокумента КАК Сумма
ИЗ
    Документ.ЧекККМ КАК Чеки
ГДЕ
    Чеки.Дата > НАЧАЛОПЕРИОДА(&ТекущаяДата, ДЕНЬ)

УПОРЯДОЧИТЬ ПО
    Чеки.Дата ВОЗРАСТАЮЩИЕ

Причина 2. Ошибки распределенной информационной базы (РИБ) и откат из резервной копии

Если в торговой сети используется распределенная информационная база (РИБ), пропажа документов за диапазон дат может быть следствием несанкционированного восстановления узла из бэкапа:

  1. Если на периферийном узле произошел сбой и локальный специалист восстановил базу данных из архивной копии трехдневной давности, все созданные за эти три дня документы бесследно исчезают в периферийной базе.
  2. При последующей синхронизации с центральной базой (ЦБ) механизм коллизий может отправить в центр информацию об отсутствии документов, либо эти документы просто не успели уйти в центр до восстановления архива.
  3. Если обмены между узлами РИБ настроены без строгого контроля номеров сообщений обмена, такая перезапись базы проходит без видимых программных ошибок.

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

Причина 3. Сбой транзакции при печати чеков и закрытии смены

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

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

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

  1. Проанализируем непрерывность нумерации: проверим цепочку номеров документов ЧекККМ до и после выпавших дней. Если номера идут без пропусков, документы в базе за этот период фактически не создавались. Наличие пропусков указывает на то, что номера выделялись, но транзакции были отменены либо объекты были удалены.
  2. Снимем электронный журнал из энергонезависимой памяти устройства. Большинство современных кассовых аппаратов и АСПД сохраняют архив операций во внутренней памяти. Через утилиту (тест драйвера ККМ) выгрузим контрольную ленту за спорные дни и сверим сумму и состав чеков с базой.

Причина 4. Влияние ограничений прав доступа (RLS) и пользовательских отборов

Иногда документы присутствуют в базе физически, но скрыты от глаз конкретного пользователя:

  1. Ограничение на уровне записей (RLS): Если в настройках прав профиля пользователя включено разделение по организациям, магазинам или кассам ККМ, при изменении реквизитов пользователя или сбое в таблицах прав документы перестают отображаться в динамических списках. Проверим видимость документов под учетной записью с полными административными правами без ограничений.
  2. Пользовательские настройки форм: В журналах документов часто сохраняются скрытые фильтры. В командной панели динамического списка нажмем Еще — Установить стандартные настройки, чтобы очистить скрытые отборы по кассе, периоду или флагу архивации чеков.

Как исправить учет, если документы найдены с неверной датой

Если документы были обнаружены в будущем периоде из-за сбитых часов ПК, исправим учетные данные следующим образом:

  1. Восстановим правильную дату и время в операционной системе кассового компьютера и синхронизируем время с сервером времени.
  2. Отменим проведение найденных документов ОтчетОРозничныхПродажах, КассоваяСмена и подчиненных чеков ККМ.
  3. Последовательно изменим реквизит Дата в кассовых сменах и чеках ККМ на реальные фактические даты продаж.
  4. Заново проведем документы для корректного формирования движений по регистрам накопления и списания товарных остатков.
  5. В случае РИБ выполним принудительную регистрацию изменений по узлам плана обмена для передачи исправленных документов в центральную базу.
← На главную