Как любой программный продукт, парсер деклараций имеет известные ошибки:
- Пока учитываются только продажи по эскроу (19.7.1.1.x.1)
Причина: иных реализаций требований 214-фз не так много, это не было учтено при реализации. - Парсинг коротких жирных чисел (44 -> 4)
Влияние: на парные числа типа 11,22,33…99.
В следующей редакции парсера влияние будет сокращено до обратного: 4->44, 1…9->11…99 - Парсинг даты декларации до 2021 года.
Причина: дата обновления отсутствует в декларации - Порядок объектов.
Порядок объектов в декларации иногда меняется, пока это не отслеживается. Влияет только на выгрузки с пообъектной разбивкой, на сумму по РД(PERMIT) или иные аггрегации не влияет - Факт сдачи объекта — объект просто пропадает из декларации и из агрегаций, что вызывает отрицательные изменения количественных параметров (пример: кол-во ДДУ 1017 -> 405)
- нечёткие расчёты долей паркинга и нежилой недвижимости (не баг, просто текущих данных недостаточно чтобы достоверно посчитать площади нежилой недвижимости по типам, затрагивает поля с префиксом other_)
В целом баги связаны с тем, что PDF-ки деклараций генерируются так, что автоматизированный их разбор известными средствами специально затруднён(у меня нет других объяснений манипуляциям типа вставки ZWSp каждые несколько символов или прорисовыванию жирного шрифта не как нормальный жирный шрифт, а как наложение одного и того же текста поверх оригинала с минимальным смещением типа “одного пикселя вниз и вправо” [см 4 -> 44 ])
Так как я не пользуюсь “известными средствами” которые можно вот так вот просто поломать, а разбираю чисто примитивы PostScript-а, могу эти грабли убирать программно. грабля с жирным шрифтом — следующая.
Я тут избегаю оценочных суждений зачем и кому нужно усложнять автоматизированный разбор деклараций, просто сообщаю что такое имеет место быть.
Ближайшие изменения
Расчёт показателя “средний метраж” (выглядит несложно: разницу в метрах поделить на разницу в количествах)
Улучшения парсера деклараций.