Податочна основа
за целиот SAMIS.

Верзија 1.0 • 02 ноември 2026 • Основа за SRS и SDD

Што е испорачано

Овој пакет ја дефинира релационата основа на SAMIS за деветте модули SAM01–SAM09 и заедничките функции. Содржи физички модел со 178 табели, 2.139 колони, 506 експлицитни декларации за надворешни клучеви, SQL миграции, контроли на интегритет, почетни каталози, работни текови, матрица на улоги, интеграциски договори, ER дијаграми, оперативен план и тестови. Броевите се добиени од генерираниот модел, а не се цел на дизајнот сами по себе.

Дизајнот ги опфаќа идентификуваните барања од четирите приложени документи и ја користи претходната SAMIS анализа од 02 ноември 2026 како контекст. Не претставува тврдење за завршена продукциска имплементација или за договорно потврдена стопроцентна усогласеност. Документите самите бараат одобрени SRS и SDD; не утврдуваат точни правни прагови, сите рокови, API договори, правила за кворум и архивски рокови. Тие точки се моделирани како конфигурација и се издвоени за потврда.

SQL може да создаде празна база. Runtime улогата е намерно ограничена на читање: продукциските командни сервиси со авторизација, потпишување и workflow предуслови треба да се имплементираат според оваа спецификација пред да добијат права за запишување. Ова е испорака на дизајн и референтна DDL основа, не готов SAMIS backend.

Извори и правила на толкување

Локаторите P0001 и понатаму се редни броеви на Word параграфите во XML редослед, вклучувајќи ги параграфите во табелите. Тие се стабилни за приложените верзии со SHA-256 во source_manifest.json; не се броеви на печатени страници. Сликите од TOR Annex B1/B2 се проверени од вградените прилози бидејќи текстуалното извлекување не ги опфаќа.

Матрицата има 625 записи за кодирани барања, описни одредби, регистри, примери и договорни граници. Тоа е број на евидентирани мапирања, не број на независни законски барања. Повторени барања во A и C се задржани со сопствени локатори. OCR не е правен доказ за потполна идентичност меѓу B и C.

Не се претпоставува автоматска договорна предност на еден документ. C §5.1 експлицитно бара PostgreSQL, .NET/C#/ASP.NET Core, React или Angular и REST/OpenAPI. A има поопшти технолошки барања. D §1.3.3 утврдува 36 месеци договор; C §4.1 наведува 2 години одржување, а други одредби поинаков старт. Ниту еден од овие периоди не се користи како рок за бришење податоци.

Архитектонска одлука

Една PostgreSQL база со одвоени логички шеми е почетната архитектура. Институциите се учесници во ист национален регистар. Нема посебна база за секој давател и нема автоматско изедначување на институција со SaaS tenant. Предметите често мораат контролирано да бидат достапни на дизајнер, КЗК, МФ, спроведувач, комисија и примател.

Модулите користат .NET сервисни интерфејси. Табелите не се директно достапни од frontend или од надворешни институции. Во почетокот модуларен монолит со една трансакциска база овозможува силни трансакции за одлука, блокада, финансиска резервација и outbox. Идно издвојување модули бара управувана миграција на договорите за податоци; не се ветува бесплатно раздвојување на физички FK во независни микросервиси.

Предложена продукциска цел е PostgreSQL 18 со актуелна одобрена minor верзија при инсталација. DDL користи синтакса компатибилна со PostgreSQL 16+, без задолжителни додатоци. Локалната извршна проверка е направена на PostgreSQL 16.2 во изолиран stand-alone режим; тоа не е препорака за продукциска верзија. Истите миграции мора да се проверат на избраната продукциска major/minor верзија.

Поделба на моделот

Основни релации и кардиналности

Програма има една или повеќе мерки; мерка може да има повеќе повици и повеќе форми на помош. Повик има многу апликации, а секоја домашна апликација е поврзана со една конкретна верзија на повик. Апликација има повеќе ревизии, проверки, дополнувања, оценки и историски одлуки. Една изборна одлука може да произведе доделена помош со повеќе инструменти. Корисникот и програмата не се дуплираат по инструмент.

Една помош може да има повеќе договори, а секој договор има оригинал и анекси како посебни верзии. Еден договор може да има многу барања за исплата; едно барање има повеќе последователни одлуки. Една реална исплата може да покрие повеќе одобрени барања, а едно барање може да се реализира во повеќе исплати. aid.payment_allocation ја моделира оваа M:N врска.

