Техничка спецификација

САМИС треба да ја поврзе целата постапка за државна помош: програмско планирање, институционални мислења, јавни повици, аплицирање, евалуација, договори, следење на реализацијата и известување. Централната евиденција ѝ овозможува на КЗК да ги анализира резултатите и навремено да ги согледа неправилностите.

Документите се наменети за МДТ, КЗК, давателите, спроведувачите и тимот за реализација. Бизнис-анализата ги дефинира деловните односи; акциската листа ги организира активностите и доказите; техничката спецификација ги конкретизира системските обврски. Трите документи се поврзуваат преку изворните SAM кодови и процесните идентификатори.

Потврдено барање е она што е наведено во изворната документација. Разработката го објаснува неговото извршување и проверка, без да создава нова законска надлежност. Одлуките што бараат институционална потврда се задржуваат како отворени точки за SRS и SDD. Ниту еден статус во овие документи не означува дека системот веќе е имплементиран или прифатен.

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

Изворна основа: МК §4.2–4.3.

Извор А е SAMIS_TOR.docx, англискиот документ за технички барања. Извор Б е TSSamisFinal.docx, македонската техничка спецификација. Извор В е скенираниот документ 4 1_compressed (1).pdf со 61 страница. Извор Г е тендерската документација за оглас 19002/2026, со насловен датум 02.11.2026.

Англискиот TOR ја дава деталната деловна логика и примерите во анексите. Македонската спецификација ги конкретизира технологиите, интеграциите, безбедноста, испораката и одржувањето. Скенираниот документ се користи како споредбен извор за македонските барања. Тендерската документација ги уредува набавката и договорните услови.

Секое досие на функционално барање го задржува изворниот код. Кодовите SAM01:7, SAM01:8 и SAM01:9 се задржуваат според нумерацијата во македонскиот извор. Прескокнатиот SAM06:06 не се пополнува со измислен модул. Дополнителните процесни и акциски идентификатори се локални идентификатори на оваа разработка.

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

Изворна основа: А; Б; В; Г.

Технологии: македонската спецификација §5.1 бара Microsoft .NET, C# и ASP.NET Core, React или Angular со JavaScript/TypeScript, PostgreSQL и REST API со OpenAPI 3.0.1 или понова верзија. Поопштите технолошки формулации во TOR не се користат за да се игнорира конкретното македонско барање.

Инфраструктура: TOR предвидува хардверски опфат и центри за поставување; македонската спецификација §5.4 наведува дека инфраструктурата ја обезбедува МДТ. Потребна е договорно потврдена поделба на обврските за опрема, системски софтвер и инсталација.

Периоди: TOR MNT01 наведува 36 месеци одржување по оперативен прием; македонската §4.1 наведува две години. §6.1 го врзува почетокот со првиот продукциски модул, а §6.5 бара подготвеност за услуги од потпишувањето. ТД §1.3.3 наведува договорно траење од 36 месеци. Овие различни поими не се спојуваат во претпоставена поделба 12 плус 24 месеци.

Формалната предност на документите и точниот календар мора да се утврдат со договорниот орган. До тоа усогласување акциската листа користи зависности и контролни точки, а не измислени календарски датуми.

Изворна основа: TOR HWR01 и MNT01; МК §4.1, §5.1, §5.4, §6; ТД §1.3.3.

Пред деталната имплементација се потврдуваат: редоследот на програмските одлуки и консултациите; третманот на физички лица по мерка; застапувањето и делегирањето; административниот исход наспроти евалуацискиот избор; органот и роковите за жалби.

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

Интеграциските институции ги потврдуваат сервисите, полињата, дозволите и однесувањето при недостапност. МДТ ги потврдува инфраструктурата, мониторингот и управувачките пристапи. Договорниот орган ги разрешува разликите за периодите и опремата.

Отворена точка се затвора кога постои одговорно лице, формален исход и изменет релевантен документ. Во акциската листа таа се следи преку конкретен резултат и зависност. Без таков доказ останува отворена и не се претставува како одобрена конфигурација.

Изворна основа: TOR и МК според наведените процеси; разработка за SRS.

Системот е модуларна веб-апликација со независна надградба на функционалните модули. Ова не наложува задолжително микросервиси. Конкретниот начин на поставување се разработува во SDD според инфраструктурата и оперативните услови.

Можноста за идно вградување frontend функционалности во други државни портали се обезбедува преку micro-frontend архитектура или еквивалентен пристап, ако биде побарано. Не се бара истовремена употреба на React и Angular.

Plain HTML/CSS/Vanilla JavaScript прототип може да служи за усогласување на изгледот, но не ја заменува продукциската frontend технологија наведена во македонската спецификација.

Изворна основа: МК §5.1.

Изворно функционално барање

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

Очекувано системско однесување

МДТ добива функционален систем и можност да го одржува по договорот.

Правило и граница

Испорака на извршна верзија не ја заменува предавањето на изворниот код и документацијата.

Проверка за прием

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

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM01:01.

Изворно функционално барање

Технологијата и изворниот код на САМИС не смеат да бидат од затворен (proprietary) карактер, односно Нарачателот мора да има можност да го изменува изворниот код и да го продолжи развојот на системот без ограничувања. Одделни модули, можат да бидат понудени како самостојни софтверски алатки, но мора да биде овозможена нивна целосна прилагодливост и надградба од страна на Нарачателот.

Очекувано системско однесување

Промените на деловните правила не смеат да зависат од недостапен затворен модул.

Правило и граница

Самостојно понудена алатка мора да дозволува договорената прилагодливост и надградба.

Проверка за прием

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

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM01:02.

Изворно функционално барање

Сите потребни лиценци за системски и стандарден софтвер мора да бидат јасно наведени, специфицирани и ценовно прикажани во понудата. Тоа вклучува најмалку: софтвер за виртуелизација, системски софтвер, база на податоци, систем за резервни копии (backup) и сите лиценци за останатите понудени делови на САМИС. Лиценците треба да бидат трајни лиценци за користење, освен доколку за одреден софтвер поради неговата природа тоа не е возможно, при што таквите исклучоци мора да бидат јасно наведени, образложени и ценовно прикажани во понудата. Нема да се прифаќаат скриени лиценцни трошоци. За главните модули на САМИС кои ќе бидат развиени како наменски софтвер не смее да постои лиценцна обврска.

Очекувано системско однесување

Нарачателот има видливост на трошоците за системски софтвер и зависности.

Правило и граница

Трајните лиценци се правило; исклучоците мора да бидат образложени и ценовно прикажани.

Проверка за прием

Споредба на инвентарот на инсталиран софтвер со лиценцната листа и понудата.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM01:03.

Изворно функционално барање

САМИС ќе ги складира сите податоци во релациона база на податоци. Добавувачот треба да обезбеди систем за управување со релациона база на податоци и да го користи во рамките на развиениот систем. Може да се понудат и платформи со отворен код.

Очекувано системско однесување

Поврзаните регистри обезбедуваат единствена и проверлива евиденција.

Правило и граница

Општото барање за релациона база се конкретизира со PostgreSQL во точка 5.1.

Проверка за прием

Проверка на референцијален интегритет и конзистентни записи во сите пет основни регистри.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM01:04.

Изворно функционално барање

Серверските оперативни системи мора да бидат компатибилни со постојните хардверски компоненти на МДТ и виртуелната серверска инфраструктура. Системскиот софтвер мора да го поддржува понудениот САМИС. Мора да овозможува редовна примена на безбедносни закрпи и надградби.

Очекувано системско однесување

Системот се поставува во постојната виртуелна инфраструктура на МДТ.

Правило и граница

Не се претпоставува конкретен оперативен систем без потврден инфраструктурен инвентар.

Проверка за прием

Инсталациски тест во договорената околина и проверка на поддржаноста на компонентите.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM01:05.

Изворно функционално барање

Софтвер за резервни копии (Backup): мора да поддржува резервни копии на бази на податоци и виртуелни машини; може да биде самостојно решение или дел од предложеното решение за виртуелизација или база на податоци. Мора да ги поддржува следните видови резервни копии: Целосна (Full Backup); Инкрементална (Incremental Backup); Диференцијална (Differential Backup).

Очекувано системско однесување

Податоците и виртуелните машини може да се обноват по дефект.

Правило и граница

Постојна backup датотека не е доволен доказ без проверка на обновување.

Проверка за прием

Проверка на трите видови копии и документ со резултат од test restore.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM01:06.

Изворно функционално барање

Системот мора да обезбеди управување со корисници и улоги. Сите корисници, освен јавните корисници, мора да се најавуваат со корисничко име и лозинка или со X.509 сертификат преку безбедна форма за најава. Најавувањето во системот треба да биде овозможено и со помош на шема за електронска идентификација со високо ниво на сигурност што е регистрирана во Регистарот на даватели на доверливи услуги и шеми за електронска идентификација. Системот мора да поддржува безбедност базирана на улоги (RBAC). Еден корисник може да има една или повеќе улоги. Минимално треба да се поддржат следните улоги: Дизајнер на програма за државна помош; Давател на државна помош; Спроведувач на државна помош; Апликант/Примател на државна помош; Комисија за евалуација; Генерален секретаријат на Владата; Комисија за заштита на конкуренцијата; Трезор. Каде што е применливо, управувањето со корисници треба да биде интегрирано со централизираните системи за автентикација и управување со корисници на институциите, со цел корисниците да немаат повеќе кориснички сметки, лозинки или токени и да бидат идентификувани на национално ниво (е-ИД / Single Sign-On / Active Directory).За административните и привилегираните кориснички сметки системот мора да поддржува повеќефакторска автентикација (MFA), согласно безбедносните политики на Нарачателот. Системот треба да овозможи конфигурирање на политики за кориснички сесии, вклучително автоматско истекување на неактивни сесии, ограничување на времетраење на активна сесија и заклучување на корисничка сметка по однапред дефиниран број неуспешни обиди за најава, со можност за автоматско или административно отклучување.

Очекувано системско однесување

Корисникот пристапува само во дозволениот институционален и деловен контекст.

Правило и граница

Националната најава не докажува сама по себе право да се застапува компанија.

Проверка за прием

Позитивен тест со дозволена улога и негативен тест за туѓ предмет и директен API пристап.

Изворна основа: МК SAM01:7.

Изворно функционално барање

Сите шифарници во системот мора да бидат управливи. Администраторот треба да може да додава, брише, ажурира, активира и деактивира вредности во секој шифарник.

