[Данни]: Липсващи договори след 2020

[atanasster]

Какъв е проблемът с данните

3. Липсващи договори (процедури от 2020 г. насам) — Засегнати: ~628 договора / ~0,95 млрд. €.
   Примери (в СИГМА няма нито един запис): 00080-2020-0004 (МЗ, ~51,8 млн.), 00197-2020-0005 (ВиК Пловдив, ~41,7 млн.), 01389-2020-0004 (Градски транспорт Варна, ~33,6 млн.).

midt-bot анализ:

3. Липсващи договори — това е поглъщане/нормализация, не дисплей, и не мога да го докажа само от кода (нямам достъп до данните). Но ето къде да гледаш и как да го локализираш:
   served-ът взима само source LIKE 'eop:%' OR 'ocds:%' (normalize-raw.sql ред 271), а authorities-стъпката филтрира authority_eik IS NOT NULL (refresh-slice.sql ред 32).
   Диагностика (ти имаш данните): SELECT * FROM raw_contracts WHERE unp='00080-2020-0004'.
   → ако НЯМА ред → пропуск в източника/дъмпа (тези процедури просто не са в заредения EOP/OCDS export).
   → ако ИМА ред, но липсва в served → нормализацията ги дропва: провери authority_eik (NULL → пада), конструкцията на ключа (c:e:/c:o:) и дедупа. Това казва кое от двете е.

Конкретен пример (адрес / ЕИК / УНП)

00080-2020-0004

Източник за правилната стойност (по желание)

No response

Преди да изпратите

• Потърсих съществуващ issue за същия запис или проблем.

[lyubomir-bozhinov]

От кода не мога да го докажа (нямам достъп до посевните данни), но посочените места са правдоподобни и има конкретна връзка с вече отворен bug.

refresh-slice.sql authorities-стъпката филтрира authority_eik IS NOT NULL, а #196 описва точно това: обявления с authority_eik = списък от няколко ЕИК („000024695; 000261598") се ключат като един несъществуващ възложител (~406 реда) — при split/нормализация такъв ред лесно изпада от served-а. #253 (todorkolev) пренаписва точно тази стъпка: вместо да сече многоЕИК-овите, ги приписва към всеки съвъзложител — тъй че част от липсващите тук може да се възстановят с #253. Струва си да се провери припокриването на двата списъка.

Диагностика (ти имаш данните): преброй source процедурите от 2020+ срещу served-а, групирано по authority_eik LIKE '%; %' и по source NOT LIKE 'eop:%' AND NOT LIKE 'ocds:%', за да разделиш „многоЕИК-сеч" от „source-филтър". Слагам etl, priority: high.

[todorkolev]

Проверихме го сами, защото данните са публични, и намерихме нещо, което променя картинката.

Какво проверихме. Трите примера - 00080-2020-0004, 00197-2020-0005 и 01389-2020-0004 - не се намират нито в кешираното копие на фийда на storage.eop.bg (2357 дни, 2020-01-01 до 2026-06-14), нито в архива от отворените данни на АОП, който пазим локално. Тоест не става дума за запис, който сме взели и после сме изгубили при обработката.

И 2020 е системно тънка година:

Година	Поръчки	Договори
2020	8 302	5 753
2021	19 331	26 426
2022	21 951	31 421

2020 е около 40 на сто от нормална година по поръчки и около 22 на сто по договори. Това не изглежда като случайна липса.

Заключението ни: това е дупка в източника, а не изпускане при нормализацията. ЦАИС ЕОП влиза в сила поетапно през 2020, а по-ранните процедури остават в стария регистър на АОП, който текущият процес не чете.

Защо е важно: предстоящото пресъздаване на базата пуска същото взимане на данни срещу същия източник, тоест ще възпроизведе липсата. Никаква поправка в обработката не връща данни, които ги няма във фийда.

Какво би помогнало най-много: срещу какво ги сравняваш? Ако имаш друг източник, в който тези поръчки ги има - регистърът на АОП, порталът, или собствен набор от данни - това е точно липсващото парче. Ние можем да поправим обработката, но не можем да измислим записи, които не присъстват в източника, който четем. Ако разполагаш с източник, който ги съдържа, кажи ни го и ще направим взимането на данни от него.

И ако е възможно, пълният списък с ~628-те УНП, за да измерим точния обхват.

[atanasster]

Проверих трите примера срещу нашия корпус — и трите ги имаме, със стойности, които съвпадат с вашите до стотинка: 00080-2020-0004 (МЗ, €52,5 млн.), 00197-2020-0005 (ВиК Пловдив, €41,7 млн.), 01389-2020-0004 (Градски транспорт Варна, €33,6 млн.).

Източникът, който ви липсва, е „Регистър на обществените поръчки" (РОП) на АОП — пред-ЦАИС регистърът. При нас той влиза през два отделни канала, като и двата са извън ЦАИС ЕОП фийда, който вие четете:

Източник	Какво е	Договори	УНП	€	Период (подписване)
РОП — годишни CSV	Годишните набори на АОП на data.egov.bg (по един на година)	244 976	62 967	€46,3 млрд.	2000–2025
РОП — досиета	Скрейп на досието на всяка процедура от www.aop.bg (case2.php?mode=show_doc)	20 203	8 989	€3,2 млрд.	2011–2018
ЦАИС ЕОП — flat feed	storage.eop.bg	118 273	54 355	€36,4 млрд.	2020–
ЦАИС ЕОП — OCDS	OCDS releases	20 524	9 115	€12,2 млрд.	2009–

По години кой източник е основен:

