Почему в 1С:Розница 2.2 при использовании ЕНВД периодически пробиваются чеки по УСН и как это исправить?

В розничной торговле при совмещении нескольких систем налогообложения (например, УСН и ЕНВД или патентной системы) владельцы магазинов часто сталкиваются с крайне неприятной проблемой. На ККМ периодически пробиваются чеки не с той системой налогообложения (СНО), которая должна быть по умолчанию. Особенно критично это выглядит, когда в программе 1С настроен ЕНВД, но в личном кабинете ОФД вдруг начинают «всплывать» чеки с УСН.

Самое коварное в этой ситуации — бессистемность ошибки. Чек с неверной СНО может пробиться один раз за день или несколько раз в периоды пиковой нагрузки (наплыва клиентов), а при попытке протестировать этот же товар отдельно — СНО определяется корректно. Давайте вместе разберем причины этого технического сбоя, проанализируем архитектуру конфигурации 1С:Розница 2.2 и выработаем пошаговый план решения проблемы.

Причина 1. Особенности архитектуры хранения СНО в 1С:Розница

Выясним, как именно программные механизмы 1С определяют, какую систему налогообложения отправить на фискальный регистратор. В конфигурациях линейки «1С:Розница» данные о налогах хранятся в нескольких связанных регистрах сведений:

1. СистемыНалогообложенияОрганизаций — здесь задается базовая (основная) налоговая система для юридического лица или ИП в целом. По логике разработчиков, в качестве основной СНО может выступать только общая (ОСН) или упрощенная (УСН) система.
2. ВидыОсобыхНалоговОрганизаций — именно этот регистр отвечает за назначение специальных налоговых режимов (таких как ЕНВД или Патент). При этом привязка особого налога осуществляется не к организации напрямую, а к конкретному складу (торговой точке) организации.
3. Регистры распределения продаж и услуг — управляют распределением номенклатуры по товарным группам для правильного разделения продаж между складами.

Если для какого-либо проданного товара в карточке не заполнена «Товарная группа», или для этой группы не настроено корректное распределение продаж по складам, алгоритм 1С не может сопоставить позицию со складом ЕНВД. В таком случае система применяет поведение по умолчанию — обращается к регистру СистемыНалогообложенияОрганизаций и забирает оттуда основную СНО предприятия (в нашем случае — УСН).

Причина 2. Ловушка при копировании документов и персональные настройки

Рассмотрим ситуацию, когда при обычном подборе товаров в РМК чек пробивается корректно (ЕНВД), но при копировании документа или создании нового на основании старого СНО сбивается на УСН. Это происходит из-за механизма заполнения реквизитов по умолчанию.

При стандартном оформлении продажи через интерфейс кассира склад подтягивается жестко из настроек текущего рабочего места ККМ. Однако при копировании документа или оформлении возврата платформа может обратиться к «Персональным настройкам пользователя»:

1. Перейдем в раздел Администрирование — Настройки пользователей и прав — Персональные настройки.
2. Проверим значение в поле «Основной склад» у всех учетных записей кассиров и администраторов.
3. Если там указан основной (управляющий) склад компании, который по умолчанию находится на УСН, то при копировании документа склад в чеке перезапишется. Соответственно, СНО автоматически изменится на УСН. Поле «Основной склад» у розничных продавцов должно либо оставаться пустым, либо содержать строго розничный склад ЕНВД.

Причина 3. Сетевые блокировки файловой базы данных в пиковые часы

Проанализируем крайне важный симптом: почему при переносе базы данных локально на рабочее место кассира (РМК) проблема полностью исчезла, а при работе по сети в файловом режиме она периодически возвращалась? Дело в механизме обработки транзакций и блокировок в файловых СУБД (формат *.1cd).

В моменты пиковой нагрузки, когда несколько пользователей одновременно проводят документы, формируют отчеты или происходит фоновая синхронизация РИБ (распределенной информационной базы), таблицы регистров сведений могут временно блокироваться. При фискализации чека код программы обращается к регистру ВидыОсобыхНалоговОрганизаций. Ниже приведен пример того, как это работает на уровне встроенного языка:

