Для всего этого у нас есть доступ к API статрегистра и ЕГРЮЛа (из сервиса apicrafter.ru), но их много разных на рынке, можете воспользоваться любым. Через них проверяем каждую организацию и заполняем колонки:
- statreg_name - название организации в статрегистре,
- ogrn - код ОГРН
- egrul_name - название организации в ЕГРЮЛ (сокращённое),
- okved_code - код ОКВЭД
- okved_name - наименование основного кода ОКВЭД

На выходе имеем CSV файл где к изначальным колонкам добавлены ещё и эти, собранные в процессе обогащения данных.

Финальные проверки
Есть 2 способа проводить проверки. Для малого объёма данных, делать это вручную, для большого автоматизировано. В нашем случае объём скорее малый, вручную проверяется за пару часов, поэтому можно сделать и то и то.
Коды ИНН уже проверены, поэтому проверять надо остальные 1142 организации (1142 = 1173 всего - 31 с невалидными ИНН).
Далее я пропущу автоматическую проверку названий, она включает чуть более сложные проверки чем корректность кодов ИНН, фактически разбор и нормализация названия организации и я чуть позже опубликую её код. Пока это можно проделать и вручную.
Простейшие проверки:
а) У организации в списке указано что она в юр. форме ОАО или ЗАО, а в ЕГРЮЛе указано что это АО или ООО. Дело в том что юридические формы ОАО и ЗАО более не существуют и организации должны сменить юр. форму в ОАО или ООО по выбору при первом изменении в ЕГРЮЛ.
б) У организации понятная юр. форма ООО или АО, но в ЕГРЮЛе указана другая. Это скорее всего ошибка, неверное название.
в) Название организаций не совпадает полностью. В этом случае пробиваем ЕГРЮЛ на название в из поля названия в списке и ищем ИНН. Если у организации находится ИНН, то это ошибка с указанием другой организации. Если нет, то это ошибка в названии организации.

Всё это проверяем вручную в 2 прохода. В промышленной работе, это обычно, делают специалисты по ручной обработке, которые проверяют после алгоритмов. В данном примере, я описываю то как, примерно, ставится им задача.

Инструментально всё это можно проделать в Excel, LibreOffice, Google Spreadsheets или в OpenRefine. Я считаю что последний удобнее для любых задач преобразования данных (data wrangling), но неудобен для совместной работы нескольких человек проверяющих вручную. Выбор тут есть, и коммерческие решения тоже существуют.

Итоги и выводы

Итого у нас на выходе 20 подобных записей, а вместе с 31 записью с некорректными ИНН это 51 запись с ошибками, что около 4,3% реестра. Много это или мало? Об этом лучше судить тем кто может измерить экономические последствия неверно представленных данных. Например неполучение поддержки организациями имеющими на неё право или получение её теми что не имеют. Это вопрос уже к экономистам, аудиторам и следователям.

Если вдуматься в причины почему такой важный реестр ошибочен на 4,3% то причин тут несколько:
1) Отсутствие культуры работы с данными. Основная и главная причина, поскольку более 27 или 51 ошибки - это ошибки самого базового уровня работы с Excel.
2) Отсутствие проверки и валидации данных на стороне Минэкономразвития, что бы не поступало им на вход, они должны были перепроверить и затребовать исправление.
3) Низкое качество реестров ФОИВов где указаны устаревшие названия организаций и просто наименования с ошибками
4) Более системная проблема, отсутствие регламентов ведения подобных списков именно с точки зрения данных.

Итоговый файл с результатами и конкретными ошибками можно скачать на Data.world [4]

P.S. Этот материал - это заготовка для обучающих материалов по работе с данными. Он очень хорошо помогает в формировании наглядных примеров того как проверять корректность данных и для чего это необходимо. Вскоре на его основе будет Jupiter Notebook или какой-то его аналог где всё уже будет ещё более подробно разобрано.

Ссылки:
[1] https://data.economy.gov.ru/
[2] https://data.economy.gov.ru/system_org.xlsx
[3] https://github.com/datacoon/undatum/blob/master/undatum/validate/ruscodes.py
[4] https://data.world/infoculture/system-orgs-analysis

Comments

Be the first to add a comment