ØIR LEVERANDØRMØDE. Afklaringsforløb: Debitor 14. september KDF Kommunernes Datafælleskab

Transkript

1 ØIR LEVERANDØRMØDE Afklaringsforløb: Debitor 14. september 2015 KDF Kommunernes Datafælleskab

2 Agenda Generel forretningsforståelse Begrebsmodel tentativ Overordnede krav til integrationen Udfordring Gennemgang af begrebsmodellen Næste trin

3 Generel forretningsforståelse Debitorforhold opstår i fagsystemer og i debitorløsningen Dette bestemmer løsnings -ejer af debitorholdet Til debitorforholdet knytter sig en eller flere fordringer (betalingskrav) Ejeren af debitorforholdet vil typisk ligeledes eje alle fordringer på debitorforholder. Gælder det altid, hvad med rykkergebyr og renter? Til en fordring knytter der sig en eller flere opkrævninger Typisk er det debitorløsningen som forestår dannelse af opkrævning, rykker opkrævning. Dvs. ejer opkrævningen Men ikke altid, i nogle tilfælde er givet ejeren af debitorforholdet, som har dannet den sammen med fordringen (fx parkeringsafgift) Indbetaling knytter sig til opkrævning Registrering/kontering af indbetaling foretages af debitorløsningen Indbetaling kan komme som betaling via en bank eller fra et fagsystem

4 Begrebsmodel - tentativ

5 Overordnet krav til integration Entydigt dataejerskab Dataejerskab er altid forankret i en løsning (master) for en myndighed. To muligheder: Master-løsningen opretter dataobjektet (fx debitorforhold) og kommunikere dette til relevante parter (fx debitorløsning) Løsning A anmoder løsning B om at oprette dataobjektet. Løsning B bliver herved master-løsning for dataobjektet Det er kun masterløsningen, som har ret til at ajourføre data på dataobjektet. Den modtagne løsning kan naturligvis tilføje data til det modtagne dataobjekt men ikke rette i data Entydig og robust kommunikation Service skal kunne understøtte at at least once Data skal kommunikeres med entydig reference både ift. transaktion og tid (idempotent)

6 Udfordring Begrebsmodel som reflekterer dataejerskab Er den enkelte klasse robust ift. dataejerskab? Hvordan reflekteres forholdet mellem dataejerskab og den løsning som har initieret oprettelsen? Kan der fastlægges robust dataejerskab på tværs af klasser? Udfordringen ligger i, at atomisering af dataejerskab er Svært at overskue Svært at implementere ens forretningsregler på tværs af løsninger

7 Begrebsgennemgang Gennemgang af hovedbegreber Debitorforhold Fordring / Delfordring Parter Indbetaling Opkrævning

8 Debitorforhold Det centrale begreb i debitorsnitfladen Holder centrale informationer omkring debitorforholdet Binder kravet sammen med de juridisk parter Har yderligere specifikationer som er indeholdt i DebitorSpecifikation EFI håndteres af debitorløsningen, det er derfor udenfor scope for snitfladen

9 Debitorforhold Afklaring Er dataejer for debitorforhold robust (= samme for alle elementer)? Do ift. Juridisk ansvarlig og Administrator ift. debitorforholdet? Vil dataejer for debitor altid være dataejer for fordringer Er dataejer for fordringer/delfordringer robust Debitorspecifikation Giver det mening at have specifikationen for sig? Er typificering af debitor nødvendig? Er der behov for at en løsning kan anmode om oprettelse af et debitorforhold, hvor debitorløsningen bliver master? Vil det være enkelt eller masse transaktioner? Bør der tilføjes Tekst (F.eks. betalingsspecifikationstekst)? EANNummer? Påligningsår? Andet?

10 Fordringer Fordring Holder de overordnede økonomiske informationer om en eller flere delfordringer (betalingskrav) Samler delfordringer, som skal opkræves sammen Delfordring Holder det enkelte betalingskrav Angiver detaljeret information om betalingskravet

11 Fordring Afklaring Kan betalingsmodtager være forskellig per delfordring indenfor samme fordring? Kan ydelsesmodtager være forskellig per delfordring indenfor samme fordring? Er det korrekt at juridisk medhæfter er knyttet til delfordring og ikke fordring? Frigivelse af en fordring/delfordring til opkrævning. Ligger det på delfordringen (stopmarkering) eller på debitorforholdet (opkrævning)? Attributter med spørgsmålstegn? Registreringsnummer, Ydelsesinformation (antal, enheder, ydelsesmodtager, betalingsmodtager, momsberegning og skattebeløb Andet

12 Parter Angiver Beskriver de forskellige parter, som er involverede i debitorforholdet Partstyper er angivet ved: CPR-nr eller CVR-nr Afklaring Er der andre partstyper? Skal adresseoplysninger med? Har vi alle parter (roller) med? Er der behov for supplerende tekst på partsforholdet?

13 Posteringsoplysninger Angiver Posteringsoplysninger angiver, hvorledes debitorforholdet fordringer og indbetalinger skal posteres i finansbogholderiet Afklaring Skal det være med i integrationen? Eller vil det være en intern del af debitorløsningen?

14 Indbetaling Angiver Angiver en indbetaling ift. en fordring Indeholder information om organisation mv., som er ansvarlig for indbetalingen Afklaring Knytter indbetaling sig til fordring, delfordring eller debitor? Indbetalingssted/Organisatorisk reference giver begge mening? Er det korrekt, at der kan foretages indbetaling uden opkrævning? Er indbetaling fra bank at sidestille med indbetaling via ydelsestilbagehold, fx fra KY

15 Opkrævning Angiver Angiver en opkrævningsspecifikationen Afklaring Dannes den altid i debitorløsningen eller kan den også oprettes af et fagsystem? Samleopkrævninger, er det en beslutning som tages i fagsystem og/eller debitorløsning? Skal den være understøttet i snitfladen Kan opkrævning og faktura sidestilles som begreber?

16 Næste trin 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 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