Очекувано системско однесување

Администрацијата одржува усогласени деловни вредности без измени во кодот.

Правило и граница

Бришење користена вредност не смее да ја уништи историјата на поднесените предмети; начинот се утврдува во SRS.

Проверка за прием

Додавање, измена и деактивирање вредност со проверка на постојните записи.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM01:8.

Изворно функционално барање

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

Очекувано системско однесување

Релевантните лица навреме добиваат порака за задача, рок или исход.

Правило и граница

Каналот, примателите, условот и јазикот се конфигурираат без измена на код.

Проверка за прием

Промена на шаблон и активирање настан со проверка на точните приматели.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM01:9.

Изворно функционално барање

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

Очекувано системско однесување

Нови деловни атрибути може да се користат во форми, пребарување и аналитика.

Правило и граница

Типот и зависностите на полето се метаподатоци, а не произволен текст без валидација.

Проверка за прием

Креирање поле, внес невалидна вредност и пребарување и извоз на валиден запис.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM01:10.

Изворно функционално барање

САМИС мора да биде тестиран согласно процедурата за корисничко прифатно тестирање (User Acceptance Testing – UAT) во развојна/тест околина пред започнување на целосното оперативно прифатно тестирање во продукциска околина.

Очекувано системско однесување

Деловните корисници потврдуваат дека системот ги поддржува постапките.

Правило и граница

UAT се извршува во развојна или тест околина пред оперативното прифатно тестирање.

Проверка за прием

Проодни сценарија поврзани со барања, со потврден исход и затворени блокирачки дефекти.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM01:11.

Изворно функционално барање

САМИС ќе биде хостиран на опрема обезбедена од МДТ. Носителот на набавката има за обврска да го инсталира САМИС на соодветната инфраструктураПред пуштање на системот во продукциска употреба мора да бидат спроведени тестирања на перформанси, тестирања на оптоварување, безбедносни тестирања и пенетрациско тестирање. Извештаите од тестирањата мора да бидат доставени до Нарачателот и сите критични и високи ранливости мора да бидат отстранети пред приемот на системот.

Очекувано системско однесување

Решението се инсталира на опремата на МДТ со докажани перформанси и безбедност.

Правило и граница

Критичните и високите ранливости мора да се отстранат пред прием.

Проверка за прием

Повторно тестирање на поправените ранливости и функционална проверка по инсталацијата.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM01:12.

Изворно функционално барање

Системот мора да поддржува дефинирање на работни текови за секој процес и да овозможи автоматски тек на документи/записи помеѓу корисниците без потреба од програмски код.Работните процеси (тек) треба да поддржуваат конфигурабилни предуслови и валидации за премин помеѓу фази, вклучително проверка на задолжителни податоци и документи пред продолжување на постапката

Очекувано системско однесување

Администраторот може да постави насочување документи без програмирање.

Правило и граница

Конфигурацијата мора да произведе извршлива постапка со улоги и услови.

Проверка за прием

Промена на тек преку интерфејс и извршување нов предмет без измена на изворниот код.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM02:01.

Изворно функционално барање

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

Очекувано системско однесување

Секој предмет има разбирлива тековна фаза.

Правило и граница

Статусот на предметот мора да одговара на реално извршени активности.

Проверка за прием

Проверка на приказот на фазата по дозволен премин и зачувување на претходната историја.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM02:02.

Изворно функционално барање

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

Очекувано системско однесување

Програмирањето, аплицирањето, реализацијата и известувањето се водат низ системот.

Правило и граница

Не смее деловно задолжителен чекор да постои само во корисничко упатство.

Проверка за прием

Извршување на целосен процес со предавање задачи меѓу различни кориснички улоги.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM02:03.

Изворно функционално барање

Секој работен тек се состои од повеќе статуси и акции/услови кои можат да се активираат за премин од еден статус во друг.

Очекувано системско однесување

Постапката продолжува само по исполнети предуслови.

Правило и граница

Дозволено копче во интерфејсот не е замена за проверка на серверската страна.

Проверка за прием

Обид за премин без задолжителен документ мора да биде одбиен без промена на состојбата.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM02:04.

Изворно функционално барање

Системот мора да обезбеди функционалност за следење на секој процес (статуси, активности, доцнења, времетраење и други релевантни податоци за секоја активност и постапка).

Очекувано системско однесување

Раководителот добива увид во траење, застој и одговорност по предмет.

Правило и граница

Роковите се поврзуваат со конкретна постапка; не се измислува еден универзален рок.

Проверка за прием

Симулација на истечен рок и проверка на приказот, историјата и дозволените дејства.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM02:05.

Изворно функционално барање

Сите примени и испратени извештаи мора да добијат единствен архивски број и класификација согласно националното законодавство.

Очекувано системско однесување

Примените и испратените извештаи имаат единствена службена идентификација.

Правило и граница

Правилото за архивска класификација мора да биде усогласено со надлежната институција.

Проверка за прием

Истовремен прием на повеќе извештаи без дупликат броеви и со зачувана класификација.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM02:06.

Изворно функционално барање

Модулот треба да овозможи чување и управување со следните регистри: Регистар на програми и шеми за државна помош; Регистар на видови државна помош, класифицирани според вид, категорија, износ, времетраење, надлежен орган, ниво на власт, правна основа и сл.; Регистар на даватели на државна помош; Регистар на спроведувачи на програми за државна помош; Регистар на други државни органи вклучени во доделувањето на државна помош; Регистар на деловни субјекти/приматели на државна помош со поврзување со Централниот регистар на деловни субјекти; Регистар на ex ante одобренија, консултативни мислења и одлуки; Регистар на документи и одлуки од ex post контрола; Регистар на договори за доделена државна помош (датум, давател, примател, програма, износ, вид на помош и сл.); Регистар на месечни, квартални, годишни и ад-хок извештаи.

Очекувано системско однесување

Програмите, органите, примателите, одлуките и договорите се поврзани во единствена евиденција.

Правило и граница

Деловен регистар не значи посебна физичка база; односите мора да останат следливи.

Проверка за прием

Отворање досие и следење на сите поврзани записи без изгубени или противречни врски.

Изворна основа: МК SAM03:01.

Изворно функционално барање

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

Очекувано системско однесување

Корисникот ги пронаоѓа предметите според нивните атрибути.

Правило и граница

Пребарувањето мора да го зачува ограничувањето на пристап и при комбинирани филтри.

Проверка за прием

Комбинирано пребарување со познат очекуван сет и проверка дека не се појавуваат туѓи записи.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM03:02.

Изворно функционално барање

Сите регистри мора да имаат можност да бидат објавени преку МИМ2 и достапни за користење од други национални системи. Изведувачот е должен да развие, документира и имплементира веб-сервиси преку кои системот ќе ги експонира релевантните податоци кон националната Платформа за интероперабилност, во улога на давател на податоци. Веб-сервисите треба да овозможат другите институции, како повикувачи на податоци, да пристапуваат до потребните податоци преку стандардизирана, безбедна и автоматизирана електронска размена.

Очекувано системско однесување

Другите институции користат дозволени податоци од САМИС како извор.

Правило и граница

Објавување сервис преку МИМ2 не прави лични регистарски записи јавно достапни.

Проверка за прием

Повик со дозволен и недозволен идентитет и проверка на ограничените полиња во одговорот.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM03:03.

Изворно функционално барање

Системот треба да му овозможи на Дизајнерот на програма за државна помош да поднесе програма за добивање претходно мислење од КЗК. Системот мора да ги обезбеди следните функционалности: пополнување на образец за барање; валидација на внесените податоци; поставување/прикачување на повеќе документи; поднесување на барањето; автоматско известување по електронска пошта (и/или преку друг електрнски систем) до КЗК; чување на барањето и сите поврзани метаподатоци во системот; повлекување на барањето пред негово разгледување; промена/повлекување/додавање на прикачен документ пред истекот на рокот за аплицирање; добивање потврда за успешно поднесување; следење на статусот на барањето; преглед на добиениот одговор од КЗК (метаподатоци и документи); преземање на одговорот од КЗК.Пред започнување на постапката за одобрување, системот мора автоматски да изврши проверка на комплетноста на поднесената документација и задолжителните податоци. Доколку недостасуваат задолжителни информации или документи, системот не смее да дозволи продолжување на постапката сe додека недостатоците не бидат отстранети.

Очекувано системско однесување

Дизајнерот доставува комплетна програма и добива следлива потврда.

Правило и граница

Некомплетно барање не продолжува; повлекување и измена на прилози се дозволуваат само во утврдените услови.

Проверка за прием

Поднесување комплетно барање и блокирање барање без задолжителни податоци.

Изворна основа: МК SAM04:01.

Изворно функционално барање

Системот треба да ѝ овозможи на КЗК да достави одговор на примено барање за претходно мислење.

Очекувано системско однесување

КЗК дава одговор поврзан со точното барање и верзијата на програмата.

Правило и граница

Претходното мислење не се заменува со ex-ante одобрение.

Проверка за прием

Преглед на одговорот од дизајнерот и проверка на неговата врска со поднесената верзија.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM04:02.

Изворно функционално барање

Владата или ресорното министерство поднесува барање до КЗК за ex-ante одобрување на програма за државна помош

Очекувано системско однесување

Владата или ресорното министерство ја иницира формалната постапка пред КЗК.

Правило и граница

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

Проверка за прием

Поднесување со дозволен институционален контекст и одбивање неовластен подносител.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM04:03.

Изворно функционално барање

Системот треба да ѝ овозможи на КЗК да достави одговор на примено барање за ex-ante одобрување.

Очекувано системско однесување

КЗК го евидентира исходот на формалната постапка.

Правило и граница

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

Проверка за прием

Проверка на одлуката во регистарот на одобренија и нејзината достапност до овластените страни.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM04:04.

Изворно функционално барање

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

Очекувано системско однесување

Јавноста добива влез до програми, активни повици и статистика.

Правило и граница

Јавниот преглед користи само одобрени јавни полиња.

Проверка за прием

Проверка без најава и споредба со приватното досие за да нема изложени доверливи полиња.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM05:01.

Изворно функционално барање

Корисникот може да пребарува програми во базата на податоци на програми за државна помош.

Очекувано системско однесување

Корисникот може да најде релевантна програма во каталогот.

Правило и граница

Критериумите за пребарување мора да бидат разбирливи и усогласени со класификациите.

