При работе с контрольно-кассовой техникой (ККТ) в программе 1С:Управление торговлей 11 пользователи часто сталкиваются с ошибкой: «Длина реквизита (Кассир) превышает 64 символа». Эта проблема носит не только программный характер, но и жестко регламентирована законодательством. Согласно Приказу ФНС о форматах фискальных документов (ФФД), реквизит «Кассир» (тег 1021) ограничен длиной ровно в 64 символа. Если строка, передаваемая из 1С в драйвер кассы, длиннее хотя бы на один знак, фискальный регистратор (особенно модели АТОЛ) возвращает ошибку и блокирует пробитие чека.
В этой статье мы подробно разберем причины возникновения данной ситуации, проанализируем механизмы формирования данных в 1С и рассмотрим несколько способов решения проблемы — от простых административных до программных правок через расширение конфигурации.
Проанализируем ситуацию: в типовой конфигурации УТ 11 данные для чека собираются из справочника Ответственные лица организаций. Проблема заключается в том, что поле Рабочее наименование в этом справочнике часто используется бухгалтерами для хранения избыточной информации, необходимой для печатных форм счетов-фактур или накладных. Рассмотрим типичный пример содержимого этого поля:
«Иванова Светлана Александровна, кассир, по доверенности №123 от 01.01.2023 от ООО "Торговый Дом Ромашка"»
Длина такой строки значительно превышает допустимые 64 символа. Система пытается передать это «Рабочее наименование» целиком в XML-пакет для драйвера ККТ, что и вызывает ошибку. При этом «ФИО» самого физического лица может быть коротким (например, 25 символов), но 1С приоритетно берет именно строковое представление из регистра сведений ответственных лиц.
Рассмотрим самый простой способ, не требующий программирования. Если для вашей организации не критично иметь длинные подписи в первичных документах, мы можем привести справочник в порядок.
Организации.Ответственные лица.Рабочее наименование оставим только фамилию, имя и должность, например: «Иванова С.А., кассир».Должность для печати, но помните, что алгоритмы формирования чека в разных релизах БПО могут склеивать эти поля.Важный нюанс: Как было отмечено в обсуждении на форуме, иногда ошибка «Неверная длина» возникает даже при коротком имени, если у кассира не хватает прав на чтение справочника должностей. Убедитесь, что у пользователя есть соответствующие права доступа в его профиле.
Если бизнес-процессы требуют сохранения длинного наименования в справочнике, нам придется прибегнуть к разработке расширения. Посмотрим на типичную ошибку начинающих разработчиков: использование процедуры ВыполнитьКоррекциюЗаполненияТэгов. Как показала практика, обрезка в этом месте иногда приводит к ошибке «Неверная длина». Это происходит из-за того, что после функции Лев() в строке могут остаться невидимые символы или нарушиться структура XML.
Проанализируем правильный алгоритм обрезки строки. Нам нужно перехватить формирование параметров чека до того, как они будут упакованы в XML. Оптимальное место для вмешательства — общий модуль МенеджерОборудованияВызовСервера или МенеджерОборудованияУзлы.
Рассмотрим пример кода, который гарантированно очистит строку от лишних пробелов и обрежет её до лимита ФНС:
&После("СформироватьДанныеДляПечатиЧека")
Процедура ОП_СформироватьДанныеДляПечатиЧека(ПараметрыЧека, Результат)
Если ПараметрыЧека.Свойство("Кассир") Тогда
// Используем СокрЛП для удаления лишних пробелов по краям
// и функцию Лев для жесткого ограничения длины
ПараметрыЧека.Кассир = СокрЛП(Лев(ПараметрыЧека.Кассир, 64));
КонецЕсли;
КонецПроцедуры
Почему это работает лучше? Функция СокрЛП убирает пробелы, которые могли появиться в конце после обрезки длинной строки. Для драйверов ККТ (особенно АТОЛ 10.х) наличие пробела в конце строки, если она достигает предела длины, критично.
Более элегантное решение — настроить систему так, чтобы в чек всегда попадало чистое ФИО из справочника ФизическиеЛица, игнорируя «мусор» из рабочего наименования ответственного лица. Разберем, как получить эти данные программно.
Посмотрим на пример функции, которая извлекает ФИО текущего пользователя:
Функция ПолучитьКорректноеИмяКассира(ПользовательСсылка)
ФизЛицо = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(ПользовательСсылка, "ФизическоеЛицо");
Если ЗначениеЗаполнено(ФизЛицо) Тогда
// Получаем ФИО на текущую дату
СтруктураФИО = РегистрыСведений.ФИОФизическихЛиц.СрезПоследних(ТекущаяДата(), Новый Структура("ФизическоеЛицо", ФизЛицо));
Если СтруктураФИО.Количество() > 0 Тогда
Данные = СтруктураФИО[0];
Возврат СокрЛП(Данные.Фамилия + " " + Лев(Данные.Имя, 1) + "." + Лев(Данные.Отчество, 1) + ".");
КонецЕсли;
КонецЕсли;
Возврат "Кассир";
КонецФункции
Используя такой подход, мы получим строку вида «Иванова С.А.», которая гарантированно укладывается в 64 символа и соответствует требованиям проверяющих органов.
Проанализируем технический лог ошибки (из сообщения 36 форума). В нем фигурирует драйвер версии 10.6.2.0. При возникновении ошибки «Неверная длина» важно учитывать Тег 1203 (ИНН кассира). В некоторых версиях БПО, если вы программно меняете поле Кассир, система может «потерять» связанный с ним ИНН. Согласно ФФД 1.05 и выше, ИНН кассира является обязательным реквизитом (если кассир — не ИП). Если строка ФИО обрезана корректно, но ИНН передан в неверном формате или стал пустым, касса также может выдать ошибку «Неверная длина».
Рекомендации при отладке:
СформироватьXMLДляЧека.Символы.ПС), которые при кодировании в UTF-8 могут занимать больше байт, чем кажется на первый взгляд.Таким образом, для стабильной работы необходимо либо жестко ограничить ввод данных в справочнике Ответственные лица организаций, либо внедрить расширение, которое будет принудительно очищать и обрезать поле Кассир перед отправкой команды на пробитие чека. Это обеспечит бесперебойную работу торговой точки и соответствие требованиям ФНС.