Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1
  • 2

TOPIC: Waarom FRST niet laten vervallen?

Waarom FRST niet laten vervallen? 06 feb 2014 18:26 #1

Het is een open deur wellicht, maar toch serieus.
Waarom zouden de banken het verschil FRST en RCUR niet zelf kunnen verwerken.
Als een doorlopende machtiging vanaf het begin een RCUR is bij de gebruikers scheelt dat zo'n hoop gedoe en ellende voor iedereen dat het de moeite waard is om het te overwegen zou ik zeggen.
De banken kunnen zelf zien of bijhouden dat er een incasso is geweest op een kenmerk.
Als die er niet is geweest gaat de procedure FRST in werking en anders is het een RCUR.
Ja maar dat kost meer tijd zal de reactie zijn. Ik zou er dan voor zijn als een bestand dan desnoods altijd 5 of 6 dagen verwerkingstijd heeft.
Zelfs als er meerdere eerste opdrachten tegelijk in een bestand zitten zou dat technisch moeten kunnen. Als eentje mag mag de rest toch ook?

Wie is er voor, of wat is er op tegen????

Johan
The administrator has disabled public write access.

Waarom FRST niet laten vervallen? 06 feb 2014 22:39 #2

Volgens mij is dat een onderdeel van het bestrijden van fraude. Bij een FRST moeten banken allerlei controles doen, en als alles in orde is wordt het mandaat opgeslagen (bij beide banken - crediteur/debiteur). Bij RCUR wordt alleen gecheckt of de belangrijke gegevens nog steeds hetzelfde zijn, bij een FNAL wordt het mandaat op inactief gezet. OOFF is zowel FRST als FNAL.

Ja, banken zouden het zelf kunnen bedenken, maar dan zijn zij ook verantwoordelijk. Volgens mij heeft die vlag dus ook een juridische lading.
Last Edit: 06 feb 2014 22:40 by Alex Hekstra.
The administrator has disabled public write access.

Waarom FRST niet laten vervallen? 07 feb 2014 13:15 #3

heb hier al eerder een idee over gelanceerd wat de verantwoordelijkheid op de plek laat waar die hoort, alleen het wordt voor iedereen iets makkelijker gemaakt..

Verwacht je als bank een FRST en je krijgt een RCUR, behandel de incasso als FRST en storneer deze niet.. De incassodatum doorzetten zoals in het verleden ook gebeurde met te laat ingezonden clieop.s

Verwacht je als bank een RCUR en je krijgt een FRST. Behandel deze als FRST.
The administrator has disabled public write access.

Waarom FRST niet laten vervallen? 07 feb 2014 14:22 #4

Dit gaat inderdaad over verwantwoordelijkheden.

In het Rulebook staat dat de incasserende partij correct via FRST (D-5) en RCUR (D-2) moet aanleveren. Dus die everantwoordelijkheid lijkt duidelijk.
Maar waarom de banken nu opeens gaan controleren op FRST en RCOR, en dus mandaten moeten gaan onthouden/vastleggen enzovoort is mij een raadsel....
Bij BtB snap ik het, maar bij BtC niet.
Ook aan banken-kant maakt dat de SDD opeens enorm complex, terwijl het ook een stuk simpeler had kunnen zijn.

En als je dan wel besluit dat je dat aan de banken-kant wilt controleren, doe het dan ook in 1 keer goed, en zorg ervoor dat je de incasserende partij helpt door foutief aangeleverde posten automatisch correct te maken. Wel zul je dan goed moeten afstemmen hoe het dan zit met de retourinfo, en op welke datum bepaalde posten worden bijgeschreven... Maar aangezien banken ook nu al soms de incassodatum wijzigen zou dat geen issue moeten zijn.

Ik stel voor dat we dat bij de overgang naar D-1 (want daar gaan we onze Nederlandse banken toch wel toe dwingen hooop ik?) maar in 1 keer goed oplossen.....
En als de banken hulp nodig hebben om dit te verzinnen, ff sparren kan altijd :-)
The administrator has disabled public write access.

Waarom FRST niet laten vervallen? 09 feb 2014 19:35 #5

Neem nu de volgende situatie
De eerste incasso bij een maandelijkse contributie wordt geweigerd vanwege een rekeningblokkade.
Dus de FRST is niet gelukt. Blokkade gaat er af wordt me verzekerd.
De volgende maand dient zich aan dus het tweede bedrag staat eigenlijk al klaar voor verwerken.
Het programma ziet geen gelukte incasso dus het is ook een FRST
Bij verwerking ziet het programma twee keer FRST in dezelfde batch, prima want dat mag niet.
Wat moet ik nu doen om het recht te trekken?
Wachten tot de volgende maand want een batch voor 1 opdracht gaan we niet doen.
Maar dan staat maand nummer drie al in de wachtrij en is nog steeds FRST. De derde.

Wat een ellende....
Dat kan je op een normale manier in de software toch niet meer stroomlijnen?
En hoe prenotificeer ik dat als de oorzaak niet bij mij ligt?
Bedragen samenvoegen mag ook niet want dat is ook niet afgesproken met de leden.
In theorie zal het allemaal wel kloppen maar in de praktijk werk het systeem slecht.


Johan
Last Edit: 09 feb 2014 19:39 by Johan Gerrits.
The administrator has disabled public write access.

Waarom FRST niet laten vervallen? 10 feb 2014 12:24 #6

Johan Gerrits wrote:
Neem nu de volgende situatie
Wat een ellende....
Dat kan je op een normale manier in de software toch niet meer stroomlijnen?
En hoe prenotificeer ik dat als de oorzaak niet bij mij ligt?
Bedragen samenvoegen mag ook niet want dat is ook niet afgesproken met de leden.
In theorie zal het allemaal wel kloppen maar in de praktijk werk het systeem slecht.
Mee eens dat het systeem niet heel goed doordacht lijkt. Dus oproepen aan banken om e.e.a. anders te gaan doen zijn m.i. terecht, maar de hoop dat er op korte termijn wat aan verandert lijkt mij iets te optimistisch.

Wat m.i. wel werkt is een pragmatische aanpak: flexibele afspreken met leden (of andere debiteurs), bedragen optellen enz. en daar open over communiceren.
The administrator has disabled public write access.
  • Page:
  • 1
  • 2
Time to create page: 0.301 seconds
Powered by Kunena Forum

Enigma Consulting