Проверка за прием

Пребарување по назив и повеќе атрибути со точен резултат и празна состојба.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM05:02.

Изворно функционално барање

Листа на активни јавни повици – Оваа секција треба да ги обезбеди следните функционалности: пребарување и преглед на листа на активни јавни повици; преглед на деталите за секој јавен повик; можност за преземање на прикачени документи.

Очекувано системско однесување

Компаниите ги гледаат актуелните можности и потребните документи.

Правило и граница

Статусот на повикот мора да одговара на рокот и на одлуката за објавување или повлекување.

Проверка за прием

Преглед на активен повик, преземање прилог и проверка по истек на рокот.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM05:03.

Изворно функционално барање

По одобрување на програмата, спроведувачот на програмата може да објави јавен повик. Процесот треба да ги опфати следните функционалности: најава на порталот за информации за државна помош; креирање нов јавен повик; внесување и потврдување на податоци за програмата, критериумите, правилата, правилниците и релевантните закони; пребарување на зачувани програми според различни критериуми; следење на програмите според фаза; валидација на внесените податоци; автоматско пополнување на веќе постоечки податоци од системот; преземање на податоци за компании и други податоци од јавни регистри преку националната платформа за интероперабилност; објавување на јавен повик; повлекување на јавен повик од јавен приказ; бришење на јавен повик; автоматско повлекување по истекот на рокот; продолжување на рокот на објавен јавен повик; измена на податоци во веќе објавен јавен повик.Системот мора да овозможува преглед на историјата на сите измени направени на јавниот повик, при што за секоја измена ќе се евидентираат корисникот кој ја направил измената, датумот и времето на измената, описот на измената и претходната вредност на изменетите податоци (како и секој дополнителен лог/податок).

Очекувано системско однесување

Спроведувачот управува со јавниот повик по одобрување на програмата.

Правило и граница

Продолжување, повлекување и измена мора да имаат историја со претходна вредност и автор.

Проверка за прием

Измена на рок и проверка на јавниот приказ, ревизискиот запис и претходната вредност.

Изворна основа: МК SAM05:04.

Изворно функционално барање

Апликантите можат да поднесат приговор или жалба преку порталот за државна помош. Оваа функционалност ги опфаќа и аспектите за дигитално потпишување на поднесокот, известување на сите поврзани страни за поднесениот приговор/жалба, роковите и одговорите и следење на статусот на приговорот/жалбата.

Очекувано системско однесување

Приговорите и жалбите се регистрираат и се следат преку порталот.

Правило и граница

Поднесок за програма и жалба на апликација се различни предмети со различни надлежности.

Проверка за прием

Поднесување, известување на поврзаните страни и преглед на статусот без туѓи податоци.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM05:05.

Изворно функционално барање

Сите документи и електронски обрасци кои се обработуваат во процесите поврзани со програмирање на државна помош каде што е потребно согласно закон мора да бидат дигитално потпишани со електронски сертификат.

Очекувано системско однесување

Правно потребните програмски документи се дигитално потпишуваат.

Правило и граница

Видот документ и применливата постапка го определуваат задолжителното потпишување.

Проверка за прием

Проверка на потписот врз точната верзија на документот и одбивање изменета содржина.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM05:06.

Изворно функционално барање

САМИС мора да биде дизајниран така што ќе комуницира со Националниот портал за електронски услуги и Каталогот на услуги. Услугите на САМИС мора да бидат објавени, пребарливи и достапни преку порталот е-Услуги, при што корисниците ќе бидат насочувани кон САМИС, согласно делот 4.1 од оваа техничка спецификација.

Очекувано системско однесување

Услугите на САМИС се пронаоѓаат преку националниот портал и водат до САМИС.

Правило и граница

Насочувањето кон САМИС не значи автоматски вградување во мобилна апликација.

Проверка за прием

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

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM05:07.

Изворно функционално барање

По објавување на јавен повик, апликантите можат да поднесат апликации. Процесот треба да ги опфати следните функционалности: најава на порталот за поднесување апликации преку Националниот систем за единствена најава (SSO); пребарување и избор на програма или јавен повик; пополнување на образец за апликација; автоматско пополнување на податоци од јавни регистри, каде што е применливо; прикачување на сите потребни документи; логичка валидација на внесените податоци; валидација на податоците преку надворешни регистри за утврдување на евентуални неправилности или причини за исклучување на апликантот; автоматско известување до спроведувачот на програмата; •следење на статусните промени; прием на известувања за промена на статус, барање за дополнување или други настани; поднесување одговор на барање за дополнителни појаснувања, вклучително и прикачување документи.

Очекувано системско однесување

Компанијата поднесува барање за помош на објавен повик.

Правило и граница

Поднесената верзија и документите мора да бидат препознатливи при понатамошната обработка.

Проверка за прием

Поднесување преку SSO, автоматски податоци, потврда и видливост во сандачето на спроведувачот.

Изворна основа: МК SAM06:01.

Изворно функционално барање

Спроведувачот на програмата ги разгледува пристигнатите апликации и ги известува апликантите. Процесот ги опфаќа следните функционалности: најава во модулот за евалуација на апликации; преглед на сите примени апликации; преглед на деталите за избрана апликација; преземање на дигитално потпишани документи; прием на известувања за новоподнесени апликации; автоматска проверка на податоците, каде што е применливо преку МИМ2; креирање и испраќање барање за дополнителни појаснувања; одобрување или одбивање на апликацијата; доставување на одлуката до апликантот; испраќање известување до апликантот.

Очекувано системско однесување

Спроведувачот проверува комплетност и бара појаснувања.

Правило и граница

Административниот исход треба да се разграничи од одлуката на комисијата за избор во SRS.

Проверка за прием

Циклус барање за појаснување и одговор со прилози, известување и зачувана историја.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM06:02.

Изворно функционално барање

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

Очекувано системско однесување

Комисијата ги оценува апликациите и утврдува приматели, износи и очекувани резултати.

Правило и граница

Кумулацијата и применливите правила мора да се разгледаат пред конечната одлука.

Проверка за прием

Одлука со приматели и износи, со известени апликант и спроведувач и проверливи податоци за кумулација.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM06:03.

Изворно функционално барање

Апликантите за државна помош треба да имаат можност да поднесат приговор или жалба директно преку интерфејсот на апликацијата, користејќи го постојниот механизам за жалби. Идентификаторот на апликацијата автоматски се поврзува со метаподатоците на жалбата за полесна обработка во системот.

Очекувано системско однесување

Апликантот може да го оспори исходот преку постојниот механизам.

Правило и граница

Имплементацијата за сите апликанти во истиот повик мирува до разрешување на жалбата.

Проверка за прием

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

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM06:04.

Изворно функционално барање

САМИС треба да овозможи безбедно управување со електронски потпишани договори и нивни анекси, во согласност со принципите на електронско управување со документи.

Очекувано системско однесување

Се чуваат потпишаните договорни документи со целосна врска до помошта.

Правило и граница

Анексот не ја брише претходната договорна верзија.

Проверка за прием

Преглед на договор и анекс, контрола на пристап и проверка на потпис или прикачена скенирана верзија.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM06:05.

Изворно функционално барање

САМИС треба да овозможи електронска достава на одлуките на Комисијата за евалуација до давателот и спроведувачот на државната помош. Доставата мора да биде дигитално заверена и да има правна важност согласно важечките закони и прописи.

Очекувано системско однесување

Давателот и спроведувачот ја добиваат формалната одлука за избрани приматели.

Правило и граница

Доставата мора да биде дигитално заверена и временски означена согласно барањето.

Проверка за прием

Проверка на содржината, адресатите и доказот за достава без мешање со обична нотификација.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM06:07.

Изворно функционално барање

Системот треба да му овозможи на давателот или спроведувачот да ажурира информации за статусот на секоја доделена помош (одобрена, во тек, завршена, откажана). Во случај на откажување мора да постои можност за внесување образложение.

Очекувано системско однесување

Давателот или спроведувачот ја ажурира реализацијата.

Правило и граница

Откажувањето има причина; историјата не смее да исчезне со промена на статус.

Проверка за прием

Премин во завршена и откажана состојба со проверка на причината и историските вредности.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM06:08.

Изворно функционално барање

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

Очекувано системско однесување

Примателот бара средства врз основа на придружна документација.

Правило и граница

Давателот може да одобри целосно, делумно или да одбие; реалната исплата е надвор од САМИС.

Проверка за прием

Делумно одобрување со различни побаран и одобрен износ и без автоматска ознака исплатено.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM06:09.

Изворно функционално барање

Системот мора да поддржува квалификуван електронски потпис, квалификуван електронски печат и квалификувана електронска временска ознака (timestamp).

Очекувано системско однесување

Одлуките и документите добиваат потребни механизми за автентичност и време.

Правило и граница

Потпис, печат и временска ознака имаат различни функции и се проверуваат одделно.

Проверка за прием

Верификација на трите елементи, со неуспешен исход за изменет или невалиден документ.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM06:10.

Изворно функционално барање

Поднесување извештаи – Системот мора да овозможи поднесување на структурирани и неструктурирани податоци преку веб-форми. Корисниците, согласно нивната улога и фазата на процесот, треба да можат да внесуваат податоци, како и да прикачуваат документи. Секој поднесен извештај мора автоматски да добие единствен идентификациски број и да биде зачуван во системот. Барања за исплата претставуваат посебен вид извештаи и мора да овозможуваат внесување на дополнителни метаподатоци (на пример: побаран износ, број на барање, период на кој се однесува и сл.) со цел следење, анализа и известување.

Очекувано системско однесување

Структурираните податоци и прилозите добиваат единствен запис за следење.

Правило и граница

Барањето за исплата е посебен вид извештај со дополнителни метаподатоци.

Проверка за прием

Прием на веб-образец и прилози со единствен број и зачувана врска до програмата.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM07:01.

Изворно функционално барање

Системот треба да овозможи преглед на сите поднесени извештаи во листа, пребарување според повеќе критериуми (датум, статус, подносител, програма, примател и други атрибути), како и отворање на деталниот приказ на секој извештај. Системот треба да обезбеди интерактивни контролни табли (dashboards) за различни категории на корисници, со графички приказ на клучните показатели, статистики, реализација на програми, искористеност на средства, статус на апликации, динамика на исплати и други релевантни индикатори.

Очекувано системско однесување

Корисниците добиваат листи и контролни табли според овластувањата.

Правило и граница

Агрегатите мора да се усогласат со основните записи и дозволениот опфат.

Проверка за прием

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

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM07:02.

Изворно функционално барање

Поднесените извештаи треба да имаат различни статуси кои се менуваат во текот на деловниот процес.

Очекувано системско однесување

Извештајот ја следи фазата на неговата деловна обработка.

Правило и граница

Конкретните статуси и дозволените премини се утврдуваат во SRS по тип извештај.

Проверка за прием

Премин по овластено дејство и забранет премин од несоодветна фаза.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM07:03.

Изворно функционално барање

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

Очекувано системско однесување

Примателот го добива исходот од разгледувањето на барањето.

Правило и граница

Образложението е задолжително и за целосен, делумен или негативен исход според изворот.

Проверка за прием

Обид без образложение е одбиен; валидна одлука создава известување до вистинскиот примател.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM07:04.

Изворно функционално барање

Системот треба да овозможи извоз на структурирани податоци во најмалку следните формати: PDF, Excel (XLSX), CSV, XML и JSON, согласно доделените кориснички овластувања. и да може да се подготват за печатење согласно дефинирани шаблони.

Очекувано системско однесување

Овластените корисници користат податоци надвор од интерфејсот.

Правило и граница

Извозот ги почитува истите ограничувања на пристап како прегледот.

Проверка за прием

Отворање валидни датотеки во сите наведени формати и споредба со избраниот сет податоци.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM07:05.

Изворно функционално барање

Системот, најмалку мора да ги поддржува следните извештаи: • месечни, квартални и завршни извештаи за реализација на програмите и примателите на државна помош (реализирана и нереализирана државна помош); • извештаи за корисниците на државна помош кои ги содржат договорените износи и реално одобрените и исплатени средства; • годишен извештај за доделена државна помош и приматели, наменет за Комисијата за заштита на конкуренцијата и Управата за јавни приходи; • извештај за искористеноста на државната помош и постигнатите резултати (од примател до давател); • извештаи за ex-ante одобрување.

Очекувано системско однесување

Се обезбедуваат периодични, финансиски, годишни и ex-ante извештаи.

Правило и граница

Договорено, одобрено и реално исплатено се прикажуваат одделно.

Проверка за прием

Годишен и периодичен извештај со усогласени износи и точна целна институција.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM07:06.

Изворно функционално барање

Системот мора да овозможи генерирање на извештаи кои можат да се печатат или извезуваат во PDF формат. Секој извештај мора да биде генериран согласно однапред дефиниран шаблон кој содржи: • лого на институцијата; • QR-код за проверка на автентичноста во реално време; • квалификуван електронски печат на институцијата, согласно Законот за електронски документи, електронска идентификација и доверливи услуги.

Очекувано системско однесување

Печатените и PDF извештаи имаат институционален изглед и проверливост.

Правило и граница

Логото и QR-кодот не го заменуваат квалификуваниот електронски печат.

Проверка за прием

Генерирање PDF, проверка на печатот и разрешување на QR до дозволен запис за проверка.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM07:07.

Изворно функционално барање

Системот мора да обезбеди графички кориснички интерфејс за креирање и конфигурирање на аналитички извештаи. Извештаите треба да можат да се поврзат со извори на податоци (релациона база на податоци, аналитичка база или OLAP) за преземање на податоци. Треба да се поддржат различни начини на прикажување на податоците, вклучувајќи текст, табели, графикони и други визуелизации. Системот мора да обезбеди интерактивни контролни табли (dashboards) со графички приказ на клучните показатели за различни категории корисници. Секој извештај може да содржи влезни и излезни параметри, кои се дефинираат пред неговото извршување.

Очекувано системско однесување

Корисникот конфигурира параметри, табели, графикони и контролни табли.

Правило и граница

Изборот на аналитички извор не наметнува конкретен производ за OLAP.

Проверка за прием

Креирање извештај преку интерфејс и споредба на неговите резултати со основните записи.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM08:01.

Изворно функционално барање

Системот мора да овозможи зачувување на дефинираните аналитички извештаи и нивно организирање во логичка хиерархија на папки или категории.

Очекувано системско однесување

Зачуваните извештаи се организираат во папки или категории.

Правило и граница

Дефиницијата и резултатот од извршување се различни предмети.

Проверка за прием

Зачувување, повторно отворање и извршување извештај со зачувани параметри.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM08:02.

Изворно функционално барање

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

Очекувано системско однесување

Прегледот, извршувањето и измената се дозволуваат според овластувања.

Правило и граница

Корисник со право за извршување не мора да има право за менување на дефиницијата.

Проверка за прием

Одделни тестови за преглед, извршување и измена со различни профили.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM08:03.

Изворно функционално барање

Системот мора да овозможи извоз на аналитичките извештаи во најмалку следните формати: PDF, Microsoft Excel (XLSX), Microsoft Word (DOCX), CSV, JSON, REST API response, Power BI compatible datasets, OData и XML.

Очекувано системско однесување

Аналитичките резултати може да се користат во канцелариски и интеграциски алатки.

Правило и граница

Power BI компатибилност не е автоматска обврска да се набави Power BI engine.

Проверка за прием

Проверка на сите формати, структурата на dataset и овластувањето на машинскиот пристап.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM08:04.

Изворно функционално барање

Системот мора да овозможи пристап, преглед и извршување на аналитички извештаи преку веб-портал, согласно доделените кориснички овластувања.

Очекувано системско однесување

Извештаите се прегледуваат и извршуваат во порталот.

Правило и граница

Ниту URL ниту зачувана врска не смеат да го заобиколат овластувањето.

Проверка за прием

Директно отворање извештај со дозволен и недозволен профил.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM08:05.

Изворно функционално барање

Зачуваните аналитички извештаи треба да можат да се интегрираат во други информациски системи преку програмски интерфејси (API), со цел нивно повторно користење и автоматска размена на податоци.

Очекувано системско однесување

Другите системи користат зачувани аналитички извештаи преку интерфејси.

Правило и граница

Правата и верзијата на интерфејсот мора да се документираат одделно од визуелниот приказ.

Проверка за прием

Повик со исти параметри како веб-извештај и споредба на резултатите во дозволениот опфат.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM08:06.

Изворно функционално барање

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

Очекувано системско однесување

Резултатот е читлив и погоден за официјална употреба.

Правило и граница

Скратени колони или отсечени графикони не се прифатлив печатен приказ.

Проверка за прием

Проверка на повеќестраничен извештај со повторени заглавија, единици и видливи филтри.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM08:07.

Изворно функционално барање

Системот мора да биде испорачан со најмалку следните претходно дефинирани аналитички извештаи: извештај за евалуација на програмите за државна помош врз основа на дефинирани индикатори; преглед на сите програми за државна помош со можност за филтрирање и групирање според давател, примател, програма, статус на програмата и други критериуми; извештај за напредокот на програмите за државна помош, со приказ на буџетот и реализацијата по временска линија; извештај за индикаторите за успешност (KPI); извештај за поднесени приговори и жалби.

Очекувано системско однесување

Системот се испорачува со програмска евалуација, напредок, KPI и жалби.

Правило и граница

Генератор на празни извештаи не го исполнува барањето за готови аналитички прегледи.

Проверка за прием

Извршување на секоја задолжителна категорија врз контролиран сет податоци.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM08:08.

Изворно функционално барање

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

Очекувано системско однесување

САМИС ја централизира евиденцијата и за податоци обработени во други системи.

Правило и граница

Архивирањето и бришењето се спроведуваат согласно утврдените правила и следливост.

Проверка за прием

Увоз и ажурирање ист запис без дуплирање и со јасно потекло на податоците.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM09:01.

Изворно функционално барање

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

Очекувано системско однесување

Податоците од надворешни постапки служат за аналитика и следење.

Правило и граница

Надворешните апликации не поминуваат повторна евалуација во САМИС.

Проверка за прием

Увезена апликација е видлива во аналитика, но не се распределува на домашна комисија.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM09:02.

Изворно функционално барање

Добавувачот мора да ги развие сите потребни програмски интерфејси (API) и услуги за размена на податоци со други државни информациски системи. API услугите мора да поддржуваат безбедна автентикација, авторизација, евиденција на пристапи (audit trail) и верзионирање на услугите. Системот треба да поддржува синхрона и асинхрона размена на податоци преку МИМ2, со механизми за повторно испраќање, обработка на грешки и следење на статусот на пораките.Интеграцискиот модул ги поддржува и интеграциските активности утврдени во делот 4.2 од оваа техничка спецификација.

Очекувано системско однесување

Размената е документирана, безбедна, верзионирана и следлива.

Правило и граница

Неуспешна порака бара контролиран повторен обид и јасен статус.

Проверка за прием

Синхрон и асинхрон повик со прекин и повторување без двојна деловна обработка.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM09:03.

Изворно функционално барање

Кога за тоа ќе се создадат услови, САМИС мора да биде интегриран со информационен систем на Министерството за финансии преку Националната платформа за интероперабилност, со цел преземање на финансиски податоци потребни за управување и следење на државната помош. Интеграциите со Министерството за финансии, (Open Finance и/или IFMIS/Трезор) или нивни идни наследници се реализираат согласно барањата утврдени во делот 4.1 од оваа техничка спецификација.

Очекувано системско однесување

Финансиските податоци се преземаат од МФ кога ќе се создадат потребните услови.

Правило и граница

Open Finance, IFMIS или Трезор се условени интеграции, не доказ дека сервисите веќе се достапни.

Проверка за прием

Усогласување на примерен одговор со договореното мапирање и евиденција на недостапен сервис.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM09:04.

Изворно функционално барање

САМИС, кога за тоа ќе се создадат услови, треба да биде интегриран со информациските системи на управата за јавни приходи и со постоечкиот систем на Царинската управа преку Националната платформа за интероперабилност, заради автоматска проверка на исполнетоста на условите за доделување државна помош, како што е уредено со закон.

Очекувано системско однесување

Проверките помагаат во подобноста и следењето на деловната состојба.

Правило и граница

УЈП и Царинската управа се поврзуваат кога се создадени услови; недостапноста не е негативен деловен резултат.

Проверка за прием

Разграничување валиден негативен одговор од техничка грешка или timeout.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM09:05.

Изворно функционално барање

САМИС мора да биде интегриран со Централниот регистар преку Националната платформа за интероперабилност, со цел автоматско преземање и верификација на податоци за деловните субјекти, каде што е применливо.

Очекувано системско однесување

Податоците за компаниите се преземаат и верификуваат преку интероперабилност.

Правило и граница

САМИС не создава сопствена копија на националниот регистар.

Проверка за прием

Проверка на компанија преку МИМ2 и следливост до користениот одговор во дозволениот опфат.

Доказ и следливост

Проверката се извршува со контролиран пример во дозволениот кориснички контекст. Се зачувуваат влезот, очекуваниот резултат, фактичкиот исход и доказот од извршувањето. Неуспешен тест се поврзува со дефект и повторна проверка; статусот на барањето останува отворен до потврден исход.

Изворна основа: МК SAM09:06.

НФ 01. САМИС мора да биде развиен како модуларен систем кој овозможува независно надградување на поединечните функционални модули (workflow, документи, аналитика, интеграции и база на податоци), без влијание врз останатите компоненти на системот. Системот мора да биде развиен како повеќеслојна архитектура со јасно логичко раздвојување на презентацискиот слој (UI), слојот на деловна логика, интеграцискиот слој и слојот за пристап до податоци. Системот мора да биде модуларен, да поддржува повеќекорисничка работа и да користи релациона база на податоци. Архитектурата мора да овозможува лесна надградба, додавање нови функционалности и прилагодување на деловните процеси без значителни измени на постојните модули.

НФ 02. Поради постојната ИКТ архитектура, инфраструктура и технолошката стандардизација на Договорниот орган на Microsoft технологии, како и со цел обезбедување компатибилност, одржливост, централизирано управување, понатамошен развој и преземање на изворниот код од страна на Договорниот орган, backend слојот на САМИС треба да биде развиен со Microsoft .NET, C# и ASP.NET Core, на поддржана верзија во моментот на имплементација.

НФ 03. Frontend апликацијата треба да биде развиена со React или Angular, со JavaScript/TypeScript. За управување со структурирани податоци системот треба да користи PostgreSQL релациона база на податоци. Интеграциите и програмските интерфејси треба да бидат реализирани преку REST API и документирани согласно OpenAPI 3.0.1 или понова верзија.

Верификација

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

Опфат на проверката

Оваа група барања важи хоризонтално за засегнатите модули. Исполнетост на еден екран не докажува исполнетост на сите интерфејси, извози и интеграции. Доказите се поврзуваат со конкретните НФ идентификатори.

Изворна основа: МК §5.1; локална нумерација НФ.

НФ 04. Системот треба да биде развиен како модуларна веб апликација, со можност за идно издвојување и вградување на одделни frontend функционалности во други државни портали, вклучително и uslugi.gov.mk, преку micro-frontend архитектура или еквивалентен технички пристап, доколку тоа биде побарано од Договорниот орган.

НФ 05. Системот мора да обезбеди едноставен, интуитивен и конзистентен кориснички интерфејс, кој овозможува брзо совладување од страна на корисниците и минимални потреби за обука.

НФ 06. Корисничкиот интерфејс мора да биде целосно веб-базиран и достапен преку современи интернет-прелистувачи (Google Chrome, Microsoft Edge, Mozilla Firefox и други прелистувачи базирани на Chromium), без потреба од инсталација на дополнителен клиентски софтвер или административни права на корисничките работни станици, освен доколку тоа е неопходно поради законски барања за електронско потпишување.

Верификација

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

Опфат на проверката

Оваа група барања важи хоризонтално за засегнатите модули. Исполнетост на еден екран не докажува исполнетост на сите интерфејси, извози и интеграции. Доказите се поврзуваат со конкретните НФ идентификатори.

Изворна основа: МК §5.1; локална нумерација НФ.

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

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

НФ 09. Системот мора автоматски да ги пополнува сите податоци што се достапни преку Националната платформа за интероперабилност, со цел да се избегне повторен внес на податоци.

Верификација

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

Опфат на проверката

Оваа група барања важи хоризонтално за засегнатите модули. Исполнетост на еден екран не докажува исполнетост на сите интерфејси, извози и интеграции. Доказите се поврзуваат со конкретните НФ идентификатори.

Изворна основа: МК §5.1; локална нумерација НФ.

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

НФ 11. Системот мора да поддржува квалификуван електронски потпис, квалификуван електронски печат и облачно електронско потпишување преку даватели на доверливи услуги регистрирани во националниот Регистар на даватели на доверливи услуги.

НФ 12. Целокупната комуникација мора да биде реализирана преку TLS 1.3 или понова верзија, согласно важечките безбедносни стандарди.

Верификација

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

Опфат на проверката

Оваа група барања важи хоризонтално за засегнатите модули. Исполнетост на еден екран не докажува исполнетост на сите интерфејси, извози и интеграции. Доказите се поврзуваат со конкретните НФ идентификатори.

Изворна основа: МК §5.1; локална нумерација НФ.

НФ 13. При проектирањето, развојот и документацијата мора да се применуваат меѓународно прифатени стандарди и најдобри индустриски практики.

НФ 14. Системот мора да обезбедува известувања преку електронска пошта, електронско сандаче (е-Сандаче) и системски известувања за статуси, рокови, активности и други релевантни настани.

НФ 15. Системот мора да обезбеди сигурна, доверлива и високо достапна работа, при што сите податоци се достапни исклучиво за автентицирани и овластени корисници.

Верификација

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

Опфат на проверката

Оваа група барања важи хоризонтално за засегнатите модули. Исполнетост на еден екран не докажува исполнетост на сите интерфејси, извози и интеграции. Доказите се поврзуваат со конкретните НФ идентификатори.

Изворна основа: МК §5.1; локална нумерација НФ.

НФ 16. Секоја активност во системот мора да биде евидентирана со информации за корисникот, датумот, времето, извршената операција, старите и новите вредности, IP адресата и другите релевантни метаподатоци.

НФ 17. Системот мора да обезбеди механизми за идентификација, автентикација, авторизација, интегритет, доверливост, непроменливост на податоците, непризнавање на трансакциите (non-repudiation) и целосна ревизиска трага.

НФ 18. Системот мора да обезбеди време на одговор не подолго од 2 секунди за најмалку 200 истовремени активни корисници при нормално оптоварување.

Верификација

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

Опфат на проверката

Оваа група барања важи хоризонтално за засегнатите модули. Исполнетост на еден екран не докажува исполнетост на сите интерфејси, извози и интеграции. Доказите се поврзуваат со конкретните НФ идентификатори.

Изворна основа: МК §5.1; локална нумерација НФ.

НФ 19. Системот мора да поддржува најмалку 2.000 регистрирани корисници без дополнителни лиценцни ограничувања или ограничувања на функционалностите.

НФ 20. Системот мора да поддржува имплементација и работа во локална инфраструктура (on-premises), приватен облак и хибридна инфраструктура.

НФ 21. Системот мора да поддржува хоризонтално и вертикално скалирање без промена на апликативната логика.

Верификација

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

Опфат на проверката

Оваа група барања важи хоризонтално за засегнатите модули. Исполнетост на еден екран не докажува исполнетост на сите интерфејси, извози и интеграции. Доказите се поврзуваат со конкретните НФ идентификатори.

Изворна основа: МК §5.1; локална нумерација НФ.

НФ 22. Системот мора да обезбеди автоматско креирање резервни копии, можност за враќање на податоци, конфигурирање на политики за задржување и складирање на резервните копии на одделна инфраструктура.

НФ 23. Системот мора да обезбеди потпишување на XML и PDF документи преку веб-прелистувач, користејќи квалификувани сертификати и облачни сертификати, без потреба од дополнителен десктоп софтвер, во согласност со законите и подзаконските акти кои ја регулираат оваа материја.

НФ 24. Сите клиентски компоненти мора да бидат компатибилни со Google Chrome, Microsoft Edge, Mozilla Firefox и други современи прелистувачи базирани на Chromium.

Верификација

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

Опфат на проверката

Оваа група барања важи хоризонтално за засегнатите модули. Исполнетост на еден екран не докажува исполнетост на сите интерфејси, извози и интеграции. Доказите се поврзуваат со конкретните НФ идентификатори.

Изворна основа: МК §5.1; локална нумерација НФ.

НФ 25. Сите финални, излезни и правно релевантни документи мора да содржат квалификуван електронски печат, QR-код за проверка и да бидат усогласени со Законот за електронски документи, електронска идентификација и доверливи услуги.

НФ 26. Системот не смее да создава сопствени копии на националните регистри. Сите лични и други чувствителни податоци мора да се преземаат во реално време преку Националната платформа за интероперабилност и согласно Законот за заштита на личните податоци.

НФ 27. Сите правно релевантни документи мора да бидат потпишани со квалификувана електронска временска ознака (Qualified Timestamp).

Верификација

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

Опфат на проверката

Оваа група барања важи хоризонтално за засегнатите модули. Исполнетост на еден екран не докажува исполнетост на сите интерфејси, извози и интеграции. Доказите се поврзуваат со конкретните НФ идентификатори.

Изворна основа: МК §5.1; локална нумерација НФ.

НФ 28. Сите интеграции и размена на податоци со други државни информациски системи задолжително се реализираат преку Националната платформа за интероперабилност.

Верификација

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

Опфат на проверката

Оваа група барања важи хоризонтално за засегнатите модули. Исполнетост на еден екран не докажува исполнетост на сите интерфејси, извози и интеграции. Доказите се поврзуваат со конкретните НФ идентификатори.

Изворна основа: МК §5.1; локална нумерација НФ.

Физичкото лице, компанијата и институцијата се различни поими. Деловните улоги се доделуваат во конкретен опфат, а не само според постоење сметка.

Минимални деловни атрибути

Идентификатор; вид субјект; назив; контакт; институција; улога; поврзан идентитет.

Релации

Корисникот се поврзува со предмети преку овластување. Компанијата останува ист апликант и кога нејзиниот претставник се менува.

Ограничувања

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

Насока за физички модел

Техничка разработка за SDD: стабилни примарни идентификатори, референцијални врски и ограничувања за уникатност се определуваат според деловниот модел. Износите се чуваат како точни децимални вредности со валута; временските настани имаат јасна временска зона. Овие дизајнерски избори не се претставуваат како дословни тендерски типови на колони.

Прием на податочниот слој

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

Изворна основа: МК §4.4.1; SAM01:7; §5.1; физичкиот модел се потврдува во SDD.

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

Минимални деловни атрибути

