Рассмотрим частую проблему, с которой сталкиваются пользователи и администраторы конфигурации 1С:Розница (в том числе локализованных версий, например, для Казахстана). При закрытии кассовой смены формируется ОтчетОРозничныхПродажах, в котором общая сумма и сумма оплат платежными картами указаны верно, а вот сумма наличных средств оказывается меньше фактической. Создается впечатление, что некоторые чеки, оплаченные наличными, просто не попадают в итоговый отчет.
Особенность ситуации заключается в том, что при выгрузке базы в файловую копию и повторном закрытии смены ошибка часто не воспроизводится. Проанализируем возможные причины такого поведения и разберем по шагам, как диагностировать и устранить эту проблему.
Если магазин работает круглосуточно, смены часто закрываются поздно ночью или рано утром, захватывая чеки за разные календарные дни. Выясним причину, почему чеки могут выпадать: происходит рассинхронизация времени между SQL-сервером, рабочим местом кассира (РМК) и фискальным регистратором.
В рабочей базе чеки, пробитые ровно в момент закрытия смены (или на границе смены дат), могут не попасть в запрос, формирующий отчет. Время проведения таких чеков может оказаться за границей времени кассовой смены. На локальной копии базы транзакции не идут в реальном времени, поэтому при тестировании ошибка исчезает.
Посмотрим на ситуацию в магазине с несколькими кассами. Если в процессе снятия Z-отчета транзакции не блокируются жестко, кассиры могут продолжать пробивать чеки. В результате на уровне SQL-сервера возникают транзакционные блокировки.
Запрос на формирование отчета о розничных продажах просто не успевает «увидеть» самые последние чеки, хотя они уже перешли в статус Архивный. База-копия работает в однопользовательском режиме, транзакционных конфликтов нет, поэтому на ней отчет собирается корректно.
Статус Архивный — это всего лишь реквизит документа ЧекККМ. Отчет о розничных продажах при заполнении опирается на данные регистров накопления, таких как ДенежныеСредстваВКассахККМ или РасчетыПоЭквайрингу.
Если во время интенсивной работы произошел микросбой, чек мог сменить статус, но не сформировать нужные движения по регистрам. На копии при перепроведении или тестировании и исправлении эти движения восстанавливаются. Рекомендуется сверить движения проблемных чеков с нормальными.
Проанализируем другие аспекты учета, которые могут исказить сумму наличных:
ВидыОплат может привести к тому, что система вычтет сумму бонусов или сертификатов из наличных средств, а не из выделенного безналичного пула.Чтобы найти проблемные чеки, воспользуемся консолью запросов. Проанализируем виды оплат, статусы чеков и суммы за конкретный день. Для этого выполним следующий запрос:
ВЫБРАТЬ
ЧекККМОплата.ВидОплаты.Код КАК ВидОплатыКод,
ЧекККМОплата.ВидОплаты КАК ВидОплаты,
ЧекККМОплата.Ссылка.СтатусЧекаККМ КАК СтатусЧекаККМ,
ЧекККМОплата.Ссылка КАК Ссылка,
ЧекККМОплата.ЭквайринговыйТерминал КАК ЭквайринговыйТерминал,
ЧекККМОплата.Сумма КАК Сумма,
ЧекККМОплата.ПроцентКомиссии КАК ПроцентКомиссии,
ЧекККМОплата.СуммаКомиссии КАК СуммаКомиссии,
ЧекККМОплата.НомерПлатежнойКарты КАК НомерПлатежнойКарты,
ЧекККМОплата.ДанныеПереданыВБанк КАК ДанныеПереданыВБанк,
ЧекККМОплата.ИдентификаторПлатежнойСистемы КАК ИдентификаторПлатежнойСистемы
ИЗ
Документ.ЧекККМ.Оплата КАК ЧекККМОплата
ГДЕ
НАЧАЛОПЕРИОДА(ЧекККМОплата.Ссылка.Дата, ДЕНЬ) = ДАТАВРЕМЯ(2022, 5, 23)
УПОРЯДОЧИТЬ ПО
ВидОплатыКод
Как использовать результаты запроса:
Внимательно изучите полученную таблицу. Сравните время создания чеков с точным временем закрытия смены. Проверьте реквизит СтатусЧекаККМ. Найдите чеки, сумма которых не вошла в отчет, и откройте их движения по регистрам. Если движения отсутствуют или чек проведен в ту же секунду, что и Z-отчет — вы нашли причину. Далее потребуется либо отладить механизм проведения, закрыв возможность пробития чеков во время Z-отчета, либо вручную перепроводить зависшие чеки после закрытия смены.