Nos ocupamos de errores y "muletas" en el Registro Estatal Unificado de Entidades Legales - el registro estatal de entidades legales

La semana pasada, publicamos un artículo sobre el registro de registros, un registro estatal con datos de 10 millones de empresas. Ese material habla de cosas básicas, por lo que es mejor comenzar con él.

Aquí revelaremos un tema rico y fértil: los problemas del Registro Estatal Unificado de Entidades Legales que evitan que nuestros desarrolladores se aburran.

La estructura XML se rompe periódicamente

En 2017, cada dos o tres meses, las actualizaciones trajeron xmls en el formato incorrecto. Hay un conjunto completo: etiquetas desconocidas, etiquetas abiertas, falta de coincidencia del tipo de datos. Por ejemplo, en xsd se especifica el tipo de fecha, pero de hecho hay una cadena incomprensible.

Cuando esto sucede, queda por escribir al soporte técnico y esperar humildemente. Nada más se puede hacer. Pero debemos admitir que en 2018 no hubo problemas, todo está claro.

Y en la descarga completa para 2015 se encuentra un xml roto, que nunca se solucionará. El Servicio de Impuestos Federales dijo que lo sabían, pero que no tenía la intención de repararlo: tome, dicen, las siguientes actualizaciones.

Las actualizaciones aparecen en carpetas de fechas pasadas

Situación: descargó el libro de referencia completo a principios de 2018, aplicó todas las actualizaciones y las descargó a diario. Estás relajado y sereno, porque sabes: en tu base de datos los datos más relevantes sobre personas jurídicas.

Pero aún se perdió un hecho: anoche el Servicio de Impuestos Federales no solo lanzó la próxima actualización, sino que también puso nuevos archivos en una carpeta hace tres meses. Muy bien, tu base está desactualizada.

Las actualizaciones retroactivas vienen en dos tipos:

• Cambiar archivos existentes
• Añadir nuevos.

Para eliminar algo, no vimos.

Estamos luchando con todo esto aquí. Nuestro directorio local contiene el segmento de datos actual del servidor FTS, el estándar. Todas las noches descargamos absolutamente todos los archivos del servidor de registro y lo comparamos con el estándar.

Encontramos los nuevos archivos claramente cómo: simplemente no existen en el directorio local. Si el archivo era, pero las fechas de su cambio en la referencia y las nuevas bases de datos son diferentes, compare las sumas de verificación. Cuando sean diferentes, tome un nuevo xml-ku y aplique la actualización.

¡Pero hay un matiz! A veces, la información irrelevante viene en la actualización retroactivamente, luego no se puede aplicar. Ahora habrá un ejemplo un poco confuso, mira tus manos.

Supongamos que, el 21 de mayo, se lanzó una actualización para LLC Romashka. Se encuentra en la carpeta 21/06/2018 . Y el 22 de mayo, el Servicio de Impuestos Federales puso un archivo en el directorio el 20/06/2018 , también tenía algo sobre "Daisy". Esto es algo que no tocaremos. Aunque el nuevo archivo es nuevo, su contenido es irrelevante debido a la actualización del 21 de mayo.

Los registros desaparecen entre años

Parece que si toma el archivo 01/01 / 2015_FULL y luego actualiza todas las actualizaciones para 2015, obtendrá datos del 01/01 / 2016_FULL. Y no!

La situación habitual de nuestro mundo imperfecto:

1. Todo el 2016 en el registro no hay nada sobre la empresa. Ni en el archivo completo a principios de año, ni en las actualizaciones.
2. El 01.01.2017_FULL, la compañía aparece de repente y vive en silencio todo el año.
3. Y luego bam - el 01/01/ 2018_FULL no hay compañía otra vez. Con suerte, vendrá más tarde en una de las actualizaciones, pero no es un hecho.

Cerca de 1000 personas jurídicas desaparecen de año en año.


_{Esta maravillosa LLC se iluminó en el Registro Estatal Unificado de Entidades Legales solo una vez: en la actualización del 21.02.2017. No hay compañía en ningún otro lado, ni en una descarga completa}

Por lo tanto, no funcionará realizar una descarga completa a principios de año y aplicar todas las actualizaciones hasta hoy. Comience amablemente a partir de 2015, de lo contrario su registro estará incompleto.

Xsd cambia de repente

Un par de veces desde 2015, el Servicio de Impuestos Federales cambió repentinamente xsd. Se ve así: llega una actualización, intenta analizarla de acuerdo con el formato anterior, pero nada funciona. ¡Vigoriza!

Adaptarse al nuevo xsd es, en general, algo cotidiano. El problema es que nadie está advirtiendo sobre los cambios. Acrobacias aéreas: publique un anuncio en una sección arbitraria en el sitio web del Servicio de Impuestos Federales, pero generalmente no lo es. Aprenderá sobre todo sobre el hecho.

No está claro cómo identificar afiliados.

Como dije en un artículo anterior, las sucursales en la USRLE no son registros separados, son atributos de entidades legales. Por ley, las sucursales y oficinas de representación no pueden existir por sí mismas, por lo que se almacenan en los registros de la empresa principal.

