STRUCT-KEY-UNIQUE - klucze naturalne bez duplikatów (B_01.01, B_01.02, B_01.03, B_02.01, B_02.02, B_02.03, B_03.01, B_03.02, B_03.03, B_04.01, B_05.01, B_05.02, B_06.01, B_07.01)

Oficjalny tekst kontroli (EBA, verbatim)

For open tables, you cannot have multiple rows with identical key values

Źródło: kontrola techniczna EBA 806 (arkusz "DPM Technical Checks", kategoria "Additional Plain-csv" w oficjalnym zestawieniu kontroli technicznych RoI). RoI Builder wykonuje ją jako kontrolę strukturalną STRUCT-KEY-UNIQUE.

Co sprawdza ta reguła

Kontrola obejmuje 14 szablonów otwartych. Każdy ma klucz naturalny zdefiniowany przez taksonomię - od jednokolumnowego (c0010: LEI w B_01.02, numer referencyjny ustalenia umownego w B_02.01, kod identyfikacyjny dostawcy w B_05.01) po ośmiokolumnowy klucz B_02.02. Żadne dwa wiersze szablonu nie mogą nieść identycznego klucza: każde wystąpienie po pierwszym daje jedno naruszenie blokujące na tym wierszu, a parametry naruszenia niosą numer wiersza pierwszego wystąpienia.

Wiersze z NIEKOMPLETNYM kluczem (jakakolwiek pusta komórka klucza) są tu wyłączone: każda pusta komórka klucza to już blokujące naruszenie STRUCT-MANDATORY, więc nic nie przechodzi po cichu i żadna komórka nie jest raportowana podwójnie. Bezkluczowa tabela zamknięta B_99.01 jest poza zakresem - jej limit wierszy to STRUCT-CLOSED-TABLE-ROWS.

To jedyny egzekutor unikalności w całym stosie walidacji: pomiar na oficjalnej liście reguł - W2 nie zawiera żadnej reguły unikalności (0 z 71); duplikaty to sprawa strukturalna. Szczegół przydatny przy lekturze oficjalnych artefaktów: kontrola EBA 806 leży w arkuszu "DPM Technical Checks", a jej kategoria brzmi "Additional Plain-csv" (jedyny taki wiersz; spec mapowania dokumentuje to tak, jak opublikowano).

To kontrola strukturalna (warstwa STRUCT, severity: blocking). Jej niezaliczenie oznacza techniczne odrzucenie paczki przy przyjęciu (feedbackMain = REJECTED). Warstwa strukturalna jest jedyną warstwą blokującą złożenie.

Najczęstsze przyczyny

• Ten sam podmiot, ustalenie umowne albo dostawca wprowadzony dwa razy (np. po scaleniu dwóch arkuszy roboczych).
• Skopiowany wiersz zmieniono w kolumnach danych, ale komórki klucza zostały bez zmian.
• W B_02.02 wiersze różnią się tylko kolumną niekluczową - wszystkie 8 kolumn klucza jest identyczne, więc dla rejestru to ten sam wiersz zgłoszony dwa razy.

Jak to naprawić, krok po kroku

1. Otwórz wskazany szablon i znajdź wskazany wiersz - naruszenie podaje jego numer, wartości klucza i numer wiersza pierwszego wystąpienia.
2. Porównaj oba wiersze. Jeśli opisują to samo, scal różnice do pierwszego wiersza i usuń duplikat.
3. Jeśli opisują różne rzeczy, popraw komórkę klucza błędnie powtarzającą klucz pierwszego wiersza (np. numer referencyjny albo rank).
4. Uruchom walidację ponownie i potwierdź, że naruszenie zniknęło.

Przykład: błędnie vs poprawnie

Błędnie - dwa wiersze B_01.02 z tym samym kluczem; naruszenie oznacza wiersz 2 i wskazuje wiersz 1 (firstRowNumber = 1):

Wiersz	c0010 (LEI podmiotu)	c0020 (nazwa podmiotu)
1	549300Q5EH2NP82EPE32	Bank Testowy A
2	549300Q5EH2NP82EPE32	Bank Testowy A - oddzial

Poprawnie - każdy wiersz ma własny klucz (tu: odrębny LEI na podmiot); oddział to nie drugi wiersz B_01.02 pod tym samym LEI - oddziały żyją w B_01.03 pod własnym, dwukolumnowym kluczem.

Powiązane reguły

• STRUCT-MANDATORY - puste komórki klucza raportowane są tam; wiersze z niekompletnym kluczem są wyłączone z tej kontroli unikalności.
• STRUCT-CLOSED-TABLE-ROWS - odpowiednik dla tabeli zamkniętej: bezkluczowy B_99.01 dopuszcza najwyżej jeden wiersz.
• STRUCT-FK - odwołania międzyszablonowe rozwiązują się po tych kluczach naturalnych, więc zdublowane klucze czyniłyby cele odwołań niejednoznacznymi.