PBS udfordringer

Question

Mangler:

1. PBS kørsel hvor der fremkommer kreditnota

2. Sammenspil mellem indbetalingsregistrering ved PBS fil og Rykkerudsendelse

3. Manglende CVR registrering (Betalingsleverandør)

 

I forbindelse med PBS kørsler så mangler der et par væsentlige ting for at systemet fungere rigtigt.
Jeg ved at i i de 2 sidste år har haft fokus på at finde en løsning, kommer der snart noget ??????
1. Der kan ikke udlæses til PBS hvis en faktura udviser en negativ saldo= kreditnota. Denne mulighed bruges f.eks hvis man kører ejendomsadministration og skal tilbagebetale varme/vand afregninger.

2. Når man kører PBS og efterfølgende kører rykker procedure så mangler der en mulighed for at kunne indlæse indbetalingen fra banken når kunden betaler tilbage via koden på OCR-linien. Grunden er at PBS læser kunde nr. og OCR læser faktura nummer.

3. Hvis man er betalingsleverandør så skal man via PBS bruge sit eget CVR nummer som betalingsleverandør men i E-conomic opsætningen henter den cvr nummer fra stamdata feltet så dette cvr nummer er ikke korrekt i PBS filen der læses ind  

Alle 3 punkter kan løses i dagligdagen hvis man "misbruger" systemet og bruger en masse ekstra administrativ tid men det giver jævnligt støj blandt kunderne.

Answer 1

Hej Brian
Tusinde tak for dit indlæg.

Jeg vil besvare dit indlæg hvor jeg bevare det punktopstillede overblik.

1. Selve forslaget om muligheden, at kunne inkluderer kreditnotaer i en PBS kørsel således det mere automatisk kunne tilbagebetale f.eks. varme/varm afregninger eller et depositum er givet videre til teknikken og ligger i en pulje over forslag.

Det er indtil videre ikke blevet prioriteret, at udbedre dette.
Det er derfor ikke en opgave som ligger lige for men når der sker mere på det område vil du kunne følge med på følgende indlæg: http://forum.e-conomic.dk/19131 der omhandler netop dette.


2. Der helt klart en udfordring når der anvendes PBS som betalingsmiddel og der så sendes en rykker med OCR linjen – Udfordringen ligger i, at der ikke denne rykker der sendes ikke er connected med fakturaen der i sin tid var sendt igennem PBS og derfor er der ikke sammenhæng.

For, at afklare det helt så er udfordringen ikke, at PBS kigger på kunde nr. Og OCR kigger på faktura nr. da OCR linjen kigger på kunde nr. ved en rykker.
Hvorimod PBS aflæses kundenummeret i e-conomic hvor det bliver bundet op på PBS interne betalings ID – dette muliggøre så importen af PBS adviseringer da dette interne betalings ID bliver konverteret over til kundenummeret i e-conomic.


Derfor vil rykkerbetalingen via OCR linjen så vidt jeg har forstået det kunne indlæses som en FIK betaling – I og med denne opkrævning ikke er sendt via PBS (som rykker) og derfor kan PBS ikke matche den op på deres interne betalings ID men udelukkende via OCR/FIK betalingen.

Det er dog ikke hensigtsmæssig, at arbejde med både FIK/OCR linje betalinger sammen med der anvendes PBS da alle betalinger vil samles i en fil og du vil derfor når du importere PBS betalinger få fejl ved, at det ikke kan genkende nummeret
.
Nu ved jeg ikke hvor mange rykkere der bliver sendt afsted når betalingen går igennem PBS – i min optik skulle det gerne være i mindre grad, da PBS skulle sikre betalingerne. Det var derfor måske lettere, at håndtere disse som alm. indbetalinger så det ikke køres over OCR og PBS. Da filen ikke skelner imellem disse. 

Der ser derfor ikke ud til, at være en anden/bedre løsning i sigte.
 

 

3. Jeg kunne rigtig godt tænke mig, at høre lidt nærmere om processen i, at være ”betalingsleverandør” for bedre, at forstå udfordringen. PBS eksporten giver muligheden for, at udtrække en PBS opkrævningsfil ud fra de bogførte fakturaer i aftalen – hvor der skulle være en sammenhæng i mellem Stamdata CVR. Nr. og PBS aftalen.

Så jeg håber, at du vil beskrive lidt nærmere for mig hvordan arbejdsgangen er når i er betalingsleverandør og hvordan denne PBS fil anvendes.



Det var i hvert fald lidt overblik, at starte med – jeg ser frem til, at høre nærmere så vi forhåbentlig kan finde frem til en afklaring.