В связи с изменениями в законодательстве о применении контрольно-кассовой техники (ФЗ-54), при расчетах между организациями и индивидуальными предпринимателями (сделки B2B) в чеке обязательно должны фигурировать реквизиты покупателя. К ним относятся наименование покупателя (тег 1227) и ИНН покупателя (тег 1228). Без этих данных расчеты по кассе между юрлицами признаются некорректными, что влечет за собой штрафные санкции.
Разработчики часто сталкиваются с ситуацией: в коде 1С все доработки сделаны, в XML-пакет, передаваемый на ККТ, добавлены параметры CustomerINN и CustomerInfo (или CustomerName), данные уходят на драйвер без ошибок, однако на бумажной ленте заветные строки так и не появляются. В этой статье мы подробно разберем, почему «шайтан-машина» игнорирует ИНН контрагента и как заставить ККТ АТОЛ печатать обязательные реквизиты.
Рассмотрим стандартную ситуацию. В процессе отладки перед отправкой XML-пакета на кассу мы видим полностью сформированную структуру, содержащую необходимые теги:
<?xml version="1.0" encoding="UTF-8"?>
<CheckPackage>
<Parameters PaymentType="1" TaxVariant="0" CashierName="Кассирова Кассирша Кассировна" CustomerEmail="" CustomerPhone="" CustomerInfo="ИП Пупкин Василий Васильевич" CustomerINN="650801094561">
<AgentData/>
<PurveyorData/>
</Parameters>
<Positions>
<FiscalString Name="Принято от: ИП Пупкин Василий Васильевич Основание: Реализация товаров и услуг ТЕЦ00073076 от 25.06.19" Quantity="1" PriceWithDiscount="827.5" SumWithDiscount="827.5" DiscountSum="" Department="0" Tax="10" SignMethodCalculation="3" SignCalculationObject="1" TaxSum="75.23"/>
</Positions>
<Payments Cash="827.5" ElectronicPayment="0" Credit="0" AdvancePayment="0" CashProvision="0"/>
</CheckPackage>
Несмотря на то, что параметры CustomerInfo и CustomerINN присутствуют в корневом узле Parameters, ККТ выдает стандартный чек без указания данных покупателя. Выясним основные причины такого поведения оборудования:
Проанализируем шаги, которые необходимо предпринять для устранения этой проблемы.
Для корректного вывода наименования и ИНН покупателя в ККТ АТОЛ (например, модели АТОЛ 55Ф, АТОЛ 22Ф / FPrint-22, АТОЛ 30Ф) необходимо обновить внутреннее программное обеспечение кассы. Прошивка должна быть не ниже версии 7942 (для Платформы 2.5) или осуществлен переход на актуальную Платформу 5.0 (версии прошивок 5.7.х и выше).
Обратите внимание: самостоятельно прошивать кассу без опыта не рекомендуется, так как это может привести к потере лицензий в ККТ. Лучше обратиться к аккредитованному партнеру АТОЛ или в сервисный центр.
Просто установить поверх новую версию ДТО (Тест драйвера ККТ) недостаточно. Старые библиотеки часто остаются зарегистрированными в системе и мешают работе 1С. Выполним полное удаление по шагам:
C:\Program Files\ATOL\ или C:\Program Files (x86)\ATOL\.Перейдем к настройке в самой системе 1С. Очень часто в конфигурациях (особенно сильно переписанных, таких как старые редакции «Управление торговлей 10.3») компоненты интеграции хранятся внутри обработок обслуживания. Для корректной работы нам потребуется:
Atolkkt) до актуальной версии (не ниже 2.9).После обновления драйверов и прошивки вы можете столкнуться со следующей проблемой: из документов «Реализация товаров и услуг» чеки печатаются корректно, а при попытке пробить чек из документа «Приходный кассовый ордер» (ПКО) касса аннулирует чек и возвращает ошибку «Неверная длина».
Выясним причину этой ошибки. Она кроется в особенностях заполнения полей 1С и ограничениях протокола ККТ:
ООО "ТПК Вектор-Снабжение-Запад").Для решения этой проблемы в конфигурациях типа УТ 10.3 требуется обновить релиз до актуального (например, до версии 10.3.54.4 или выше), где алгоритмы формирования XML-пакета для чека были доработаны под требования законодательства. В этих релизах система автоматически обрезает лишние символы наименования покупателя и проверяет валидность строки ИНН. При необходимости можно воспользоваться готовой обработкой обслуживания ККТ АТОЛ на ДТО 10 для УТ 10.3.
Если ваша конфигурация сильно изменена и обновить ее стандартными средствами невозможно, придется внести изменения в код формирования XML вручную. Ниже приведем пример того, как программно очистить ИНН и подготовить данные контрагента перед отправкой в драйвер ККТ.
Рассмотрим функцию очистки строки ИНН от лишних символов:
Функция ОчиститьИННДляККМ(Знач ИсходныйИНН) Экспорт
// Оставляем только цифры
ОчищенныйИНН = "";
Для Позиция = 1 По СтрДлина(ИсходныйИНН) Цикл
Символ = Сред(ИсходныйИНН, Позиция, 1);
Если Найти("0123456789", Символ) > 0 Тогда
ОчищенныйИНН = ОчищенныйИНН + Символ;
КонецЕсли;
КонецЦикла;
// Проверяем корректность длины для ККМ
ДлинаИНН = СтрДлина(ОчищенныйИНН);
Если ДлинаИНН = 10 Или ДлинаИНН = 12 Тогда
Возврат ОчищенныйИНН;
Иначе
// Если ИНН некорректной длины, лучше не передавать его вовсе,
// чтобы избежать блокировки печати чека
Возврат "";
КонецЕсли;
КонецФункции
Также необходимо ограничить длину наименования покупателя, чтобы избежать ошибки превышения длины тега 1227 в ККТ. Посмотрим на пример обработки наименования:
Функция ПодготовитьНаименованиеДляККМ(Знач ИсходноеИмя) Экспорт
// ККТ обычно накладывает ограничение в 256 символов,
// но на старых прошивках лимит может быть жестче (например, 128 или 64 символа)
МаксимальнаяДлина = 120;
ОчищенноеИмя = СокрЛП(ИсходноеИмя);
Если СтрДлина(ОчищенноеИмя) > МаксимальнаяДлина Тогда
ОчищенноеИмя = Лев(ОчищенноеИмя, МаксимальнаяДлина);
КонецЕсли;
Возврат ОчищенноеИмя;
КонецФункции
При интеграции этих функций в общий модуль, отвечающий за формирование XML-пакета чека (например, в модулях работы с торговым оборудованием или обработки ATOLKKT), вы гарантированно избавитесь от ошибок "Неверная длина" и добьетесь стабильной печати реквизитов на чековой ленте.
Дополнительно рекомендуется проверять уходящие чеки через личный кабинет вашего ОФД (Оператора фискальных данных). Если в бумажном виде реквизиты покупателя отсутствуют (например, из-за экономии ленты настройками шаблона самой кассы), но в электронном виде в ОФД передаются теги 1227 и 1228 — закон считается полностью соблюденным, и налоговые органы не будут иметь к вам претензий.