При работе с контрольно-кассовой техникой (ККТ) АТОЛ FPrint 22 PTK, особенно в связке с системами 1С, пользователи могут сталкиваться с проблемой ограничения на количество позиций в одном чеке — для оптимизации процессов пригодится система автоматизации онлайн-касс АТОЛ. Изначально это может показаться ограничением самой ККТ или программного обеспечения, но при более детальном рассмотрении выясняется, что основная причина кроется в возможностях фискального накопителя (ФН), особенно когда речь идет о маркированных товарах (КМ).
В этой статье мы подробно разберем, что вызывает такое ограничение, как его диагностировать и, самое главное, как реализовать эффективный способ обхода этой особенности посредством доработки конфигурации 1С:Управление торговлей. Для внутренних нужд иногда используют нефискальный чек для УТ 11.4 - 11.5 — для этого есть готовый шаблон нефискального товарного чека с QR-кодом.
Когда мы говорим об ограничении количества позиций в чеке на ККТ АТОЛ FPrint 22 PTK, важно понимать, что это ограничение связано не столько с самим кассовым аппаратом или программой 1С, сколько с возможностями фискального накопителя. Фискальный накопитель, который является сердцем любой современной онлайн-кассы, имеет свои технические лимиты.
Ключевая особенность: Фискальный накопитель допускает включение в один чек не более 128 кодов маркировки (КМ). Это аппаратное или прошивочное ограничение самого ФН, и оно не может быть изменено стандартными средствами или настройками ККТ.
Когда этот лимит превышается, мы можем столкнуться с различными ошибками, которые явно указывают на проблему с маркированными товарами. Вот наиболее распространенные из них:
Эти сообщения являются сигналом того, что система пытается отправить в ФН больше данных, чем он способен принять в рамках одного фискального документа.
Давайте подробнее рассмотрим, почему это ограничение существует. Оно продиктовано не только техническими характеристиками самого фискального накопителя, но и требованиями протоколов информационного обмена между ККТ и ФН. Каждый аспект фискального чека – от наименования товара до его стоимости и кода маркировки – кодируется и передается в ФН для записи.
Протокол информационного обмена: Протокол информационного обмена между контрольно-кассовой техникой (ККТ) и фискальным накопителем имеет максимальный размер данных сообщения в 1536 байт. Этот лимит напрямую влияет на объем информации, которую можно передать в одном фискальном документе. Каждый код маркировки, особенно в формате Data Matrix, занимает значительное количество байт. Когда суммарный объем данных по всем КМ в чеке приближается к этому лимиту или превышает его, ФН отказывается обрабатывать такой документ.
Требования к содержимому чека: Кроме того, существуют строгие требования к содержимому чека, особенно при работе с маркированными товарами. Каждый код маркировки должен быть корректно передан и записан. ФНС (Федеральная налоговая служба) устанавливает общие требования к максимальной длине данных кассового чека (до 32768 байт), однако, как мы видим, для специфических данных, таких как КМ, существуют более строгие внутренние лимиты ФН.
Таким образом, фискальный накопитель просто не может обработать бесконечное количество маркировочных кодов в рамках одной транзакции, что и приводит к возникновению ошибки.
Когда мы сталкиваемся с данной проблемой, система 1С, при попытке пробить чек с большим количеством маркированных товаров, выдаст ошибку. Как правило, эта ошибка будет аналогична той, что была упомянута в обсуждении на форуме: "произошла ошибка проверки средствами ккт по причине перезаполнена таблица хранения КМ".
Очень важно понимать, что это сообщение об ошибке генерируется не самой программой 1С, а поступает от ККТ, которая, в свою очередь, получает его от фискального накопителя. Система 1С лишь транслирует это сообщение пользователю. Поэтому искать решение проблемы на уровне "отключения проверки" в 1С или в настройках кассового аппарата не имеет смысла, так как это ограничение находится на более низком, аппаратном уровне.
Для пользователя это означает, что попытка пробить чек с, например, 150 маркированными товарами, приведет к неудаче и появлению одного из вышеупомянутых сообщений об ошибке.
Для специалистов, которым необходимо внести изменения в логику формирования чека, крайне важно знать, где в конфигурации 1С находится соответствующая процедура. Это позволит нам вмешаться в процесс и реализовать логику обхода ограничения.
В конфигурациях 1С, построенных на Библиотеке Стандартных Подсистем (БСП), таких как 1С:Управление торговлей (УТ) версии 11.5 и выше, функционал работы с подключаемым оборудованием и фискализации чеков централизован. Мы будем искать логику, отвечающую за подготовку данных для фискального регистратора.
Обычно эти процедуры находятся в общих модулях, связанных с подсистемой "ПодключаемоеОборудование". Вот несколько ключевых областей, где стоит искать:
Общие модули "ПодключаемоеОборудованиеКлиентСервер" или "ПодключаемоеОборудованиеМенеджер": В этих модулях содержатся функции и процедуры, которые вызываются для взаимодействия с различными видами подключаемого оборудования, включая ККТ. Именно здесь происходит основная логика подготовки данных и их отправки.
Процедуры, связанные с формированием данных для фискализации: В рамках этих модулей или связанных с ними, мы будем искать процедуры, которые отвечают за формирование структуры данных, передаваемых в ККТ. В контексте обсуждения на форуме упоминалась процедура или команда, отвечающая за "СформироватьXMLПакетДляФискализацияЧека". Хотя это название может быть обобщенным или специфичным для какой-то конкретной реализации, оно указывает на функцию, которая подготавливает "сырые" данные чека в формате, пригодном для передачи на фискальный регистратор. Реальные названия могут быть более детализированными, например, ПолучитьДанныеЧекаККМДляПередачиВФН, ПодготовитьДанныеДляЧекаККМ или ФискализироватьЧек.
Обработчики событий из форм документов: Часто вызов процедур фискализации происходит из обработчиков команд в формах документов, таких как "Чек ККМ" или "Реализация товаров и услуг". Также существуют расширения, позволяющие формировать чеки ККМ из документа реализации напрямую.
Нашей задачей будет найти точное место в коде, где формируется окончательный список маркированных товаров для отправки в один фискальный документ. Именно в этом месте мы и будем внедрять логику по проверке количества КМ и, при необходимости, по разбиению чека.
Учитывая, что ограничение на 128 КМ в одном чеке является аппаратным ограничением фискального накопителя и протокола обмена, "убрать" или "обойти" эту проверку на уровне ККТ или 1С невозможно. Единственный рабочий и подтвержденный практикой способ — это доработка конфигурации 1С таким образом, чтобы при превышении лимита система автоматически разбивала один большой заказ или документ на несколько отдельных фискальных чеков — для этого подойдёт обработка автоматического разделения чека в 1С.
Давайте разберем суть этого решения и концептуальные шаги его реализации:
Почему это единственное решение?
Мы уже установили, что лимит в 128 КМ встроен в логику работы фискального накопителя и протокола обмена. Это означает, что любое сообщение, отправленное в ФН, содержащее более 128 кодов маркировки, будет отклонено. Следовательно, единственный способ успешно пробить все позиции — это отправлять их в ФН порциями, каждая из которых соответствует установленному лимиту. Каждая такая "порция" будет оформлена как отдельный фискальный документ, то есть как отдельный чек.
Суть решения:
Нам необходимо изменить стандартную процедуру формирования чека в 1С. Вместо того чтобы формировать один большой пакет данных для фискализации, мы будем проверять количество маркированных позиций. Если оно превышает допустимый лимит (128 КМ), мы программно разделим исходный список товаров на несколько частей. Каждая такая часть будет содержать количество КМ, не превышающее лимит (например, мы можем установить свой внутренний лимит чуть ниже, скажем, 120 КМ, чтобы иметь небольшой запас). Затем каждый из этих "под-чеков" будет последовательно пробит на ККТ как самостоятельный фискальный документ.
Пошаговая концептуальная реализация:
Определение точки контроля: Нам нужно найти в коде 1С точное место, где формируется список товаров для чека и где происходит добавление кодов маркировки. Как обсуждалось ранее, это, скорее всего, будет в общих модулях, отвечающих за работу с подключаемым оборудованием и фискализацию.
Подсчет КМ: Перед тем как отправить данные на фискальный накопитель, мы должны реализовать логику подсчета общего количества кодов маркировки в текущем чеке или пакете данных, который готовится к фискализации.
Условие разбиения: Если подсчитанное количество КМ в текущем пакете данных превышает установленный нами лимит (например, 120 или 128), мы активируем логику разбиения.
Создание временных списков (или пакетов данных): Мы программно разделим исходный список товаров и их кодов маркировки на несколько подсписков. Каждый подсписок будет представлять собой данные для отдельного фискального чека и будет содержать количество КМ, не превышающее наш установленный лимит.
Цикл фискализации: После того как мы сформировали несколько пакетов данных (под-чеков), мы должны будем в цикле последовательно пробить каждый из них на ККТ. Для каждого под-чека будет выполнен стандартный процесс фискализации, в результате чего он будет зарегистрирован как отдельный фискальный документ.
Обработка ошибок: Важно предусмотреть robustную обработку ошибок для каждого из пробиваемых чеков. Если один из под-чеков не удалось пробить, необходимо информировать пользователя и, возможно, предложить варианты действий (например, повторить попытку или отменить весь процесс).
Такой подход позволит нам успешно оформлять чеки с большим количеством маркированных позиций, соблюдая при этом технические ограничения фискального накопителя.
Рассмотрим примерный алгоритм, как концептуально может выглядеть доработка в конфигурации 1С:Управление торговлей (например, версии 11.5), чтобы реализовать разбиение чека по количеству маркированных позиций.
Как мы уже выяснили, в конфигурациях на БСП это может быть функция или процедура, которая занимается подготовкой XML-пакета для фискализации или структуры данных для драйвера ККТ. Часто этот функционал располагается в обработчиках, вызываемых из модуля формы документа "Чек ККМ" или из общих модулей, таких как ПодключаемоеОборудованиеКлиентСервер или ПодключаемоеОборудованиеМенеджер. Для примера, мы можем искать код в процедурах, которые вызываются при выполнении команды "Пробить чек" или "Закрыть чек". Ключевые точки для анализа:
ПодключаемоеОборудованиеКлиентСервер, ПодключаемоеОборудованиеМенеджер.СформироватьДанныеДляФискализации, ПолучитьПараметрыЧека, ФискализироватьЧек.Конкретно, нам нужно найти точку, где уже сформирована коллекция товаров для чека, и мы можем получить доступ к информации о маркировке.
Внутри найденной процедуры формирования чека, перед тем как отправить данные на фискальный накопитель, мы должны подсчитать количество всех маркированных товаров, которые планируются к включению в текущий чек. Это позволит нам определить, нужно ли разбивать чек.
Предположим, у нас есть структура ДанныеЧека, которая содержит табличную часть с товарами, и в каждой строке товара есть информация о кодах маркировки.
// Пример псевдокода для подсчета КМ в пакете данных чека
Перем КоличествоМаркированныхПозицийВТекущемЧеке;
КоличествоМаркированныхПозицийВТекущемЧеке = 0;
Для Каждого СтрокаТовара Из ДанныеЧека.Товары Цикл // Предположим, ДанныеЧека.Товары - это ТЧ
Если СтрокаТовара.ЭтоМаркированныйТовар И СтрокаТовара.КодыМаркировки.Количество() > 0 Тогда
// Учитываем количество КМ для каждой позиции.
// Если одна позиция может иметь несколько КМ, суммируем их.
// Если считаем КМ по уникальным строкам, то 1.
// В данном случае, ФН считает общее количество КМ
КоличествоМаркированныхПозицийВТекущемЧеке = КоличествоМаркированныхПозицийВТекущемЧеке + СтрокаТовара.КодыМаркировки.Количество();
КонецЕсли;
КонецЦикла;
// Лимит для ФН, обычно 128, но лучше оставить запас
ЛимитКМНаЧек = 120;
Если КоличествоМаркированныхПозицийВТекущемЧеке превышает допустимый ЛимитКМНаЧек, нам нужно будет создать несколько новых объектов чека (или структур данных для чеков) и заполнить их частями исходного списка товаров и кодов маркировки. Каждый новый "под-чек" должен соответствовать ограничениям ФН.
Если КоличествоМаркированныхПозицийВТекущемЧеке > ЛимитКМНаЧек Тогда
СписокЧековДляФискализации = Новый СписокЗначений();
ТекущийПакетДанныхЧека = Новый Структура; // Структура для первого под-чека
// Инициализируем ТекущийПакетДанныхЧека базовыми данными,
// такими как тип чека, кассир, общие реквизиты.
// ТекущийПакетДанныхЧека.Кассир = ДанныеЧека.Кассир;
// ТекущийПакетДанныхЧека.ТипЧека = ДанныеЧека.ТипЧека;
// ... другие общие реквизиты
ТекущийПакетДанныхЧека.Товары = Новый ТаблицаЗначений(); // Табличная часть для товаров под-чека
ТекущийПакетДанныхЧека.КоличествоКМВПакете = 0; // Вспомогательный счетчик КМ для текущего пакета
Для Каждого ИсходнаяСтрокаТовара Из ДанныеЧека.Товары Цикл
КоличествоКМВТекущейСтроке = 0;
Если ИсходнаяСтрокаТовара.ЭтоМаркированныйТовар Тогда
КоличествоКМВТекущейСтроке = ИсходнаяСтрокаТовара.КодыМаркировки.Количество();
КонецЕсли;
// Если добавление текущей строки товара превысит лимит КМ для текущего под-чека
Если ТекущийПакетДанныхЧека.КоличествоКМВПакете + КоличествоКМВТекущейСтроке > ЛимитКМНаЧек Тогда
// Сохраняем текущий, уже заполненный под-чек
Если ТекущийПакетДанныхЧека.Товары.Количество() > 0 Тогда
СписокЧековДляФискализации.Добавить(ТекущийПакетДанныхЧека);
КонецЕсли;
// Создаем новый под-чек
ТекущийПакетДанныхЧека = Новый Структура;
// Переинициализируем его общими реквизитами
// ТекущийПакетДанныхЧека.Кассир = ДанныеЧека.Кассир;
// ТекущийПакетДанныхЧека.ТипЧека = ДанныеЧека.ТипЧека;
// ...
ТекущийПакетДанныхЧека.Товары = Новый ТаблицаЗначений();
ТекущийПакетДанныхЧека.КоличествоКМВПакете = 0;
КонецЕсли;
// Добавляем текущую строку товара в текущий под-чек
НоваяСтрокаТовара = ТекущийПакетДанныхЧека.Товары.Добавить();
ЗаполнитьЗначенияСвойств(НоваяСтрокаТовара, ИсходнаяСтрокаТовара); // Копируем данные строки
ТекущийПакетДанныхЧека.КоличествоКМВПакете = ТекущийПакетДанныхЧека.КоличествоКМВПакете + КоличествоКМВТекущейСтроке;
КонецЦикла;
// Добавляем последний сформированный под-чек, если он не пуст
Если ТекущийПакетДанныхЧека.Товары.Количество() > 0 Тогда
СписокЧековДляФискализации.Добавить(ТекущийПакетДанныхЧека);
КонецЕсли;
// Теперь в цикле пробиваем каждый чек из СпискаЧековДляФискализации
Для Каждого ПодЧекДанные Из СписокЧековДляФискализации Цикл
// Здесь необходимо вызвать функцию или процедуру фискализации для каждого под-чека.
// Например, это может быть вызов метода из общего модуля:
// РезультатФискализации = ПодключаемоеОборудованиеКлиентСервер.ФискализироватьЧек(ПодЧекДанные, ПараметрыПодключенияККТ, ...);
// Обрабатываем результат для каждого чека.
КонецЦикла;
Иначе
// Если количество КМ не превышает лимит, пробиваем исходный чек как обычно
// РезультатФискализации = ПодключаемоеОборудованиеКлиентСервер.ФискализироватьЧек(ДанныеЧека, ПараметрыПодключенияККТ, ...);
КонецЕсли;
Важные моменты при реализации:
Критически важно помнить, что каждый разбитый чек будет являться отдельным фискальным документом со своим порядковым номером. Убедитесь, что такая логика не противоречит внутренним требованиям учета вашего предприятия и действующему законодательству, а также позволяет корректно формировать отчетность.
Рекомендуем проконсультироваться с налоговым специалистом или представителем ОФД, если у вас возникнут вопросы относительно корректности такого подхода с точки зрения фискальных требований.
Мы выяснили, что ограничение на количество маркированных позиций в одном чеке на ККТ АТОЛ FPrint 22 PTK (до 128 КМ) является аппаратным и связано с возможностями фискального накопителя. Это ограничение невозможно обойти путем простых настроек или "отключения проверки".
Единственным эффективным и рабочим способом решения этой проблемы является доработка конфигурации 1С:Управление торговлей. Эта доработка должна заключаться в реализации логики, которая позволяет автоматически разбивать большой чек с множеством маркированных товаров на несколько отдельных фискальных документов, каждый из которых будет содержать допустимое количество КМ — также можно использовать универсальное решение для подключения онлайн-касс с разделением чеков.
Такой подход потребует внесения изменений в модули, отвечающие за фискализацию, но обеспечит бесперебойную работу с маркированными товарами и соблюдение требований законодательства.
Всегда проводите тщательное тестирование доработанного функционала в тестовой среде перед внедрением на рабочем контуре.