SAMIS број; официјален код; назив; опис; дизајнер; правна основа; буџетска класификација; период; статус.

Релации

Програмата содржи мерки и е поврзана со одобренија, повици и програмски извештаи.

Ограничувања

Измена по одобрување бара одлука дали повторно се одобрува; не се препишува одобрената содржина без трага.

Насока за физички модел

Техничка разработка за SDD: стабилни примарни идентификатори, референцијални врски и ограничувања за уникатност се определуваат според деловниот модел. Износите се чуваат како точни децимални вредности со валута; временските настани имаат јасна временска зона. Овие дизајнерски избори не се претставуваат како дословни тендерски типови на колони.

Прием на податочниот слој

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

Изворна основа: TOR Programs Register; МК §4.4.2; физичкиот модел се потврдува во SDD.

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

Минимални деловни атрибути

Код; назив; цел; сектор; регион; форма; износ; давател; спроведувач; критериуми; индикатори.

Релации

Една програма има повеќе мерки; повикот упатува на релевантната мерка и нејзините правила.

Ограничувања

Ист назив на форма на помош не значи идентични правила за сите програми.

Насока за физички модел

Техничка разработка за SDD: стабилни примарни идентификатори, референцијални врски и ограничувања за уникатност се определуваат според деловниот модел. Износите се чуваат како точни децимални вредности со валута; временските настани имаат јасна временска зона. Овие дизајнерски избори не се претставуваат како дословни тендерски типови на колони.

Прием на податочниот слој

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

Изворна основа: TOR Programs Register и Cumulation rules; МК §4.4.2; физичкиот модел се потврдува во SDD.

Повикот го определува периодот и условите за поднесување. Јавниот приказ е ограничен пресек од административниот запис.

Минимални деловни атрибути

Идентификатор; програма; мерка; назив; почеток; крај; услови; прилози; статус; историја.

Релации

Апликацијата се поврзува со повикот; жалбеното мирување се применува на истиот повик.

Ограничувања

Продолжување рок и повлекување имаат автор и претходни вредности. Архивската јавна видливост се договара.

Насока за физички модел

Техничка разработка за SDD: стабилни примарни идентификатори, референцијални врски и ограничувања за уникатност се определуваат според деловниот модел. Износите се чуваат како точни децимални вредности со валута; временските настани имаат јасна временска зона. Овие дизајнерски избори не се претставуваат како дословни тендерски типови на колони.

Прием на податочниот слој

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

Изворна основа: МК SAM05:03–04; SAM06:04; физичкиот модел се потврдува во SDD.

Се чуваат одделни записи за претходно мислење, ex-ante исход, буџетско мислење и владина одлука.

Минимални деловни атрибути

Број; тип; подносител; институција; програма; верзија; датум; документ; исход; корекции.

Релации

Одговорот упатува на конкретно барање. Една програма може да има повеќе последователни одговори.

Ограничувања

Едно поле одобрено не е доволно да ги претстави различните институционални одлуки.

Насока за физички модел

Техничка разработка за SDD: стабилни примарни идентификатори, референцијални врски и ограничувања за уникатност се определуваат според деловниот модел. Износите се чуваат како точни децимални вредности со валута; временските настани имаат јасна временска зона. Овие дизајнерски избори не се претставуваат како дословни тендерски типови на колони.

Прием на податочниот слој

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

Изворна основа: TOR Approvals Register; МК SAM04; физичкиот модел се потврдува во SDD.

Апликацијата ја опишува компанијата и нејзиниот инвестициски проект во рамки на повикот.

Минимални деловни атрибути

Број; апликант; претставник; повик; мерка; датум; побарана помош; план; прилози; статус.

Релации

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

Ограничувања

Поднесената верзија и дополнувањата треба да останат разликувани; надворешните записи имаат ознака на потекло.

Насока за физички модел

Техничка разработка за SDD: стабилни примарни идентификатори, референцијални врски и ограничувања за уникатност се определуваат според деловниот модел. Износите се чуваат како точни децимални вредности со валута; временските настани имаат јасна временска зона. Овие дизајнерски избори не се претставуваат како дословни тендерски типови на колони.

Прием на податочниот слој

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

Изворна основа: TOR Applications Register; МК §4.4.4; SAM06; физичкиот модел се потврдува во SDD.

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

Минимални деловни атрибути

Примател; мерка; апликација; форма; вредност; договор; датум; статус; очекувани и постигнати резултати.

Релации

Записот ги поврзува одлуката, договорот, барањата за исплата и извештаите.

Ограничувања

Одобрена, договорена и исплатена вредност се различни факти и не смеат да се дуплираат во агрегатите.

Насока за физички модел

Техничка разработка за SDD: стабилни примарни идентификатори, референцијални врски и ограничувања за уникатност се определуваат според деловниот модел. Износите се чуваат како точни децимални вредности со валута; временските настани имаат јасна временска зона. Овие дизајнерски избори не се претставуваат како дословни тендерски типови на колони.

Прием на податочниот слој

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

Изворна основа: TOR Granted Aid Register; МК §4.4.5; физичкиот модел се потврдува во SDD.

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

Минимални деловни атрибути

Број; помош; договор; период; побарано; одобрено; образложение; потврдено исплатено; извор.

Релации

Еден договор може да има повеќе барања и повеќе реализациски записи; потребно е усогласување по период и износ.

Ограничувања

САМИС не врши паричен трансфер. Механизмот за потврда зависи од интеграциската и институционалната подготвеност.

Насока за физички модел

Техничка разработка за SDD: стабилни примарни идентификатори, референцијални врски и ограничувања за уникатност се определуваат според деловниот модел. Износите се чуваат како точни децимални вредности со валута; временските настани имаат јасна временска зона. Овие дизајнерски избори не се претставуваат како дословни тендерски типови на колони.

Прием на податочниот слој

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

Изворна основа: МК SAM06:09; SAM07:04 и 06; SAM09:04; физичкиот модел се потврдува во SDD.

Извештајот е службен поднесок со период и статус. Индикаторот има цел и мерна единица; измерената вредност има извор и период.

Минимални деловни атрибути

Број; тип; период; подносител; примател; статус; индикатор; почетна вредност; цел; тежина; резултат.

Релации

Примателските извештаи се поврзуваат со помош, а програмските и годишните извештаи ги консолидираат дозволените записи.

Ограничувања

Недостасувачка вредност не смее да се третира како нула без одобрено правило. Официјалниот сет се разликува од аналитички подмножества.

Насока за физички модел

Техничка разработка за SDD: стабилни примарни идентификатори, референцијални врски и ограничувања за уникатност се определуваат според деловниот модел. Износите се чуваат како точни децимални вредности со валута; временските настани имаат јасна временска зона. Овие дизајнерски избори не се претставуваат како дословни тендерски типови на колони.

Прием на податочниот слој

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

Изворна основа: TOR Reporting и Monitoring; МК SAM07–08; физичкиот модел се потврдува во SDD.

Ревизиската трага го објаснува дејството, а интеграцискиот запис го објаснува потеклото на преземен податок.

Минимални деловни атрибути

Корисник; време; операција; стари и нови вредности; IP; сервис; верзија; корелација; исход.

Релации

Настанот се врзува за предмет и документ. Надворешниот идентификатор овозможува контролирано ажурирање без дупликат.

Ограничувања

Во логовите не треба да се изложуваат тајни; деталите за минимизација и задржување се специфицираат во SDD.

Насока за физички модел

Техничка разработка за SDD: стабилни примарни идентификатори, референцијални врски и ограничувања за уникатност се определуваат според деловниот модел. Износите се чуваат како точни децимални вредности со валута; временските настани имаат јасна временска зона. Овие дизајнерски избори не се претставуваат како дословни тендерски типови на колони.

Прием на податочниот слој

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

Изворна основа: МК §5.1; SAM09:03; физичкиот модел се потврдува во SDD.

Идентификација и единствена најава. Надворешен актер: Надворешни корисници.

Разменети податоци

Идентитет и договорен контекст.

Услови

Неуспешна автентикација го спречува пристапот; успешна најава не дава автоматско застапување.

Тест и активирање

Конкретни endpoint адреси, credentials, мрежни опсези и SLA на надворешната институција не се измислуваат. Тие се внесуваат во договорот за интерфејс по усогласување. Пред прием се извршуваат успешна размена, недозволен повик и тест на недостапност.

Изворна основа: МК §4.2; SAM01:7; SAM06:01; разработка на договорот за интерфејс во SDD.

Задолжителен канал за размена со државни системи. Надворешен актер: Национална интероперабилност.

Разменети податоци

Договорени барања, одговори и статуси.

Услови

Се поддржуваат синхрона и асинхрона размена, грешки и повторни обиди; не се претпоставува директен заобиколен канал.

Тест и активирање

Конкретни endpoint адреси, credentials, мрежни опсези и SLA на надворешната институција не се измислуваат. Тие се внесуваат во договорот за интерфејс по усогласување. Пред прием се извршуваат успешна размена, недозволен повик и тест на недостапност.

Изворна основа: МК SAM03:03; SAM09:03; §5.1; разработка на договорот за интерфејс во SDD.

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

Разменети податоци

Идентификатор, назив, статус и други достапни атрибути.

Услови

Точните полиња се усогласуваат со сервисот; САМИС не создава сопствена копија на регистарот.

Тест и активирање

Конкретни endpoint адреси, credentials, мрежни опсези и SLA на надворешната институција не се измислуваат. Тие се внесуваат во договорот за интерфејс по усогласување. Пред прием се извршуваат успешна размена, недозволен повик и тест на недостапност.

Изворна основа: МК SAM09:06; §5.1; разработка на договорот за интерфејс во SDD.

Дозволени лични идентификациски проверки. Надворешен актер: Национален регистар.

Разменети податоци

Атрибути потребни за конкретната постапка.

Услови

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

Тест и активирање

Конкретни endpoint адреси, credentials, мрежни опсези и SLA на надворешната институција не се измислуваат. Тие се внесуваат во договорот за интерфејс по усогласување. Пред прием се извршуваат успешна размена, недозволен повик и тест на недостапност.

Изворна основа: МК §4.1–4.2 и §5.1; разработка на договорот за интерфејс во SDD.

Проверки за подобност и аналитички потреби. Надворешен актер: Надлежни даночни и царински органи.

Разменети податоци

Обврски, долгови и договорени деловни атрибути.

Услови