Физичко лице се најавува како iam.principal и може да застапува повеќе субјекти. core.party е деловен/институционален субјект, не корисничка сметка. Една институција може да биде дизајнер, давател и спроведувач во различни програми. „Апликант“ и „Примател“ се контекстуални деловни улоги; не се две независни копии на компанија.

Идентификатори и типови

Внатрешен клуч е UUID. Почетниот SQL користи gen_random_uuid(); UUIDv7 може да се воведе по избор на major верзија и benchmark. Архивски број, владина шифра, број на договор, eID subject и надворешен ID се посебни атрибути со соодветен опфат на уникатност. Не се користат EMBG, IBAN или даночен број како примарен клуч.

Датуми на деловно дејство се date; настани и рокови се timestamptz. Базата и API разменуваат UTC; приказот и локалните рокови користат Europe/Skopje и календар по постапка. Паричните износи се numeric(20,4), курсевите numeric(24,12), односите numeric(12,9), мерењата numeric(24,8). Бројот децимали за конечен документ се зема од валутата и од одобрен метод на заокружување. Не се користат float/double/money за финансиска вредност.

JSONB е ограничен на верзионирани форми, декларативни правила, параметри, layout и дополнителни специфични услови. Програма, мерка, субјект, одлука, договор, валута, износ и датум се нормализирани колони со FK. Списоци на приматели, членови, форми, сектори и документи се релации, не текст со запирки.

За JSON Schema и изразите не се тврди дека PostgreSQL CHECK целосно ги валидира. JSON структурата се валидира во одобрен .NET engine со whitelist на оператори, ограничена сложеност и без извршување произволен код или SQL. Базата проверува основни типови, FK и избрани критични инваријанти.

Стабилен ресурс и контрола на пристап

core.resource е централниот идентификатор на заштитен агрегат. prg.program, app.application, aid.award, rpt.report и другите корени користат ист UUID како ресурсот и генериран resource_kind. Композитен FK го спречува користењето ресурс од погрешен тип. Детските редови носат resource_id и, каде што имаат заеднички родител, композитни FK го спречуваат поврзувањето со дете од друго досие.

Создавањето ресурс, типизиран корен и првите права е една трансакција. Продукциската команда проверува дека не останува ресурс без корен. DDL не наметнува универзален deferred reverse FK за сите типови; ова е експлицитен сервисен инваријант и тест во UAT-SCOPE.

Читањето на агрегатот не дава автоматски пристап до сите поврзани агрегати. На пример, апликантот не добива пристап до сите документи на комисијата или до други апликации затоа што го гледа повикот. doc.attachment и doc.document имаат одделни контроли: сервисот проверува дозволено досие и дозволен документ пред да издаде краткотраен download URL.

iam.resource_grant е ефективна дозвола со временска важност, врска кон доделена улога или застапување и причина. iam.party_grant овозможува пристап само до минималниот идентитет на субјектите потребни за дозволен предмет. Административното право за конфигурација не носи право за потпишување или одлучување.

RLS е дополнителен слој за читање. samis_api не е owner, superuser или BYPASSRLS. Контекстот app.actor_id го поставува исклучиво проверен .NET gateway со SET LOCAL во секоја трансакција. Custom GUC не е доказ за идентитет сам по себе: секој со произволен SQL пристап може да го постави. Затоа нема директна база за корисници, нема произволен SQL во report designer и нема доверба во actor_id испратен од browser.

Верзии и историска точност

Програмите, мерките, повиците, формите, правилата, KPI сетовите и workflow дефинициите се верзионирани. Нацрт може да се менува; објавена/поднесена верзија не се препишува. Измена создава нова верзија со причина, автор и врска кон претходната. Старите апликации го задржуваат својот call_version_id. Нови правила не се применуваат ретроактивно без формална, евидентирана одлука.

app.decision, prg.approval_decision, aid.payment_decision, doc.version, wf.event и финансиските настани се append-only. Поништување или корекција е нов запис со supersedes/reverses референца. Не се бришат старите одлуки или реализацијата за да се добие посакуван тековен износ.

row_version обезбедува оптимистичка конкурентност. API UPDATE/команда прима очекувана верзија и враќа конфликт ако таа е сменета. SQL touch trigger ја зголемува верзијата, но секој произволен UPDATE не проверува автоматски очекувана верзија; тоа го прави командата. Критичните финансиски команди користат и row locks.

Програми и одобренија

prg.approval_request.request_kind ги разликува cpc_pre_opinion, cpc_ex_ante, mof_budget, government_preapproval и government_adoption. Мислење не се користи како ex ante одобрение, а буџетско одобрение не се користи како одлука за избор на апликант.

