Skip to content

fix(etl): каноничното име на възложителя (MIN на името) подвежда при споделен ЕИК — поръчки на МОН излизат под училище #194

Description

@todorkolev

Симптом (потребителски сигнал)

Профилът на "БСУ „Д-р Петър Берон" - МОН" показва обществени поръчки за много големи суми (национален достъп до Elsevier / Web of Science, доставки на компютри за ученици, платформата „Дигитална раница", лицензи Microsoft). Това създава впечатление, че възложител е училище, което изглежда невярно.

Първопричина

Възложителите се дедупликират по ЕИК, а изписваното име се избира с MIN(authority_name) в scripts/normalize-raw.sql (редове 47-56):

INSERT OR IGNORE INTO authorities (id, name, bulstat, type)
SELECT 'auth:' || authority_eik, MIN(authority_name), authority_eik, MAX(authority_type)
FROM ( raw_contracts UNION ALL raw_tenders )
GROUP BY authority_eik;

MIN() връща азбучно най-ранния низ. В кирилицата „Б..." (БСУ) се нарежда преди „М..." (Министерство), затова печели училищното съставно име, а не името на министерството.

Доказателства (проверени срещу обслужващата база)

  • ЕИК 000695114 е реалният ЕИК на Министерството на образованието и науката.
  • Под този ЕИК в изходните данни съществуват три варианта на името: МИНИСТЕРСТВО НА ОБРАЗОВАНИЕТО И НАУКАТА (доминиращ, 620 договорни реда / 444 реда обявления), БСУ „Д-Р ПЕТЪР БЕРОН", Прага и съставното БСУ „Д-Р ПЕТЪР БЕРОН" - МИНИСТЕРСТВО НА ОБРАЗОВАНИЕТО И НАУКАТА.
  • Профил auth:000695114: 285 договора, 295 946 730 EUR (SUM amount_eur), 272 обявления. Най-големите пера са безспорно министерски: 32.2M EUR устройства с Windows за ученици, 18.0M + 11.6M + 6.4M EUR национален достъп до Elsevier / Web of Science, 17.0M EUR Chromebook-програма, 13.2M EUR „Дигитална раница", 9.3M EUR лицензи Microsoft.
  • Единственото истинско училищно перо е ремонт на санитарен възел в Прага за ~148k лв.
  • БСУ „Д-р Петър Берон" (Прага) е второстепенен разпоредител към МОН и работи под неговия ЕИК - няма собствен ЕИК.

Класификация

Дефект в избора на изписваното име върху реалност на споделен ЕИК. Договорите са коректно свързани с ЕИК-а на МОН - обединяването е правилно (едно юридическо лице). Не е сгрешен ЕИК в изходните данни и не е визуален проблем на клиента.

Предложения за корекция (с компромиси)

  1. Каноничното име по „най-често срещано" (mode), не по MIN(). За този случай избира „МИНИСТЕРСТВО НА ОБРАЗОВАНИЕТО И НАУКАТА" (620 реда) вместо съставното. Евтино. Недостатък: mode може да улучи вариант само с главни букви - трябва тайбрек (напр. предпочитане на смесен регистър / най-скорошния).
  2. Предпочитане на официалното име от Търговския регистър / административния регистър при съвпадение по ЕИК. Най-качествено и авторитетно. Недостатък: бюджетни органи като МОН може да липсват в tr-companies - нужно е picване от административен регистър.
  3. Показване на вариантите на името в профила („записан също като..."). Ниско-рисково и прозрачно, но само по себе си не оправя заглавието.
  4. Разделяне на второстепенните разпоредители в под-профили под ЕИК-а на родителя (Прага срещу централно МОН). Най-вярно, но иска ключ за разпоредител отвъд ЕИК; училището в чужбина легитимно няма собствен ЕИК.

Бележка за адресите: слъговете на възложителите/фирмите се ключат по ЕИК (packages/db/src/queries/identity.ts), затова опции 1-3 сменят само надписа, не адреса (URL остава стабилен).

Свързани

Activity

  1. added
    bugНещо не работи
    data-qualityКачество/коректност на данните (ETL, регистри)
    etlОбласт: etl
    priority: highВисок приоритет
    on Jul 3, 2026
  2. todorkolev commented on Jul 3, 2026

    @todorkolev
    CollaboratorAuthor

    Придружаващи issue-та от същия потребителски сигнал: #195 (eik_valid без контролна сума -> обединени изпълнители) и #196 (многоЕИК-ови редове възложители).

  3. lyubomir-bozhinov commented on Jul 5, 2026

    @lyubomir-bozhinov
    Collaborator

    Двата PR-а решават #194, но и двата са на един и същ branch fix/authority-canonical-name (от различни fork-ове) → ще се конфликтнат по normalize-raw.sql + refresh-slice.sql; само единият може да влезе. Проверено локално:

    Материалната разлика не е посоката на tie-break (по-късо хваща абревиатури като „МОН", по-дълго хваща съставни „дете–родител" имена — нито едното не е универсално вярно), а че само #215 има курирания override — детерминистичен изход при мода-на-типо/дрейф за бюджетните тела (които ги няма в ТР). Това е решаващото за #194.

    Предложение: за самото #194 — #215 (обхватен, override, ADR); #203 да влезе само след като #195/#196 се извадят в отделни PR-и (променят authority/bidder агрегати — извън обхвата на #194). Изборът е на @todorkolev.

  4. lyubomir-bozhinov commented on Jul 16, 2026

    @lyubomir-bozhinov
    Collaborator

    Триаж: адресира се от два PR-а — #203 (@StanislavBG, „Fixes #194", покрива и #195/ЕИК checksum) и #215 (@cefothe, „Closes #194", каноничното име по frequency-mode). И двата ще затворят #194 при merge и се припокриват по каноничното име на възложителя. Нужно е решение кой води и в какъв ред се merge-ват, за да не се дублира логиката.

  5. todorkolev commented on Jul 28, 2026

    @todorkolev
    CollaboratorAuthor

    Затворено от PR #251 (merged 2026-07-23) - каноничното име и видът на възложителя вече се избират по честотна мода, а не с MIN()/MAX().

    scripts/normalize-raw.sql гради authority_canonical_name и authority_canonical_type с прозоречен CTE над броя срещания, с детерминирани tie-break-ове. За ЕИК 000695114 модата (620 договорни реда) избира МОН преди какъвто и да е tie-break; ключът auth:ЕИК е непокътнат, така че адресите не мърдат.

    Работата дойде през разделянето на #203 на фокусирани PR-и; #215 на @cefothe покриваше същото и е затворен в полза на този път.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugНещо не работиdata-qualityКачество/коректност на данните (ETL, регистри)etlОбласт: etlpriority: highВисок приоритет

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions