Из тридцати четырёх номеров разрешительных документов, которые я взял на проверку, в едином реестре Евразийского экономического союза (ЕАЭС) нашлось пятнадцать. После починки одной ошибки в моём же коде стало восемнадцать. У всех восемнадцати реестр отдал и дату начала, и дату окончания действия, то есть ровно то, ради чего к нему идут.
Это не история успеха. Это история про час работы, который окупает неделю, и про три гипотезы, из которых одна оказалась верной, а я сначала доказал обратное, потому что сломал собственный опыт.
Повод календарный. Карточка товара на маркетплейсе с первого октября становится объектом проверки, и у разрешительного документа начинают иметь значение поля, которые годами заполняли как придётся. Даты действия в первую очередь.
Все замеры ниже сняты 23 сентября 2026 года, на платформе 8.3.27.
Реестр отвечает без регистрации, и это главное
Единый реестр ЕАЭС для человека живёт по адресу tech.eaeunion.org. Под ним лежит открытый JSON-интерфейс, и авторизация ему не нужна: ни ключа, ни токена, ни соглашения.
POST https://tech.eaeunion.org/spd2/find
?collection=kbdallread.service-prop-35_1-conformityDocDetailsType
&limit=1&skip=0
Content-Type: text/plain
{"docId":"ЕАЭС RU С-RU.АЯ46.В.40025/25"}
Номер в примере я взял из самого реестра, чтобы его можно было повторить: действующий сертификат, выдан 10 апреля 2025 года, действует до 9 апреля 2030-го.
Ответ приходит в расширенном JSON: даты лежат внутри объекта с ключом $date, рядом unifiedCountryCode и conformityDocKindCode. Разбор на стороне 1С выглядит так:
Чтение = Новый ЧтениеJSON; Чтение.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку()); Данные = ПрочитатьJSON(Чтение, Истина); Если Данные["matchedDocuments"] > 0 Тогда Документ = Данные["result"][0]; // {"$date":"2025-04-10T00:00:00Z"} - дата лежит уровнем глубже ДатаНачала = Документ["docStartDate"]["$date"]; КонецЕсли;
Ловушек в запросе две, и обе молчаливые.
Первая в заголовке. Тело надо слать как text/plain. Поставите application/json, как подсказывает здравый смысл, получите 415 и ни слова объяснения.
Вторая в теле, и она коварнее:
Соединение = Новый HTTPСоединение("tech.eaeunion.org", 443, , , , 30, Новый ЗащищенноеСоединениеOpenSSL); Путь = "/spd2/find?collection=kbdallread.service-prop-35_1-conformityDocDetailsType" + "&limit=1&skip=0"; Запрос = Новый HTTPЗапрос(Путь); Запрос.Заголовки.Вставить("Content-Type", "text/plain"); // третий параметр обязателен: в режиме совместимости умолчание ставит BOM, // а реестр на теле с BOM отдаёт 500 с пустым телом ответа Запрос.УстановитьТелоИзСтроки("{""docId"":""" + Номер + """}", КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать); Ответ = Соединение.ОтправитьДляОбработки(Запрос);
Про BOM я узнал не из документации. Отправил тело с тремя лишними байтами в начале и получил пятисотый код без единого слова в ответе. Если ваша конфигурация работает в режиме совместимости, умолчание третьего параметра поставит BOM за вас.
Разведка реестра не требует договора, согласования и бюджета: её можно сделать сегодня и узнать, стоит ли браться.
Ноль совпадений означает две разные вещи, и различить их нельзя
Это надо знать до всего остального, иначе замер ниже не имеет смысла.
На корректно оформленный запрос реестр отвечает кодом 200 всегда. И когда документ найден, и когда его нет, и когда вы прислали мусор вместо номера. Разница только в поле matchedDocuments, а ноль в нём означает сразу две вещи: "такого документа у меня нет" и "я не понял, что ты написал".
Проверил на заведомо живом номере:
| Что отправлял | Ответ | Совпадений |
|---|---|---|
| тело в UTF-8 без BOM | 200 | 1 |
| то же тело, но кириллица ужата в один байт на символ | 200 | 0 |
то же тело, кириллица записана escape-последовательностями \uXXXX |
200 | 1 |
| заведомо несуществующий номер | 200 | 0 |
| то же тело с BOM в начале | 500 | - |
заголовок application/json |
415 | - |
Вторая строка и есть ловушка. Номер правильный, документ в реестре лежит, а ответ ничем не отличается от ответа про несуществующий документ. Воспроизводится она просто: возьмите тело в UTF-8 и отбросьте у каждого двухбайтового символа старший байт, именно так его портит любой слой, считающий строку однобайтовой.
Лечится двумя способами. Либо собирать тело байтами явно в UTF-8, либо записывать кириллицу escape-последовательностями: третья строка показывает, что такой вариант реестр понимает.
Отсюда правило для любого замера по этой статье: начинайте с заведомо живого номера. Если он не находится, ломается отправка, и до ваших данных дело ещё не дошло.
Сколько там документов и с какой скоростью
Раскладка снята 23 сентября, каждая строка отдельным запросом.
| Что спрашивал | Найдено |
|---|---|
| всего в коллекции | 8 909 857 |
декларации РФ, номер начинается на ЕАЭС N RU |
6 100 424 |
сертификаты РФ, ЕАЭС RU |
419 437 |
старый формат Таможенного союза (ТС), ТС RU |
318 764 |
Казахстан, ЕАЭС KZ через пробел |
264 593 |
Казахстан, ЕАЭС.KZ. через точку |
10 099 |
Складывать эти строки нельзя: список префиксов неполный, других стран и форматов тут нет вовсе. И числа живут: российские строки за двадцать минут наблюдения подросли на полторы сотни, а закрытые исторические форматы не изменились ни на единицу.
Про скорость, потому что от неё зависит, можно ли ходить в цикле:
| Запрос | Совпадений | Время |
|---|---|---|
точный docId |
1 | 0,4 с |
якорный ^ЕАЭС.KZ. |
10 099 | 0,4 с |
якорный ^ЕАЭС N RU |
6 100 424 | 6,1 с |
неякорный ЕАЭС KZ |
264 593 | 13,7 с |
неякорный ЕАЭС |
8 216 989 | 15,7 с |
Неякорный запрос честно отвечает даже на полном переборе восьми миллионов, но делает это за пятнадцать секунд. В цикле так ходить нельзя, для разведки один раз можно.
Замер: пятнадцать из тридцати четырёх
Выборка небольшая, и я называю это прямо: тридцать четыре номера из рабочих протоколов, не случайный срез справочника. Но для ответа на вопрос "стоит ли писать загрузчик" её хватило.
| Страна документа | Номеров | Нашлось |
|---|---|---|
| Россия | 16 | 8 |
| Казахстан | 11 | 5 |
| Киргизия | 7 | 2 |
| Итого | 34 | 15 |
У всех пятнадцати пришли обе даты. Ни одного случая, когда документ есть, а срок действия пуст, мне не попалось.
Дальше девятнадцать номеров, которые не нашлись, и три версии почему.
Гипотеза первая: номеров такого формата в реестре нет
В моём протоколе прошлого прогона стояла запись: номера определённого формата в едином реестре отсутствуют, потому что живут в национальном реестре своей страны. Убедительно, объясняет наблюдаемое, и я так и записал.
Проверка это опровергла, и причина оказалась не там, где я думал. Реестр держит номера в двух разных написаниях. Через пробел и через точку, и это разные строки в поле docId, поиск по одной форме про вторую не знает.
| Как спрашивал | Найдено |
|---|---|
^ЕАЭС KZ через пробел |
264 593 |
^ЕАЭС\.KZ\. через точку |
10 099 |
Вот по документу каждого вида, оба взяты из самого реестра:
ЕАЭС KZ 02421.05.01.00001 действует 25.11.2021 - 24.11.2026 ЕАЭС.KZ.1110033.24.01.00691 действует 02.05.2018 - 02.05.2019
На отдельно взятом органе это видно резче. У органа 1110033 через пробел не находится ничего, а через точку находятся все семнадцать его документов.
Категорическое "их там нет" было неверным. Прежде чем писать нормализацию номера, посмотрите двумя якорными запросами, сколько написаний у вашей страны в реестре, и только потом решайте, к какому виду приводить.
Гипотеза вторая: значит, дело в написании
Раз написаний два, а мой матчер знал одно, объяснение выглядело найденным. Я переизмерил всю выборку: каждый номер спрашивал дважды, в форме через пробел и в форме через точку.
Через точку не нашлось ни одного номера. Ни единого из тридцати четырёх.
То есть две формы в реестре есть, и знать про них надо, но мои промахи ими не объясняются: этих документов нет в обеих формах. Красивая гипотеза умерла об собственный замер.
Гипотеза третья: латиница в номере. И как я сам сломал этот опыт
Третья версия такая. Номер ЕАЭС набирается двумя алфавитами сразу, и на месте маркерных букв в учётных базах регулярно оказывается латиница: C вместо С, B вместо В. На глаз строка неотличима.
Глазами это подтверждалось: у всех найденных номеров маркер С- был кириллический, а среди промахов попадались C-JP, C-KR, C-CN с латинской C.
Первый опыт дал ноль. Я взял промахи, заменил все буквы-близнецы сначала на кириллические, потом на латинские, спросил реестр и не оживил ни одного номера. Записал гипотезу в опровергнутые.
Опыт был сломан, и сломал его я. Заменяя все буквы-близнецы, я менял их и в приставке ЕАЭС, где стоят Е, А и С. Приставка превращалась в EAЭC с латинскими буквами, и реестр закономерно не находил ничего. Мой опыт проверял не гипотезу, а мою же способность испортить строку.
Переделал: приставку держу кириллической, перебираю все сочетания начертаний только в номерной части. Пятнадцать промахов, семьдесят пять запросов.
Ожило три номера, и все три оказались теми самыми, где я видел латинскую C глазами:
было : ЕАЭС RU C-JP.МЕ10.В.01054/22 (латинская C) стало: ЕАЭС RU С-JP.МЕ10.В.01054/22 (кириллическая С) -> найден
Хит-рейт поднялся с пятнадцати до восемнадцати из тридцати четырёх. Три документа, которые по учётным данным не существовали, оказались живыми, и разница между двумя строками ровно в одной кодовой точке.
Мораль тут не про латиницу. Мораль про то, что опыт, опровергающий гипотезу, надо проверять так же придирчиво, как опыт, её подтверждающий. Отрицательный результат выглядит окончательным и не вызывает желания перепроверить, а стоил он мне трёх документов и одной неверной записи в протоколе.
Что остаётся
После трёх версий шестнадцать номеров из тридцати четырёх так и не нашлись, и объяснения у меня нет. Причины назвать могу: документ выдан национальным органом и в единый реестр не передавался, документ аннулирован и вычищен, номер в базе записан с искажением, которого я не воспроизвёл. Проверять каждую я не стал, её стоимость выше пользы.
Дыра в тексте остаётся, и пусть она лучше будет видна. Закрыть её правдоподобной причиной я мог бы одной фразой, и именно так в протоколе появилась первая гипотеза.
Час на замер против недели на загрузчик
Вот к чему всё сводится практически.
Когда в базе тысячи разрешительных документов с неполными данными, первая мысль инженерная: написать загрузчик. Это нормализация номера, обработка ответов, пагинация, идемпотентность, журнал, обработка отказов. Неделя, если делать прилично.
Замер доли адресуемого занимает час и делается до всего этого:
- Выбрать из базы три-четыре десятка номеров разных форматов. У меня вышло тридцать четыре, и этого уже мало для уверенности, но хватило для решения.
- Привести каждый к форме
docId, по одной строке на формат. - Спросить реестр по точному номеру, последовательно, с паузой в одну-две десятых секунды. Никаких отказов по частоте я на такой скорости не получал.
- Посчитать долю найденных и разрез по странам и форматам.
Дальше решение принимается числом. Нашлось девять из десяти, пишите загрузчик. Нашлась половина, считайте, покрывает ли половина ту боль, ради которой всё затевалось. Нашлись единицы, закройте вкладку.
У меня вышло пятьдесят три процента, и это ровно тот случай, когда решение неочевидно и принимать его должен владелец задачи, потому что разработчик на таком числе скорее увидит интересную работу, чем сомнительную пользу.
Чего в реестре нет и где это искать
Одна оговорка, без которой картина неполная. Реестр отвечает на вопрос "что это за документ и когда он действует". Он не отвечает на вопрос "действует ли он сейчас с точки зрения надзора".
Для российских документов второй вопрос закрыт в типовой конфигурации. В 1С:Управление торговлей 11.5 у справочника СертификатыНоменклатуры есть реквизиты СтатусРосаккредитации, ДатаОбновленияСтатусаРосаккредитации и СсылкаНаСертификатРосаккредитации, а обновляет их регламентное задание ОбновлениеСтатусовСертификатовНоменклатурыРосаккредитации. Источником вендор называет pub.fsa.gov.ru, это описано в информации об обновлении версии 11.5.15.40.
То есть если вам нужен статус, идти в единый реестр незачем, посмотрите сначала в свою конфигурацию. А вот реквизиты срока действия в набор, который обновляет это задание, не входят. За ними я и ходил.
Чем я это делал
Всё описанное это несколько десятков строк на стороне 1С плюс запросы руками. Отдельного инструмента под это у меня нет: разовый замер и не должен быть инструментом, иначе он перестаёт быть дешёвым.
Под соседнюю часть истории, когда документы уже надо возить в карточку товара, инструменты выложены:
- Загрузка сертификатов в OZON из 1С;
- Загрузка сертификатов и деклараций в Яндекс Маркет из 1С;
- Загрузка сертификатов и деклараций в Wildberries из 1С.
Что меняется с первого октября и почему разрешительный документ становится частью карточки, разбирал в статье Платформенная экономика РФ: почему сертификат становится частью карточки товара.
Другие наши инструменты
- Сводная таблица в Excel из 1С без COM - выгрузить результат замера и показать владельцу задачи.
- Анализ кода внешних обработок 1С - посмотреть, что делают обработки, которые ходят наружу с вашими данными.
- Журнал регистрации, свёрнутый для нейросети - разобрать, кто и когда правил справочник сертификатов.
Вопрос
Пятьдесят три процента это выборка в тридцать четыре номера, собранная из того, что попадалось в протоколах. Насколько она показательна, я честно не знаю.
Вопрос к тем, кто ходил в этот реестр со своей базой. Какая доля номеров находится у вас, и от чего она зависит сильнее: от страны выдачи, от года или от органа сертификации? И попадался ли кому-нибудь документ, который в реестре есть, а даты у него пустые?
Вступайте в нашу телеграмм-группу Инфостарт