Интеграцијата е условена со создадени услови. Timeout не се толкува како долг или неподобност.

Тест и активирање

Конкретни endpoint адреси, credentials, мрежни опсези и SLA на надворешната институција не се измислуваат. Тие се внесуваат во договорот за интерфејс по усогласување. Пред прием се извршуваат успешна размена, недозволен повик и тест на недостапност.

Изворна основа: МК SAM09:05; разработка на договорот за интерфејс во SDD.

Финансиски податоци за следење на помошта. Надворешен актер: Министерство за финансии.

Разменети податоци

Open Finance, IFMIS или Трезор и нивни идни наследници.

Услови

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

Тест и активирање

Конкретни endpoint адреси, credentials, мрежни опсези и SLA на надворешната институција не се измислуваат. Тие се внесуваат во договорот за интерфејс по усогласување. Пред прием се извршуваат успешна размена, недозволен повик и тест на недостапност.

Изворна основа: МК §4.1; SAM09:04; разработка на договорот за интерфејс во SDD.

Објавување и пронаоѓање услуги со насочување кон САМИС. Надворешен актер: МДТ.

Разменети податоци

Опис, адреса, категории и дозволени јавни метаподатоци.

Услови

Идно вградување frontend функционалности е можност по барање, преку micro-frontends или еквивалент.

Тест и активирање

Конкретни endpoint адреси, credentials, мрежни опсези и SLA на надворешната институција не се измислуваат. Тие се внесуваат во договорот за интерфејс по усогласување. Пред прием се извршуваат успешна размена, недозволен повик и тест на недостапност.

Изворна основа: МК SAM05:07; §5.1; разработка на договорот за интерфејс во SDD.

Известување за статуси, рокови и активности. Надворешен актер: Национални и договорени канали.

Разменети податоци

Примател, шаблон, јазик, врска до предмет и статус.

Услови

Нотификацијата и правно релевантната достава мора да се разликуваат во моделот на доказ.

Тест и активирање

Конкретни endpoint адреси, credentials, мрежни опсези и SLA на надворешната институција не се измислуваат. Тие се внесуваат во договорот за интерфејс по усогласување. Пред прием се извршуваат успешна размена, недозволен повик и тест на недостапност.

Изворна основа: МК SAM01:9; SAM06:07; §5.1; разработка на договорот за интерфејс во SDD.

Централизација на веќе обработени програми и апликации. Надворешен актер: Даватели на помош 2.

Разменети податоци

Програми, апликации, жалби и доделена помош.

Услови

Се зачувуваат потекло и идентификатори; нема повторна евалуација на апликациите во САМИС.

Тест и активирање

Конкретни endpoint адреси, credentials, мрежни опсези и SLA на надворешната институција не се измислуваат. Тие се внесуваат во договорот за интерфејс по усогласување. Пред прием се извршуваат успешна размена, недозволен повик и тест на недостапност.

Изворна основа: МК §4.3.6; SAM09:01–03; разработка на договорот за интерфејс во SDD.

Јавна машинска размена и доверливост на документи како одделни интеграции. Надворешен актер: Национален портал и регистрирани даватели.

Разменети податоци

Јавни datasets и метаподатоци; потпис, печат и временска ознака.

Услови

Размената на јавни податоци не открива приватно досие; криптографската проверка е одделна од QR-приказот.

Тест и активирање

Конкретни endpoint адреси, credentials, мрежни опсези и SLA на надворешната институција не се измислуваат. Тие се внесуваат во договорот за интерфејс по усогласување. Пред прием се извршуваат успешна размена, недозволен повик и тест на недостапност.

Изворна основа: МК §4.1–4.2; SAM06:10; SAM07:07; §5.1; разработка на договорот за интерфејс во SDD.

Регистарот на корисници ги содржи основни податоци за корисниците на САМИС системот. На секој субјект треба да му се додели единствен идентификациски број со кој ќе се референцира низ целиот систем. За физичките лица тоа може да биде електронскиот број кој се издава од Централниот регистар на население, а за правните тоа треба да биде ЕДБС. Регистарот содржи име/назив на субјектот, идентификациски број, улога во системот, дополнителни информации согласно закон и лице за контакт.

Примена во дизајнот

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

Проверка на целосност

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

Изворна основа: МК §4.4.1.

Регистарот на програми (база на податоци) вклучува податоци за сите програми/планови на помош и соодветни мерки. Податоците за програмите се собираат и ажурираат во текот на одобрувањето на програмите. За секоја програма треба да се внесат следните податоци: Наслов на програмата, САМИС број на програмата, Број/код на програмата, опис на програмата, дизајнер на програмата, список на поврзани мерки, број на одобрување од КЗК, број на одобрување од Министерството за финансии, правна основа, класификација од државниот буџет, вредност на програмата, класификација на програмата од Владината програма, датум на почеток на програмата, времетраење на програмата, статус на програмата.

За секоја од програмските мерки треба да се обезбедат следните податоци: Наслов на мерката, САМИС број на мерката, број/код на мерката, образложение, цели, индикатори, категорија, регион, сектор, форма на помош, правила за помош, доделувач, имплементатор, список на задолжителни документи што треба да се поднесат, критериуми за подобност, правила за кумулација, повици за аплицирање, закони и стратегии.

Сите други информации за програмите треба да може да се видат само преку приложени .pdf датотеки, бидејќи тие се премногу специфични и се однесуваат само на една програма или на тесен сет на програми.

Примена во дизајнот

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

Проверка на целосност

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

Изворна основа: МК §4.4.2.

Податоците за одобрување на програмите за помош од страна на КЗК и МФ се забележуваат во рамки на модулот за одобрување на програми и базата на податоци на КЗК. Базата на КЗК содржи: ИД на програмата, број на одобрување на проект, конечна одлука на проект, број на одобрување од Владата, конечна одлука од Владата, датум на поднесување на проект, датум на одлука на Владата, датум на поднесување на одлука од Владата, датум на одлука од Владата, барање за ажурирање, ажурирање, жалба/коментар/прашање, решавање на жалба / одговор на коментар или прашање и статус на одобрување на програмата.

Базата на МФ содржи: ИД на програмата, број на одобрување од Министерството за финансии, конечна одлука од Министерството за финансии, датум на поднесување, датум на одлука, барање за ажурирање, ажурирање, статус на одобрување.

Примена во дизајнот

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

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

Проверка на целосност

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

Изворна основа: МК §4.4.3.

Овој регистар ќе ги чува достапните податоци за апликациите за повици и деталите за евалуација. Следниот сет на податоци поврзани со барателот и апликацијата за државна помош е задолжителен: ИД на апликант, поврзани субјекти, деловни информации на компанијата, ИД на апликацијата, ИД на мерката, ИД на повик, датум/време на поднесување, датум на одлука, писмо за намери, бизнис план, придружни документи, барана помош, одобренa помош, кумулација, одлука за кумулација, жалба, одлука за жалба, статус на апликацијата, надворешна апликација.

Апликантот не мора да ги достави сите податоци и документација бидејќи некои од податоците/документите можат да се добијат од соодветните регистри преку рамката за интероперабилност.

Примена во дизајнот

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

Проверка на целосност

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

Изворна основа: МК §4.4.4.

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

Примена во дизајнот

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

Проверка на целосност

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

Изворна основа: МК §4.4.5.

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

Инсталација и работење

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

SRS и SDD

§5.2.3, насловена SRS, експлицитно бара модел на податоци, дизајн на база со DDL, размена на податоци, книга на грешки, статички и динамички UML, модел на случаи на употреба и дизајн на перформанси. §5.2.4 бара SDD со инфраструктурна интеграција, софтверски компоненти, верзии, firmware и лиценци. Терминолошкото преклопување не е основа да се изостави содржина: структурата се усогласува и двата документа се одобруваат пред испораката.

Крајна испорака

Најдоцна 20 работни дена пред истекот на договорот за одржување се доставуваат: спецификација на развиените функции; ажурирана архитектура и врски; лиценци со траење; целосен код со опис и build/deployment постапки; опис на базата со табели и релации; административни и кориснички упатства; API и останата документација. Постоечката документација се ажурира без надомест; за непостоечката се применува условот за адаптивни часови од §7.6.

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

Изворна основа: МК §5.2–5.4; §6.1; §7.6.

Превенција

Превентивниот опфат вклучува постојан автоматски мониторинг и алармирање, дијагностика, закрпи, мерење и анализа на параметри, оптимизација, информативни графикони, видеа и упатства. Се поднесуваат месечни извештаи за трансакции, даватели и видови услуги. Се одржуваат копии, мониторинг на ранливости, акциски план за нивно отстранување и релевантни интеграциски и smoke тестови.

Реакција

Реактивниот опфат вклучува дијагностика и корекции на апликацијата, базата и компонентите; грешки од рутинска корисничка работа или развој; конфигурациски проблеми и повторно оспособување со последните резервни копии. Се обезбедува сопствен тикетинг систем и се користи системот на договорниот орган кога е обезбеден.

Контролирана промена

Адаптивното барање се означува посебно во тикетинг системот. Договорниот орган го утврдува приоритетот, а повисокиот приоритет има предност независно од редот на поднесување. Следуваат анализа ако е побарана, естимација, временска рамка и одобрување; развој и тестирање; корисничко тестирање и договорено продукциско поставување; ажурирање на документацијата. Бројот на часови не се измислува во оваа разработка.

Надградби и континуитет

Надградбите на оперативни и апликативни решенија користат стабилни поддржани верзии и се верификуваат преку независни безбедносни тестови и алатки на договорниот орган. Лиценците ги набавува договорниот орган освен ако е поинаку утврдено. За end-of-life/end-of-support и критично ранливи компоненти се подготвуваат миграциски и тест-план, се проверува компатибилноста и се применува автоматизирано управување со закрпи.

Интервенциите во продукција ја земаат предвид работата 24/7 и се изведуваат со минимален прекин, во најмалку оптоварен термин и без губење податоци. Microsoft, Red Hat, VMware и Cisco во изворот се примери на производители, а не обврска за набавка на секој наведен производ.

Изворна основа: МК §6.1–6.5.

Организација

Се применува призната методологија за ИТ проекти. Проектниот план ги опфаќа управувањето, архитектурата/backend, frontend, UX/UI, базите и интеграциите, инфраструктурата и сајбер-безбедноста. Конкретните лица и капацитети се утврдуваат во одобрениот план.

Плански испораки

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

Комуникациски правила