prg.notification_detail го покрива Annex B1: нова/изменета шема, индивидуална помош по шема или ad hoc, претходна одлука, поедноставена постапка, главна и споредна цел, корисник/категорија, очекуван број приматели, начин на финансирање, изгубен даночен приход, оправданост на траењето, кумулација, доверливост, претходно наложен поврат и изјава за точност. Прилозите и дополнителните специфични полиња од службениот образец се во cfg.form_submission и doc.attachment.

Програмски буџет се чува по година, мерка, давател, извор и класификација. Буџетската верзија и референцата до МФ се дел од одобрениот пресек. Промените на одобрен буџет се прават преку нова линија/верзија и контролирана прераспределба; не се менува основа врз која веќе се преземени обврски.

Апликации и комисија

Административната проверка утврдува комплетност и подобност. Комисијата го прави изборот и распределбата. app.decision.kind го чува разграничувањето. Неуспешен повик до УЈП се евидентира како unavailable или inconclusive, не како доказ за неплатен данок.

Комисиите, членството, претседателот, секретарот, кворумот, правото на глас, изземањето, критериумите и тежините се посебни записи. Начинот на гласање, кворумот и дали одлуката е колективна или потпишана од овластен претседател се потврдуваат во SRS. Базата проверува дел од врските и границите на бодовите; сервисот проверува членство, важност, изземање, кворум и сите задолжителни оценки пред одлука.

Надворешна апликација има external_origin=true и статус external_record. Не влегува во локален assessment или decision. Таа останува достапна за аналитика и известување. Изворниот надворешен статус се чува во интеграцискиот договор/верзија на податоците, без лажно претставување дека SAMIS ја водел постапката.

Жалби и мирување

За секоја поднесена домашна жалба во селективен повик се создава посебна prg.call_hold. Се блокира повикот, не само апликацијата на жалителот. Повеќе жалби создаваат повеќе блокади; разрешување една не ги отстранува другите. Роковите имаат одделна wf.suspension; блокада на спроведувањето и мирување на секој конкретен рок не се ист настан.

Деблокирање бара важечка одлука за соодветната жалба, овластено лице и време на правно дејство. Remand не ја отвора постапката автоматски: потребна е дополнителна надлежна одлука и повторна евалуација според потврдена постапка. Дозволените дејства во мирување се whitelist. Прием на докази и евидентирање реално настаната исплата може да продолжи; создавање нова обврска или одобрување исплата е контролирано.

Финансиски факти што не се мешаат

Самото одобрување не создава aid.realization. Исплатата се врши надвор од SAMIS. Влезен treasury/друг доказ се усогласува со одобрени барања; различна валута бара експлицитна конверзија и изворен курс. Прекумерна или неочекувана реализација не се губи од евиденција: се евидентира како стварен факт и се отвора reconciliation/control, а не се измислува одобрение за да се совпаднат бројките.

Номинална вредност и gross grant equivalent се посебни износи. Заем од 1.000.000 не значи автоматски помош од 1.000.000. За гаранции се чуваат покриеност, премија и ризик; за даночни олеснувања данок, стапка, основа и период; за заеми главница, пазарна камата, рок, грејс и отплата. Други инструменти користат одобрена terms schema по форма, со посебна методологија за вреднување.

Кумулација и конкурентност

Правилата се верзионирани по правна основа, период на важност, валута, опфат на поврзани субјекти, период на собирање, интензитет, оправдани трошоци и праг. De minimis е режим на помош, не задолжително посебен паричен инструмент. Нема вграден универзален праг или автоматски пренесени ЕУ прагови како домашно право.

Пресметката ги идентификува сите релевантни помошти, нивниот правен grant date, извор, GGE, валута и преклопени трошоци. aid.cumulation_source бележи што е вклучено и што е исклучено. Непотполни надворешни податоци создаваат inconclusive; резултатот не се претставува како потврдено немање претходна помош.

Одлуката за нова помош мора во една трансакција да ги заклучи повикот, релевантните undertaking групи по растечки UUID и буџетските линии, да направи повторна пресметка, да резервира лимит/буџет и да ја запише одлуката со outbox. SERIALIZABLE со retry на 40001/40P01 или еквивалентно контролирано заклучување е задолжително за спречување паралелни доделувања над лимит. Овој интегрален reserve/award command е сервисен договор во docs/06, не целосно имплементирана SQL функција. Постојат физички табели за сите негови факти.

Извештаи и аналитика

