Organisatie wijzigt van bank

Laatst bijgewerkt op
Als PDF opslaan

(beschrijving n.a.v situtatie bij Cubiss Limburg)

Het wijzigen van IBAN en incassant_id heeft gevolgen voor:

Betalen via iDeal
Betalen via automatische incasso
Betalen via formulieren/betalen op kenmerk (nota's)

Algemeen

Het nieuwe IBANnr moet worden opgenomen in de systeemtabel IBANnrs
De nieuwe dagboeken aanmaken met daaraan gekoppeld het nieuwe IBANnr
Advies is om ook voor Incasso een apart dagboek te maken.
TABDGG: de dagboeken koppelen, dit moet op het laatste moment. Kan in test uiteraard al eerder. Ook het dagboek Retour deposito niet vergeten.

Betalen via iDEAL

Het contract met de huidige bank moet worden opgezegd.
Bij de nieuwe bank moet een contract worden afgesloten.
De configuratie in OCLC Wise moet worden aangepast op de nieuwe gegevens (Martijn)
In OCLC Wise moet een nieuwe Ideal-methode worden aangemaakt.
Het nieuwe IBANnr invoeren bij het dagboek voor Ideal
Is er al een nieuw contract?

Betalen via automatische incasso

Het incassocontract bij de huidige bank moet worden opgezegd
Bij de nieuwe bank moet een nieuw contract worden afgesloten
De contract gegevens moeten ingevoerd worden bij het betreffende IBANnr (systeemtabel IBANnrs).
Het IBANnr invoeren bij het betreffende dagboek voor incasso, dit moet voor de incassorun van januari plaatsvinden.
Zet het aantal 'heraanbiedingen' op 1, mocht er iets fout gaan dan worden niet meteen alle incassogegevens opgeruimd.
Omdat het IBANnr en het incassant_id van de bank wijzigt, ben je verplicht om alle incasso's met dit IBANnr weer als FRST aan te bieden. Om er voor te zorgen dat alle incasso's weer als FRST worden aangeboden, moet voorafgaand aan de run van januari, de volgende actie worden uitgevoerd; het huidige incassant_id bij de klant moet worden gewijzigd naar het nieuwe incassant_id.

Vanaf versie 6.3.2 is dit als volgt opgelost:

In de tabel actor_incasso is een nieuw veld 'incassant_id' toegevoegd. Bij alle incasso in de tabel actor_incasso moet eerst het incassant_id worden toegevoegd.
Dit doe je door het uitvoeren van de call:
call _oneoffs_incassant();
Dit moet VOOR de run van januari en ook, en dat is belangrijk, VOOR het nieuwe incassant_id wordt ingevoerd in de systeemtabel IBANnr.
Tijdens de run van januari zal OCLC Wise een nieuw incassant_id detecteren en automatisch een FRST incasso aanmaken.
Machtigingen: als de machtigingen worden overgenomen dan is er geen probleem, de eerste incasso wordt weer als FRST aangeboden omdat zowel het IBANnr als het incassant_id is gewijzigd.
Machtigingen: als de machtiging niet wordt overgenomen zullen alle klanten opnieuw een machtiging af moeten geven. Maar ik vermoed dat niemand daar op zit te wachten. Hoe dat precies gaat met overname van machtigingen weet ik ook niet. De klant zal daar inderdaad toestemming voor moeten geven, maar hoe dat in z'n werk gaat zal denk ik de bank verder regelen.
Als er een nieuwe incassomachtiging wordt afgegeven zal het machtigings_id worden uitgebreid met een volgnr.

Betalen via formulier/kenmerk (nota's)
Zodra de TABDGG is aangepast (dagboeken gekoppeld) zal het nieuwe IBANnr worden gebruikt op de diverse formulieren. Als jullie daar niet helemaal gerust op zijn kun je ook tijdelijk het IBANnr (in blok rechtsboven) verwijderen uit de stylesheet en het nr opnemen in de tekst. Dat is misschien de eerste maanden aan te raden omdat klanten die in deze maanden een nota hebben gekregen, of nog krijgen met het oude IBANnr. Op de herinnering zal dan het nieuwe IBANnr worden afgedrukt. Dat kan misschien voor verwarring zorgen.

In je mail schrijf je dat de IBANnrs al eerder op de nota's kunnen worden afgedrukt, betekent dat dat het nieuwe IBANnr al in gebruik is? De TABDGG en de dagboeken zijn de enige twee plekken waar het IBANnr van de organisatie van belang is. Daarna regelt OCLC Wise de opname in naarola, incasso, berichten etc. (Het IBANnr in de vestiging is alleen van belang als de vestiging naast het IBAN van de instantie nog een eigen IBANnr heeft voor bijvoorbeeld lokale activiteiten.)

Uiteraard is het zeer wenselijk om de contributie-run van januari eerst helemaal in test uit te voeren. De test is belangrijk, zo komen we erachter of we iets over het hoofd hebben gezien.

Voor de december-run zou je in test alvast een en ander kunnen uitproberen (zie stappen hieronder).

Live:
Contributierun januari:

Stap 1 januari openen
TABDGG: dagboeken wijzigen
call uitvoeren om er voor te zorgen dat iedere incassoklant een incassant_id heeft (kan voor het gehele systeem worden uitgevoerd, dan is dat maar klaar indien er in de toekomst meer van dit soort gevallen komen).
Stap 2: factureren
Stap 3; selecteren posten
controle tabel incasso; zijn incasso's FRST en welk IBAN en incassant_id wordt er meegegeven.
Controle tabel naarola
Maak het incassobestand aan;
controleer de gegevens op het dashboard verslag (aantal FRST/RCUR).
Print de formulieren en kijk of IBANnr correct wordt weergegeven.

Overig
Verwerkt Heerlen ook betalingen met behulp van RABO MT 940? Indien Ja: dit tijdig regelen met de ING.

Terugbetalen tegoeden via SEPA-uitbetaalbestand:
Indien Heerlen hier gebruik van maakt, het dagboek Retour deposito voorzien van juiste IBANnr. En vragen bij ING wat nog meer nodig is.

Blijft het huidige IBNAnr in gebruik bij andere vestigingen/Cubiss? Indien ja: houd er rekening mee dat er nog geruime tijd betalingen voor Heerlen binnenkomen op dit IBANnr (betaling oude nota's). Storneringen die gedaan worden op het oude rekeningnr, klanten kunnen tot 56 dagen na incassering nog storneren.

Er zal dus altijd een periode zijn waarop bij beide IBANnrs betalingen/storneringen voor Heerlen zullen worden gedaan.