Опубликовано: 7 августа 2026 года. Проверено по разъяснениям ФНС 2026 года и руководству программиста FDU.
Ошибку в ставке НДС обнаружили не в одном чеке, а после нескольких дней работы: затронуто 500, 1000 или больше расчетов. Формировать документы вручную долго, а один общий чек на итоговую сумму не дает идентифицировать исходные операции. Разбираем, как собрать реестр, написать программу и провести коррекцию без дублей.
Почему нельзя сделать один чек на общую сумму
В апреле 2026 года ФНС рассмотрела случай, когда организация несколько дней указывала в чеках неправильную систему налогообложения. Вывод службы применим и к массовой ошибке НДС: по ФФД 1.1 и 1.2 каждая корректируемая сумма должна отражаться отдельной строкой. Одной общей суммы недостаточно, потому что она не позволяет идентифицировать конкретные расчеты.
Это меняет архитектуру решения. Программа не должна получать на входе только два числа: «общая ошибочная выручка» и «общий НДС». Нужен реестр исходных фискальных документов с позициями, оплатами и связями.
Сколько новых документов может получиться
Если каждый исходный ошибочный чек принят ФНС и применяется ФФД 1.1/1.2, консервативная инженерная оценка предусматривает обратный и правильный документ для каждого расчета. Это не универсальное правило количества для любой базы, а безопасная оценка нагрузки до анализа данных.
ошибочных чеков
До 1000 новых документов при парной схеме для всех принятых расчетов.
ошибочных чеков
До 2000 новых документов, плюс пилотные проверки и итоговая сверка.
непринятый чек
Обратный документ может не требоваться; статус проверяется отдельно по каждому расчету.
Фактическое число зависит от приема ФНС, ФФД, состава позиций и согласованного способа идентификации. Программа должна уметь рассчитать план после импорта, а не получать заранее заданное число документов.
Шаг 1. Остановите появление новых ошибок
До исправления истории нужно закрыть источник проблемы. Иначе очередь растет, пока специалисты готовят реестр. Проверьте, где именно хранится ставка: в 1С или ДАЛИОН, карточке товара Frontol, налоговой группе, обмене, драйвере или прошивке ККТ.
- Исправлена ставка в учетной системе
- Выполнен обмен с кассовой программой
- Обновлены ПО, драйвер и прошивка
- Сформирован новый обычный тестовый чек
- Документ принят ОФД и ФНС
- Проверены все торговые точки и кассы
Если ошибка связана с переходом на НДС 22% в 2026 году, отдельно проверьте период до установки обновления: ФНС предусмотрела для него специальное исключение. Не включайте такие документы в массовую очередь автоматически.
Шаг 2. Определите точные границы реестра
Задайте период начала и окончания ошибки, список организаций, магазинов и ККТ, затронутые товары или налоговые группы. Затем разделите документы минимум по четырем признакам:
| Признак | Почему важен | Что делает программа |
|---|---|---|
| Статус приема ФНС | Для принятого документа нужна обратная операция, для непринятого она может не требоваться | Создает разные сценарии обработки |
| Версия ФФД | ФФД 1.05 исправляется иначе, чем 1.1/1.2 | Не смешивает документы в одной очереди |
| Дата расчета | Для операции 2025 года в коррекции 2026 года может сохраняться ставка 20% | Применяет историческое правило, а не текущую дату |
| Состав чека | Маркировка, аванс, агент, несколько ставок и возвраты требуют отдельных проверок | Останавливает автоматическую обработку и отправляет строку на ручной разбор |
Шаг 3. Откуда брать данные для 500-1000 чеков
Основной источник — электронная выгрузка ОФД. Она показывает фактически сформированные фискальные документы и их реквизиты. Данные Frontol, 1С или другой учетной системы нужны для проверки того, как расчет должен был выглядеть.
- ОФД: ФН, ФД, ФПД, дата, время, признак расчета, позиции, суммы, НДС, оплаты, статус передачи.
- Кассовая программа: внутренний идентификатор документа, касса, рабочее место, товарные данные и история настройки.
- 1С или ДАЛИОН: правильная ставка, классификация товара, учетная операция и связь с продажей.
- ККТ и драйвер: контроль состояния, поддерживаемых операций и результата фискализации.
Какие поля должны быть в рабочем реестре
| Группа | Минимальные данные | Контроль |
|---|---|---|
| Идентификация | Организация, РН ККТ, ФН, ФД, ФПД, дата и время | Исходный расчет находится однозначно |
| Формат | ФФД, статус приема ФНС, вид документа, признак расчета | Выбран правильный сценарий |
| Позиции | Наименование, количество, цена, сумма, предмет расчета | Нет одной агрегированной суммы |
| Налоги | Ошибочная ставка, правильная ставка, СНО | Ставка подтверждена учетными данными |
| Оплата | Наличные, безналичные, аванс, кредит и итог | Сумма оплат равна сумме документа |
| Особые реквизиты | Маркировка, агент, поставщик, покупатель при наличии | Сложный чек не попал в автоматическую очередь без проверки |
| Результат | ФД и ФПД новых документов, время, статус ОФД, ошибка | Есть полный аудиторский след |
Персональные данные покупателей в рабочем файле маскируются, если они не нужны для фискального сценария. Доступ к выгрузке ограничивается, а перед передачей подрядчику используется обезличенная копия.
Архитектура программы для массовой коррекции
У программы должны быть два физически разделенных режима:
- Dry Run. Читает выгрузку, строит проекты и отчет, но не открывает чек и не обращается к фискальному накопителю.
- Фискализация. Доступен только после подтверждения проекта и запускается для выбранной очереди с журналом каждого действия.
Полезные функции: фильтр по кассе и периоду, лимит пакета, пауза, ручное исключение строки, продолжение с контрольной точки, экспорт ошибок и сравнение итогов до и после.
Почему сначала нужен пилот на нескольких расчетах
Фискальный документ нельзя удалить после записи в ФН. Поэтому первый запуск на всей тысяче чеков недопустим даже при идеальной выгрузке. Выберите несколько разных примеров: простой чек, смешанный чек, документ с возвратом и сложный случай, который программа должна остановить.
Проверка без ККТ
Бухгалтер и инженер сверяют проекты обратного и правильного документов с исходными данными.
Ограниченный пилот
Фискализируются несколько согласованных документов. Для каждого сохраняются ФД и ФПД.
Проверка ОФД и учета
Оба документа должны быть приняты, суммы и налоговые реквизиты сверены, очередь ККТ очищена.
Пакетный запуск
Только после подписанного результата пилота увеличивается размер очереди, например по одной смене или одной кассе.
Как отправлять документы через драйвер без дублей
Руководство программиста FDU прямо предупреждает: ошибка может возникнуть на любом этапе формирования чека. Перед началом следующего документа рекомендуется запросить состояние предыдущего методом GetStatus(). Если чек остался открытым, сначала нужно безопасно завершить или отменить его. Сервисный метод NewDocument() объединяет часть подготовительных действий.
Из этого следуют обязательные правила очереди:
- Одновременно открыт только один документ
- Перед следующим проверяется состояние предыдущего
- Таймаут не считается автоматическим отказом
- Повтор возможен только после проверки ФД и состояния
- Каждая команда и ответ записываются в журнал
- Смена и срок более 24 часов контролируются
- Ошибка бумаги или связи переводит очередь на паузу
- Оператор может безопасно остановить пакет
Старое руководство FDU нельзя использовать как готовую спецификацию современной коррекции: в нем есть ограничения на число позиций и поддержку обратных чеков коррекции для ККТ нового порядка. Перед разработкой проверяют актуальный ДККТ 10, прошивку, модель и поддерживаемые константы API.
Почему нельзя писать напрямую в базу Frontol
Запись строк в таблицы Frontol не создает фискальный документ и может нарушить внутренние связи кассовой программы. Даже если документ появится в журнале программы, это не доказывает запись в ФН и прием ОФД.
Безопасная интеграция использует поддерживаемый механизм:
- обработка 1С готовит и проверяет реестр;
- отдельная Windows-утилита управляет очередью через официальный драйвер;
- Frontol используется через предусмотренный API или штатный импорт, если нужная операция поддерживается;
- для АТОЛ Онлайн применяется его отдельный XML/API-формат, а не команды локальной ККТ.
Выбор варианта делается после аудита контура. Для типовой 1С удобна внешняя обработка, для нескольких кассовых систем — отдельная утилита или сервис. Обзор услуг по таким доработкам есть на странице автоматизации B2C.
Что происходит при обрыве связи
Самая опасная ошибка пакетной программы — считать любой таймаут неуспешной операцией и сразу повторять чек. Команда могла быть выполнена ККТ, а ответ потерялся по USB, сети или RPC. Повтор создаст второй фискальный документ.
У каждой задачи должен быть уникальный идентификатор и состояния: `подготовлена`, `подтверждена`, `отправляется`, `результат неизвестен`, `фискализирована`, `принята ОФД`, `требует проверки`. После неопределенного результата автоматическая очередь останавливается. Программа запрашивает состояние кассы, номер последнего ФД и сверяет журнал.
Каким должен быть итоговый отчет
| Исходный расчет | Обратный документ | Правильный документ | Результат |
|---|---|---|---|
| ФН, ФД, ФПД, дата, сумма | Новый ФД/ФПД, вид, время | Новый ФД/ФПД, правильная ставка | Принят ФНС, сверка успешна |
| Принят ФНС | Создан и принят | Создан и принят | Завершено |
| Не принят ФНС | Не требуется по выбранной схеме | Создан и принят | Завершено после проверки причины отказа |
| Сложный чек | Не отправлен | Не отправлен | Ручная проверка |
| Неопределенный ответ ККТ | Статус уточняется | Не запускается | Очередь остановлена без повтора |
В конце бухгалтер должен видеть не просто количество «успешных» строк, а цепочку каждого расчета. Итоги по суммам, оплатам и ставкам сверяются по кассе, дню и организации. Остаток необработанных строк не скрывается.
Какие чеки нельзя отправлять общей автоматической очередью
- маркированные товары без проверки кода и статуса вывода из оборота;
- авансы, предоплаты, кредиты и последующие полные расчеты;
- агентские схемы и чеки с данными поставщика;
- несколько организаций или систем налогообложения;
- расчеты на границе 2025 и 2026 годов;
- чеки, по которым уже были возвраты или другие коррекции;
- неполные выгрузки без ФПД, позиций или статуса ФНС;
- ККТ с неизвестной версией драйвера и неподтвержденной поддержкой операции.
Такие строки остаются в реестре, но получают статус ручной проверки. Это лучше, чем остановить весь пакет или получить сотни новых некорректных документов.
Можно ли поручить массовую коррекцию ИИ-агенту
ИИ-агент полезен не как автономный кассир, а как технический помощник. Он может разобрать обезличенную выгрузку ОФД, сопоставить поля, найти дубли и пропуски, подготовить реестр, написать черновик обработки 1С или Windows-утилиты, сформировать тесты и итоговый отчет.
Решение о правильной ставке, составе фискального документа и запуске очереди остается за специалистом. Агент сначала анализирует, задает вопросы, готовит Dry Run и показывает риски. Доступ к командам фискализации включается отдельно после проверки пилота.
B2C сделает под ключ
Проверим выгрузку, спроектируем реестр, напишем обработку или программу, подключим официальный драйвер, проведем пилот и подготовим сверку.
Обучим вашу команду
Настроим ИИ-агента и научим программистов или аналитиков решать такие задачи на их конфигурации, данных и внутренних правилах.
Обучение ИИ на реальных задачах 1С включает настройку инструментов, безопасного доступа, проектных правил и проверку самостоятельной работы. Команда получает не готовую «черную коробку», а понимание, как поддерживать решение дальше.
Что нужно для оценки разработки
- Обезличенная выгрузка 3-10 разных чеков
- Описание неправильного и правильного НДС
- Период и примерное число документов
- ОФД и доступный формат экспорта
- Кассовая программа и учетная система
- Модель ККТ, ФФД, драйвер и прошивка
- Наличие маркировки, авансов и агентов
- Количество организаций и торговых точек
На этих данных можно определить: сколько сценариев требуется, подойдет ли обработка 1С, нужен ли отдельный сервис, какая часть реестра автоматизируется и какие строки останутся на ручной разбор.
Разберем реестр до запуска кассы
Пришлите несколько обезличенных чеков и описание ошибки. B2C оценит объем, выделит опасные сценарии и предложит два варианта: разработать решение под ключ или настроить ИИ-агента и обучить вашу команду.
Рассчитать разработку обработкиОбучить команду работе с ИИОфициальные источники
Частые вопросы о массовой коррекции чеков
Для ФФД 1.1 и 1.2 ФНС требует, чтобы каждая корректируемая сумма расчета отражалась отдельной строкой. Одного итогового значения за несколько дней недостаточно, потому что по нему нельзя определить, какие исходные расчеты исправлены.
Поэтому программа хранит каждый первоначальный чек со своими ФН, ФД, ФПД, датой, позициями, ставками и оплатами. Даже если технически несколько строк попадут в один документ, связь с каждым расчетом и его реквизитами не должна теряться.
Для ФФД 1.05 ФНС допускает особую ситуацию с общей суммой только при направлении налоговому органу сведений и документов, достаточных для идентификации каждого расчета. Это не основание упрощать процесс для ФФД 1.1/1.2.
Для первоначальной оценки принятого ФНС чека ФФД 1.1/1.2 закладывают до двух новых документов: обратный с некорректными данными и прямой с правильными. Поэтому 500 чеков могут дать до 1000 документов, а 1000 — до 2000.
Это оценка мощности очереди, а не универсальная норма для любой выгрузки. Часть чеков может быть не принята ФНС, относиться к ФФД 1.05, переходному периоду НДС или требовать ручного сценария. Сначала программа классифицирует реестр и только затем рассчитывает количество.
Итоговый план должен показывать не только число новых документов, но и число исключенных строк, сложных случаев и чеков с неопределенным статусом.
Основным источником является ОФД, потому что там хранится электронный состав фактически сформированного фискального документа и его статус. Нужны ФН, ФД, ФПД, дата, признак расчета, позиции, НДС, оплаты и результат передачи.
Frontol, 1С или ДАЛИОН используются для сопоставления: программа должна понять, какая ставка и какие реквизиты должны были быть переданы. Если данные ОФД и учета расходятся, строка не отправляется автоматически, пока причина не выяснена.
Логи драйвера полезны для диагностики конкретной отправки, но не являются надежной заменой полной выгрузки за период. Они могут быть очищены, содержать технические команды без бизнес-контекста или не включать все реквизиты.
Нет. Строка в базе кассовой программы не равна фискальному документу в ФН. Прямая запись может нарушить ссылки, нумерацию, состояния документов и обмен с товароучетной системой, но при этом не сформировать законный чек.
Фискализация выполняется через поддерживаемый интерфейс: официальный драйвер ККТ, API кассовой программы или штатный формат импорта, если он предусматривает нужную операцию. Для АТОЛ Онлайн используется отдельный облачный API или XML-схема.
Читать данные из БД для диагностики допустимо только в согласованном read-only режиме и после резервной копии. Даже в этом случае источником статуса приема остается ОФД, а не внутренний флаг таблицы.
Нельзя считать любой таймаут отказом и сразу повторять документ. ККТ могла записать чек в ФН, а программа не получила ответ из-за обрыва USB, сети или службы драйвера. Повторная команда тогда создаст дубликат.
Очередь переводит строку в состояние «результат неизвестен» и останавливается. Затем запрашиваются состояние ККТ, открытый чек, номер последнего ФД и данные журнала. Руководство FDU рекомендует перед новым чеком проверять завершение предыдущего через
GetStatus().Продолжение разрешается только после однозначного вывода: документ успешно фискализирован и его реквизиты записаны в реестр либо чек не был создан и повтор безопасен. Неопределенный случай передается оператору.
Некоторые версии драйверов поддерживают электронный режим, при котором документ не печатается на чековой ленте. Например, в руководстве FDU свойство
CheckModeразличает электронный и печатный режимы.Но наличие свойства в документации еще не означает, что его можно безусловно применить на любой ККТ и для любого сценария. Нужно проверить модель, ФФД, прошивку, состав электронного документа и требования к предоставлению чека в конкретном расчете.
В техническом задании режим печати задается явно. Пилот подтверждает, что документ записан в ФН и принят ОФД без бумажной печати. Если поддержка не доказана, программа не должна молча отключать ленту ради экономии.
Выбор зависит от установленного контура, но для современных касс АТОЛ рабочую реализацию нужно сверять с актуальным ДККТ 10 и его API. Там определяются современные типы документов, ставки, реквизиты и поддержка конкретной модели.
Старое руководство FDU полезно для понимания последовательности открытия, регистрации, оплаты, закрытия и проверки состояния. Одновременно оно содержит прежние ставки НДС и ограничения по коррекционным операциям для ККТ нового порядка, поэтому копировать номера свойств без проверки нельзя.
Перед оценкой программы фиксируются версия драйвера, разрядность, способ подключения, модель ККТ, прошивка и ФФД. Затем на стенде проверяются поддерживаемые операции и электронный состав одного документа.
ИИ-агент может выполнить большую подготовительную часть: разобрать обезличенную выгрузку, сопоставить колонки, найти пропуски и дубли, помочь написать обработку, сформировать тест-кейсы и отчет. Это заметно ускоряет проект с большим объемом однотипных данных.
Но агент не должен самостоятельно определять налоговую ставку из названия товара или бесконтрольно запускать фискализацию. Правильные реквизиты подтверждает бухгалтер или ответственный специалист, а инженер проверяет ФФД и возможности драйвера.
Безопасная схема: анализ, вопросы, план, Dry Run, проверка человеком, пилот, сверка ОФД и только затем ограниченная очередь. На обучении B2C команда осваивает именно такой процесс на своих задачах.
Не без предварительной проверки. По каждому коду нужно понимать, что было передано в исходном документе, как он принят ОФД и системой маркировки, были ли возвраты и какой реквизит должен попасть в новые документы.
Универсальная программа обязана распознавать маркированную позицию и переводить ее в ручной или специализированный сценарий. Попытка исправить только НДС, игнорируя код и его статус, может создать повторное выбытие или фиктивный возврат.
После разработки отдельного обработчика такие чеки можно включить в автоматизацию, но они проходят собственный пилот. Результат проверяется не только у ОФД, но и по движению маркировки.
Подготовьте обезличенную выгрузку нескольких разных чеков, описание ошибочного и правильного значения, период, примерное количество документов, название ОФД, кассовой и учетной программы. Нужны также модели ККТ, версии ФФД, драйвера и прошивки.
Отдельно укажите маркировку, авансы, агентские чеки, несколько организаций, системы налогообложения и уже оформленные возвраты. Эти признаки определяют число сценариев и долю строк, которые нельзя отправить общей очередью.
После короткого аудита можно выбрать формат: внешняя обработка 1С, отдельная Windows-утилита, сервис для нескольких касс или интеграция АТОЛ Онлайн. Оценка строится по реальному реестру, а не только по количеству чеков.
Telegram
MAX
Оставить контакт