Обврска за известување има субјект, период, тип, рок и задолжителни приматели. Извештајот има посебен број, ревизии, статус, потпис, архива и достава. Годишните ставки од Annex B2 ги поврзуваат примателот, големината, секторот, одобрението од КЗК, формата, интензитетот, износите, работните места и следниот буџет.

Почетниот каталог содржи 20 типови извештаи и 62 предложени индикатори. Примерите од TOR не се прогласени за задолжителни во секој повик. Финансиски формули од анексите што се двосмислени остануваат со status proposal_requires_definition_approval. Сите збирни извештаи прво агрегираат поединечни факти, а потоа ги спојуваат, за да нема множење на износи при joins.

Официјална оцена користи целосен одобрен KPI сет. Поединечни показатели имаат почетна вредност, цел, тежина, период, единица, извор и квалитет. Збирот на тежини во одобрен официјален сет е 1. Формула за растечки индикатор е 100 × (постигнато − почетно)/(цел − почетно); за намалување, опсег, boolean, нулт именител, негативни вредности, недостасувачки мерења и резултат над 100% се применува посебна одобрена политика. Нема претворање непознат резултат во нула.

Секоја пресметка чува algorithm_version, KPI верзија, as_of и input manifest. Официјална и истражувачка оцена се одделни. Споредба со неизбрани апликанти и со секторски компании е можна само врз законски достапни податоци; корелација не се прикажува како докажан каузален ефект.

Национални регистри и лични податоци

C §5.1 и A NFR01:26 забрануваат сопствени реплики на национални регистри. core.party содржи стабилна референца и дозволен минимум за SAMIS предмет; не е национален master registry. Лични и чувствителни тековни податоци се прибавуваат преку MIM2 кога се потребни. Не се гради копија на население или персонален регистар на сите вработени.

Потребата за доказ што било проверено и историски KPI не ја укинува оваа забрана. Се чуваат метаподатоци, резултат од проверка, извор, време, hash и минимални дозволени службени докази/агрегати во предметот, со утврдена правна основа и рок. Дали конкретен payload или идентификациски атрибут смее да се задржи е одлука за SRS и политика на обработка. До нејзино одобрување се чува само референца/резултат; нема трајно кеширање целосни одговори во JSON, логови или аналитичка база.

Контактните вредности и банкарските референци се шифрирани на апликативно ниво, со клучеви надвор од базата. Аудитот содржи стари/нови вредности, па и тој е заштитен систем со рок на чување; во него се чуваат ciphertext, минимални идентификатори и маскирани интеграциски грешки, не plaintext тајни.

Документи и јавност

Бинарните PDF/XML/прилози се во контролирано on-prem object/DMS складиште со верзионирање; PostgreSQL чува метаподатоци, hash, тип, големина, пристап и врски. Ова техничко решение треба да се потврди со нарачателот ако „сите податоци во релациона база“ се толкува како барање и бинарните бајти да бидат во PostgreSQL; алтернатива е BYTEA/large objects со соодветен backup и тест за оптоварување. Нема јавни директни bucket URLs.

Финален правно релевантен документ се проверува за потребниот квалификуван потпис, институционален печат и временска ознака. Метаподаточен запис validation_status='valid' не е криптографска валидација сам по себе: доверливиот сервис мора да провери сертификат, синџир, revocation, timestamp и формат и да зачува доказ. Базата го врзува резултатот со точна непроменлива верзија.

QR користи непогодлив токен; во базата се чува hash. Јавната проверка дава само одобрен минимум и евентуално редактирана копија. Знаењето QR URL не дава пристап до целото приватно досие. Потпис на хартија се означува како таков; скенирана копија не се претставува како оригинален квалификуван е-документ.

Јавниот портал чита само pub.publication snapshot одобрен со политика за редакција. Не се објавува оперативна табела со SELECT *. MIM2 изложување на регистар не е јавно објавување. Отворените податоци имаат одделен dataset contract, лиценца, шема, privacy check и верзија на објава.

Граници на одговорноста

Ниту една база сама не може да гарантира квалитет на интерфејс, квалификуван потпис, 2 секунди крајно време на одговор или законитост на постапката. Моделот ги прави тие барања конкретни, следливи и тестирачки проверливи.

Индивидуална помош надвор од повик

Предложена патека за индивидуална помош е prg.program.program_kind=individual, нотификација со конкретен примател и позитивно/условно cpc_ex_ante одобрение. aid.award.direct_approval_decision_id ја поврзува со оваа одлука; не се создава фиктивен повик или апликација. SQL ја разликува од патеката selection_decision_id и не дозволува двете истовремено. Точната примена, дополнителните владини/буџетски акти и исполнување услови се потврдуваат во SRS O11; оваа патека не е автоматско правно овластување за доделување.

