Клиент переходит с 7.7 на КА. Перетащили розничные точки. И вот в одном магазине (патент) вдруг отказался пробиваться самый примитивный чек, без скидок и других нюансов. До этого чека другие чеки пробивались, после этого тоже. Касса Атол 55ф. платформа 2.5, драйвер 10.9.3.1. Номер прошивки сейчас не знаю, но по моему давнишняя. Сделал копию базы и провел эксперименты на примерно аналогичной тестовой кассе FPRINT 22 (переделана умельцами в ККТ онлайн).  Результат тот же. В чеке 3 позиции, опытным путем установил, что чек не пробивается из за одной позиции. Внешне ничем не отличается от других, внимательно изучал карточку номенклатуры, не нашел ничего интересного. Чек не пробивается при любом виде оплаты. Менял наименование товара, подозревая "плохие" символы, но ничего не помогает. Маркировки нет. В логе кассы тоже не
извлек ничего полезного для себя. На финише " Объекту 0x9468C860 присвоен код ошибки 11 [Не поддерживается в данной версии]. Правда очень смущает наличие в логе вот такого фрагмента
LIBFPTR_PARAM_MARKING_CODE (65760) = 34 36 35 37 38 32 31 30 33 30 31 36 35
Откуда он может браться и он ли влияет на проблему. Никаких маркировок не используется. Остается ковырять отладчик, но очень не хочется, может кто сталкивался?

Из 7.7 на этом же драйвере без проблем пробивается

https://rarus.ru/forum/forum7/topic14813/
Сканером считали код маркировки, он передался в кривом виде и пытается пробить с ним

(2)исключено. И сканера нет, и я товар в тестовой базе руками набираю

вот эта позиция из XML пакета, вроде ничего криминального. Никаких кодов

    <Positions>
        <FiscalString Name="Тумба 111" Quantity="1" PriceWithDiscount="14605" AmountWithDiscount="14605" DiscountAmount="0" Department="1" VATRate="none" VATAmount="" PaymentMethod="4" CalculationSubject="1">
            <GoodCodeData EAN13="NDY1NzgyMTAzMDE2NQ=="/>
            <AgentData/>
            <VendorData/>
            <IndustryAttribute/>
        </FiscalString>
    </Positions>
    <Payments Cash="0" ElectronicPayment="14605" PrePayment="0" PostPayment="0" Barter="0"/>
</CheckPackage>

(4) "NDY1NzgyMTAzMDE2NQ==" - это нифига не EAN13
вероятно 1С и интеграционный компонент (ВК) перед драйвером атол воспринимает это как код маркировки и пытается засунуть

(5)+ Хотя 1С делает все правильно
https://its.1c.ru/db/metod8dev/content/4829/hdoc

(6)+ Проблема в интеграционном компоненте (ВК между 1С и драйвером атол)
Он пытается распознать тип кода, видит что не EAN и передает его как "данные от сканера" в драйвер атол

https://integration.atol.ru/api/#zaregistrirovat-pozitsiyu

(5)вот меня он тоже смущает. Но вопрос в том, откуда он его взял. В карточке есть ШК, но нормальный. Но чек про него не знает. Со сканером не работают, там мебель ..ну и попутное

(6)что мне с этим делать?) Типовая КА с несколькими расширениями. Откуда может лезть этот код ?

я верю, что все правильно работает и не вмешиваюсь в этот процесс. Мне надо найти причину и ее отрубить. Интеграционная компонента кстати осталась только для ФФД 1.2

(9) Выяснить отладкой какое место в 1С у тебя преобразует код ШК в base64 и засовывает в GoodCodeData

Это ШК из карточки, значит он кривой. Я его не анализировал )
Щас проверю, заранее огромное спасибо ))) нахера только 1с его потянула в чек)

(11)Спасибо, все ОК. Пробивается )) Жесть)

Тут происходит
Откуда кривые данные подтягивает хз

(14)Откуда - понятно. ШК в РС ШтрихкодыНоменклатуры. Но зачем? Посмотрю, в самом чеке вроде нет ШК

В ТЧ чека есть. Но у пробитого чека там пусто.