Ik denk dat we de discussie moeten afronden. Dit omdat nu wel bekend is wat ik wil.
Hahaha, dat hoopten we beiden.
Maar na toch weer ruim een uur telefoneren (ik zag m'n weekend al voorbij gaan), denk ik dat we beiden vinden dat we beiden begrijpen wat jij wilt. Of zoiets.
Laten we onderstaand plaatje maar ald leidraad nemen
(trouwens, ik heb zo maar wat gedaan in het systeem hier, en er komen allemaal "beton" betalingen voorbij ?? hoe kan dat nou toeval zijn)
E.e.a. onder het voorbehoud van totale afkeuring door Wouter ...
Zoals het momenteel werkt :
De betalingen van de "klant" werken via een Ontvanger. Deze ontvanger (een Debiteur-ID) wordt feitelijk door jezelf aangegeven. Waarschijnlijk treden er mechanismen onder water op die e.e.a. automatisch kunnen bepalen, maar in elk geval ... wanneer ADOVGN (het genereren van de Afschriften) er niet zelf uitkomt (omdat de Ontvanger (nog) niet bekend is), zie in je ADOVRA (zie plaatje) de Afschriften staan die (om die reden) niet konden worden verwerkt. Vervolgens kan je via ADOVWY de Ontvanger aangeven (zie "Debiteur-id").
Het probleem is nu dat de betaling kan worden gedaan door bijvoorbeeld een hoger orgaan -zoals Holding maatschappij van de eigenlijke Debiteur-, en dat deze Holding daarmee logischerwijs ook een betaling kan doen voor meerdere Debiteuren van jou (vallen allemaal onder dezelfde Holding, maar zijn voor jou individuele Debiteuren).
Wat je nu ziet is dat het rijtje fakturen wat in dit geval door Stuytvriezen B.V. wordt betaald, niet bij één Debiteur van jou hoort, en dus het Afschrift als geheel niet onder één Debiteur kan worden verwerkt. Dit moet ook niet natuurlijk.
Wat er verder gebeurt is dat na het invullen van een aan de orde zijnde Debiteur (die volgt uit 1 of meer Faktuurnummers), de betreffende Faktuurnummers worden genoemd in plaats van het rijtje wat meerdere Debiteuren impliceert, waarna het Afschrift voor dit deel kan worden verwerkt.
Ik neem aan dat het bedrag (zie de 9050.77) hierop sluitend moet worden gemaakt, maar zonder dat zou het ook wel werken (er worden gewoon Fakturen tegengeboekt en als Betaald gekenmerkt).
Omdat je dit zo voor alle geïmpliceerde Debiteuren moet doen voor alleen al dit ene Afschrift, ben je wel even bezig.
Het verhaal doet nu de ronde dat het best gebruikelijk is om één Faktuurnummer volledig te noemen, bijvoorbeeld 129784, om de rest 621, 548, 549, 785, 786 te noemen (zie weer plaatje, waar dit overigens niet is toegepast). Er zouden mechanismen aanwezig zijn die op basis hiervan hun werk doen, ofwel, het volledige Faktuurnummer match met de (??) Debiteur, en de rest kan daaruit worden afgeleid.
Wat alleen niét gebeurt, is dat ditzelfde mechanisme wordt gebruikt om de Debiteur sowieso op te selekteren ... Om haar te "kiezen" dus.
Ik vermoed dat e.e.a. wel werkt als alle via dit mechanisme bepaalde Faktuurnummers horen bij één Debiteur, maar niet als dit niet het geval is, zoals de in dit topic beschreven problematiek.
Verder zal het nooit rekening zijn gehouden met een situatie als deze, ook in aanmerking nemend dat in Profit het ooit niet mogelijk was om zulk soort betalingen te doen (namens dochtermaatschappijen enz.), wat ook eens werd ontwikkeld. Dat was de andere kant dus, en nu deze zijde van het verhaal nog ...
Ofwel, wat er lijkt te moeten gebeuren - maar vooral wat lijkt te kùnnen gebeuren, is dat ieder uitgewerkt volledig Faktuurnummer wordt gematched met bestaande Fakturen, die aldus zal behoren bij een bestaande Debiteur (waar we ooit de Faktuur naartoe hebben gezonden), opdat e.e.a. alsnog automatisch kan werken.
Laten we er maar eens vanuit gaan dat we dit stukje wel voor elkaar kunnen krijgen. Maar om te zien hoe e.e.a. funktioneel uitpakt, moet ik denk ik eerst terug naar wat Dinand wilde (via laatste telefoongesprek) :
In onderstaande plaatje vullen we Debiteur-id in, en noemen op de regel de betreffende (dus bijbehorende) Faktuurnummers in. Dit dan wel volgens het principe van 1 volledig nummer en de rest "afgekort". Gedaan ? volgende Debiteur.
Let wel, en let op, want dit heb ik eerder in dit topic beschreven als : en dan genereer je de Afschriften opnieuw, die vervolgens jouw gewijzidge regel meenemen, en dus werkt het bij een volgende poging.
Echter, deze werkwijze was meer gebaseerd op het "Zie specifikatie" voorbeeld, en dacht te veel aan één benodigde ronde hiervan, waar we het er nu over meerderen hebben (net zoveel als dat er verschillende Debiteuren worden geïmpliceerd). En *nu* zie ik niet hoe dat moet werken, waar een Afschrift immers een Afschrift is, en je hier gaart bewerkstelligen dat er meerdere regels in ADOVRA gaan bestaan voor één Afschrift(regel).
Of dit erg is - of al intrinsiek aanwezig is weet ik niet, maar *dit* is in elk geval het nog resterende probleem.
Terug naar de zojuist beschreven oplossing, zie je dat e.e.a. samenkomt in dit probleem, als je van een Afschrift weliswaar 4 Fakturen hebt weten te vinden en hebt weten te presenteren in het ADOVRA overzicht, maar 2 anderen niet konden worden verwerkt. En dan nog om 2 verschillende redenen ook ...
Als we nu nog weer eens het plaatje bekijken, zien we al dat e.e.a. voor zoiets niet is gemaakt. Immers, ADOVWY toont dat we met het originele Afschrift bezig zijn (althans, origineel zoals de betreffende regel is gepresenteerd door de bank), en dat we alleen op dat niveau iets kunnen, welk niveau niet het onze is. Niet meer, want wij "moeten" iets met individuele Faktuurnummers.
Of je nu mijn volledig automatische verwerking van nu (zie boven) neemt, of het mindere mooie van het door mij met Dinand jl. vrijdag bedachte ... beiden lopen vast op ADOVRA die hiervoor hiet is gemaakt.
Het volledig automatische geeft dan nog de beste mogelijkheden, omdat dat immers er toe zou kunnen leiden dat alles wordt gevonden, en ADOVRA alleen maar "kan worden verwerkt" regels toont. Maar ja, daar kunnen we niet vanuit gaan.
Laten we maar zeggen dat het bovenstaande allemala redelijk degelijk is, terwijl het onderstaande te veel een brainstorm zal zijn ...
Volgens mij moet het een soort van andersom. Soort van, niet echt;
ADOVRA blijft zoals ze is, doch het "Kommentaar" in de zin van "reden van afkeur" moet meer specifiek worden en eigenlijk gaan verwijzen naar een achterliggend overzicht (per regel) wat op Faktuurniveau werkt. In dat overzicht (als zijstap op te vragen per Afschriftregel) vinden we de bepaalde (volledige) Faktuurnummers, en per Faktuurnummer weer Kommentaar zoals in ADOVRA. Let wel, de redenen van afkeur die we in dit zijstap overzicht vinden (laten we het maar even ADOVUFRA noemen), zijn
bepalend voor wat in ADOVRA wordt getoond. Niet andersom dus. Anders gezegd, als ADOVUFRA een "Geen te gebruiken Faktuurnummer gevonden" toont, en via een ADOVUFWY wordt dit omgezet naar een wel te gebruiken Faktuurnummer, dan zorgt dit op het hogere ADOVRA niveau ervoor dat aldaar het overeenkomstige Kommentaar (zie de in de praktijk bestaande voorbeelden) verdwijnt (of in elk geval consistent wordt met de samenvatting van alle onderliggende "faktuurregels".
Volgens mij komt het er ook op neer dat waar het "Verwerken Afschriften" nu op basis van ADOVRA werkt, dit zal moeten gaan werken op basis van de nieuwe ADOVUFRA. Dit kan (volgens mij) niet anders.
Er zijn, vrees ik, nog wel meer implicaties, althans, meer tijdrovende zaken om e.e.a. duidelijk te houden. Zie als voorbeeld de "Reeds ontvangen - zie Volgnummer 67" in het plaatje, en je voelt wel dat als we dit zo laten, jullie als gebruiker dat straks niet meer begrijpen omdat Volgnummer 67 meerdere Fakturen heeft waarvan er wellicht 1 al is ontvangen, terwijl Volgnummer 189 zelf eveneens meerdere Fakturen heeft en de mededeling over één van die Fatuurnummers zal gaan, of zelfs meerderen. Of gewoon allemaal. Hiervoor moet je dus feitelijk in ADOVUFRA zijn, die aldaar moet kunnen doorverwijzen naar ten eerste een andere ADOVUFRA regel (van een ander Afschrift dus) en waarbij je ten tweede binnen ADOVOFRA een soort van "ADOVRA overzicht" (als in het overzicht hebben) wilt hebben.
Als dit allemaal niet juist wordt onderkend, word je helemaal gek (want je kan niets terugvinden), terwijl je ook nog eens bezig bent met uit te lokken dat je vanaf het begin niet hebt begrepen wat er gebeurt (wat nu niet kan gebeuren, want het wordt domweg afgekeurd, en vervolgens los *jij* het probleem op, en niet het onderwater-systeem-wat-niet-is-te-volgen).
Als het allemaal werkt is het volgens mij wel een stuk verbeterd ...