Состојбите и деталните команди подолу се предложена разработка на изворните процеси. Законски рокови, надлежен орган, жалбени степени, кворум и конкретна потписна политика се параметри што се потврдуваат во SRS. Нема автоматско активирање примерен workflow во продукција.

Општа команда

Секоја команда содржи command_id/idempotency_key, resource_id, expected_row_version, проверен actor, институционален контекст, payload hash, correlation_id и причина кога се менува претходен деловен факт. API ги проверува идентитетот и овластувањето, ја отвора трансакцијата, поставува SET LOCAL контекст и ги заклучува релевантните записи. Проверува потписи/докази подготвени надвор од трансакцијата, но повторно проверува нивна врска и важност пред commit.

Во истата трансакција се запишуваат деловниот факт, wf.event, ревизиската трага и intg.outbox. Надворешно повикување, PDF рендерирање и чекање човечки потпис не држат долги DB locks. Job/command продолжува преку кратка наредна трансакција со повторно читање на верзиите.

Повторено барање со ист клуч и ист payload го враќа истиот резултат. Ист клуч со различен payload враќа конфликт. Ако commit успее, а HTTP одговорот се изгуби, retry не создава второ доделување, втор архивски број или второ известување.

WF01 Пристап и застапување

Профил не е регистар на население. Не се чуваат лозинки од националниот eID. Примерен локален password fallback не е активиран; ако се договори break-glass сметка, таа бара посебна политика и одобрен password hash механизам.

WF02 Подготовка програма и консултации

Нацрт → институционална/јавна консултација → корекција → спремна верзија. Дизајнерот внесува програма, мерки, правна основа, цели, индикатори, форми, региони/сектори, буџет и правила. Учесниците доставуваат comments/questions/objections во prg.consultation_response; одговорот бележи дали се менува програмата. Коментар не се третира автоматски како управна жалба.

Пред поднесување: валидна програмска верзија, секоја мерка во правилна програма, дефиниран буџет, задолжителна документација, верзиониран образец и правила. Поднесената верзија се замрзнува. Консултација повторена по суштинска измена создава нова инстанца со врска до новата верзија.

WF03 Претходно мислење на КЗК

Нацрт → поднесено → проверка на комплетност → разгледување → мислење; дополнување враќа во нов круг на корекција. Повлекување е дозволено пред започнато разгледување, со причина и историја. Не се брише претходно поднесениот документ.

КЗК добива задача и известување. Барање за корекција има адресат, рок, текст, одговор и прифатеност. Мислењето се потпишува според политиката, се архивира и доставува. prg.approval_decision се поврзува со точно разгледаната program_version. Нова верзија не го наследува автоматски старото мислење.

WF04 Влада МФ и ex ante

Се водат одделни инстанци за government_preapproval/adoption, mof_budget и cpc_ex_ante. Владиниот/ресорниот акт, мислењето на МФ и ex ante одобрението имаат различни надлежни органи, броеви, датуми и одлуки. Изворите не се доволни за универзален непроменлив редослед на секоја национална постапка; dependency graph се конфигурира по вид програма.

Објавување повик бара одобрената програмска и мерна верзија и сите задолжителни акти за таа постапка. Условно одобрение бара проверка на исполнети услови. Одбиена програма не отвора активен повик. Повторно одобрување по суштинска измена е нов предмет со врска до претходната одлука.

WF05 Повик и јавна објава

Нацрт → проверен → објавен → затворен/повлечен/откажан → архивиран. Командата publish проверува одобренија, рокови, форма, критериуми, задолжителни документи и дозволени јавни полиња. Во истата трансакција запишува call_version, public snapshot и outbox за каталог/претплатници.

Продолжување рок или измена на услови создава нова call_version со претходни вредности во историјата. Еднаквиот третман на веќе поднесени апликации се решава со одобрена change policy: известување, евентуално дополнување/повторно поднесување и нови рокови. Нема тивка замена на правила. Автоматско затворање користи серверско време и идемпотентна job задача. Бришење е дозволено само за нацрт без правно релевантни зависности; за објавен повик се користат повлекување и архивирање.

WF06 Поднесување апликација

Нацрт → поднесена → валидација → дополнување → подобна/одбиена пред евалуација. Командата submit_application го заклучува повикот, повторно го проверува рокот, ја проверува важечката верзија и застапувањето, валидира податоци и прилози, доделува број и запишува неповратна ревизија со потврда за прием.

