При осуществлении мелкооптовой торговли в конфигурации 1С:Управление торговлей 10.3 пользователи часто сталкиваются со специфической проблемой. Когда чеки ККМ пробиваются не через Рабочее место кассира (РМК), а напрямую из документа Приходный кассовый ордер (ПКО), в печатной форме чека и в отправляемых в ОФД данных начинают фигурировать ФИО и ИНН покупателя. Если покупателем является обычное физическое лицо, вывод этих реквизитов не только избыточен, но и несет в себе серьезные юридические и технические риски.
В этой статье мы подробно разберем, почему возникает данная проблема, чем она грозит торговой организации, и рассмотрим четыре практических способа ее решения — от изменения программного кода до организационных маневров в архитектуре данных.
Перед тем как перейти к техническому решению, давайте проанализируем законодательную базу и риски, связанные с системой маркировки товаров. Согласно требованиям 54-ФЗ, заполнение тега 1227 (Наименование покупателя) и тега 1228 (ИНН покупателя) является обязательным исключительно при расчетах между организациями и/или индивидуальными предпринимателями (B2B-сегмент). При расчете с обычными гражданами (B2C) эти теги должны оставаться пустыми.
Если ваша организация продает товары, подлежащие обязательной маркировке в системе «Честный Знак» (одежда, обувь, текстиль, парфюмерия, вода и т.д.), заполнение этих тегов ведет к критической ошибке:
Поэтому обеспечение «чистоты» чека при работе с физическими лицами — это первоочередная задача автоматизатора торгового предприятия.
Выясним причину такого поведения старой конфигурации. В современных решениях на управляемых формах Библиотека подключаемого оборудования (БПО) автоматически анализирует тип контрагента: если это физлицо, теги отсекаются. Однако в устаревшей УТ 10.3 логика формирования XML-пакета для кассового аппарата устроена проще.
При печати чека из ПКО программа берет данные из реквизита Контрагент. Если поле заполнено, обработка обслуживания ККМ безусловно считывает его наименование и ИНН и передает их в структуру XML-документа для драйвера ККТ. Программа «не задумывается» о том, кем является этот контрагент в системе — юрлицом или обычным человеком.
Давайте рассмотрим, какими способами можно исправить данную проблему.
Если конфигурация у вас уже частично доработана (снята с полной поддержки, но обновляется вручную), внесение нескольких строк кода в общие модули интеграции с торговым оборудованием станет самым простым и надежным решением.
Проанализируем структуру конфигурации. Вся подготовка XML-пакета перед отправкой на фискальный регистратор происходит в общем модуле МенеджерОборудованияВызовСервера (или в модулях интеграции с обработками обслуживания, в зависимости от версии вашей БПО). Нам необходимо перехватить процедуру подготовки xml-данных чека.
Найдем функцию, формирующую xml-строку (например, ПодготовитьДанныеДляПробитияЧека), и добавим условие, проверяющее тип контрагента:
// Вставляем проверку перед конвертацией структуры в XML
Если ДанныеЧека.Свойство("Контрагент") И ЗначениеЗаполнено(ДанныеЧека.Контрагент) Тогда
// Проверяем тип контрагента в информационной базе
Если ДанныеЧека.Контрагент.ЮрФизЛицо = Перечисления.ЮрФизЛицо.ФизЛицо Тогда
// Очищаем реквизиты покупателя для физических лиц
Если ДанныеЧека.Свойство("Покупатель") Тогда
ДанныеЧека.Покупатель = "";
КонецЕсли;
Если ДанныеЧека.Свойство("ИННПокупателя") Тогда
ДанныеЧека.ИННПокупателя = "";
КонецЕсли;
КонецЕсли;
КонецЕсли;
Этот простой блок кода гарантирует, что как только система распознает физическое лицо, теги 1227 и 1228 будут принудительно очищены еще до момента формирования XML-пакета. При этом сама учетная карточка покупателя в ПКО и связанных документах (Заказ, Реализация) останется нетронутой.
Если вы хотите сохранить конфигурацию полностью типовой (для беспрепятственного обновления в будущем), но при этом работаете на современной платформе 1С:Предприятие 8.3, лучшим решением станет использование механизма расширений (.cfe).
Разберем этот метод пошагово:
МенеджерОборудованияВызовСервера.&Перед или &Вместо для процедуры генерации параметров чека.Пример реализации перехвата метода в расширении:
&Перед("СформироватьПакетДокумента")
Процедура Расш1_СформироватьПакетДокумента(ПараметрыОтправки, ДанныеДокумента)
// Проверяем, передан ли контрагент и является ли он физическим лицом
Если ДанныеДокумента.Свойство("Контрагент") И ЗначениеЗаполнено(ДанныеДокумента.Contragent) Тогда
Если ДанныеДокумента.Контрагент.ЮрФизЛицо = ПредопределенноеЗначение("Перечисление.ЮрФизЛицо.ФизЛицо") Тогда
// Удаляем или очищаем свойства, отвечающие за теги 1227 и 1228
ДанныеДокумента.Вставить("Покупатель", "");
ДанныеДокумента.Вставить("ИННПокупателя", "");
КонецЕсли;
КонецЕсли;
КонецProcedurы
Этот метод изящен тем, что основная конфигурация остается на 100% заблокированной для изменений (на «замке»), а вся логика очистки реквизитов инкапсулирована внутри расширения.
Если режим совместимости вашей базы данных не позволяет использовать расширения, а менять конфигурацию категорически запрещено политикой компании, можно прибегнуть к механизму Внешних печатных форм и обработок.
План реализации этого подхода выглядит следующим образом:
Приходный кассовый ордер.МенеджерОборудованияКлиент.ПробитьЧек() внедряем код очистки полей покупателя в структуре параметров.Данный метод требует больше времени на разработку, так как вам придется скопировать значительную часть кода печати чека, однако он абсолютно автономен.
Если у вас нет под рукой программиста 1С, проблему можно решить чисто административным и методологическим путем, изменив схему ведения документооборота.
Давайте рассмотрим, как это сделать:
Контрагенты единого обезличенного контрагента с наименованием «Розничный покупатель». Оставим его ИНН пустым, а тип укажем как «Физическое лицо».Заказ покупателя и Реализация товаров и услуг оформляем на конкретного «любимого» мелкооптовика.Корректировка долга в конце дня или недели, перенося оплату с «Розничного покупателя» на реальное физическое лицо, по которому была отгрузка.Этот путь требует дисциплины от операторов и кассиров, но позволяет обойти технические ограничения старой системы без единой строчки программного кода.
Мы проанализировали проблему вывода ИНН и наименования покупателя в чеках ККТ для УТ 10.3 и предложили несколько путей ее решения. Выбор конкретного метода зависит от технических возможностей вашей платформы 1С и готовности вносить изменения в код: