← На главную

Одной из частых проблем при работе с фискальным оборудованием в 1С:Розница является ошибка формирования чека: «Чек не напечатан на устройстве для печати чеков. ИНН поставщика для предмета расчета не указан». Несмотря на то, что в карточке контрагента все данные заполнены верно, программа может «не видеть» их в момент пробития чека. Давайте вместе разберемся, почему это происходит и как исправить ситуацию, следуя требованиям 54-ФЗ и правилам работы конфигурации.

Понимание причины возникновения ошибки

Суть проблемы заключается в том, что при комиссионной торговле согласно требованиям формата фискальных документов (ФФД), в фискальный пакет данных, отправляемый на кассу (ККТ), обязательно должен быть включен ИНН принципала (поставщика). Ошибка возникает не из-за отсутствия данных в справочнике, а из-за их отсутствия в регистрах или табличных частях документа в момент формирования фискального пакета.

Зачастую, если договор или контрагент были отредактированы уже после того, как товар был оприходован или добавлен в документ реализации, данные «не подтягиваются» автоматически в строки документа. Программа продолжает использовать устаревшие ссылки на данные.

Шаг 1: Проверка настроек договора комиссии

Первым делом проанализируем настройки договора. Часто бывает, что договор был создан как договор купли-продажи, а позже изменен на комиссионный. В таких случаях старые документы «помнят» прежний статус.

1. Откройте карточку договора с контрагентом.
2. Убедитесь, что вид договора установлен в значение Комиссионная продажа.
3. Выполните перезапись договора, чтобы обновить связи в информационной базе.

Шаг 2: Актуализация данных в документе реализации

Если простая перезапись договора не помогла, необходимо «заставить» документ реализации перечитать данные о поставщике. Для этого выполним следующие действия:

• Отмените проведение документа реализации.
• Выполните перевыбор договора в документе, даже если он кажется корректным — это инициирует обновление ссылок на комитента.
• Проверьте, заполнена ли ссылка на документ поступления или партию в строках табличной части документа реализации. Именно оттуда система часто берет информацию о принципале.
• Если данные все еще не подтягиваются, удалите строку с товаром из табличной части и добавьте её заново (через сканирование или подбор). Это гарантирует, что программа подтянет актуальные данные из карточки номенклатуры и контрагента.

Шаг 3: Проверка номенклатуры и видов расчетов

Иногда проблема кроется в самой карточке номенклатуры. Проанализируем настройки:

Убедитесь, что для позиции номенклатуры выбран правильный Вид номенклатуры, который корректно определяет товар как комиссионный. Если признак предмета расчета не установлен верно, система может игнорировать необходимость передачи ИНН, что приведет к конфликту при отправке данных на фискальный накопитель.

Шаг 4: Использование инструментов диагностики

Если вы хотите проверить, заполнено ли поле ИННПоставщикаУслуг (или аналогичные реквизиты, используемые в конкретном релизе 1С:Розницы) на уровне базы данных, воспользуйтесь запросом к объектам метаданных. Разумеется, если запрос показывает, что значение заполнено, но ошибка сохраняется, это подтверждает нашу теорию о том, что данные «застряли» где-то на этапе передачи в драйвер ККТ.

Если штатные методы перевыбора не приносят результата, можно рассмотреть использование групповой обработки для принудительного заполнения реквизита ИННПоставщикаУслуг в объектах, где он оказался пустым. Однако, мы рекомендуем начинать именно с логической цепочки «перевыбора» данных в документах, так как это наиболее безопасный способ для целостности данных.

Алгоритм действий (краткий итог)

1. Проверить вид договора — Комиссионная продажа.
2. Перезаписать договор.
3. Перевыбрать договор и товар непосредственно в документе реализации.
4. Провести документ повторно.

Следуя этим шагам, мы обеспечим корректное попадание данных в фискальный пакет и успешно сформируем чек, соответствующий законодательству. Помните, что последовательность действий — контрагент -> договор -> номенклатура -> документ поступления -> документ реализации — является ключевой для исправления подобных «разрывов» в данных.