Рокот е серверски, не browser clock. Случајот „корисникот почнал upload пред рок, но поднел по рок“ бара потврдена политика; нема автоматско претпоставено продолжување. MIM2 податоци се прибавуваат по службена должност каде што се достапни. Недостапност отвора retry/manual review и не создава лажно негативен eligibility резултат.

Дополнување се поврзува со конкретно барање и со нова app.revision. Потпишаната претходна ревизија и прилозите се зачувуваат. Апликантот не смее да менува оцени, одлуки, официјални проверки или ефективен статус директно.

WF07 Проверка комисија и избор

Подобна → евалуација → кумулација → избор/неизбор → формална достава. Спроведувачот ја завршува административната проверка. Комисијата добива задачи само за соодветниот повик. Изземен член не оценува, не гласа и не потпишува по истиот предмет.

Пред колективна одлука се проверуваат: валидно назначување, кворум, сите задолжителни оценки, бодови во опсег, tie-break правила, финална ранг-листа, применета кумулација, расположлив буџет и причини за корекции. Сервисот бележи учесници и документ од седница преку forms/documents. Ако постапката бара индивидуални гласови, тие се структурирани во верзиониран службен образец; детална табела за гласање се додава по потврда на моделот за одлучување.

Одлуката и одобрените инструменти се запишуваат заедно. Не се прогласува некој за примател само по административно eligible. Чекорот за потпишување е одделен од подготовката. Сите надворешни апликации се исклучени од локална евалуација.

WF08 Кумулација и резервација

1. Утврди важечко правило според правна основа, grant date, категорија, сектор, валута и вид помош.
2. Идентификувај single undertaking/поврзани субјекти и докази за нивната важност.
3. Собери релевантни доделувања, активни резервации и дозволени надворешни записи; отстрани дупликат native/external records.
4. Пресметај GGE и конверзија со зачуван курс и метод. Разграничи grant date од cash realization date.
5. Провери преклопени оправдани трошоци, интензитет, период и максимална изложеност. Недоволни податоци → inconclusive.
6. Во финалната трансакција повторно заклучи и провери, запиши cumulation_check/source, reservation и одлука. Пренеси резервација во award/commitment без двојно броење.
7. Истечени/ослободени резервации имаат настан и причина. Expiry job не смее да ослободи веќе потрошена резервација.

Серискиот опфат на locks мора да биде поширок од само application_id: две институции може истовремено да доделуваат на ист undertaking. За различни валути и повеќе правила се заклучуваат сите засегнати лимити во стабилен редослед. Една in-memory пресметка пред трансакцијата не е доволна.

WF09 Жалба и деблокирање

Поднесена → проверка на допуштеност → разгледување → одлука → правно дејство/повторно постапување. Жалбата содржи contest reference, подносител, надлежен орган, ниво, причина, документи, рокови и достава. Поднесување домашна жалба во селективен повик атомски создава call_hold пред да може друга трансакција да започне спроведување.

Разрешувачот не се претпоставува дека е спроведувачот или комисијата што ја донела спорната одлука. Деблокирање се прави по ефективна одлука и проверка на сите преостанати блокади. Remand создава нов evaluation_round, без менување старите резултати. Надворешна жалба е reporting-only и не блокира домашен повик без посебно наложена постапка.

WF10 Договор и анекси

Одобрена непотпишана помош → подготовка → потпишување → ефективен договор → анекс/престанок. Страните, застапувањето, одобрената вредност и разликата до договорен износ се проверуваат. Различен grantor/recipient/award не може да се внесе во туѓ договор.

Електронски потпис генерира нова immutable документна верзија; хартиен договор има датум и custody reference. По проверка на сите потписи/скенот според прифатената политика, договорот станува effective. Анекс се врзува со претходната верзија; намалување под веќе одобрена/реализирана обврска бара посебна корективна постапка. Оваа целосна contract_effectuate команда е сервисна обврска, не нешто што го гарантира самото status поле.

WF11 Барање за исплата и реализација

Извештај во нацрт → поднесено барање → проверка/дополнување → целосно/делумно/одбиено → потпишана одлука → достава. Барањето има договор, период, број, ставки и прилози. Полно одобрување е еднакво на бараното; делумно е строго меѓу 0 и бараното; одбивање е 0 и бара образложение.

За одобрение се заклучуваат call → award → request. Се проверува збирот на тековните одобренија по договор, со latest revision по барање. Историски одлуки не се собираат повторно. Директно по одобрување не се генерира банкарска трансакција.

