Naast de oorspronkelijk (in 1995) ontwikkelde methode voor het inlezen van Bankafschriften, en het afletteren op openstaande fakturen, is per heden een nieuwe methode ontwikkeld.
Middels een Financiële Parameter (Hmenu-7-8-1-1) kan op het 2e Tabblad worden aangegeven of de oude methode (0) moet worden toegepast danwel de nieuwe methode (1).
Methode 0 Dit betreft de oorspronkelijk ontwikkelde methode. Helaas staat nergens goed beschreven hoe deze methode precies werkt. Voor wat ervan bekend is, wordt op basis van een Ontvangstnaam een match gemaakt met de Debiteur die betaald heeft. Deze methode is ontstaan vanuit de allereerst ontwikkelde import van de ABN Bank, waarbij het in te lezen Bankafschrift geen rekeningnummer bevatte van de betaler, en enkel de Ontvangstnaam vermeldde. In praktijk levert dit problemen op, omdat er meerdere klanten in uw klantenbestand kunnen zitten met dezelfde naam; zo heet een Grieks restaurant al snel "Rhodos", "Delphi" of "Aphrodite".
Deze methode bevatte ook diverse trucs om een zo goed mogelijke match te maken met het Faktuurnummer, door bijv. te anticiperen op de betaling van Faktuur 7261721,722,723 waarmee met 722 het rechterdeel in 7261721 zou moeten doen vervangen.
Zo ook werd bij deze methode alles wat het systeem er zelf van maakte, teruggeschreven naar de Betalingskenmerken, met als gevolg dat er in het Betalingskenmerk wat U op het scherm zag, andere gegevens konden staan dan de Debiteur bij zijn betaling vermeldde. Helaas zijn er ook praktijkvoorbeelden bekend waarbij hierdoor de Betalingskenmerken Fakturen bevatte, die helemaal niet door de Debiteur vermeld waren, maar waarvan het systeem om e.o.a. reden bedacht dat ze er wel bij hoorden; mogelijk omdat dit de enige faktuur was die open stond, of omdat er een bepaalde match kon worden gemaakt met een referentie die in de betaling stond.
Een groot nadeel van methode #0 is dat één Ontvangst maar voor één Debiteur kon zijn, en er derhalve niet op Fakturen van meerdere Debiteuren kon worden afgeletterd.
In praktijk, zeker in het voorbeeld 'restaurants' kan één persoon eigenaar zijn van meerdere restaurants, en de fakturen aan deze meerdere restaurants via dezelfde rekening betaalt.
Per heden is een nieuwe methode, die we methode #1 noemen.
Methode #1 is specifiek ontwikkeld op basis van praktijk voorbeelden van een van onze klanten, en werkt derhalve "as is". Zo zijn er ook een aantal zaken waar de oude methode wél rekening mee hield, doch welke in deze methode niet verwerkt zijn. Dergelijke zaken kunnen op zich wel als aanvullend maatwerk worden ontwikkeld.
Waar methode #0 "Ontvangstnamen" als uitgangspunt had, en slechts één Debiteur per ontvangst ondersteunde, is bij methode #1 het Rekeningnummer van de Betaler het uitgangspunt. Het Bank-/Girorekeningnummer wordt gematched met het Bank-/Girorekeningnummer zoals deze in de Financiële Parameters van de betreffende Debiteuren is opgenomen, en bepaalt op die manier welke Debiteuren er bedoeld worden als er vanaf dit rekeningnummer betaald wordt.
Hiermee kan dus het rekeningnummer van de eigenaar van de meerdere restaurants bij al die restaurants (= Debiteuren) worden opgenomen, en weet het systeem dat als er vanaf dát rekeningnummer betaald wordt, er op Fakturen van meerdere Debiteuren mag worden afgeletterd.
Nb: Alleen in de situatie dat de Debiteur slechts één Faktuur betaald, en er nog geen rekeningnummer bekend was in de Financiële Parameters van de Debiteur, zal dit rekeningnummer automatisch aan deze Debiteur gekoppeld worden.
Methode #1 werkt alleen bij het inlezen van het afschrift van de Rabobank (MUT.ASC). Merk op dat methode #1 mogelijk bij andere banken helemaal niet inzetbaar is, omdat niet iedere bank het rekeningnummer van de betaler vermeldt in het digitale bankafschrift.
Let op: deze methode is ontwikkeld vanuit de praktijk, puur omdat deze situatie (veelvuldig) toegepast wordt, en automatisch afgehandeld moet kunnen worden; handmatig verwerken van dergelijke ontvangsten zou uren per dag in beslag nemen. Hierbij oordelen we even niet over een eventueel juridisch aspekt, waarbij zoiets wel eens niet zou kunnen zijn toegestaan. Er zijn nl. ook praktijk voorbeelden waarbij een Creditnota van Debiteur A wordt verrekend met een Debetnota van Debiteur B, waar je vervolgens theoriëen achter zou kunnen zoeken dat bedrijf B "gratis" kan inkopen, en bedrijf "A" nooit haar geld terugkrijgt (omdat het aan B betaald is). Wordt een van beide bedrijven verkocht, of gaat een van de twee failliet, dan ontstaan er rare (en misschien wel niet toegestane) situaties. Het gebruik van deze methode is derhalve voor eigen rekening.
Globale verschillen met de oude werkwijze:
* Afletteren op basis van Rekeningnummer betaler, derhalve afletteren op meerde Debiteuren mogelijk.
* Elimineren van verwerking op basis van "Ontvangstnamen", derhalve geen popups tijdens inlezen afschrift om Ontvangstnamen (of nu het rekeningnummer) te moeten matchen met een Debiteur-id.
* Matchen vindt reeds plaats bij inlezen bankafschrift, en tevens na wijzigen Ontvangsten; reeds voor verwerking zal daarmee bekend zijn of de Ontvangst kan worden afgeletterd of niet.
* Matchen kan ook indien slechts één Faktuurnummer in de Betalingsomschrijving wordt opgenomen; indien in zo'n geval bij de Debiteur nog geen rekeningnummer bekend was, wordt deze automatisch opgenomen in de Financiële Parameters.
* Alleen termen die eenzelfde lengte hebben als het huidige Faktuurnummer worden verwerkt; dus, uitgaande van een Faktuurnumer van 7 posities, worden alleen alle voorkomend van 7 aansluitende cijfers uit het Betalingskenmerk verwerkt. Hiermee vallen bijv. datums of de vermelding van een ordernummer automatisch af, omdat deze niet voldoet aan 7 aaneensluitende cijfers,
* Betalingskortingen worden niet gerespekteerd; kan wel aanvullend worden ontwikkeld.
* Valutakode van de Faktuur dient in dezelfde Valuta te staan als de Valutakode van de Ontvangst.
* Betalingsomschrijving wordt niet door het systeem gewijzigd; alle informatie die de Debiteur doorgeeft, staat in de Ontvangst. Kan het systeem geen match maken, dan kunt U dat visueel mogelijk nog wel, maar daarvoor heeft U wel die info nodig die de Debiteur aangaf (en niet dat wat het systeem ervan gemaakt heeft).
* Exakte match met Faktuurbedragen, marges worden niet gerespekteerd.
Reeds bij het inlezen van het afschrift wordt bepaald of de ontvangst kan worden gematched met openstaande fakturen. Zo niet, dan wordt de ontvangst afgekeurd, en bevat de kommentaarregel de reden waarom deze is afgekeurd.
Indien een Ontvangst niet verwerkt kan worden, kan via "Wijzigen" het Betalingskenmerk worden aangepast, en kan opnieuw "Verwerken" op "Ja" worden gezet; na
F1___ zal het systeem opnieuw bepalen of er na de aanpassing wel/niet verwerkt kan worden.
Indien er geen match gemaakt kan worden tussen het rekeningnummer vanwaaraf betaald werd en de Debiteur, dan dient U dit rekeningnummer zelf op te nemen bij de betreffende Debiteur. Misschien vermeldt de Debiteur zijn Debiteurennummer (of Id) wel tijdens zijn betaling. Speciaal voor die situatie is er vanuit Raadplegen Ontvangsten een toets Shift-F5 opgenomen, waarmee we naar Financiële Parameters Debiteuren kunnen gaan. Shift-F5 zal tevens het rekeningnummer van de geselekteerde Ontvangst naar het clipboard kopiëren, zodat als U de betreffende Debiteur gevonden heeft, en deze wijzigt, U met Control+V het Rekeningnummer kunt plakken in rubriek Rekeningnummer.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| ADBHOI | Omschrijving (nog) niet bekend | 30-12-2011 | 09-03-2012 |
| ADDEOV | Verwerken Ontvangsten | 20-06-2006 | 08-03-2012 |
| ADOVBK | Omschrijving (nog) niet bekend | 27-09-2011 | 14-03-2012 |
| ADOVBPDR | Omschrijving (nog) niet bekend | - - | 09-03-2012 |
| ADOVGN | Genereren Ontvangsten Telebanking | 15-12-2011 | 08-03-2012 |
| ADOVMD | Omschrijving (nog) niet bekend | - - | 09-03-2012 |
| ADOVRA | Raadplegen Ontvangsten Telebanking | 15-12-2011 | 08-03-2012 |
| ADOVWY | Wijzigen Ontvangsten Telebanking | 03-05-2011 | 09-03-2012 |
