В процессе работы с конфигурацией 1С:Розница (или другими решениями на базе БСП и БПО) системные администраторы и программисты часто сталкиваются с неприятной ситуацией: в базе появляется документ Чек ККМ, который имеет статус «Пробитый», но при этом у него отсутствуют номер смены, номер чека и он не проведен. При попытке провести такой документ вручную или внести в него изменения система выдает ошибку: «Операции с пробитым чеком запрещены».
В этой статье мы подробно разберем, почему 1С «упирается рогом» в этот запрет, как технически возникает подобная ситуация и как правильно восстановить учет, не нарушая логику программы.
Для начала проанализируем, как происходит процесс пробития чека с точки зрения программного кода. Фискализация чека — это не одномоментное действие, а последовательность шагов, взаимодействующих с внешним оборудованием. Рассмотрим эти этапы:
Перечисления.СтатусыЧековККМ.Пробитый и выполняет метод ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение).Ситуация «пробит, но не заполнен» возникает в момент разрыва между 3-м и 5-м этапами. Если после печати бумажного чека произошел скачок напряжения, обрыв связи по USB/Ethernet или пользователь принудительно закрыл зависшее окно 1С через диспетчер задач, программа не успевает получить ответ от драйвера или записать его в базу. В некоторых случаях статус успевает смениться на «Пробитый», но транзакция проведения прерывается.
Многих пользователей возмущает отсутствие логики: «Если чек пробит, почему нельзя его просто до-провести?». Однако здесь заложена жесткая архитектурная логика, продиктованная требованиями законодательства и целостности данных.
Во-первых, статус «Пробитый» является для системы триггером того, что документ больше не подлежит редактированию. Это защита от случайного изменения состава товаров в чеке, который уже ушел в ОФД. Если бы 1С позволяла редактировать пробитый чек, возникла бы ситуация, когда в базе числится «Хлеб», а в налоговую ушло «Молоко».
Во-вторых, в типовом коде при попытке проведения пробитого чека система может попытаться повторно инициировать команду печати. Чтобы исключить риск «двойной продажи» на фискальном накопителе, разработчики 1С накладывают программный запрет на любые манипуляции с объектом, имеющим статус фискализированного.
Прежде чем исправлять документ, нам нужно убедиться, что он действительно был пробит на кассе. Для этого выполним следующие действия:
Поскольку интерактивно 1С не дает ничего сделать, мы будем использовать программные методы или стандартную обработку «Групповое изменение реквизитов». Рассмотрим алгоритм совместной работы по исправлению ситуации:
Нам необходимо обмануть проверку системы. Для этого через «Групповое изменение реквизитов» (или аналогичную обработку) найдем наш проблемный чек и временно изменим его статус с Пробитый на Чек (пустое значение или статус «К пробитию»).
Теперь, когда документ «разблокирован», откроем его и вручную (или через ту же обработку) внесем данные, которые не успели записаться:
КассоваяСмена).Теперь мы можем провести документ. Поскольку статус у него сейчас не «Пробитый», 1С не будет блокировать проведение. На этом этапе сформируются движения по регистрам:
ТоварыНаСкладах).Продажи).После успешного проведения нам нужно вернуть документу его истинный статус. Снова воспользуемся обработкой изменения реквизитов и установим Статус чека = Пробитый. Это необходимо, чтобы при закрытии смены 1С корректно подтянула этот чек в Отчет о розничных продажах.
Если вы программист и хотите автоматизировать этот процесс или выполнить его через консоль кода, можно использовать следующий фрагмент:
// Выбираем наш проблемный документ по ссылке
ОбъектЧека = СсылкаНаЧек.ПолучитьОбъект();
// Отключаем проверку на пробитый статус, временно изменив его
ОбъектЧека.СтатусЧека = Перечисления.СтатусыЧековККМ.ПустаяСсылка();
ОбъектЧека.Записать(РежимЗаписиДокумента.Запись);
// Заполняем фискальные реквизиты
ОбъектЧека.НомерЧекаККМ = 123; // номер из бумажного чека
ОбъектЧека.КассоваяСмена = НужнаяСмена;
// Проводим документ
ОбъектЧека.Записать(РежимЗаписиДокумента.Проведение);
// Возвращаем статус
ОбъектЧека.СтатусЧека = Перечисления.СтатусыЧековККМ.Пробитый;
ОбъектЧека.Записать(РежимЗаписиДокумента.Запись);
Важный момент: При использовании метода Записать(РежимЗаписиДокумента.Запись) в некоторых конфигурациях все равно могут срабатывать подписки на события или проверки в модуле объекта. В таких случаях может потребоваться установка свойства ОбъектЧека.ОбменДанными.Загрузка = Истина;, чтобы обойти прикладные проверки, однако использовать это нужно с осторожностью, чтобы не нарушить ссылочную целостность.
Чтобы подобные ситуации возникали реже, проанализируем настройки оборудования:
Таким образом, мы выяснили, что «упрямство» 1С — это лишь механизм защиты данных, а исправление ситуации требует четкой последовательности действий: подтверждение фискализации, временный сброс блокирующего статуса и ручная корректировка реквизитов.