DEBITOR LEVERANDØRMØDE 20. OKT 15. Oplæg til gennemgang på mødet

Transkript

1 DEBITOR LEVERANDØRMØDE 20. OKT 15 Oplæg til gennemgang på mødet

2 Agendag 1. Velkomst / bordet rundt Kort status Formål 2. Revideret begrebsmodel Gennemgang af større tilpasninger/principielle afklaringer Udeståender/spørgsmål 3. Servicemodel Oplæg til model / fase opdelt 4. Anvendelse af ØiR Klassifikationssystem Gennemgang af sammenhæng til debitorsnitfladen 5. Next step Tidsplan

3 Velkomst / status Bordet rund Siden sidst Intens og meget konstruktiv dialog med alle leverandører Kommunemøde Deltagere med viden indenfor økonomi, debitor og systemforvaltningen heraf Kommuner: Ballerup, Odense, Århus og København Tilbagemelding Positiv! Forretningsmæssig er vi på ret vej. Kommunerne ønsker at blive inddraget, om vi ændre i den forretningsmæssige tilgang Forslag om at tage nye områder i en runde 2 Fx berosættelse ifm. klagesager, fuldt dækkende modreningsflow KOMBIT: Arbejdet på at færdiggøre begrebsmodel og lave oplæg til servicemodel for en version 1

4 Siden sidst tidsplan fra 13SEP15 Forslag udsendes v 0.1 Præsentation af udsendt materiale v 0.1 Udsendelse af nyt forslag med feedback v møder KOMBIT og leverandører v 0.2 Udsendelse af nyt forslag med feedback /10 v 0.3 Fælles workshop om endeligt udkast v 0.3 Udsendelse af endeligt udkast v 0.9 Modtagelse af skriftligt feedback v 0.9 Endelig version udsendes v 1.0

5 Formål Begrebsmodel Præsentere de væsentlige/principielle afklaringer, som er foretaget som konsekvens af leverandørdialog Få afklaret udeståender og spørgsmål, hvor der ikke har været et (fælles) svar i leverandørdialogen Servicemodel Feed back på og fælles drøftelse af KOMBITs første version af servicemodel. Det vil danne grundlag for næst version, som vil komme i skriftlig hørring hos leverandørerne ØiR Klassifikationssystem Information om det påtænkte klassifikationssystem og dets betydning for ØiR Debitor snitfladen herunder debitorløsningernes tolkning af modtagne data.

6 Begrebsmodel (1/5) Gennemgang af større tilpasninger/principielle afklaringer Debitorløsningen har ansvar for at foretage den fulde finanspostering af bevægelser på debitorkontoen Fagsystemer skal dermed ikke foretage en parallel bogføring, som det fx kendes ifm. udbetaling fra fagløsningerne Det omfatter både fordringer og indbetalinger

7 Begrebsmodel (2/5) Debitorkonto Vil det give mening også at kunne være medhæfter for en hel konto Debitorspecifikation: Hvordan håndteres forskellige krav til forskellige fagsystemer Vil der være forretningsregler som afhænger af disse værdier? Kunne de erstattes af tekst?

8 Begrebsmodel (3/5) Fordring Ændringer: Bilag tilføjet Kontaktinformation og DebitorFinansInfo tilføjet Afklaringer/tilføjelser: Er der alligevel behov for SRB på en fordring Hvad kan man regulere på en fordring som kræver reference til en anden fordring Hvad tænkes FordringSpecifikation at bruges til Kan man have Kontaktinfo og DebitorFinansInfo uden materialemodtager

9 Begrebsmodel (4/5) Delfordring Ændringer: Posteringsoplysninger bliver Afklaringer/tilføjelser: Skal der indføres en EFIFordringstype Hvordan finanskonteres indbetalinger Skal fagsystemet selv bestemme hvilke delfordringer der kan dækkes af andre, eller udledes det af delfordringstyper Ændringer Ændringsbegrebet slettes og attributterne flyttes ned på delfordringen Der vil kun være ændringskoder på en delfordring, hvis den har reference til en anden delfordring, og derfor har ændret denne Koderne vil ikke være nødvendigvis være EFI koder

10 Begrebsmodel (5/5) Parter Ændringer: Virkning tilføjet Afklaringer/tilføjelser: Ligestillingspartner, ikke altid juridisk medhæfter? AlternativAdresse ændres til OIOUBL Fjerne part og eksplicit gøre typerne til en del af parterne