• 2000–2019 — РОП на АОП (CSV регистърът е гръбнакът; досиетата добавят CPV и запълване). ЦАИС ЕОП изобщо не покрива тези години.
• 2020 — преходна: РОП CSV (4 951) + начало на ЦАИС eop (1 261). Точно поетапното въвеждане, което описвате.
• 2021–2023 — ЦАИС eop поема, но РОП CSV остава голям (7 953 / 30 325 / 32 606) — това са ретроактивно подписани договори по процедури, отворени преди ЦАИС да стане задължителен.
• 2024–2026 — само ЦАИС (eop + OCDS); регистърът е изчерпан.

Затова липсата не е „тънка 2020 година". Ако четете само ЦАИС ЕОП, при вас липсват:

2000(и 2019), плюс значителен дял от 2021–2023. Като цяло 62 198 УНП от нашия РОП изобщо не се срещат във вашите източници (storage.eop.bg + OCDS) — практически целият пред-ЦАИС регистър, не са само 628 записа, но и много от тях са за пред-2020, които може би не поддържате.

Едно предупреждение, ако решите да запълвате пред-2020 от РОП: 2018 е капан. В годишния CSV на АОП 2018 е почти празна (само 1 487 договора при нас). Реалният обем за 2018 (~19 хил.) съществува само в живите досиета на www.aop.bg (case2.php), които са отделен скрейп — не в годишния CSV. Ако мерите покритие само по CSV-то, 2018 ще изглежда като дупка, каквато не е.

Прилагам CSV с 3 517 УНП (процедури от 2020 г.), които идват от нашия РОП и липсват във вашите източници доколкото проверих — ~9 261 договора / ~€1,60 млрд. Трите ви примера са сред най-големите; най-голямият всъщност е 01467-2020-0037 (ЕРМ Запад / ЧЕЗ, €64,2 млн.). Всеки ред носи и точния source_url на data.egov.bg набора. „628" очевидно е бил частичен резултат от първоначалната ми проверка — възпроизводимата цифра само за 2020 е 3 517 УНП.

sigma-249-legacy-only-2020-unp.csv

[todorkolev]

Проверих каквото е проверимо от обслужваната база. Резултатът сочи празнина в източника, не изпускане при обработката - но едното твърдение не мога да докажа отвън, затова описвам и двете.

Какво излиза на staging:

• трите примера липсват изцяло: нито договор, нито процедура - 0 реда и в contracts, и в tenders за 00080-2020-0004, 00197-2020-0005 и 01389-2020-0004;
• 2020 г. като година я има: 5 753 договора с подписване през 2020.

Тоест не е сляпа дупка по време, а конкретни процедури. Това пасва на документираното в docs/etl.md решение за обхват: СИГМА зарежда единствено отворените данни на ЦАИС ЕОП (storage.eop.bg), а записите от регистъра отпреди ЦАИС съзнателно не се наливат - те са „тънки" и нямат процедурните полета, на които стъпва продуктът (обособени позиции, CPV, прогнозни стойности). 2020 е преходната година, тъй че точно нейни процедури е най-вероятно да попаднат в тази празнина.

Другата хипотеза - че записите са в източника, но нормализацията ги изпуска - не мога да я изключа от обслужваната база: следата (raw_contracts, суровите редове преди нормализация) е преходна и се трие след всеки цикъл. Ще я проверим направо в източника: публичният регистър на ЦАИС за трите процедури, после bucket-ите за датите на публикуване на договорите им. Ако ги няма там, изборът става продуктов - дали исторически backfill от стария регистър влиза в обхвата - и ще се реши изрично, не мълчаливо. Ще докладваме тук.

[todorkolev]

Направих решаващата проверка в самия източник. Отговорът е ясен: трите процедури не са в отворените данни на ЦАИС ЕОП, а нашето зареждане на 2020 г. е пълно.

Какво сканирах

Всички bucket-и на storage.eop.bg ден по ден, само четене:

обхват	дни с данни	записи	намерени от трите
поръчки, цялата 2020	269 от 366	20 529	0
договори, 2020 и 2021	544 от 731	44 087	0

Нито 00080-2020-0004, нито 00197-2020-0005, нито 01389-2020-0004 се срещат където и да е.

Пълно ли е нашето зареждане

Проверих и обратното, за да не остане съмнение, че ги изпускаме ние. Събрах всички различни УНП, които източникът публикува през 2020 г., и ги сверих с базата:

• източникът публикува 8 234 процедури със стандартен УНП за 2020 г.;
• в базата ги има всичките, плюс 68 с УНП от 2020 г., дошли през bucket от друга година.

Отделно квалификационните системи, при които ЦАИС ползва T<номер> вместо стандартен УНП, също са налице (91 такива).

Тоест разминаване няма: каквото ЦАИС публикува за 2020 г., то е у нас. Това е и първата измерена стойност за покритието ни на 2020 г. - досега не бяхме я правили.

Решението

Тези договори съществуват, но не в емисията, която СИГМА чете. Най-вероятното обяснение е описаното в docs/etl.md: поръчки отпреди ЦАИС да стане задължителна вървят по стария ред и не влизат в отворените данни.

Затова това не е дефект в обработката, а въпрос за обхвата - и решението е: засега работим с това, което ЦАИС публикува. Историческото допълване от стария регистър остава като бъдещ отделен проект, с изрична семантика за тези по-бедни записи.

Оставям issue-то отворено - то е мястото, където този бъдещ проект ще се води. Ако имаш връзка към конкретния източник, откъдето си взел трите договора, добави я тук: тя ще е отправната точка, когато се стигне до него.

Отделно си струва границата на покритието да е видима и за читателя, а не само в docs/etl.md - но това е друга работа.

Благодаря за доклада. Заради него имаме и измерено покритие, и ясно решение вместо предположение.