M.i.v. deze Releasenote is het Gefaktureerde Verkoopoverzicht aangepast m.b.t. een optimalisatie zodra het overzicht voor één specifieke Debiteur wordt opgevraagd.
Deze optimalisatie wordt al enkele jaren met succes toegepast vanuit het CRM scherm, is de funktionaliteit wordt nu standaard toegepast, mits het 1e niveau in het Verkoopoverzicht "F" (Debiteur) is én de eerste Debiteur gelijk is aan de laatste Debiteur (Van - T/M dienen met dezelfde Identifikatie gevuld te worden).
Bij de Gefaktureerde Verkoopoverzichten hebben we meer dan een miljoen kombinaties om de faktuurgegevens te rapporteren (met 40 selektie mogelijkheden op 4 niveau's komen we al op 40x39x38x37 mogelijkheden).
Standaard worden alle Fakturen uit de opgegeven periode doorlopen. Per geldige Faktuur worden vervolgens de Faktuurregels doorlopen, en mogelijk wordt de data van een nóg diepere stap gebruikt: de geleverde Charges. Alles afhankelijk van het niveau waarop gerapporteerd wordt.
Indien op Faktuurheaderniveau al gekonstateerd kan worden dat deze Faktuur niet geldig is, dan zullen de regels van die Faktuur niet hoeven te worden doorlopen.
Stel eens even dat we 1000 Debiteuren hebben, die ieder 100 Fakturen op jaarbasis hebben, en dat op iedere Faktuur 10 regels staan.
Stel dat we een rapport opvragen over de afgelopen 4 jaar, dan zijn daarbij 4 x 1000 x 100 = 400.000 Fakturen betrokken en 4.000.000 Faktuurregels.
Zouden we een Verkoopoverzicht opvragen van één Debiteur, dan worden standaard 400.000 Faktuurheaders doorlopen. 399.600 Fakturen kunnen direkt overgeslagen worden omdat de Debiteur niet overeenkomt, en van de resterende 400 Fakturen zullen de Faktuurregels worden doorlopen (4.000 stuks).
Hoewel in bovenstaand voorbeeld 399.600 Fakturen overgeslagen moeten worden, is daar op zich nog wel op te wachten. Dit zal geen "uren" duren.
Het verhaal wordt echter anders zodra we niet op de Debiteur van de Faktuur rapporteren, maar op basis van de Debiteur van de Verkooporder. Zo leveren we bijv. aan Albert Heijn filiaal 2514, maar de Faktuur gaat naar AH Zaandam, en we willen in ons overzicht zien wat we aan welk filiaal geleverd hebben.
Een Faktuurheader is niet altijd representatief voor één Afleverdebiteur. Denk maar aan de situatie dat we aan 50 verschillende AH filialen kunnen leveren, maar één Verzamelfaktuur sturen naar AH Zaandam. We kunnen dus niet op headerniveau konstateren of de Debiteur van de Verkooporder juist is, en dus wordt dat nu per Faktuurregel bepaald !
Resultaat is dus dat we 4 x 1000 x 100 x 10 = 4.000.000 Faktuurregels moeten doorlopen, op zoek moeten gaan naar de Verkooporderregel horende bij die Faktuurregel, en op basis daarvan moeten bepalen of deze Faktuurregel verwerkt moet worden of niet.
Uiteindelijk zoeken we nu in 4.000.000 Faktuurregels, en levert het resultaat slechts 4 x 100 x 10 = 4.000 regels op.
Indien we nu een overzicht opvragen voor
alle Debiteuren van de afgelopen 4 jaar, dan is het logisch dat we 4.000.000 Faktuurregels moeten doorlopen om aan het juiste saldo te komen. Dat we dan moeten wachten op ons overzicht is verklaarbaar. Echter, dat we óók zo lang moeten wachten als we slechts één Debiteur opvragen is zonde.
De ingebouwde optimalisatie bouwt eerst een tijdelijk bestand op met daarin de Fakturen die aan de orde zijn bij het overzicht op de opgegeven Debiteur. Afhankelijk van of er op basis van de Debiteur van de Faktuur danwel de Debiteur van de Verkooporder wordt gerapporteerd, zal deze tabel op een slimmere manier worden opgebouwd.
Zo zal bij rapportage o.b.v. de Faktuurdebiteur alle Fakturen worden doorlopen van de opgegeven Debiteur (via een hiervoor beschikbare index op Debiteur + Faktuurdatum) en dit als basis gelden voor het op te vragen overzicht.
Bij een rapportage o.b.v. de Debiteur van de Verkooporder, zullen de Verkooporders van deze Debiteur worden doorlopen. Van deze orders wordt bepaald op welke Fakturen deze in rekening zijn gebracht, en op deze wijze wordt een tabel opgebouwd met de te doorlopen fakturen die als basis dient voor het op te vragen overzicht.
Met name in dit laatste geval levert dit een hele flinke performance verbetering op.
Let op: vereiste is dat dus dat op het 1e niveau gefilterd wordt op Debiteur (F) en dat de Van Debiteur gelijk is aan de T/M Debiteur.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOPRVKO1 | Omschrijving (nog) niet bekend | 26-10-2010 | 27-10-2010 |