11 Servicemodel (1/10) Integrationsmønster for debitorløsning SFTP Masseforsendelser SFTP Asynkron Fagsystem WS Volumenforsendelser (100) ØiR Debitorløsning WS Enkelt- Forsendelse (1) WS Synkron

12 Servicemodel (2/10) Overordnede principper for opdeling (1/2) Større dataforsendelser håndteres (batchleverance) Asynkront Filbaseret / SFTP-baseret Samme indholdsmæssige datastruktur, XML, som synkrone webservices Enkeltforsendelse hånderes (straksleverance) Synkront Webservice Datastruktur i XML

13 Servicemodel (3/10) Overordnede principper for opdeling (2/2) Opret Fagsystemer anvender Opret-operationen til oprettelse af Debitorkonto, Fordring og Delfordring Indbetaling på en eller flere delfordringer Opret findes i både en synkron og asynkron version Handlingsoperationer Ajourføring af debitorkontoen med dens tilhørende elementer Hent information om debitorkonto Søgning af debitorkonti Der er tale om en sammensat service med operationer, som repræsenterer ovennævnte handler Synkron service på en dataforekomst

14 Servicemodel (4/10) Opret Generelt Opret-operationen fungerer, som man kender den fra OIO Sag, dog således, at det er fagsystemet, som angiver UUID for de enkelte forekomster. Der kan foretages samtidig oprettelse af debitorkonto med dens underelementer (fordring, delfordringer m.m.) Efterfølgende tilføjelse af fordringer, delfordringer og indbetalinger er ligeledes opret Korrekt af den delfordring = oprettelse af ny delfordring Debitorløsningen Skal validere oprettelsen, dvs. om modtagne data er i overensstemmelse med det aftalte samt at fagsystemet er autoriseret til at foretage oprettelse Oprettelse vil altid ske i kontekst af en debitorkontor. Valideres en opdatering negativ skal samtlige opret under denne debitorkonto afvises.

15 Servicemodel (5/10) Handlingsoperationer Generelt Placeret i en webservice, som flere operationer. En af disse operationer er Opret Understøtter en debitorløsning ikke en af de angivne operationer, da skal debitorløsningen angive et kvalificeret retursvar herom Operationer RetPart RetTilstand Søg Hent ForetagEjerskifte (bortfalder?)

16 Servicemodel (6/10) Handlingsoperationer RetPart Scope Skift af part med virkningsperiode JuridiskMedhæfter (UUID reference til delfordring) Materialemodtager (UUID reference til debitorkonto) (Juridisk Ansvarlig (UUID reference til Debitorkonto)) Angivelse eller skift af alternativ adresse for JuridiskMedhæfter, Materialemodtager og Juridisk Ansvarlig Reference til UUID hovedobjekt + part (identifikation af parten) Angivelse af virkning Fradato Lig dags dato eller senere Debitorløsningen Er ansvarlig for håndtering af historik Validerer at fagsystemet er autoriseret til at foretage operationen på det angive dataobjekt Skal alene validere om fradato ligger indenfor virkningsperioden af partsobjektet. Ved negativt udfald, skal rettelsen afvises.

17 Servicemodel (7/10) Handlingsoperationer RetTilstand Scope (version 1) Debitorkonto (UUID reference til delfordring) Ajourføring af OpkrævningsStatus Debitorløsningen Validerer at fagsystemet er autoriseret til at foretage operationen på det angive dataobjekt Simpel valideringen ift. OpkrævningsStatus. NB: Samme operation kan i en evt. senere version udbygges til at dække berosættelse

18 Servicemodel (8/10) Handlingsoperationer Søg Søgeparametre Altid debitoridentifikation og/eller juridisk ansvarlig Debitorkonto Periode Debitorkontotype Fordringer Forfaldsdato Opkrævningsstatus Delfordringer Periode Delfordringstype Åbne/lukkede Kan indbetales til Output Primært lister af fundne UUID på debitorkonto UUID på fordringer UUID på delfordringer Anden central info der kan sikre, at man kan identificere det man leder efter Debitorløsningen Validerer at fagsystemet er autoriseret til at foretage operationen, samt foretage dataafgrænsning ift. autorisation