Pero nuestros clientes tienen sus propias necesidades: brindan servicios a sucursales de otras compañías, firman documentos comunes con ellos y mantienen sucursales en sus sistemas de contabilidad como entidades separadas. Debido a esto, transformaremos sucursales y oficinas de representación de USRLE en tarjetas separadas y nos uniremos al registro maestro.

Las tarjetas de afiliado creadas deben identificarse. La estructura USRLE proporciona PPC, un nombre abreviado, nombre completo e incluso el nombre en latín. Pero para hacerlo más divertido, el Servicio de Impuestos Federales está garantizado para completar solo la dirección. Cómo mostrar sucursales, no mostrar direcciones.


_{Un ejemplo típico: las ramas en la descarga no tienen más que una dirección}

Primero, todavía miramos en el campo con un nombre abreviado: de repente, algo yace allí. En el 50% de los casos, el campo realmente no está vacío, pero aun así es demasiado pronto para alegrarse: el nombre puede ser el mismo para todas las sucursales de una entidad jurídica. Como identificador, esto no es más útil que un campo vacío.

Si el nombre de la rama está vacío o no es único, lo creamos nosotros mismos.

Por ejemplo, tomaremos la misma LLC "Camomile". Tiene tres ramas con nombres vacíos y tales direcciones:

• Moscú, Turchaninov Lane;
• Moscú, terraplén Ozerkovskaya;
• San Petersburgo, Nevsky Prospect.

Tomamos los datos de la empresa que son y los convertimos en un identificador de nombre sensato de la sucursal.

1. Agregue la palabra "Sucursal" o "División" en el nombre, se les proporcionaron diferentes atributos en el Registro Estatal Unificado de Entidades Legales.
2. Incluir en el nombre nombre corto de la organización principal. Ahora tenemos tres nombres idénticos "Rama de LLC Romashka".
3. Tomamos las direcciones de las ramas y entre paréntesis agregamos a los nombres las diferentes partes de las direcciones.
   
   Atribuimos la dirección a una parte única: para las dos primeras ramas de “Margaritas”, esta es la dirección completa, y para la tercera, solo “San Petersburgo”. Si todas las ciudades fueran diferentes, agregarían solo ciudades a los nombres de las sucursales.

En nuestro ejemplo, las ramas serán las siguientes:

• "Sucursal de LLC Romashka (Moscú, Turchaninov Lane)";
• "Sucursal de LLC Romashka (Moscú, Ozerkovskaya Embankment)";
• "Sucursal de LLC Romashka (San Petersburgo)".

Sí, si la sucursal en la USRLE tiene un nombre, pero no es único, omitimos los dos primeros pasos. Agregamos la parte de la dirección a este nombre no exclusivo.

Llevamos la dirección del nombre al máximo a la calle, porque el infierno comienza con la parte de la casa como "dmvld 3, building 5, room 14/51, de. 145. " Es difícil de desmontar, pero como parte del nombre de la rama se ve ridículo. Por lo tanto, unimos sucursales ubicadas en la misma calle. ¡Incluso hay diferentes sucursales en el mismo edificio! Afortunadamente hay pocos.

Solo toma y conecta el registro no funciona

Además de estos problemas, el Registro Estatal Unificado de Entidades Legales está lleno de errores a nivel de símbolos, direcciones y otras pequeñeces. Por ejemplo, cuando en lugar de "LLC" encuentra tres ceros en el directorio, esto ni siquiera es sorprendente.

También hay direcciones con errores, sin ellas. Por ejemplo, "Leningrado" en lugar de "San Petersburgo" es un caso muy significativo. Una opción más mundana: la dirección de la organización Zheleznodorozhny en la región de Moscú se indica como una ciudad, aunque ha sido un distrito de Balashikha durante varios años.

De hecho, todo es cierto en el directorio, porque USRLE almacena los detalles de los documentos constitutivos de la organización. Pero para trabajar con la base de datos, para buscar en ella, los datos deben hacerse realidad. Nuestros usuarios buscan organizaciones ubicadas en San Petersburgo, y no una vez registradas en Leningrado.

Por lo tanto, abrir el Registro Estatal Unificado de Entidades Legales y obtener una base adecuada para la operación industrial es otra tarea. Permítame recordarle los volúmenes: si toma el libro de referencia completo a principios de 2015 y todas las actualizaciones hasta hoy, obtendrá 100 millones de entradas.

Para analizar el USRLE, escribimos un algoritmo: recibe todas las entradas en la entrada desde 2015, y en la salida da 10 millones de relevantes. Administra en algún lugar en una hora. Una parte importante del proceso es nuestro producto Single Client . Ordena los datos: limpia direcciones, encuentra duplicados, corrige errores tipográficos.

Si desea analizar libros de referencia complejos, estructurar datos y llevarlos a una forma humana, venga a trabajar con nosotros. Ahora estamos buscando un javista, salario - 195,000-250,000 ₽ antes de la deducción, detalles - en hh.ru. Y también necesita un control de calidad: de 115,000 a 150,000 ₽, detalles sobre el mismo hh .