Мы сталкиваемся с весьма необычной, но, как оказалось, достаточно распространенной проблемой в работе 1С:Розница 2.3. Суть ее заключается в том, что при пробитии чека в режиме рабочего места кассира (РМК) кассовый аппарат успешно печатает фискальный чек, эквайринговый терминал проводит оплату (если оплата была безналичной), и все данные корректно уходят в Оператор фискальных данных (ОФД). Однако в самой информационной базе 1С этот чек по какой-то причине остается непроведенным или непробитым.
Это приводит к целому ряду неприятных последствий. Во-первых, при закрытии смены кассир видит сообщение об обнаруженных непробитых чеках, что требует повторного их пробития. Во-вторых, повторное пробитие фактически дублирует продажу в базе 1С, искусственно завышая выручку и вызывая расхождения в учете. И, что самое неприятное, журнал регистрации 1С при этом зачастую остается "чист", не содержа ошибок, которые могли бы указать на первопричину сбоя. Давайте проанализируем эту ситуацию и выясним, почему такое происходит и как с этим бороться.
Основной симптом, на который указывают пользователи, — это несоответствие между фактической фискализацией чека (печать на ККТ и отправка в ОФД) и его статусом в 1С. Кассиры выполняют свои стандартные операции, но система не фиксирует чек как завершенный. Как правило, мы видим следующие проявления:
ЧекККМ остается в статусе "Не пробит" или "Не проведен".Такая ситуация является не только неудобной для кассиров, но и ведет к серьезным искажениям в управленческом и бухгалтерском учете, требует ручных корректировок и может вызвать вопросы со стороны контролирующих органов.
Мы выясним, что проблема, когда чек пробивается по кассе и уходит в ОФД, но не регистрируется в 1С, является известной недоработкой в 1С:Розница 2.3. Ее часто связывают с особенностями логики завершения транзакций в самой 1С. В некоторых версиях 1С была изменена логика пробития чека: сначала он проводится в базе, а затем отправляется на печать. Если на этапе печати возникает сбой (например, потеря связи), чек может остаться проведенным в 1С, но не напечатанным физически, или же РМК может его "отбросить", что приводит к созданию нового чека при повторной попытке и появлению дубликатов.
Давайте рассмотрим подробнее, какие факторы могут способствовать возникновению этой проблемы:
Как упоминается в нашем обсуждении, использование файловой базы данных 1С через веб-сервер, хоть и возможно, является скорее "тестовым" или временным вариантом для небольшого числа пользователей. При такой схеме работы:
В условиях высокой нагрузки или даже незначительной нестабильности сети такая архитектура может приводить к "потере" состояния между клиентским приложением (РМК) и базой данных в критически важные моменты, например, в процессе окончательной фиксации пробитого чека. Если в момент подтверждения статуса чека происходит кратковременный разрыв соединения или таймаут, то чек может быть успешно пробит на ККТ, но статус его проведения в 1С не будет обновлен.
Нередко причиной подобных сбоев становятся некорректные настройки оборудования или программного обеспечения контрольно-кассовой техники:
Работа торгового оборудования критически зависит от общей стабильности IT-инфраструктуры. Мы можем выделить следующие внешние факторы:
Когда мы сталкиваемся с непробитым чеком в 1С, но при этом уверенны, что он фискализирован и ушел в ОФД, нам необходимо скорректировать его статус в базе данных. Рассмотрим несколько подходов:
Этот метод подходит, если кассир обнаружил ошибку сразу или покупатель еще не ушел, и есть возможность повторно воздействовать на документ в 1С. Мы разберем по шагам, как это сделать:
ЧекККМ из "Журнала чеков ККМ" в 1С:Розница.ЧекККМ. Для этого обычно достаточно нажать кнопку "Провести" или "Записать и провести". Если документ не был проведен, это могло быть причиной его некорректного статуса.Важно: этот метод эффективен, если 1С еще не считает чек "пробитым" и готов его обработать. Однако, если система уже "зафиксировала" некую ошибку и не позволяет просто так "пробить" его, или если повторное нажатие кнопки приводит к созданию дубликата (как в описанной проблеме с закрытием смены), то нам потребуются другие методы.
Для исправления статуса уже проведенных, но ошибочно "не пробитых" чеков, мы можем использовать стандартную обработку 1С "Групповое изменение реквизитов". Этот метод позволяет напрямую влиять на служебные поля документа ЧекККМ. Разберем шаги:
Администрирование – Обслуживание – Корректировка данных.Документ.ЧекККМ.Проведен в значение Да.Статус в значение Пробитый.ФискальныйПризнак), которые также можно заполнить, если у нас есть соответствующие данные из ОФД или распечатанного чека.Внимание: Работа с групповым изменением реквизитов требует осторожности. Всегда создавайте резервную копию информационной базы перед выполнением подобных операций. Некорректные изменения могут привести к порче данных.
В случае, когда чек был фактически пробит по кассе и отправлен в ОФД (или оплата прошла, а чек не вышел), но в 1С он не зарегистрирован как пробитый, и покупатель уже ушел (то есть невозможно выполнить ручное пробитие или получить дополнительные данные от покупателя), для соблюдения законодательства и исключения штрафов за неприменение ККТ рекомендуется использовать документ Чек коррекции. Для автоматизации массового оформления таких документов подойдёт обработка для пробития чеков коррекции за период в 1С:Розница 2.3.
Чек коррекции в 1С:Розница.Чек коррекции. Этот документ отправится в ОФД и будет зарегистрирован в ФНС.Критически важно понимать ограничения Чека коррекции:
ЧекККМ. Это означает, что он не влияет на остатки товаров, взаиморасчеты с покупателями, расчеты по эквайрингу и не взаимодействует с системами маркировки.Чек коррекции лишь корректирует фискальные данные для Федеральной налоговой службы через ОФД, уведомляя ее о фактически прошедших, но не отраженных продажах.Чека коррекции вам все равно потребуется вручную внести корректировки в 1С, чтобы отразить правильные остатки товаров, выручку и взаиморасчеты. Это может быть сделано с помощью ручных операций, оприходования/списания товаров, корректировки регистров или других методов, в зависимости от конкретной ситуации.Наиболее надежным и автоматизированным решением, которое устраняет корневую проблему и предотвращает ее повторное появление, является разработка собственного внешнего отчета, обработки или расширения. Как упоминалось в нашей теме, другие пользователи сталкивались с подобной проблемой и создавали такие инструменты.
Принцип работы такой обработки:
Документ.ЧекККМ в 1С, которые находятся в статусе "Не пробит", но при этом содержат данные, указывающие на попытку фискализации (например, заполненные реквизиты, которые обычно заполняются после отправки на ККТ, но до подтверждения статуса).ЧекККМ, которые заполняются только после успешной фискализации (например, НомерЧекаККМ, ДатаЧекаККМ, ФискальныйПризнак).ЧекККМ в 1С.
// Пример концепции кода для обработки
Функция ИсправитьСтатусЧека(СсылкаНаЧек)
// Получаем объект документа ЧекККМ
ОбъектЧек = СсылкаНаЧек.ПолучитьОбъект();
// Проверяем, если чек не проведен и его статус "Не пробит"
Если НЕ ОбъектЧек.Проведен И ОбъектЧек.Статус = Перечисления.СтатусыЧековККМ.НеПробит Тогда
// Здесь должна быть логика получения подтверждения фискализации.
// Например, через API ОФД или проверку определенных полей документа
// (если они заполняются драйвером ККТ, но 1С не успевает их обработать).
// Пример: если у чека уже есть фискальный признак, но он не проведен
Если ЗначениеЗаполнено(ОбъектЧек.ФискальныйПризнак) Тогда
ОбъектЧек.Проведен = Истина;
ОбъектЧек.Статус = Перечисления.СтатусыЧековККМ.Пробит;
Попытка
ОбъектЧек.Записать(РежимЗаписиДокумента.Проведение);
Возврат Истина; // Успешно исправлено
Исключение
Сообщить("Ошибка при проведении чека " + СсылкаНаЧек + ": " + ОписаниеОшибки());
Возврат Ложь;
КонецПопытки;
КонецЕсли;
КонецЕсли;
Возврат Ложь;
КонецФункции
// Пример использования в цикле по 'подозрительным' чекам
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ЧекККМ.Ссылка
|ИЗ
| Документ.ЧекККМ КАК ЧекККМ
|ГДЕ
| НЕ ЧекККМ.Проведен
| И ЧекККМ.Статус = &СтатусНеПробит
| И ЧекККМ.Дата МЕЖДУ &ДатаНачала И &ДатаОкончания"; // Добавьте свои условия отбора
Запрос.УстановитьПараметр("СтатусНеПробит", Перечисления.СтатусыЧековККМ.НеПробит);
// ... установить параметры дат
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
ИсправитьСтатусЧека(Выборка.Ссылка);
КонецЦикла;
Для поля Статус следует использовать значения из перечисления Перечисления.СтатусыЧековККМ.
Разработка такой обработки требует навыков программирования на платформе 1С:Предприятие, но является наиболее гибким и эффективным решением, позволяющим автоматизировать процесс и избежать ручных ошибок. В качестве альтернативного способа восстановления пропущенных продаж можно применить обработку для создания документов отчетов о продажах на основе данных ОФД.
В более свежих версиях 1С:Розница 2.3 (начиная с 2.3.18) были добавлены полезные инструменты, которые могут помочь в диагностике и контроле подобных проблем:
Журнал действий кассиров: Этот журнал позволяет более детально отслеживать операции, выполняемые кассирами, и фиксировать события, связанные с пробитием чеков. Анализируя его, мы можем выявить точный момент сбоя и понять, что предшествовало проблеме.Незавершенные действия с чеком: Этот отчет предназначен для выявления документов ЧекККМ, по которым произошли какие-либо незавершенные операции. Он может стать отправной точкой для поиска "потерянных" чеков, которые требуют ручного вмешательства или программной корректировки.Рекомендуется активно использовать эти инструменты для мониторинга и своевременного выявления проблемных ситуаций, особенно если вы пока не готовы к кардинальным изменениям в инфраструктуре или разработке собственного решения.
Чтобы минимизировать возникновение подобных проблем в будущем, мы можем предпринять ряд превентивных мер:
Проблема, когда чек пробивается и уходит в ОФД, но не регистрируется в 1С:Розница 2.3, является сложной и многогранной, часто коренящейся в нестабильности инфраструктуры и особенностях взаимодействия между компонентами системы. Мы рассмотрели, что это известная недоработка, особенно проявляющаяся при работе файловой базы через веб-сервер. Для ее решения доступны как ручные методы корректировки статусов через стандартные обработки 1С (Групповое изменение реквизитов), так и более сложные, но эффективные подходы, требующие программной доработки (создание собственной обработки/расширения).
При этом мы подчеркиваем важность превентивных мер, направленных на повышение стабильности всей системы, поскольку устранение причин сбоев всегда предпочтительнее борьбы с их последствиями. Применение Чека коррекции является вынужденной мерой для фискальных целей и не решает всех учетных задач.
Выбрав подходящий способ решения и применив профилактические меры, мы сможем добиться стабильной работы РМК и корректного отражения всех операций в 1С:Розница.