Попытка
    // Запрос к регистру особых налогов для определения ЕНВД/Патента
    ПараметрыСНО = ПолучитьОсобыйНалогСклада(ВыбранныйСклад, ТекущаяДата);
    Если ПараметрыСНО = Неопределено Тогда
        // Особый налог не настроен, используем СНО по умолчанию
        СистемаНалогообложения = ПолучитьОсновнуюСНО(Организация);
    Иначе
        СистемаНалогообложения = ПараметрыСНО.ВидНалога;
    КонецЕсли;
Исключение
    // В случае сетевой блокировки или таймаута программа перехватывает ошибку,
    // чтобы не прерывать обслуживание покупателя на кассе сбоем программы
    СистемаНалогообложения = ПолучитьОсновнуюСНО(Организация);
    ЗаписатьВЖурналРегистрации("Сбой определения СНО из-за блокировки базы. Использован дефолт.");
КонецПопытки;

Если в момент обращения к регистру таблица заблокирована другим процессом по сети, платформа 1С по таймауту может вернуть пустое значение. Конструкция Попытка...Исключение перехватывает это событие, предотвращая аварийное завершение работы кассира, но при этом подставляет базовую СНО из регистра СистемыНалогообложенияОрганизаций — то есть УСН.

Для решения этой проблемы мы рекомендуем отказаться от работы нескольких пользователей с одной сетевой файловой базой. Оптимальный вариант — использовать полноценный режим РИБ, где на каждом РМК развернута своя локальная база данных, а обмены происходят в фоновом режиме по расписанию. Также стоит рассмотреть перенос базы на клиент-серверный вариант (SQL) или ее публикацию на веб-сервере (IIS/Apache).

Причина 4. Кэширование данных драйвером ККТ АТОЛ

Еще одна неочевидная техническая деталь кроется во взаимодействии интеграционной компоненты 1С и драйвера торгового оборудования (особенно часто это проявляется на устаревших интеграционных библиотеках и 9-й версии драйверов АТОЛ):

1. Если из-за кратковременного сбоя кэша или сетевой задержки 1С передает СНО в xml-пакете для ККТ как пустое поле (Null), драйвер не останавливает печать, а применяет СНО по умолчанию.
2. СНО по умолчанию считывается из настроек самой кассы (параметры регистрации ККТ в ФН). Если при регистрации кассы первой СНО была указана УСН, то ККТ применит именно ее.
3. При возникновении микросбоев порта связи ККТ драйвер также может продублировать СНО из предыдущего успешно напечатанного документа.

Чтобы исключить этот фактор, необходимо запустить «Утилиту регистрации ККТ АТОЛ» (без закрытия архива ФН и замены накопителя) и перерегистрировать кассу, установив ЕНВД (или патент) в качестве приоритетной СНО по умолчанию. Также настоятельно рекомендуется обновить драйверы торгового оборудования АТОЛ до стабильной 10-й версии и обновить обработку обслуживания ККТ в самой 1С.

Пошаговый чек-лист для исправления проблемы

Для гарантированного устранения проблемы выполним следующие действия:

1. Проверим номенклатуру: Убедимся, что абсолютно у всех товаров заполнена «Товарная группа».
2. Настроим распределение продаж: Перейдем в настройки распределения продаж и проверим, чтобы все товарные группы для нужного магазина были жестко привязаны к розничному складу, для которого в регистре ВидыОсобыхНалоговОрганизаций задан ЕНВД.
3. Очистим персональные настройки: Проверим справочник пользователей в 1С. Убедимся, что у кассиров в поле «Основной склад» не выбран склад с УСН.
4. Настроим кассовый аппарат: Через тест драйвера ККТ проверим, какая система налогообложения прописана в самой кассе в качестве основной. Сделайте приоритетным ЕНВД.
5. Устраним сетевые задержки: Если база файловая, перенесем ее локально на РМК, настроив обмен по схеме РИБ, либо переведем систему на клиент-серверный режим работы.