Надворешниот доказ за исплата создава aid.realization со уникатна надворешна референца. Усогласување е посебна команда; allocation не надминува реализација или важечка одобрена вредност. Поништување е reversal со ист инструмент и валута и не може збирно да надмине изворниот факт. При делумен reversal на веќе распределена исплата, сервисот создава корективно усогласување и го зачувува allocation audit; ова бара дополнителен command contract пред продукциско финансиско книжење.

WF12 Непарична помош

Правно доделување → вреднување → остварено право → периодичен доказ → проверка. Даночно олеснување, заем, гаранција, преземен долг, капитална инвестиција и продажба под пазарна вредност имаат различни параметри и не бараат сите банкарски payment_request. aid.realization ја бележи стварната корист според одобрениот метод.

Гаранција што не е активирана не се меша со готовинска исплата. GGE може да е различен од номиналната изложеност. Датум на правно доделување, рок на инструментот и период на реализација се чуваат посебно.

WF13 Периодично известување и KPI

Создадена обврска → доспевање → поднесен извештај → проверка/корекција → прифатен извештај → пресметка. Scheduler создава обврски идемпотентно по subject/type/period/party. Прифатен извештај исполнува точно определена обврска; нацрт не ја затвора.

Официјалните индикатори се заклучени со одобрение; измена тежини создава нов сет, reason и effective date. Calculation run ги замрзнува алгоритамот, сетот и изворниот пресек. Збирни резултати наведуваат број вклучени/исклучени приматели и причините за недостасувачки податоци.

КЗК добива извештај за неисполнети обврски. Можна забрана за нова помош се евидентира само со посебна овластена одлука во reporting_restriction. Автоматска job задача не изрекува санкција.

WF14 Ex post и повторна процена

Отворена контрола → анализа → наод → препорака/мерка → одговор → верификација → затворање. Контролата може да биде за програма, конкретна помош, неочекуван настан или непријавување. Препораките можат да побараат измена, усогласување, постепено укинување или нов извештај. Изворната помош и старите одобренија остануваат зачувани.

Повратот има основа, надлежен орган, главница, валута, каматна методологија и реални приливи. Овие табели се предложена можност за проширување. Изворите не дефинираат целосна национална постапка и автоматски engine за наплата; не се активира без усогласување.

WF15 Надворешни портали и миграција

Прием → schema validation → staging → дедупликација → усогласување → apply → ACK/quarantine. Клуч е system + entity_kind + external_id. Ист version со различен hash е конфликт. Постара верзија не препишува понова. Tombstone значи контролирано архивирање ако има зависности; не прави cascade delete на договори и извештаи.

Програми, апликации, помош и жалби од надворешни портали имаат потекло и се вклучуваат во аналитика. Надворешната евалуација не се повторува локално. При миграција batch има count/control totals по валута, редови со грешки, owner sign-off и reconciliation извештај. Не се меша валиден делумен увоз со целосен успех.

WF16 Документ потпис и достава

Upload → quarantine scan → чиста непроменлива верзија → подготовка потпис → потпис/печат/timestamp → валидација → архива → достава → доказ. Само чиста верзија може да биде прикачена. Потпишување и испраќање користат idempotency keys и provider job IDs. Повторна валидација по истек на сертификат се чува како нов доказ, без препишување стар резултат; doc.signature овозможува повеќе validation записи врз иста верзија.

Е-пошта и in-app notification не се автоматски правно релевантна достава. doc.delivery_event е доказен настан, а legally_served_at се утврдува по одобрена service rule. Рок за жалба почнува од соодветниот правен настан, не нужно од моментот кога worker испратил email.

WF17 Јавност и отворени податоци

Избор на дозволени полиња → редакција → проверка → одобрен snapshot → објава → каталог/отворени податоци → верзионирано ажурирање. Report designer нема автоматско право да објавува. Лични податоци не влегуваат во јавен search index. Повлекување објава ги инвалидира кешот и dataset lifecycle според правилата, со зачувана приватна трага.

Заклучувања и повторување

Lock редоследот е дел од сервисниот API договор. Недостигаат live multi-session тестови во испорачаната локална проверка; задолжителни се сценарија со паралелни жалби/доделувања/исплати пред продукција.

Сите размени на деловни/регистарски податоци со државни системи се преку MIM2, како што бара C §4.1–4.3.6 и §5.1. SAMIS е и повикувач и давател. Не се прават директни SELECT врз базите на другите институции. Конкретните service IDs, URLs, сертификати, payload schemas и правни основи се добиваат од одобрен интеграциски договор; тука не се измислени продукциски endpoints.

Интеграциска матрица

