...
I forbindelse med at CPR moderniserer GCTP Services er der en række områder hvor GCTP Services generelt afviger fra de tidligere services, herunder funktionaliteter som udgår. Disse afvigelser er en del af version 2 af GCTP protokollen (<Gctp v="2.0">).
| Anchor | ||||
|---|---|---|---|---|
|
...
Tidligere ville myndighedsfelter i services ofte være låst efter man har initieret servicen. Typisk låst , typisk med den indberettende myndighed, på vegne af eller land.
Dette er ikke længere tilfældet. Myndighedsfeltet i en indberetning vil fremadrettet altid være åbent og man kan indsende en vilkårlig af systemet kendt myndighed. Dette betegnes som den konstaterende myndighed, dvs. Altså den myndighed der har konstateret de data der indberettes.
Ofte vil det være selvsamme myndighed som der er tilknyttet brugeren, der er logget ind er tilknyttet, men det kan også være en anden myndighed. Altså at man er . F.eks. er man logget ind som en kommune, men har behov for at indberette, at det er land der har konstateret data.
...
Det er ikke alle myndigheder der kan anvendes som konstaterende myndighed og da dette er forskelligt fra service til service, er dette dokumenteret som en del af servicedokumentationen på den individuelle service.
| Anchor | ||||
|---|---|---|---|---|
|
Under initiering har man før kunne angive hhv. på vegne af og land som en del af initieringsrequestet, hvilket så blev ført med over i selve indberetningen. Dette udfases, da man i stedet arbejder men en konstaterende myndighed. Der er i de fleste services et ét specifikt felt hvor man angiver denne konstaterende myndighed og hvor det tidligere har været låst er det nu et åbent felt hvor man kan angive den myndighed der menes at have konstateret data der indberettes.
I stedet for at anvende på vegne af eller land, angiver man således i selve myndighedsfeltet på indberetningen hvilken myndighed der har konstateret data, og i det tilfælde det havde været på vegne af eller land, så er det den myndighed man angiver.
...
I CPRWeb vil felterne løbende bliver fjernet fra initieringsskærmbilledet.
| Anchor | ||||
|---|---|---|---|---|
|
I udvalgte services er det muligt at angive, at data der indberettes, er verificeret. Disse vil altid være åbent for ændring, og vil altid være markeret som standard.
Hvis der redigeres i eksisterende data, vil den bære den markering der måtte være i det eksisterende data.
Dette er forskelligt fra tidligere, hvor det var forskelligt fra service til service om feltet var låst eller ej, og hvor vidt der blev forudfyldt.
| Anchor | ||||
|---|---|---|---|---|
|
En person kan have indberetningsdata liggende i en kladde, som afventer endelig godkendelse, eller bare en dato for offentliggørelse. Hvis en person har data i dette kladdesystemet, også kaldet Vent, så vil der komme en advarsel, når man forsøger at validere eller gemme en indberetning på denne person.
Dette er som tidligere bare en advarsel, og man kan gemme data alligevel, hvis man gemmer igen efter at have fået advarslen.
Dette er forskelligt fra tidligere, hvor det ikke var alle indberetninger, der kom med denne advarsel.
Hensigten med advarslen er, at personen potentielt kan have data liggende i kladdesystemet, som vil overskrive de data man ellers indberetter.
...
En række GCTP Services understøtter indberetning af data i tabeller, hvor der således kan være flere rækker. I den gamle version af GCTP er der ikke et entydig krav om, at man som anvender identificerer hver række med en nøgle, men det . Dette er et KRAV ved anvendelse af tabeller i den moderniserede GCTP Services.
Nøgler skal altid udfyldes, skal være unikke i GCTP kaldet, og der skal anvendes de nøgler som en GCTP service evt. har udstedet under initiering.Nøglerne SKAL være unikke.
En række i GCTP før modernisering kunne f.eks. se ud som herunder, hvor man ønsker at lave en ny registrering af notatlinie 1 i Kommunale notater
...
I den moderniserede GCTP skal k-attributten være udfyldt med en unik nøgle, herunder med værdien k="NOTAT1_NOEGLE"
...
Der understøttes kun ISO-8859-1 encoding.
| Anchor | ||||
|---|---|---|---|---|
|
Sekundære services er udgået af version 2 af GCTP Protollen og services protollen. Services der tidligere har fungeret med sekundære services håndteres fremadrettet med komposit services, hvor de tidligere sekundære services er indlejret i hovedservicen, såfremt deres data er påkrævet for servicens funktionalitet. For sekundære services der ikke er påkrævet, skal disse services i stedet anvendes og kaldes for sig selv, som selvstændige services.
| Anchor | ||||
|---|---|---|---|---|
|
...
Dette udfases og services forsimples til at indeholde så få ekstra domæner som muligt. F.eks. vil en flytning fremadrettet kun kunne anvendes til at flytte personen. Har man behov for at registrere beskyttelse, skal man derfor anvende denne service beskyttelsesservicen til det formål.
Der er enkelte services hvor disse ekstra domæner stadig vil være til stede, dog i mindre omfang. Men fF.eks. vil en Indrejse vil kræve mere end bare oplysninger om indrejsen.
...
Dokumentation forefindes kun på dansk.