19 Servicemodel (9/10) Handlingsoperationer Hent Input UUID for det element/objekt der hentes Fx vil man hente en specifik delfordring, angiver man ikke fordring og debitorkonto Der kan hentes flere debitorkonti, fordringer eller delfordringer Man henter altid på samme niveau Man kan hente fra forskellige øvre niveauer, fx fordringer tilhørende forskellige debitorkonti eller indenfor samme debitorkonto? Filtreringsparametre Debitorkonto Åbne/lukkede fordringer/delfordringer Fordringer Forfaldsdato Opkrævningsstatus Åbne/lukkede delfordringer Delfordringer Periode Delfordringstype Åbne/lukkede Kan indbetales til Output Resultater inden for afgrænsning Hvilken information skal med for de forskellige afgrænsninger? Skal historik med? Debitorløsningen Validerer at fagsystemet er autoriseret til at foretage operationen, samt foretage dataafgrænsning ift. autorisation

20 Servicemodel (10/10) Handlingsoperationer ForetagEjerskifte Input? Output? Debitorløsningen Validerer at fagsystemet er autoriseret til at foretage operationen, samt foretage dataafgrænsning ift. autorisation Alternativt E&E vil manuelt oprette nye konti og nedskrive gamle fordringer. E&E ikke har ikke behov for ejerskiftefunktion. Der er enighed om, at benytte E&E modellen som en generel model Derfor skal der ikke i version 1 laves en specifik ejerskiftefunktion. Der skal ifm. version 2 afklares om øvrige løsninger/interessenter er enige heri (parkering, forbrugsafgifter m.fl.)

21 ØiR Klassifikationssystem (1/4) Begrebsmodellen, benytter taxonomier i Organisation Myndighed: cvr.nr. (URN:OIO:CVR-NR:xxxxxxxx) It-system: GUID Klassifikation Alle øvrige værdisæt Klassifikation består af GUID + brugervendt nøgle Organisatoriske referencer, Fx debitorkontos OrganisatoriskReference Angives i debitorsnitfladen, som en klasse (element) i klassifikation For at mindste ØiRs brug af Organisation Fagløsningen finder værdien ved en relation mellem den organisatoriske enhed i fagløsningen og en klasse (element) i klassifikation

22 ØiR Klassifikationssystem (2/4) ØiR Klassifikationssystem Hierarkisk struktur Klassifikationselementerne har en GUID og brugervendt nøgle Hierarkiet kan beskrives i en række niveauer Brugervendte nøgler er nødvendigvise ikke unikke indenfor et hierarki Niveau 1 Niveau 2 Niveau 3 Niveau 4 GUID Nøgle GUID Nøgle GUID Nøgle GUID Nøgle GUID Nøgle GUID Nøgle GUID Nøgle GUID Nøgle GUID Nøgle GUID Nøgle GUID Nøgle GUID Nøgle

23 ØiR Klassifikationssystem (3/4) Anvendelse af ØiR Klassifikation i registrering Alle registreringer anvender GUID en, fx debitorkontotype ERP-løsningen kan ud fra klassifikationens opbygning udlede overordnede niveauer. Både i form af GUID og brugervendte nøgler Anvenderløsningens forretningslogik bestemmer, hvor detaljeret registreringen kan/skal være. Jo højere niveau desto mere detaljeret angivelse med flere informationer fra overliggende niveauer

24 ØiR Klassifikationssystem (4/4) ØiR Klassifikation Struktur for debitorområdet Fælleselementer, fx Debitorkonto.Type Delfordring.Enhed Delfordring.EFIfordringstype Løsningsspecifikt (KY, KSD, ), fx Delfordring.Type Delfordring.Ændringstype Myndighedsspecifikt (kommune), fx Debitorkonto.OrganisatoriskRerence Posteringsoplysninger. Firmakode Indbetaling.OrganisatoriskReference

25 Next step - UDKAST Tidsplan 1. Begrebsmodel 1. Leverandører skriftlige review-input 22. oktober 2. Fælles - evt. afklaring pr. mail 3. KOMBIT fremsendelse af version oktober 2. Servicemodel (Integrationsbeskrivelse inkl. WSDL) 1. KOMBIT - udsender v oktober 2. Leverandører skriftlige review-input 4. november 3. Fælles - evt. afklaring pr. mail 4. KOMBIT fremsendelse af version november