- PVSM.RU - https://www.pvsm.ru -
На прошлой неделе мы выпустили статью про устройство ЕГРЮЛ [1] — госреестра с данными 10 миллионов компаний. Тот материал рассказывает о базовых вещах, поэтому начать лучше с него.
Здесь же мы раскроем богатую и благодатную тему — проблемы ЕГРЮЛа, которые не дают нашим разработчикам заскучать.
В 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. А вот и нет!
Обычная ситуация из нашего неидеального мира:
Из года в год пропадает примерно 1000 юрлиц.
Это замечательное ООО засветилось в ЕГРЮЛ единственный раз: в обновлении от 21.02.2017. Больше компании нет нигде, ни в одной полной выгрузке
Поэтому не получится взять полную выгрузку на начало года и применить все обновления до сегодняшнего дня. Извольте начинать с 2015-го, иначе ваш ЕГРЮЛ будет неполным.
Пару раз с 2015 года ФНС внезапно менял xsd. Выглядит это так: приходит обновление, ты пытаешься его разобрать по старому формату, но ничего не получается. Бодрит!
Подстроиться под новую xsd — дело, в общем-то, житейское. Проблема в том, что никто не предупреждает об изменениях. Высший пилотаж — повесить в произвольном разделе на сайте ФНС объявление, но обычно и того нет. Обо всем узнаешь по факту.
Как я говорил в предыдущей статье, филиалы в ЕГРЮЛ — не отдельные записи, это атрибуты юридических лиц. По закону филиалы и представительства не могут существовать сами по себе, поэтому их и хранят в записи основной компании.
Но у наших заказчиков свои нужды: они оказывают филиалам других компаний услуги, подписывают с ними общие документы, в своих учетных системах ведут филиалы как отдельные сущности. Из-за этого мы преобразуем филиалы и представительства из ЕГРЮЛ в отдельные карточки и привязываем к основной записи.
Созданные карточки филиалов нужно идентифицировать. Структура ЕГРЮЛ предусматривает КПП, сокращенное название, полное название и даже название на латинице. Но чтобы было веселее, ФНС гарантированно заполняет только адрес. Как же показывать филиалы, не адреса же выводить.
Типичный пример: у филиалов в выгрузке нет ничего, кроме адреса
Сначала мы все же смотрим в поле с сокращенным названием: вдруг там что-то лежит. В 50% случаев поле и правда не пустое, но даже тогда радоваться рано: название может быть одинаково для всех филиалов юрлица. Как идентификатор это не полезнее пустого поля.
Если название филиала пустое или неуникальное, мы создаем его самостоятельно.
Для примера возьмем все то же ООО «Ромашка». У него три филиала с пустыми названиями и такими адресами:
Мы возьмем те данные о компании, что есть, и превратим их во вменяемое название-идентификатор филиала.
Мы приписываем адрес до уникальной части: для первых двух филиалов «Ромашки» это полный адрес, а для третьего — только «Санкт-Петербург». Будь все города́ разные, добавили бы в названия филиалов только города.
В нашем примере филиалы получатся такие:
Да, если у филиала в ЕГРЮЛ есть название, но неуникальное, первые два мы шага пропускаем. Адресную часть дописываем к этому неуникальному названию.
Адрес для названия мы берем максимум до улицы, потому что с домовой части начинается ад вроде «дмвлд 3, к. 5, пом. 14/51, оф. 145». Разбирать такое сложно, а как часть названия филиала оно выглядит нелепо. Поэтому филиалы, расположенные на одной улице, мы объединяем. Встречаются даже разные филиалы в одном здании! К счастью, таких немного.
Помимо перечисленных проблем в ЕГРЮЛ полно ошибок на уровне символов, адресов и прочих мелочей. Например, когда вместо «ООО» встречаешь в справочнике три ноля — это даже не удивляет.
Попадаются и адреса с ошибками, куда без них. Например, «Ленинград» вместо «Санкт-Петербург» — очень показательный случай. Более приземленный вариант: в адресе организации Железнодорожный Московской области указан как город, хотя он уже несколько лет район Балашихи.
По факту в справочнике все верно, потому что ЕГРЮЛ хранит реквизиты из учредительных документов организации. Но для работы с базой, для поиска по ней данные нужно привести к реальности. Наши пользователи ищут организации, находящиеся в Питере, а не когда-то прописанные в Ленинграде.
Поэтому распарсить ЕГРЮЛ и получить пригодную к промышленной эксплуатации базу — та еще задача. Напомню объемы: если взять полный справочник на начало 2015 года и все обновления до сегодня, получается 100 миллионов записей.
Для парсинга ЕГРЮЛ мы написали алгоритм: на вход он получает все записи с 2015 года, а на выходе дает 10 миллионов актуальных. Справляется где-то за час. Важная часть процесса — это наш продукт «Единый клиент [2]». Он приводит данные в порядок: чистит адреса, находит дубли, исправляет опечатки.
Если нравится парсить сложные справочники, структурировать данные и приводить их к человеческому виду, приходите к нам работать. Сейчас ищем джависта для продукта «Фактор». Зарплата — от 175 000 до 275 000 ₽, подробности — на hh.ru [3].
Автор: DEADStop
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/otkry-ty-e-danny-e/283745
Ссылки в тексте:
[1] статью про устройство ЕГРЮЛ: https://habr.com/company/hflabs/blog/413891/
[2] Единый клиент: https://hflabs.ru/uniform-client/
[3] на hh.ru: https://hh.ru/vacancy/25173248
[4] Источник: https://habr.com/post/414885/?utm_campaign=414885
Нажмите здесь для печати.