Hvorfor er kreditor og betaling ikke låst?

Transkript

1 Hvorfor er kreditor og betaling ikke låst? TIE/CPS/ØSY Hvorfor er der ikke låst for editering af kreditorer og udbetalinger? Af og til bliver vi mødt med spørgsmålet om, hvorfor det er muligt at ændre et eksisterende kreditorkort eller et antal kreditorbetalinger udsøgt til betaling. Tanken bag dette spørgsmål er typisk afledt af det forhold, at hvis data til betaling er låst fra data modtages til der sker en fysisk udbetaling med udgangspunkt i disse data, så kan behovet for kontrol undervejs i processen enten reduceres eller helt elimineres. I det følgende beskrives håndteringen i Navision Stat og begrundelsen herfor. Håndtering i Navision Stat Hvorvidt det er muligt at oprette og editerer kreditorstamdata via kreditorkortet afhænger af hvordan data relateret til kreditoren udveksles imellem Navision Stat, INDFAK og REJSUD Kreditorer, hvor der modtages købsfakturaer via INDFAK Kreditorerne oprettes og vedligeholdes i Navision Stat 1, hvorefter INDFAK henter data til brug for kontering i INDFAK via GIS. Se også afsnittet om GIS. I INDFAK foretages der en kontering og en godkendelse inden fakturaen med betalingsoplysninger sendes til Navision Stat. Såfremt der er tale om en faktura indtastet manuelt direkte i INDFAK 2, skal det oprindelige fakturabilag vedhæftes som dokumentation. Denne dokumentation bruges i godkendelsen på INDFAK og sendes med den indtastede faktura til Navision Stat, hvor den bruges til anden godkendelse i udbetalingskladden. Ved anden godkendelse tjekkes betalingsoplysningerne fra det indgående dokument (og for de manuelt indtastede fakturaer i INDFAK med det vedhæftede dokument), med de oplysninger der ligger i udbetalingskladden. Er der forskel på oplysningerne skal dette dokumenteres, og dokumentationen gemmes. 1 For ØSC servicerede kunder, sker dette via kundens regnskabsteam i ØSC et. 2 Fx ved registrering af udenlandske fakturaer, der ikke kan modtages via Nemhandel/elektronisk faktura.

2 Side 2 af 5 I dette scenarie, er det principielt ligegyldigt, om der spærres for editering på kreditorkortet eller ej, uanset om det drejer sig om de normale elektroniske bilag sendt til INDFAK, eller de manuelle fakturaer, indtastet direkte på INDFAK. For de normale fakturaer kontrolleres betalingsoplysningerne i udbetalingskladden altid imod det fakturabilag, der er modtaget i INDFAK og videresendt til Navision Stat. For de manuelt indtastede fakturaer kontrolleres betalingsoplysningerne i udbetalingskladden altid imod den vedhæftede originale faktura, der er vedhæftet i INDFAK og videresendt til Navision Stat. I dette tilfælde er der således ikke låst for editering af kreditorkortet. Kreditorer der modtager betalinger med udgangspunkt i rejseafregninger og udlæg registreret i REJSUD1 Oprettelsen af kreditorer i Navision Stat sker på baggrund af rapporten Navision Udbetalingsafstemning som trækkes i REJSUD. Rapporten viser en oversigt over de kreditorer med tilhørende betalingsoplysninger, der er registreret direkte i REJSUD, forud for registreringen i Navision Stat. Kreditorerne oprettes og vedligeholdes i Navision Stat 3, hvorefter REJSUD henter kreditordata via GIS, uden betalingsoplysninger, til brug for kontering i REJSUD. I REJSUD foretages en kontering og godkendelse inden faktureringsgrundlaget, uden betalingsoplysninger, oversendes til Navision Stat. Rapporten Navision Udbetalingsafstemning bruges som dokumentation ved anden godkendelse i udbetalingskladden, hvor betalingsoplysningerne for disse udbetalinger trukket direkte fra kreditorkortet, sammenholdes med rapporten. Er der forskel på betalingsoplysningerne skal dette dokumenteres og dokumentationen gemmes. I dette scenarie, er det principielt ligegyldigt, om der spærres for editering på kreditorkortet eller ej, da betalingsoplysningerne i udbetalingskladden altid kontrolleres i mod oplysningerne i rapporten Navision Udbetalingsafstemning 3 For ØSC servicerede kunder, sker dette via kundens regnskabsteam i ØSC et.

