При работе с Системой Управления Заказами (СУЗ) «Честного Знака» на тестовом контуре (песочнице) разработчики часто сталкиваются с неожиданной блокирующей ошибкой: Not enough balance. Ситуация кажется парадоксальной, так как стенд предназначен для тестирования, и реальные денежные расчеты на нем не производятся. В рамках этой статьи мы подробно разберем, почему возникает эта проблема, как устроена логика счетов в СУЗ и что нужно сделать для возобновления работы.
Проанализируем ситуацию. Тестовый стенд markirovka.demo.crpt.tech максимально имитирует поведение промышленной среды (продуктивного контура). Несмотря на то что коды маркировки в песочнице бесплатны, система все равно прогоняет каждый заказ через модуль биллинга. Это необходимо для того, чтобы разработчики могли отладить обработку ответов системы, связанных с финансами.
Разберем основные причины возникновения ошибки:
Рассмотрим основной и фактически единственный надежный способ решения проблемы. Как отмечают опытные участники форума, пополнение баланса демо-стенда происходит исключительно по запросу в службу технической поддержки оператора ЦРПТ.
Для решения проблемы нам необходимо подготовить и отправить официальное письмо. Разберем по шагам процесс взаимодействия с техподдержкой:
1. Сформируйте электронное письмо на адрес support@crpt.ru.
2. В теме письма обязательно укажите: «Пополнение баланса СУЗ (Тестовый стенд / Песочница)». Это ускорит распределение вашей заявки в нужный отдел.
3. В тексте письма необходимо указать следующие данные:
Not enough balance.Важный момент: Техподдержка может отвечать в течение нескольких рабочих дней. Будьте готовы к тому, что вы получите серию автоматических уведомлений (письмо получено, письмо в работе), прежде чем баланс будет фактически изменен.
Иногда ошибка баланса может быть ложной и свидетельствовать о неверных настройках интеграции. Проанализируем ситуацию, когда данные перепутаны. Проверьте следующие параметры в вашей программе (1С или самописном решении):
1. Адреса серверов: Убедитесь, что запросы на получение токена и на заказ кодов уходят именно на *.demo.crpt.tech, а не на основные адреса системы.
2. Соответствие токенов: Часто возникает путаница, когда используется API-ключ от промышленного контура для обращения к тестовому. Система в этом случае может выдать невнятную ошибку, включая сообщение о балансе, так как не находит учетную запись в текущей базе.
3. Идентификатор соединения: Проверьте, что в коде правильно передается заголовок clientToken (или аналогичный в зависимости от версии API), который привязан именно к вашей тестовой СУЗ.
Разберем еще один важный технический аспект, упомянутый в обсуждении: «СУЗ — оперативная система». Это означает, что база данных СУЗ не предназначена для долгосрочного хранения информации о заказах.
Выясним детали:
Посмотрим на пример логики работы с заказами: всегда старайтесь завершать цикл тестирования (Заказ -> Эмиссия -> Получение кодов -> Печать) в рамках одной-двух недель, чтобы не сталкиваться с очисткой данных.
В ходе дискуссии был поднят вопрос о странностях в выборе товарных групп для маркировки, в частности блузок. Рассмотрим текущую ситуацию для разработчиков и бизнес-аналитиков. На ранних этапах список товаров легкой промышленности (ЛП) действительно был узким и включал в себя специфические категории вроде «блузок трикотажных машинного вязания».
Однако проанализируем современные реалии: список товаров ЛП постоянно расширяется. На текущий момент под обязательную маркировку подпадает практически вся одежда (джемперы, юбки, костюмы, платья). Поэтому при тестировании на демо-стенде рекомендуется использовать актуальные коды ТН ВЭД, чтобы убедиться, что ваша система правильно обрабатывает проверку принадлежности товара к категории обязательной маркировки.
Подведем итоги совместной работы над проблемой Not enough balance:
Соблюдение этих рекомендаций позволит вам быстро преодолеть технические барьеры настройки «Честного Знака» и сосредоточиться на логике обмена данными в 1С.