Bekijk Volledige Versie : Wie heeft er al een goede SEPA Direct Debit Core PHP classe
tomadmiraal
27/11/13, 16:19
Ik weet niet of dit in het juiste forumgedeelte staat, maar geef hem anders maar een schop naar het juiste gedeelte
Ben al geruime tijd aan het zoeken naar een goeie SEPA Direct Debit Core PHP classe die geschikt is voor de Nederlandse banken. In ons geval gaat het om de Rabobank.
Weet iemand nog een goede classe hiervoor of heeft iemand deze toevallig liggen?
Een wat? Serieus wij onderhouden diverse grote koppelingen wat betreft SEPA en PAIN, enkel heb ik niet direct het idee waar je naar opzoek bent :P.
Waarschijnlijk een PHP class die het uiteindelijk XML bestand genereert. Die bestaan wel, maar dan ben je er nog niet. Als je zelf een administratie pakket schrijft dan zul je er toch wat dieper in moeten duiken. Het maken van de class is nog niet eens het lastigste.
Waarschijnlijk een PHP class die het uiteindelijk XML bestand genereert. Die bestaan wel, maar dan ben je er nog niet. Als je zelf een administratie pakket schrijft dan zul je er toch wat dieper in moeten duiken. Het maken van de class is nog niet eens het lastigste.
Ook dit is niet helemaal waar meer. Clieop03 files waren makkelijk te genereren, enkel worden de PAIN bestanden een stuk ingewikkelder. Zo zijn er wereldwijd meer dan 250 verschillende bestanden. Waarbij de banken een standaard wilden ontwikkelen is SEPA wel het beste voorbeeld waar het totaal gefaald is.
Wij zijn op dit moment dagelijks bezig met het integreren van SEPA binnen financiële applicaties en het leggen van koppelingen met Twinfield en Exact en hebben hier ook nauw contact met deze partijen. Een basis Clieop03 kon je bij alle Nederlandse banken gebruiken. Echter is dit bij de nieuwe PAIN bestanden niet meer zo. Ook is het een stuk ingewikkelder wat betreft eerste en vervolg incasso's.
Hoewel de verschillen en het aantal in de PAIN bestanden nog wel meevalt zit het grote probleem in de response van de bank.
Zo moet je tegenwoordig bij administratiepakketten ook opgeven met welke bank je werkt omdat hier de bestanden mee afgestemd dienen te worden. Het mooie is dat zelfs banken van zichzelf nog met verschillende versies bestanden werken.
Zo diep zit ik er dan weer niet in, maar dat het complexer is geworden is zeker waar. De implementatie die wij doen is redelijk generiek, maar wel voor meerdere banken. Daar lopen we af en toe wel ergens tegen aan, maar dat was zelfs bij Clieop03 in het begin wel eens het geval.
Wij handelen overigens niet de response van de bank af, misschien dat het daarom bij ons mee valt.
In ieder geval: een class downloaden van het internet gaat echt niet genoeg zijn voor de TS. Misschien lijkt het makkelijk, maar vergis je niet.
Zo diep zit ik er dan weer niet in, maar dat het complexer is geworden is zeker waar. De implementatie die wij doen is redelijk generiek, maar wel voor meerdere banken. Daar lopen we af en toe wel ergens tegen aan, maar dat was zelfs bij Clieop03 in het begin wel eens het geval.
Wij handelen overigens niet de response van de bank af, misschien dat het daarom bij ons mee valt.
In ieder geval: een class downloaden van het internet gaat echt niet genoeg zijn voor de TS. Misschien lijkt het makkelijk, maar vergis je niet.
Wat jij zegt inderdaad. Zelfs als je voor Clieop03 ging zoeken viel het aanbod nog vies tegen (het is er wel). SEPA is erg nieuw en ze zijn nog steeds de specificaties aan het wijzigen. Zeker nu ga je nog niks fatsoenlijks vrij beschikbaar vinden. Denk zelf nog dat je nooit iets kant en klaars gaat vinden (gratis & goed).
Als het alleen gaat om het genereren van een batchfile voor een specifieke bank (TS heeft het over Rabobank) dan zou ik gewoon aan de slag gaan met iets dat een XML-document op een beetje handige manier kan genereren, dat is wat we hier hebben gedaan in ieder geval. Als je PAIN-bestandjes genereert aan de hand van de door je bank verstrekte specificaties dan is het niet ingewikkeld (in zekere zin zelfs eenvoudiger dan CLIEOP03). Natuurlijk moet je dan wel een en ander aanpassen als je van bank wisselt.
Het verder aanpassen van je systemen gaat inderdaad wel iets verder dan even een class erbij zetten. Denk o.a. aan het converteren van rekeningnummers, het toevoegen en administreren van kenmerken aan je machtigingen en het splitsen van eerste en vervolgopdrachten in afzonderlijke batches.
tomadmiraal
28/11/13, 09:46
Ik geloof dat er in elke reactie wel een kern van waarheid zit wat betreft mijn probleem.
Ten eerste heeft golden gelijk: ik wist niets, toen dacht ik dat ik het wist maar gaande weg kwam ik er achter dat ik nog steeds niet verder was gekomen. Kortom SEPA is vaag, niet uitgewerkt, complex en zelfs de bank zelf kan er geen zinnig woord over zeggen.
Ik ben opzoek naar een classe die (net zoals clieop3) een batchfile genereert die ik bij de Rabobank kan importeren voor het automatisch (SEPA) incasseren (Direct Debit) op de simpelste manier (Core aka B2C). Aangezien de administratie zelf geschreven is, kan alle info uit de database gehaald worden en gebruikt worden op welke manier dat dan ook nodig is.
Ik ben zoveel classes tegen gekomen op internet die allemaal wel een batchfile genereren, maar bij geen had ik de indruk dat het klopte. Een van de redenen was de PAIN versie die dus bij elke bank verschillend blijkt te zijn.
Zoals NederHost opmerkt ben ik opzoek naar een CLIEOP3 vervanger in de simpelste SEPA vorm.
Alle banken wijken zo ongeveer van elkaar af. Als je een klein beetje budget hebt zou ik een Twinfield of Exact administratie nemen.
Debiteuren en crediteuren via de api uitwisselen, en dan binnen de boekhouding of via de api een PAIN bestand genereren. Moet dit uiteraard wel in het budget passen.
tomadmiraal
29/11/13, 14:52
golden
Ik snap je punt, alleen dat is nou juist net niet de bedoeling... Ik ben echt opzoek naar een classe.
tomadmiraal
Geen probleem. Succes met de zoektocht in ieder geval. Stiekem ben ik bang dat je voorlopig in ieder geval nog niks kant en klaars gaat vinden.
Mocht ik ongelijk hebben dan hoop ik dat je dat met mij en de anderen hier deelt.
Zoals gezegd: het is afhankelijk van het softwarepakket dat je uiteindelijk gaat gebruiken; met name vanwege het onderscheid tussen eerste en opvolgende payments. Dat kan onder omstandigheden wel lastig zijn. De class op zich moet niet zo ingewikkeld zijn...
SebastiaanStok
30/11/13, 19:18
Clieop03 files waren makkelijk te genereren, enkel worden de PAIN bestanden een stuk ingewikkelder. Zo zijn er wereldwijd meer dan 250 verschillende bestanden. Waarbij de banken een standaard wilden ontwikkelen is SEPA wel het beste voorbeeld waar het totaal gefaald is.
Kennelijk hadden ze geen betere naam kunnen bedenken dan "PAIN" :drunk: eindelijk is een product met een eerlijke naam!
Het nieuwe SepaXML formaat is niet zo'n enorm fijn formaat om mee te werken. Voor een klant hebben wij hiervoor een implementatie in de direct debit stand gemaakt (compleet met mandaat meuk enz), en het klopt dat je hier redelijk goed op moet letten.
Onze implementatie is geloof ik redelijk netjes (op de brug naar de andere programma's na), maar ik denk niet dat we het zomaar mogen open sourcen.
Bij iedere implementatie zul je overigens altijd nog even naar de XSD moeten kijken van het bestand. Anders is het een beetje lastig te valideren voor je het naar de bank stuurt. Verder bemerk ik wel dat als het voor 1 bank werkt, het over het algemeen ook bij andere banken wel werkt, alleen de terugkoppeling is altijd anders :(. (MT940 etc)
Het nieuwe SepaXML formaat is niet zo'n enorm fijn formaat om mee te werken. Voor een klant hebben wij hiervoor een implementatie in de direct debit stand gemaakt (compleet met mandaat meuk enz), en het klopt dat je hier redelijk goed op moet letten.
Onze implementatie is geloof ik redelijk netjes (op de brug naar de andere programma's na), maar ik denk niet dat we het zomaar mogen open sourcen.
Bij iedere implementatie zul je overigens altijd nog even naar de XSD moeten kijken van het bestand. Anders is het een beetje lastig te valideren voor je het naar de bank stuurt. Verder bemerk ik wel dat als het voor 1 bank werkt, het over het algemeen ook bij andere banken wel werkt, alleen de terugkoppeling is altijd anders :(. (MT940 etc)
In grote lijnen heb je gelijk. Als een PAIN bij 1 bank werkt is de kans groot dat hij bij een andere bank ook ingelezen kan worden. Echter doen de banken er ieder voorzich weer allerlei vage checks op achteraf.
TotallyHosted
02/12/13, 15:03
Wij hebben dit inmiddels zelf in elkaar geknald, de naam PAIN is inderdaad zeer goed... het formaat is een PAIN in the ass.
Na 2 dagen knutselen en bellen met de bank is het gelukt om dit zelf te maken, echter hebben we op dit moment zelf nog problemen met innen van ING. Geen idee waarom, maar zij weigeren al onze incasso's. Ik ben benieuwd of dat deze maand nog zo is. ABN en Equens weten het ons in elk geval niet te melden.
Overigens valt mij op dat onze bank (ABN Amro) ons heeft medegedeeld dat we per se FRST moeten gebruiken (wat betekende dat wij opeens 14 dagen langer op ons geld moesten wachten), terwijl de meeste van onze klanten al jarenlang bij ons via autoincasso betalen, zij het via Clieop3.
De banken weten zelf ook nog niet zo goed waar zij mee bezig zijn, foutmeldingen lukken nog niet zo goed, een online checker is er praktisch niet (was er van ING wel, maar die is volgens mij momenteel niet meer openbaar), en duidelijke documentatie of duidelijke voorbeeldbestanden ben ik ook nog niet tegengekomen. Het had allemaal veel makkelijker gekund!
Daarnaast valt het mij op mijn privé-rekening (van ING) op dat bijvoorbeeld Oxxio wel netjes FRST heeft gebruikt, maar een aantal andere partijen zoals UPC en FBTO wel gelijk RCUR hebben gebruikt. Blijkbaar mag dit dus toch wel?
tomadmiraal
04/12/13, 11:04
Ondanks dat er geen kant en klare classe uit deze topic rolt, ben ik wel blij met alle info die gedeeld wordt. Er zitten een hoop punten bij waar rekening mee gehouden dient te worden.
TotallyHosted
Geldt die FRST alleen bij de eerste incasso van een klant en daarna altijd RCUR ongeacht het bedrag?
Bij iedere eerste incasso voor een klant moet je deze altijd onder de PmtInfo zetten welke als FRST gemarkeerd is. Daarna mag je voor dezelfde klant RCUR gebruiken.
Bij iedere eerste incasso voor een klant moet je deze altijd onder de PmtInfo zetten welke als FRST gemarkeerd is. Daarna mag je voor dezelfde klant RCUR gebruiken.
Dat klopt niet 100%. Stel dat de klant de 1e incasso storneert dien je nogmaals de FRST te sturen. Sommige banken accepteren dat je dat niet doet, maar andere vallen daarover.
Dus sommige banken zullen de 2e ook weigeren op het moment dat de betreffende persoon de 1e gestorneert heeft.
Goed punt. Klopt inderdaad.
Goed punt. Klopt inderdaad.
Het is zonde dat we het dienen te benoemen. Helaas merk je dat er elke maand meer storno's komen.
dennis0162
14/12/13, 15:34
Vandaag voor iemand de volgende SEPA incasso class gebruikt: https://github.com/BureauPartners/SEPA-Incasso
Werkte vrij snel zonder problemen.
Zelf gebruiken we WeFact dus dat is al ingebouwd.
TotallyHosted
17/12/13, 15:31
Vandaag voor iemand de volgende SEPA incasso class gebruikt: https://github.com/BureauPartners/SEPA-Incasso
Werkte vrij snel zonder problemen.
Zelf gebruiken we WeFact dus dat is al ingebouwd.
Hoewel die er wel goed uit ziet, doet hij alleen FRST?
dennis0162
17/12/13, 15:49
In de class kan je het aanpassen.
Ik zal vanavond even kijken welke regel.
Sent from my HTC One using webhostingtalk mobile app
https://github.com/congressus/sepa-direct-debit deze ziet er wat uitgebreider uit, misschien is het wat?
tomadmiraal
17/12/13, 16:51
Arieh
Ik wilde net gaan posten dat ik die class heb toegepast. In deze class is ook de XSD-validatie meegenomen. Binnenkort het uur van de waarheid.
TotallyHosted
Die FRST en RCUR, kun je dat ook gebruiken wanneer je verschillende bedragen bij mensen int? dus in maart 30 euro, in april 15 euro en augustus 68 euro?
Arieh
Ik wilde net gaan posten dat ik die class heb toegepast. In deze class is ook de XSD-validatie meegenomen. Binnenkort het uur van de waarheid.
TotallyHosted
Die FRST en RCUR, kun je dat ook gebruiken wanneer je verschillende bedragen bij mensen int? dus in maart 30 euro, in april 15 euro en augustus 68 euro?
Zolang de machtigingskenmerk het toelaat kan je een hele boel. In tegenstelling tot wat veel mensen denken mag je in je machtigings- en aankondigings brief erg globaal zijn.
Je hoeft zelfs niet officieel een bedrag te tonen in de brief of je kan bedragen tussen de, of rond de benoemen.
Je hoeft enkel bij de 1e incasso per machtiging de first te gebruiken tenzij de 1e gestorneerd wordt.
Die classess zijn trouwens erg leuk maar voorzien je ook maar enkel in het simpelste gedeelte van het gehele SEPA traject.
tomadmiraal
18/12/13, 10:36
golden
Dat klopt. maar de simpele manier is voor mij bijvoorbeeld op dit moment genoeg. Die FRST en RCUR kan ik op zich makkelijk inbouwen.
Wat ik me alleen nog wel afvroeg, hoe zit het eigenlijk wanneer je om wat voor rede dan ook, 2 accounts hebt met de zelfde incasso gegevens? dus 2 accounts die de zelfde bank gegevens gebruiken? hoe reageert sepa hier op?
golden
Dat klopt. maar de simpele manier is voor mij bijvoorbeeld op dit moment genoeg. Die FRST en RCUR kan ik op zich makkelijk inbouwen.
Wat ik me alleen nog wel afvroeg, hoe zit het eigenlijk wanneer je om wat voor rede dan ook, 2 accounts hebt met de zelfde incasso gegevens? dus 2 accounts die de zelfde bank gegevens gebruiken? hoe reageert sepa hier op?
Dat is geen probleem. Zolang ze ieder maar een geldig machtigingskenmerk hebben.
tomadmiraal
18/12/13, 10:41
Dat is geen probleem. Zolang ze ieder maar een geldig machtigingskenmerk hebben.
Ja het machtigingskenmerk heb ik uniek
Ik denk/ga er vanuit dat er na de invoering op 1 februari langzaam ook andere classes naar buiten gaan komen met de volledige implementatie van SEPA. de simpele implementatie van SEPA doet niets meer of minder dan de oude CLIEOP3 variant. Behalve wat langere wachtperiodes
Ik denk/ga er vanuit dat er na de invoering op 1 februari langzaam ook andere classes naar buiten gaan komen met de volledige implementatie van SEPA. de simpele implementatie van SEPA doet niets meer of minder dan de oude CLIEOP3 variant. Behalve wat langere wachtperiodes
Wel iets meer:
- splitsen eerste en vervolgincasso's,
- je bent dus ook verplicht storno's van (in ieder geval eerste) incasso's als zodanig te verwerken zodat een volgende incasseringspoging van het juiste type is,
- machtigingskenmerk en datum moet worden geregistreerd en vermeld bij iedere incassering,
- je bent uiteraard verplicht naast het IBAN ook de BIC op te geven voor iedere rekening vanaf waar je incasseert,
- terugmeldingen van storno's is bij ING in ieder geval substantieel veranderd in hun MT940-bestanden (in tegenstelling tot wat de bank beweert overigens),
- de machtigingsformulieren moeten worden aangepast met een aantal nieuwe verplichte elementen, o.a. het woord 'SEPA', kenmerk van de machtiging en je incassant-ID (en dit is echt verplicht voor iedere machtiging die vanaf 1 februari wordt verleend),
- vergeet ook niet je Europese incassocontract te controleren (ik heb sterk de indruk dat o.a. limieten strenger worden gehandhaafd).
Zoals al eerder gezegd in deze thread is het maken van het XML-bestand veruit het eenvoudigste deel van het nieuwe SEPA-incassosysteem. Je kunt in de meeste gevallen niet zomaar je CLIEOP03-generatie vervangen door een PAIN008-generatie (tenzij je de benodigde extra gegevens om de 1 of andere reden al vastlegde). Als het allemaal eenvoudig te implementeren is dan zou ik dat gewoon zo snel mogelijk doen zodat je eventuele moeilijkheden zo snel mogelijk tegenkomt. Tot na 1 februari wachten lijkt me niet verstandig (tenzij je graag extra lang op je geld wacht natuurlijk).
Dat een en ander snel fout gaat blijkt wel uit de 188 miljoen euro-fout van de gemeente Amsterdam (centen ipv euro's) en de mislukte incassorun van Ziggo in december (RCUR ipv FRST).