PURRING PÅ BETALING - BESTILLING - Side 1 / 6 R106 PURRING PÅ BETALING - BESTILLING Beskrivelse sist revidert: År: 2008. Måned: 07. Dag: 02. PURRING PÅ BETALING - BESTILLING Hensikt Forhåndsbetingelser Rapportparametere Virksomhetsid Pr. dato Forfallsdato I IS Customer finnes det flere forskjellige regningstyper som man kan dele inn i to hovedgrupper, periodiske og aperiodiske (= individuelle). Periodiske regninger er slike som er bestilte (herav ordet bestilling i rapportnavnet) i egne batchkjøringer, dvs. akonto og avregning. R106 er laget for å håndtere purring på disse to regningstypene. Samlefaktura er egentlig også en periodisk faktura, men man har likevel valgt å håndtere purring på denne med rapport R107. I tillegg til å produsere varsler, kan det også bli opprettet et gebyr. Dette skjer dersom everket har oppdatert aktuelle felt i bildet Everkets inkassoopplysninger (EINK). Dersom det er oppgitt en verdi i feltet Min.dg.gebyr, vil denne bestemme om gebyr skal genereres eller ikke. I feltet Min.dg.gebyr angis minimum antall dager fra forfall på faktura til produksjon av varsel (kjøredato for purring) for at varselgebyr skal genereres. Gebyret blir eventuelt fakturert ved neste regning på salgsordren. Systemparametre på everksopplysninger (EINK-bildet) med betydning for purring: Laveste beløp for varsling Laveste beløp for stengeordre: aktive og opphørte Løpedager for varsling Min.dg.gebyr Antall varsler Gebyr 1. varsel Gebyr 2. varsel Prosessmanualen inneholder ingen prosess-skjema med henvisning hit.. Behandler kun salgsordrer med oppgitt virksomhet. Blank betyr alle. Aktuelle verdier: EL (Standardverdi) (= Elektrisitet) Omsetning av elektrisk kraft. FV (= Fjernvarme) Fjernvarme. VA (= Vannleveranse) Vannleveranse. Grensedato Vil purre på regninger som er forfalt før denne datoen. Feltet må oppgis. Betalingsfrist Forfallsdato på purringer som dannes (eller betalingsfrist). Feltet må oppgis.
PURRING PÅ BETALING - BESTILLING - Side 2 / 6 Sorteringskode Faktureringsgruppe Regningstermin Geografisk område [Post_m_post/saldo] Purretype Formular -Se Sorteringskoder i IS Customer for forklaring av koder. Behandler kun salgsordrer i denne faktureringsgruppen. Behandler kun salgsordrer med anlegg i dette området. Dersom termin oppgis, gjelder følgende regler (etter saldoprinsippet): Fakturaer produsert etter oppgitt termin behandles ikke. Fakturaer som er produsert til og med oppgitt termin, vil kun bli purret dersom forfallsdato er mindre eller lik Pr. dato (dvs. at fakturaer produsert i tidligere terminer, ikke blir tatt med i purringen dersom forfallsdato på fakturaen er etter Pr. dato). Uforkortet: Post mot post / saldo I utgangspunktet er denne rapportparameteren skjult. P eller S eller blank Denne parameteren vises vanligvis ikke i bestillingsbilde, den er satt til default verdi (blank) som normalt ikke trengs å endres. Metode er om fakturering skal være iht post mot post P eller saldo S. Disse verdiene kan legges inn etter bestilling og vil overstyre default som er blank, som betyr at fakturering vil skje slik som det er definert på faktureringsgruppen 1,2,S eller A/blank (auto) Denne parameteren vises vanligvis ikke i bestillingsbilde, den er satt til default verdi (blank) som normalt ikke trengs å endres. Purretype kan ha verdiene 1, 2, S eller A/blank. Default her er blank som gjør at den "husker" forrige verdi på den aktuelle abonnenten og justerer ny verdi iht hva som er definert på abonnentgruppen. Om en vil kan en overstyre denne parameteren etter bestilling. Eks. hvis parameteren ikke endres - vil en etter å ha sendt ut 1.purring huske at neste gang skal den sende ut 2.purring. Nå kan en om en vil overstyre å si at vi vil heller Stenge salgsordren isteden for sende 2.purring. V=Vanlig F=Fals Aktuelle verdier: V (Standardverdi) (= Vanlig) Vanlig. F (= Fals) Fals.
PURRING PÅ BETALING - BESTILLING - Side 3 / 6 Benytter mjukkrav Til inkassobyrå Type varsel til inkasso Som purring 1. (J/N) Parameter som angir (J = ja, N = nei) om det skal brukes mjukkrav i stedet for 1.gangs varsel. Mjukkrav skiller seg fra 1. varsel ved at kunden kan unngå varselgebyret dersom han betaler innen fristen på mjukkravet. Dersom salgsordrer skal behandles med mjukkrav, er det viktig at installasjonsparameter mjukkrav (i USA-applikasjonen) settes lik "J" - da vil fremdaterte diversebeløp m/kode 901 (varselgebyr) bli fjernet ved innbetaling. A-Aktive, O-Opphørte, B-Begge deler Denne parameteren er kun tilgjengelig for de energiselskap som har kjøpt tilleggsmodulen for integrasjon mellom inkassobyrå og IS Customer. Default er blank, dvs. at oppfølging av forfalte oppdrag ikke skal oversendes eksternt byrå. Merk at parameterverdiene A, O, B kun skal brukes for faktureringsgrupper som behandles etter post mot post prinsippet. Dersom parameteren ikke fylles ut, vil varsel/stengeordrer skrives ut som vanlig på salgsordrene, (ingen inkassobehandling). Ved bruk av parameterverdiene A, O, B, vil salgsordrer som får produsert varsel/ stengeordre ved kjøring av R106, merkes med autopurrekode I for "Initiert Innkreving". NB! Dersom purreprodukt brukes, overstyrer dette bestillingsparameteren. Aktuelle verdier: A (= Aktive) Kun aktive salgsordre. O (= Opphørte) Kun opphørte salgsordre. B (= Både) Både aktive og opphørte salgsordre. V-Varsel, S-Stengeordre, B-Begge deler Blankt felt betyr alternativ uten inkasso-behandling. Merk at varsel 1, og eventuelt varsel 2, skrives ut som vanlig når denne parameteren er lik S. Disse oversendes ikke til ekstern innkreving. Merk: Dersom purreprodukt brukes, overstyrer dette bestillingsparameteren. Rutiner Dag/Natt kjøring Feilsituasjoner Før man kjører R106 bør man kjøre R107. Dette for å unngå komplikasjoner i forholdet mellom disse to rapportene. Bakgrunnen er som følger: En avtale som er utløpt ved purredatoen, vil i R107 bli gjenstand for oppfølging (= varsel produseres) og får eventuelt justert sin oppfølgingsdato fremover i tid. Hvis R106 trer i funksjon før denne fremdateringen har skjedd, vil R106- programmet ikke anse at det foreligger noen gyldig avtale, og vil eventuelt purre uten å foreta seg noe med avtalen (det er jo bare R107 som oppdaterer avtaler). Ved neste kjøring av R107 vil en da kunne få samme faktura purret på ny, uten hensyn til om forfallsdatoen på forrige purring (R106-purringen) er nådd. Natt. Når rapporten kjøres testes det blant annet på purrestatus, dvs. om, og eventuelt hvilke, varsler som er produsert før. Noen system håndterer dette med purrestatus
PURRING PÅ BETALING - BESTILLING - Side 4 / 6 ulikt IS Customer, og det er derfor viktig at man kontrollerer at purrestatus er satt riktig før man kjører rapporten første gang etter konvertering. I tillegg er det viktig at betalingsstatus på fakturaene er satt riktig etter konvertering. Purring på faktura der stengeordre inngår i historikken: Dersom det er produsert stengevarsel (-ordre) men regningen fortsatt ikke blir betalt, kan man komme i en situasjon der man får produsert nye regninger (akonto) på salgsordren selv om det ligger et stengevarsel på uoppgjort faktura. Vil man så purre på de nye regningene som er produsert etter at stengeordre ble generert (saldopurring), er det viktig å være oppmerksom på at man i utgangspunktet ikke vil få purret på disse regningene. For å få purret på disse regningene, er det en forutsetning at man merker stengevarslet med regler for videre oppfølging. Det gjøres i "Detaljbilde purring" (nås via RES-bildet, Utførmenyen og Varsel) ved å velge ønsket oppfølgingskode i feltet Beh. som (behandles som). Stengeordren (utskriften av stengevarslet) er tilrettelagt for registrering av data på stengebesøket (bl.a. data om stengt dato, stengemåte, kontrollavlesning). Kjøring av R106 i helgene: Det kan også oppstå problem dersom R106 kjøres i helgen, og R107 ligger med fast bestilling og 1 D i hyppighet. Ved bruk av D i bestillingen, lages det ikke bestilling for lørdager og søndager. Det betyr at da vil R106 kjøres uten at R107 er kjørt først. Avtaler som har passert oppfølgingsdato vil bli purret av R106, men R106 vil ikke oppdatere avtalen. De samme avtalene vil derfor bli purret en gang til ved kjøring av R107. På grunn av dette bør en ha følgende faste bestillinger for R107 dersom en benytter helgene til å kjøre R106: 1. R106 med hyppighet 1 D bestilt med kjøredato på en hverdag. 2. R107 med hyppighet 1 U bestilt med kjøredato på en lørdag. 3. R107 med hyppighet 1 U bestilt med kjøredato på en søndag. Importfil Resultatfiler Ikke aktuelt for denne rapporten. Rapporten genererer ikke andre filer enn de som ev. står nevnt under tittelen er. er 1 Kvitteringsliste - Utplukk 2 Postgiro 1. varsel 3 Postgiro 2. varsel 4 Bankgiro 1. varsel 5 Bankgiro 2. varsel 6 Autogiro 1. varsel 7 Autogiro 2. varsel 8 Direkte trekk 1. varsel 9 Direkte trekk 2. varsel 10 Stengeordre 11 Purreliste 12 Stengevedlegg 13 Kvitteringsliste - BEHANDLINGSREGLER FOR RAPPORTEN
PURRING PÅ BETALING - BESTILLING - Side 5 / 6 Rapporten produserer både purringer og stengevarsel. Når forfallsdatoen er passert, kan man produsere førstegangsvarsel. Her må det da tas hensyn til dette med bankdager før man sender varsel. Det er vanlig å identifisere den kjøringen som skal purres, med forfallsdato og/eller termin, dersom det begrepet er brukt på den kjøringen som skal purres. Senere, når forfallsdato på varselet er passert og oppfølgingsdato inntreffer, kan man kjøre rapporten igjen. Da vil man få produsert stengevarsel for regningene som fortsatt står uoppgjort. De everkene som bruker annen gangs varsel, kan få produsert det mellom disse to. R106 gjør ingen oppdatering av betalingsavtaler, men det tas hensyn til eksisterende avtaler når det skal beregnes hvor stort beløp som skal purres. Nedenfor gis en detaljert beskrivelse av de regler programmet arbeider etter når det skal velge ut tilfeller for purring og bestemme purrebeløpet. For oversiktens skyld gis det en egen beskrivelse av de to purreprinsippene (post mot post- og saldoprinsippet), selv om mye er felles. POST MOT POST PRINSIPPET Programmet sjekker kun en faktura på hver salgsordre, og denne velges slik: Hvis termin ikke er oppgitt som bestillingsparameter, sjekkes eldste restanse/ regning med forfallsdato til og med Pr. dato. Hvis termin er oppgitt, sjekkes siste regning med forfallsdato til og med Pr. dato og termin lik den oppgitt. Hvis den valgte faktura er oppgjort (= blank på status i reskontrobildet), blir det ingen purring på salgsordren. Hvis fakturaen er merket uoppgjort (U) eller delvis oppgjort (D), gjør programmet videre undersøkelser. Først beregnes da forfalt restanse ved å sammenholde fakturabeløpet med godskrivinger summert på følgende måte: Først summeres alle innbetalinger knyttet til fakturaen. Til dette legges gyldige avtaler knyttet til fakturaen. Til sist legges gyldige avtaler på vedkommende salgsordre uten knytning til faktura. Den forfalte restanse beregnet på denne måten sammenlignes med beløpsgrensen på everksopplysninger (Laveste beløp for varsling eller Laveste beløp for stengeordre (aktive og opphørte) - avhengig av purretypen.) Hvis forfalt restanse er lavere enn beløpsgrensen, avbrytes behandlingen for vedkommende salgsordre. SALDOPRINSIPPET Fakturaer som skal sjekkes velges slik: -I utgangspunktet sjekkes alle fakturaer med forfallsdato til og med Pr. dato. -Hvis termin er oppgitt som bestillingsparameter, gjelder følgende: -Fakturaer produsert etter oppgitt termin purres ikke. -Fakturaer som er produsert til og med oppgitt termin, vil kun bli purret dersom forfallsdato er mindre eller lik Pr. dato (dvs at fakturaer produsert i tidligere terminer, ikke blir tatt med i purringen dersom forfallsdato på fakturaen er etter Pr. dato).
PURRING PÅ BETALING - BESTILLING - Side 6 / 6 Ved undersøkelsen ser programmet bort fra alle fakturaer som er oppgjort (= blank på status i reskontrobildet). Bare fakturaer som er merket uoppgjort (U) eller delvis oppgjort (D), blir sjekket videre. Først beregnes da forfalt restanse ved å sammenholde summen av fakturabeløpene på de aktuelle fakturaene med godskrivinger summert på følgende måte: 1) Først summeres alle innbetalinger knyttet til de aktuelle fakturaene. 2) Til dette legges gyldige avtaler knyttet til de aktuelle fakturaene. 3) Til sist legges gyldige avtaler på vedkommende salgsordre uten knytning til faktura. Den forfalte restanse beregnet på denne måten sammenlignes med beløps-grensen på everksopplysninger (Laveste beløp for varsling eller Laveste beløp for stengeordre (aktive og opphørte) - avhengig av purretypen.) Hvis forfalt restanse er lavere enn beløpsgrensen, avbrytes behandlingen for vedkommende salgsordre.