Се одржуваат редовни состаноци со клучниот тим и Министерството. Обрасците за управувачки документи се усвојуваат најдоцна еден месец од потпишување. Комуникацијата е на македонски јазик; неформалните разговори се поткрепуваат со е-пошта. Се обезбедуваат телефон, адреса за инциденти и систем за грешки/барања. Се почитуваат тековните и идните политики на МДТ.

Контрола

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

Квалитет и ризици

Планот за квалитет содржи функционални тестови, скрипти, тест-податоци, методологија, алатки и резултати. Стрес и перформансни тестови се извршуваат на обезбедената инфраструктура. Се вршат редовни прегледи на код и конфигурација. Ризиците се идентификуваат, анализираат и следат со мерки и одговорни лица; нивниот статус и ефективноста на мерките се пријавуваат редовно.

Изворна основа: МК §7.1–7.7.

Роковите започнуваат со евидентирањето на инцидентот преку договорениот канал. Одѕив е преземање од стручно лице и започнување дијагностика, а не автоматска потврда.

Нивоа 1 и 2: календарски часови и поддршка 24/7. Нивоа 3 и 4: понеделник–петок 07:30–17:30, без државни празници и неработни денови. Санацијата може да биде привремена, но не ја укинува обврската за трајно решение.

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

Достапноста е најмалку 99,8% месечно и годишно. Исклучок е само навремено најавено, претходно писмено одобрено одржување во одобрениот термин. При несогласување предност имаат мониторингот, логовите и тикетите на договорниот орган.

Изворна основа: МК §6.3.1.

Се предаваат опис на мерките, верзии и резултати од повторните тестирања. Се следат ENISA, NIST, ISO/IEC 27001, CIS Benchmarks и упатствата на производителите, како што се наведени во спецификацијата. Овие насоки не се претвораат во автоматски доказ за сертификација.

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

Обуките се на македонски јазик, на финализиран и инсталиран систем, со упатување на верзијата на прирачниците. Опфатот вклучува вработени во КЗК и почетна група даватели, спроведувачи и апликанти/приматели според спецификацијата, не повеќе од 50 лица. Материјалите се усогласуваат со платформата за е-учење на Министерството.

Изворна основа: МК SAM01:06; §6.2; §6.4–6.5.

Пред конечниот прием се проверуваат изворниот код, документацијата, инсталациските материјали, тестовите и корисничките упатства. Испораката се идентификува со конкретна верзија и не се сведува на презентација или визуелен прототип.

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

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

Изворна основа: МК §4.2; §5.2; §6.1; §7.

Цел: Програма со мерки и подготвена документација. Предуслов: Иницијатива за нова шема на државна помош.

Учесници: Дизајнер на програма. Влезови: Правна основа, стратегии, цели и наменети категории приматели.

Очекуван резултат

Секој повик може да се проследи до мерка и до верзијата на одобрената програма.

Негативен или граничен случај

Недефиниран давател или критериум се враќа на доработка пред формално поднесување.

Евиденција на извршување

Резултатот се документира со верзија, околина, датум, извршувач и приложен доказ. Овде е дефиниран тестот; не е тврдење дека тестирањето е веќе извршено.

Изворна основа: TOR SA Programming; МК §4.3 и §4.4.2.

Цел: Апликација со потврда и статус. Предуслов: Избор на активен јавен повик.

Учесници: Апликант. Влезови: Образец, компаниски податоци, план, износ и прилози.

Очекуван резултат

Подносителот и спроведувачот гледаат ист идентификатор и иста поднесена верзија.

Негативен или граничен случај

Недостасувачки прилог или затворен повик не дозволува успешно поднесување.

Евиденција на извршување

Резултатот се документира со верзија, околина, датум, извршувач и приложен доказ. Овде е дефиниран тестот; не е тврдење дека тестирањето е веќе извршено.

Изворна основа: МК SAM06:01; §5.1.

Цел: Жалбен предмет со следлив статус. Предуслов: Незадоволство од одлука за апликација.

Учесници: Апликант и надлежен решавач. Влезови: Одлука, образложение и прилози.

Очекуван резултат

Друга избрана компанија од истиот повик не може да ја заобиколи блокадата.

Негативен или граничен случај

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

Евиденција на извршување

Резултатот се документира со верзија, околина, датум, извршувач и приложен доказ. Овде е дефиниран тестот; не е тврдење дека тестирањето е веќе извршено.

Изворна основа: МК SAM05:05 и SAM06:04.

Цел: Целосно или делумно одобрено или одбиено барање. Предуслов: Исполнет договорен услов за барање средства.

Учесници: Примател и давател. Влезови: Договор, период, износ, извештај и докази.

Очекуван резултат

Се прикажуваат одделно побараниот и одобрениот износ и причината за исходот.

Негативен или граничен случај

Одобрениот износ може да се разликува од побараниот; исплата не се извршува во САМИС.

Евиденција на извршување

Резултатот се документира со верзија, околина, датум, извршувач и приложен доказ. Овде е дефиниран тестот; не е тврдење дека тестирањето е веќе извршено.

Изворна основа: МК SAM06:09 и SAM07:04.

Цел: Централизирана евиденција за надворешна помош. Предуслов: Надворешен систем доставува податоци.

Учесници: Давател 2 и интеграциски тим. Влезови: Програми, апликации, жалби, доделена помош и изворни идентификатори.

Очекуван резултат

Повторна серија не создава дупликат, а грешките имаат јасен запис за корекција.

Негативен или граничен случај

Примените апликации не се испраќаат на нова евалуација во САМИС.

Евиденција на извршување

Резултатот се документира со верзија, околина, датум, извршувач и приложен доказ. Овде е дефиниран тестот; не е тврдење дека тестирањето е веќе извршено.

Изворна основа: МК §4.3.6 и SAM09:01–03.

Цел: Записник со докази и предадени материјали. Предуслов: Комплетирана верзија за прием.

Учесници: МДТ, корисници и изведувач. Влезови: SRS, тест-план, извештаи и испораки.

Очекуван резултат

Изворниот код, упатствата и резултатите од тестовите се предадени пред конечниот прием.

Негативен или граничен случај

Не се прогласува прием со отворени критични и високи ранливости.

Евиденција на извршување

Резултатот се документира со верзија, околина, датум, извршувач и приложен доказ. Овде е дефиниран тестот; не е тврдење дека тестирањето е веќе извршено.

Изворна основа: МК §4.2; SAM01:11–12; §5.2.

Цел: Употребливо метаподаточно поле. Предуслов: Потреба од нов атрибут.

Учесници: Администратор и сопственик на процес. Влезови: Тип, назив, зависност и правила за поле.

Очекуван резултат

Ново поле се внесува, пребарува и извезува со иста семантика.

Негативен или граничен случај

Промена на тип не смее тивко да ги расипе веќе внесените вредности.

Евиденција на извршување

Резултатот се документира со верзија, околина, датум, извршувач и приложен доказ. Овде е дефиниран тестот; не е тврдење дека тестирањето е веќе извршено.

Изворна основа: МК SAM01:10.

Цел: Докажан капацитет и извештај за перформанси. Предуслов: Верзија подготвена за прием.

Учесници: QA и инфраструктурен тим. Влезови: Тест околина, кориснички профили и мерења.

Очекуван резултат

Барањето за најмалку 200 истовремени корисници и одговор до 2 секунди е проверено во договорените услови.

Негативен или граничен случај

Метриката за одговор и тест-профилот се усогласуваат; не се прогласува успех само со број на регистрирани сметки.

Евиденција на извршување

Резултатот се документира со верзија, околина, датум, извршувач и приложен доказ. Овде е дефиниран тестот; не е тврдење дека тестирањето е веќе извршено.

Изворна основа: МК §5.1; SAM01:12.

Цел: Конзистентни обрасци и извештаи. Предуслов: Измена на образец или шаблон.

Учесници: Администратор и сопственик на процес. Влезови: Полиња, преводи, задолжителни прилози и постојни нацрти.

Очекуван резултат

Поднесен предмет може да се прикаже со структурата со која бил примен.

Негативен или граничен случај

Начинот за третман на веќе поднесени записи се утврдува во SRS и не се менува ретроактивно.

Евиденција на извршување

Резултатот се документира со верзија, околина, датум, извршувач и приложен доказ. Овде е дефиниран тестот; не е тврдење дека тестирањето е веќе извршено.

Изворна основа: МК SAM01:10; SAM07:07; техничка разработка.

Цел: Извештај достапен само во дозволениот опфат. Предуслов: Доделување право за аналитика.

Учесници: Администратор и сопственик на извештај. Влезови: Дефиниција на извештај и институционален опфат.

Очекуван резултат

Портал, API и датотечен извоз применуваат усогласени права.

Негативен или граничен случај

Правото на дефиницијата не смее да открива податоци над дозволениот институционален опфат.

Евиденција на извршување

Резултатот се документира со верзија, околина, датум, извршувач и приложен доказ. Овде е дефиниран тестот; не е тврдење дека тестирањето е веќе извршено.

Изворна основа: МК SAM08:03–06.

Цел: Потврдено разрешена забелешка. Предуслов: Исполнета забелешка од тест или контрола.

Учесници: Одговорен обработувач и контролор. Влезови: Наод, активност, доказ и повторна проверка.

Очекуван резултат

Исходот упатува на конкретен тест или документ што ја потврдува поправката.

Негативен или граничен случај

Затворање тикет без повторна проверка не е доказ за исполнетост на барањето.

Евиденција на извршување

Резултатот се документира со верзија, околина, датум, извршувач и приложен доказ. Овде е дефиниран тестот; не е тврдење дека тестирањето е веќе извршено.

Изворна основа: МК §4.2; SAM01:11–12; §6.

Цел: Доказ дека модулите работат поврзано. Предуслов: Приемно сценарио со повеќе улоги.

Учесници: Кориснички претставници и QA. Влезови: Програма, повик, апликација, одлука, договор и извештаи.

Очекуван резултат

Идентификаторите, износите, статусите и известувањата остануваат усогласени низ целиот циклус.

Негативен или граничен случај

Поединечно успешен екран не докажува исправно предавање меѓу улоги и модули.

Евиденција на извршување

Резултатот се документира со верзија, околина, датум, извршувач и приложен доказ. Овде е дефиниран тестот; не е тврдење дека тестирањето е веќе извршено.

Изворна основа: МК §4.2–4.3; SAM01:11.