Плагин "Юкасса": ошибка фискализации маркированных товаров по ФФД 1.2 Принято

4

Сейчас в настройках плагина можно выбрать признак предмета расчёта (payment_subject), совместимый и с ФФД 1.05, и с ФФД 1.2 (товар, работа, услуга...). Это работает с ФФД 1.2 до того момента, пока в чеке не появляется маркированный товар.

Для маркированного товара в ФФД 1.2 есть отдельные типы

marked Товар, подлежащий маркировке средством идентификации, имеющим код маркировки, за исключением подакцизного товара (в чеке — ТМ). Пример: обувь, духи, товары легкой промышленности ❌ ✅
non_marked Товар, подлежащий маркировке средством идентификации, не имеющим кода маркировки, за исключением подакцизного товара (в чеке — ТНМ). Пример: меховые изделия ❌ ✅
marked_excise Подакцизный товар, подлежащий маркировке средством идентификации, имеющим код маркировки (в чеке — АТМ). Пример: табак ❌ ✅
non_marked_excise Подакцизный товар, подлежащий маркировке средством идентификации, не имеющим кода маркировки (в чеке — АТНМ). Пример: алкогольная продукция ❌ ✅

Ссылка на документацию ЮКасса

Если в чеке есть такой товар и передан код маркировки, касса (во всяком случае Orange Data) отклоняет запрос ЮКассы на фискализацию платежа (чек «полный расчёт») с ошибкой:

"Если в позиции есть код маркировки - признак предмета расчёта должен быть со значением 31 (АТМ) или 33 (ТМ)"

(31 и 33 это как раз получается из marked / marked_excise, что передаются ЮКассе плагином).

То есть — для товара без маркировки надо отдавать, как сейчас 'commodity' или что настроено. А для товара с маркировкой — 'marked' или 'marked_excise'. 

Для продавцов шуб и меховых шапок ещё будет полезно передавать 'non_marked', но тут уже непонятно — если в чеке есть обычный товар и меховое изделие, как из waOrder получить нужный тип.

Блин. Я опасаюсь, что этот тип надо передавать сразу, даже когда чек уходит, как предоплата, без кода. Но это неточно.

1 комментарий

  • +1
    Syrnik.com Syrnik.com 21 августа 2026 21:39 #

    Я тут изучил код плагина. Это баг чистой воды.

    Плагин знает про "marked", проставляет его для товара, но в строке 1114 делает

    $result += [ ...]

    В отличие от array_merge такое объединение массивов не перезаписывает существующие ключи, а 'payment_subject' уже выставлен десятью строками выше.

    Добавление от claude:

    Строка 1112 — isset заменить !empty 

    if (!empty($item['chestnyznak'])) {

    Это не косметика, а необходимое следствие первого изменения. splitItem() (строки 1052–1063) при count($values) < quantity присваивает недостающим экземплярам пустую строку '', а isset('') истинно. Сегодня баг с += это маскирует; как только payment_subject начнёт перезаписываться, каждый непромаркированный экземпляр
    частично закодированной позиции полетит как payment_subject: marked с пустым mark_code_raw — ЮKassa такой чек отклонит или пробьёт неверно.
    ответить

    Добавить комментарий

    Чтобы добавить комментарий, зарегистрируйтесь или войдите