На прошлой неделе мы выпустили статью про устройство ЕГРЮЛ — госреестра с данными 10 миллионов компаний. Тот материал рассказывает о базовых вещах, поэтому начать лучше с него.
Здесь же мы раскроем богатую и благодатную тему — проблемы ЕГРЮЛа, которые не дают нашим разработчикам заскучать.
Периодически ломается структура xml
В 2017 году раз в два-три месяца обновления приносили xml-ки в неправильном формате. Там полный набор: неизвестные теги, незакрытые теги, несоответствие типов данных. Например, в xsd указан тип date, а по факту лежит непонятная строка.
Когда такое случается, остается писать в техподдержку и смиренно ждать. Больше сделать ничего нельзя. Но надо признать, что в 2018-м проблем пока не было, все четко.
А еще в полной выгрузке за 2015 год лежит битая xml, которую никогда не исправят. ФНС сказали, что знают про нее, но чинить не намерены: берите, мол, следующие обновления.
Обновления появляются в папках давно прошедших дат
Ситуация: ты загрузил полный справочник на начало 2018 года, применил все апдейты и ежедневно накатываешь обновления. Ты расслаблен и безмятежен, потому что знаешь: в твоей базе самые актуальные данные о юрлицах.
Но один факт ты все же упустил: сегодня ночью ФНС не только выпустила очередной апдейт, но и подложила новые файлы в папку трехмесячной давности. Вжух, твоя база неактуальна.
Обновления задним числом бывают двух типов:
- меняют существующие файлы;
- добавляют новые.
Чтобы что-то удаляли, мы не видели.
Боремся со всем этим вот как. В нашей локальной директории лежит актуальный срез данных с сервера ФНС — эталон. Каждую ночь мы скачиваем абсолютно все архивы с сервера ЕГРЮЛ и сравниваем с эталоном.
Новые файлы находим понятно как: в локальной директории их просто нет. Если файл был, но даты его изменения в эталонной и новой базах разные, сравниваем контрольные суммы. Когда и те отличаются, берем новую xml-ку и применяем обновление.
Но есть нюанс! Иногда в обновлении задним числом приходят неактуальная информация, тогда применять его нельзя. Сейчас будет немного запутанный пример, следите за руками.
Допустим, 21 мая вышло обновление для ООО «Ромашка». Оно лежит в папке 21.06.2018. А 22 мая ФНС подложил файл в директорию 20.06.2018, в нем тоже что-то о «Ромашке». Вот это что-то мы не тронем. Хоть новый файл и свежее, его содержание неактуально из-за обновления 21 мая.
Записи пропадают между годами
Казалось бы, если взять архив 01.01.2015_FULL и последовательно накатить все обновления за 2015 год, получишь данные из 01.01.2016_FULL. А вот и нет!
Обычная ситуация из нашего неидеального мира:
- Весь 2016 год в ЕГРЮЛ нет ничего о компании. Ни в полном архиве на начало года, ни в обновлениях.
- В 01.01.2017_FULL компания внезапно появляется и спокойно живет весь год.
- А потом бац — в 01.01.2018_FULL компании снова нет. Если повезет, позже она придет в одном из обновлений, но совершенно не факт.
Из года в год пропадает примерно 1000 юрлиц.
Это замечательное ООО засветилось в ЕГРЮЛ единственный раз: в обновлении от 21.02.2017. Больше компании нет нигде, ни в одной полной выгрузке
Поэтому не получится взять полную выгрузку на начало года и применить все обновления до сегодняшнего дня. Извольте начинать с 2015-го, иначе ваш ЕГРЮЛ будет неполным.
Внезапно меняется xsd
Пару раз с 2015 года ФНС внезапно менял xsd. Выглядит это так: приходит обновление, ты пытаешься его разобрать по старому формату, но ничего не получается. Бодрит!
Подстроиться под новую xsd — дело, в общем-то, житейское. Проблема в том, что никто не предупреждает об изменениях. Высший пилотаж — повесить в произвольном разделе на сайте ФНС объявление, но обычно и того нет. Обо всем узнаешь по факту.
Непонятно, как идентифицировать филиалы
Как я говорил в предыдущей статье, филиалы в ЕГРЮЛ — не отдельные записи, это атрибуты юридических лиц. По закону филиалы и представительства не могут существовать сами по себе, поэтому их и хранят в записи основной компании.
Но у наших заказчиков свои нужды: они оказывают филиалам других компаний услуги, подписывают с ними общие документы, в своих учетных системах ведут филиалы как отдельные сущности. Из-за этого мы преобразуем филиалы и представительства из ЕГРЮЛ в отдельные карточки и привязываем к основной записи.
Созданные карточки филиалов нужно идентифицировать. Структура ЕГРЮЛ предусматривает КПП, сокращенное название, полное название и даже название на латинице. Но чтобы было веселее, ФНС гарантированно заполняет только адрес. Как же показывать филиалы, не адреса же выводить.
Типичный пример: у филиалов в выгрузке нет ничего, кроме адреса
Сначала мы все же смотрим в поле с сокращенным названием: вдруг там что-то лежит. В 50% случаев поле и правда не пустое, но даже тогда радоваться рано: название может быть одинаково для всех филиалов юрлица. Как идентификатор это не полезнее пустого поля.
Если название филиала пустое или неуникальное, мы создаем его самостоятельно.
Для примера возьмем все то же ООО «Ромашка». У него три филиала с пустыми названиями и такими адресами:
- Москва, Турчанинов переулок;
- Москва, Озерковская набережная;
- Санкт-Петербург, Невский проспект.
Мы возьмем те данные о компании, что есть, и превратим их во вменяемое название-идентификатор филиала.
- Добавим в название слово «Филиал» или «Подразделение», в ЕГРЮЛ для них предусмотрели разные атрибуты.
- Включим в название short name основной организации. Теперь у нас три одинаковых названия «Филиал ООО „Ромашка“».
- Возьмем адреса филиалов и в скобках допишем к названиям отличающиеся части адресов.
Мы приписываем адрес до уникальной части: для первых двух филиалов «Ромашки» это полный адрес, а для третьего — только «Санкт-Петербург». Будь все города́ разные, добавили бы в названия филиалов только города.
В нашем примере филиалы получатся такие:
- «Филиал ООО „Ромашка“ (Москва, Турчанинов переулок)»;
- «Филиал ООО „Ромашка“ (Москва, Озерковская набережная)»;
- «Филиал ООО „Ромашка“ (Санкт-Петербург)».
Да, если у филиала в ЕГРЮЛ есть название, но неуникальное, первые два мы шага пропускаем. Адресную часть дописываем к этому неуникальному названию.
Адрес для названия мы берем максимум до улицы, потому что с домовой части начинается ад вроде «дмвлд 3, к. 5, пом. 14/51, оф. 145». Разбирать такое сложно, а как часть названия филиала оно выглядит нелепо. Поэтому филиалы, расположенные на одной улице, мы объединяем. Встречаются даже разные филиалы в одном здании! К счастью, таких немного.
Просто взять и подключить ЕГРЮЛ не выйдет
Помимо перечисленных проблем в ЕГРЮЛ полно ошибок на уровне символов, адресов и прочих мелочей. Например, когда вместо «ООО» встречаешь в справочнике три ноля — это даже не удивляет.
Попадаются и адреса с ошибками, куда без них. Например, «Ленинград» вместо «Санкт-Петербург» — очень показательный случай. Более приземленный вариант: в адресе организации Железнодорожный Московской области указан как город, хотя он уже несколько лет район Балашихи.
По факту в справочнике все верно, потому что ЕГРЮЛ хранит реквизиты из учредительных документов организации. Но для работы с базой, для поиска по ней данные нужно привести к реальности. Наши пользователи ищут организации, находящиеся в Питере, а не когда-то прописанные в Ленинграде.
Поэтому распарсить ЕГРЮЛ и получить пригодную к промышленной эксплуатации базу — та еще задача. Напомню объемы: если взять полный справочник на начало 2015 года и все обновления до сегодня, получается 100 миллионов записей.
Для парсинга ЕГРЮЛ мы написали алгоритм: на вход он получает все записи с 2015 года, а на выходе дает 10 миллионов актуальных. Справляется где-то за час. Важная часть процесса — это наш продукт «Единый клиент». Он приводит данные в порядок: чистит адреса, находит дубли, исправляет опечатки.
Если нравится парсить сложные справочники, структурировать данные и приводить их к человеческому виду, приходите к нам работать. Сейчас ищем джависта для продукта «Фактор». Зарплата — от 175 000 до 275 000 ₽, подробности — на hh.ru.
Автор: DEADStop