Автентикациските протоколи и trust provider конекциите се одделни од државната размена на регистарски податоци. intg.system.government_system означува канал за државна размена, не правен статус на организацијата сопственик. Ако нарачателот бара и тие протоколни чекори преку MIM2, се усогласува топологијата пред имплементација; тие не смеат да се користат како изговор за директно преземање национални регистри.

Стандарден envelope

Пораката содржи message_id, correlation_id, causation_id, service_code, contract_version, event_type, source_system, external_entity_type/id/version, occurred_at, effective_at, purpose, legal_basis_reference, payload_hash, signature_reference и payload_ref. Реалниот payload се валидира со конкретна OpenAPI/JSON/XML шема. Envelope не дозволува слободен документ со произволни полиња.

Времињата се ISO 8601 со offset/UTC. Децимални износи во JSON се испраќаат како децимален string со валута и дефинирана скала, за да не се изгуби прецизност во JavaScript. UUID се интерни; надворешните клучеви остануваат во сопствен namespace.

Прием и дедупликација

Inbox UNIQUE(service_version_id, external_message_id) спречува повторна обработка во ист договор. Миграција на договорна верзија не смее да овозможи повторно книжење ист финансиски настан; за тоа постои и деловен уникатен клуч во realization/external_mapping. Ист message_id со различен hash оди во conflict/quarantine. ACK се праќа по commit.

Надворешен update се применува според договорен source version или монотоно sequence, а не само според локално време на прием. Позадоцнет настан може да биде нов business-effective факт, но не смее тивко да ја замени поновата authoritative верзија. Губење континуитет отвора resync процедура.

Испраќање и повторни обиди

Outbox се пополнува заедно со деловната трансакција. Worker зема ограничена серија со FOR UPDATE SKIP LOCKED, запишува lease token/expiry и ја затвора трансакцијата. Мрежното повикување е надвор од неа. Само сопственикот на lease token може да го означи резултатот; timeout/краш овозможува повторување.

Retry е exponential backoff со jitter, max_attempts по сервис, circuit breaker и dead-letter ред. 4xx schema/authorization грешки не се повторуваат бесконечно; 429/timeout/5xx се третираат по contract. Системот дава at-least-once delivery и business idempotency, не ветува глобално exactly-once преку мрежа.

Изложување на регистри преку MIM2

API има регистарски операции за програми, мерки, одобренија, апликации, доделена помош, договори и извештаи. Сервисот проверува consumer, purpose, data_access_grant, legal basis, field mask и scope. Избор на филтер не ја заменува авторизацијата. Pagination, stable cursor, bounded page size, as_of watermark и audit се задолжителни за големи резултати.

Бришење програма преку API е само дозволено lifecycle дејство: нацрт без зависности може да се избрише; правно релевантен запис добива archive/tombstone и причина. Нема општ DELETE cascade endpoint.

Достапност на извор и свежина

Секој резултат има retrieved_at, source reference, schema version, evidence hash и статус. Апликацијата прикажува дали проверката е свежа, стара, недостапна или неусогласена. Потврден негативен резултат се разликува од неуспешна интеграција. Повторна проверка пред конечна одлука е конфигурабилна по доказ и постапка.

Дозволениот кеш, TTL и чување evidence се потврдуваат за секој сервис. Нема стандардно „зачувај го целиот response засекогаш“. Мониторинг логовите содржат service/correlation/status/latency, не целосни лични податоци, токени или сертификатни приватни клучеви.

Минимални тестови за секој адаптер

Успешна размена; недозволен consumer; ист message повторно; ист ID различен payload; schema upgrade; timeout по remote commit; губење ACK; пораки надвор од редослед; stale data; partial batch; идентитет од погрешна институција; field mask; key/certificate rotation; потврда дека вкупните износи по валута се исти пред и по увоз. Секој тест има локална верзија на contract fixture и evidence од тест MIM2 средината.

Деловните улоги се одделени од PostgreSQL улогите. Дозволата важи само во доделениот ресурс, институционален контекст и период. Ознаката source значи улога наведена во изворите; proposal означува предложена оперативна поделба.

Шест прегледи на архитектурата и односите, единаесет предложени работни текови и седумнаесет доменски ER дијаграми. Mermaid и Graphviz изворите се во пакетот за понатамошно уредување. Workflow дијаграмите се нацрти за потврда; табеларните договори за команди ги дефинираат деталните предуслови.

Физичкиот каталог содржи 178 табели и 2.139 колони. Надворешните клучеви под секоја табела се точните физички декларации, вклучувајќи составени клучеви што го спречуваат поврзувањето записи од различни предмети.

178 табели