3 Side 3 af 5 I dette tilfælde er der således ikke låst for editering af kreditorkortet. Men med en markering af feltet Rejsekreditor, vil det være muligt at gennemtvinge en dobbeltgodkendelse ved oprettelser og editeringer af kreditoren igennem DDI 4. Kreditorer der modtager betalinger med udgangspunkt i rejseafregninger og udlæg registreret i REJSUD2 Kreditorerne oprettes og vedligeholdes i Navision Stat inklusiv alle betalingsoplysninger. For kreditorer, der markeres som Rejsekreditorer, skal denne oprettelse altid ske via DDI. Se også afsnittet om oprettelse af kreditorer via DDI. Kreditorer der oprettes via DDI, kan kun oprettes og ændres via en dobbelt godkendelse af alle betalingsrelaterede ændringer i Navision Stat. REJSUD henter efterfølgende kreditordata, uden betalingsoplysninger, til brug for kontering i REJSUD via GIS. I REJSUD foretages en kontering og godkendelse inden faktureringsgrundlaget, sammen med en returnering af de tilhørende kreditorstamdata, oversendes til Navision Stat. Der udveksles ingen betalingsoplysninger imellem REJSUD og Navision Stat Med den sikrede oprettelse og ændring af kreditors betalingsdata, er der ikke behov for supplerende information om betalingsoplysningerne fra REJSUD. Anden godkendelse i udbetalingskladden, hvor betalingsoplysningerne for disse udbetalinger trækkes fra det låste kreditorkort, kan umiddelbart sammenholdes med betalingsoplysningerne i udbetalingskladden. I dette scenarie kan kreditoren kun ændres via en DDI afledt dobbeltgodkendelse hos kunden, frem til første fakturering fra REJSUD. Herefter er kreditoren låst, mens dennes betalingsoplysninger fortsat kan opdateres, men kun via DDI en med tilhørende dobbeltgodkendelse. Kreditorer der oprettes i Navision Stat via GIS 5 I nogle tilfælde oprettes kreditorer i Navision Stat, overført fra et af institutionens lokale fagsystemer via GIS. I dette tilfælde opsættes den anvendte GIS datastrøm i Navision Stat med editeringsbegrænsning, og i dette tilfælde vil det ikke være muligt at rette stamdata på disse kreditorer. Når der modtages poster til betaling relateret til denne type kreditorer, overføres de til en kladde og bogføres der. 4 Bemærk at denne opsætning principielt er forberedt for REJSUD2 5 GIS: Generisk IntegrationsSnitflade.

4 Side 4 af 5 I udbetalingskladden sammenholdes betalingsoplysningerne fra den spærrede kreditor, med de oplysninger der ligger i udbetalingskladden. Er der forskel på oplysningerne skal det dokumenteres og dokumentationen gemmes. Alle kreditorer, der oprettes via GIS er låst for direkte editering i Navision Stat, med mindre editeringen sker via DDI ens dobbeltgodkendelse. Kreditorer oprettet via DDI ØSC kunder 6 har mulighed for at oprette kreditorer via en DDI kreditorbestilling. Skal kreditor oprettes med betalingsoplysninger kræver systemet, at bestillingen godkendes af anden bruger hos kunden, inden den sendes til accept i ØSC et. ØSC et har ikke mulighed for at rette bestillingen, men kan afvise den, hvorefter den bruger, der har oprettet bestillingen kan ændre den og sende den til ny godkendelse. Samme logik er gældende ved redigering af en eksisterende kreditor og de tilknyttede betalingsdata via DDI. Oprettes der konteringslinjer til kreditorpostering via DDI posteringsbestillingen, skal der vedhæftes dokumentation, for udbetalingens formål. Denne dokumentation bruges ved anden godkendelse i udbetalingskladden, hvor betalingsoplysningerne i bilaget sammenholdes med betalingsoplysningerne i udbetalingskladden. Er der forskel på oplysningerne skal det dokumenteres og dokumentationen gemmes. Hvis kreditoren er markeret som rejsekreditor, kræver oprettelse og editering af kreditorens betalingsoplysninger dobbeltgodkendelse, og efter første modtagelse fra REJSUD2, vil kreditoren være låst. I øvrige tilfælde har det ingen effekt at låse kreditoren. Udbetalingskladden Alle kreditorposteringer, der skal sendes til betaling, afleder udbetalingslinjer i en eller flere udbetalingskladder i Navision Stat. Forslaget dannes af første godkender, som tjekker om data er korrekte via rapporten Sammenlign betalingsoplysninger med originalt købsbilag. 6 Og i princippet også alle andre kunder.

5 Side 5 af 5 Rapporten sammenligner betalingsoplysning fra de modtagne bilag, med de aktuelle betalingsoplysninger for linjerne i udbetalingskladden. Alle rettelser der måtte blive foretages i udbetalingskladden dokumenteres automatisk i rapporten Sammenlign betalingsoplysninger med originalt købsbilag. Anden godkender tjekker igen rapporten Sammenlign betalingsoplysninger med originalt købsbilag, og forholder sig til de eventuelle ændringer der er foretaget i udbetalingskladden, inden vedkomne foretager anden godkendelsen og sender betalingerne frem til enten Nemkonto eller direkte til banken. Manuelle betalingsposter vil i rapporten Sammenlign betalingsoplysninger med originalt købsbilag stå anført som manuelle. Generelt vil kontrollen ved anden godkendelse ske på følgende måde: Normale INDFAK-bilag: Direkte mellem indgående købsdokument og udbetalingskladden. Bilag manuelt indtastet i INDFAK: Som en sammenstilling mellem originalbilaget indtastet i INDFAK (videresendt til Navision Stat) og oplysningerne i udbetalingskladden Bilag generet fra REJSUD1, DDI og GIS- generelt: Som en sammenstilling med udbetalingsoplysningerne i udbetalingskladden og en liste leveret fra fagsystemet. Bilag generet fra REJSUD2: Direkte mellem betalingsoplysningerne på kreditoren og udbetalingsoplysningerne i udbetalingskladden. Det er etableret mulighed for at rette data i udbetalingskladden, for en håndtering af eventuelt registrerede fejl i data, primært afledt af de manuelle betalingsposter, og GIS-leverancer der er dannet forkert fra fagsystemet, forud for den første (delvise) godkendelse, som først bliver fanget på dette tidspunkt. Alternativet er at der skal bruges tid på at udarbejde manuelle kreditnotaer, nye fakturaer og inddrive forkert udbetalte beløb. Det er således ikke effektivt at låse for ændringer i udbetalingskladden.