M.i.v. deze Releasenote is het mogelijk om bepaalde "Gefaktureerde Verkoopoverzichten" te printen op basis van een berekening die als een SQL Query wordt uitgevoerd. Deze methode is ontwikkeld voor de ADS versie van Profit, zijnde een versie die een andere database als grondslag heeft voor Profit dan de native Visual FoxPro Database: ze maakt gebruik van een Advantage Database Server. Een van de grote voordelen van deze Advantage Database is dat ze tabellen ondersteunt die groter kunnen worden dan 2 GB per stuk.
De Advantage Database kan ook middels SQL benadert worden, en met name gezien het feit dat deze tabellen 'grote' omgevingen impliceert met veel data, kan vanaf heden SQL worden ingezet om statistieken op te bouwen.
Merk op dat de statistieken tienduizenden regels coding omvat, welke niet simpelweg te vertalen is naar één SQL commando. Ook geldt dat het uiteindelijk weliswaar de bedoeling is om ADS aan de praat te krijgen met alle tabellen als Advantage tabel draaiend, vooralsnog geldt dat slechts een aantal (zeer grote) tabellen in ADS gedefinieerd kunnen worden, en de andere tabellen normale VFP tabellen zullen betreffen. Het mag duidelijk zijn dat we de ADS Server niet van een SQL opdracht kunnen voorzien met daarin data die nodig is uit tabellen die niet in de Advantage Database zijn opgenomen.
Vanuit de ADS versie zal het opvragen van een Gefaktureerd Verkoopoverzicht leiden tot een separaat menu, vanwaaruit de 'normale' versie kan worden opgestart (met daarin alle opties die we gewend waren, doch welke de database 'record voor record' benaderd), danwel de nieuwe SQL versie.
In dat menu zijn alle Selektieniveau's die nog niet zijn ondervangen disabled (lichtgrijs). Selekties die in het rood worden weergegeven, betreffen selekties die op zich al wel mogelijk zijn via de SQL statistieken, maar, welke in uw situatie niet geselekteerd kan worden omdat hiervoor benodigde tabellen niet als ADS tabel zijn gedefinieerd.
Dus, omdat we "Afleveradressen" nog niet als ADS tabel hebben gedefinieerd, zijn selekties op Afleveradres, Plaatsnaam e.d. niet mogelijk via de SQL versie.
Dan zijn er nog talloze selekties die ogenschijnlijk eenvoudig zijn, maar in werkelijkheid nèt even wat complexer worden afgehandeld. Denk hierbij aan de situatie dat we een Verkoper of een Verkoopgebied eenvoudig bij een Verkooporder kunnen weghalen, en die tabel op zich definieerbaar is als ADS tabel. Toch is een selektie op Verkoporder of op Verkoopgebied niet mogelijk, omdat, in de situatie dat er bij de Verkooporder "niets" staat, alsnog naar de defaultwaarde van de Debiteur wordt gekeken, en het juist "de debiteurentabel" is die nog niet in ADS definieerbaar is.
Een ander voorbeeld van een ogenschijnlijk eenvoudige selektie betreft het "Artikelnummer" (al dan niet in kombinatie met de Verschijningsvorm). Immers, wat is er nou simpeler dan i.g.v. een Selektie op Artikelnummer (C) en een filter op 0 t/m ZZ, een SQL Query uit te voeren:
SELECT LOAR, <omzet> FROM LOFR WHERE LOAR_AID BETWEEN '0' AND 'ZZ' Toch werkt bovenstaande selektie niet, wat weer alles te maken heeft met andere 'regels' die binnen de Profitoverzichten gelden. Zo kunnen we onze omzetgegevens op meer dan 2 miljoen verschillende manieren presenteren, maar, de totale omzet onder aan de streep moet bij ieder overzicht (waarbij 'alles' wordt opgevraagd) gelijk zijn. Dat wil dus zeggen dat er geen zaken in mogen ontbreken, maar ook geen zaken dubbel geteld mogen worden.
Een Kostenregel kent in de database géén Artikelnummer en zou door bovenstaand filter 0 t/m ZZ niet verwerkt worden; dit, terwijl het de bedoeling is dat dergelijke regels automatisch onder 'ZZ' komen te vallen.
Nog complexer wordt het als we dit kombineren met een Artikelgroep, waarbij ieder Artikel zowel in een hoofdgroep, een produktgroep alsmede een subgroep is opgenomen, en waarbij het al dan niet hebben gedefinieerd van meerdere groepen binnen de range die opgevraagd wordt ertoe moet leiden dat e.e.a. òf onder de gekoppelde groep moet worden gerapporteerd òf onder 'ZZ' om dubbeltellingen te voorkomen.
Ondanks dat bepaalde selekties tabellen behoeven die in ADS gedefinieerd zouden moeten zijn, zijn bepaalde selekties toch mogelijk ook al zijn die tabellen niet in ADS opgenomen. Dit, omdat e.e.a. intern nèt op een iets andere manier wordt opgelost (zo zal bijv. een overzicht op Debiteurengroep intern worden omgezet naar een overzicht waarbij alle Debiteuren uit de Debiteurengroep worden omgezet naar een "filter op Identifikatie") of dat achteraf een herberekening plaatsvindt op basis van de resultatentabel (een overzicht op Financiële Groep kan niet in 1 keer worden uitgevoerd omdat LOAR en LOVA niet in ADS staan; wel kan e.d. selektie worden omgezet naar een selektie op Artikel-/Verschijning, waarbij achteraf van iedere gevonden Artikel-/Verschijning alsnog de Financiële Groep bepaald wordt, en de data weer wordt samengevoegd tot het gevraagde overzicht.
Hoewel op voorhand bekend is dat we niet alle selekties aan de praat zullen krijgen, is het toch gelukt om deze SQL Statistieken voor de meest gangbare selekties te kunnen gebruiken.
Merk op dat we altijd nog de 'normale' versie hebben die de database record voor record benaderd, en waarin alle opties mogelijk zijn. Of e.d. versie nog werkbaar is in een versie waarin tabellen 20 GB of groter zijn, is daarbij de vraag. Uitgangspunt mag misschien ook wel zijn dat een bepaalde mate van detail niet meer wordt opgevraagd bij zo'n grote database, al was het maar omdat het resultaat 'te groot' zal zijn.
Opbouw: De nieuwe SQL statistieken worden volledig Object georienteerd opgezet. Ieder selektieniveau biedt daarin funktioneel dezelfde mogelijkheden, hooguit wordt dit vanuit Profit nog niet aangestuurd.
Hiermee bedoel ik dat als we een overzicht opvragen op Debiteur (F) en Artikel (C), we vanuit Profit standaard op het 1e niveau kunnen kiezen voor:
een Van - T/m selektie
òf
een reeks Identifikaties (komma gescheiden)
Voor ieder volgend niveau geldt dat we hooguit een reeks met Identifikaties kunnen opgeven. Hiermee was het nimmer mogelijk om een overzicht op te vragen van Debiteur A t/m AZ en Artikel 502 t/m 502ZZ.
Voor de SQL Rapportages bevatten de classes wel de potentie voor dergelijke selekties! hooguit kunnen ze vanuit de huidige Profit schermen nog niet worden aangestuurd (door het ontbreken van de benodidge schermvelden). E.e.a. zou er relatief eenvoudig bij kunnen worden gemaakt.
Beperkingen: * Om te beginnen beperken we ons nu tot het Gefaktureerde Verkoopoverzicht (Hmenu,8,3,2,1). De overige overzichten en statistieken, gerealiseerd, geprognotiseerd, geoffreerd kunnen nog niet o.b.v. SQL worden uitgevoerd.
* Ieder Selektieniveau van het Gefaktureerde Verkoopoverzicht zal expliciet moeten worden geïmplementeerd in de SQL versie. Om duidelijk inzichtelijk te maken welke selekties wel/niet mogelijk zijn, is het hoofdscherm van het Gefaktureerde Verkoopoverzicht in de SQL versie een aparte funktie waarin niveau's 'disabled' (uitgeschakeld) kunnen zijn. Reden dat een niveau nog niet selekteerbaar is kan zijn 'omdat de daarvoor benodigde tabel nog niet als ADS tabel ondervangen is', maar kan ook zijn 'omdat de selektie in SQL (vooralsnog) té complex is'.
Als een selektie in het rood wordt weergegeven, dan is de selektie op zich wel ondervangen, maar, kan ze niet worden uitgevoerd omdat bepaalde tabellen in uw omgeving nog niet als ADS tabel zijn opgenomen. Zo vereist bijv. een selektie op Chargenummer dat de tabel "LOCL" als ADS tabel is gedefinieerd.
* Verbijzonderingen met DKK Tarieven zijn niet ondervangen.
* Kapaciteitsbehoefte, Saldo uren berekenen Verkooporder, zijn niet ondervangen in de SQL versie.
* Stuklijsten (o.a. berekening aantal colli) zijn niet ondervangen.
* Goederen Retour (Dry Dock) is niet ondervangen v.w.b. specifikaties op Chargeniveau. Hierbij mag je je voorstellen dat we op een Verkooporder 1000 liter verkopen, maar er later voor 200 liter aan creditregels wordt opgenomen, opdat er 1 totale faktuur de deur uit gaat van 800 liter. Wordt er op Faktuurregel niveau gerapporteerd, dan is er geen probleem, immers, we vinden gewoon een Faktuur van 800 liter, en weten de kostprijs daarbij op te hoesten.
Als we echter op Chargeniveau gaan rapporteren (selektie op Chargenummer, Leverdatum, Magazijn etc) dan vinden we 1000 liter in de geleverde charges. De 200 aan credit komt niet terug in de charge records, en moet in mindering gebracht worden op de gevonden 1000 liter. Middels een complexe query vast wel mogelijk (of als stap achteraf), maar, voor nu geen prioriteit gezien een paar specifieke situaties waarin deze methode gebruikt wordt.
* Alle tabellen die voor de SQL Statistiek benodigd zijn, dienen in dezelfde Data Dictionary te zijn opgenomen. Vooralsnog is het uitgangspunt dat er maar met één Data Dictionary gewerkt wordt. Merk op dat we op zich voorbereid zijn om onze database over meerdere ADS Servers te verdelen. Deze funktionaliteit is op zich nog nergens in gebruik, maar is al zo opgezet omdat we konstateerden dat als een Server over 4 cores beschikt, en druk bezig is een tabel te reorganiseren, de CPU slechts naar 25% gaat. Bij respektievelijk 2, 3 en 4 tabellen gaat de CPU naar 50%, 75% en 100%, waaruit we kunnen konkluderen dat we bij 4 cores maximaal 4 tabellen tegelijk kunnen reorganiseren. Als de nood echt aan de man is, zouden we meerdere ADS Servers kunnen inzetten om onze database over te verdelen (even los van het kostenplaatje met dubbele (licentie) kosten). De potentie is er in ieder geval.
* Konsumentenprijs is niet ondervangen
Maar, bovenstaande is leuk bedacht, maar gaat voor een SQL Query natuurlijk niet werken, omdat die geen query kan uitvoeren die over meerdere data dictionaries heen gaat. Uiteraard zou een scheiding nog wel kunnen worden gelegd op "financieel" op de ene server, en "logistiek" op de andere.
Performance In de basis geldt natuurlijk dat hoe gedetailleerder de selektie is die u opvraagt en hoe groter de database is, des te langer het zal duren voordat het overzicht klaar is. Daarnaast zijn er ook een aantal selekties die niet rechtstreeks op de ADS database kunnen worden losgelaten, en die achteraf 'aandacht' behoeven om e.e.a. alsnog juist te kunnen presenteren. Dit soort situaties worden hieronder belicht, opdat u zich realiseert dat het gebruik ervan kan impliceren dat u langer dan anders op het resultaat moet wachten.
Detailniveau Los van het aantal niveau's waarop gerapporteerd wordt, kan iedere selektie een ander niveau van berekenen van data doen triggeren. Zo zal het verschillen of we onze Query kunnen baseren op slechts de Fakturen en hun Faktuurregels, of dat we de "Verkooporders" en "Verkooporderregels" erbij moeten betrekken, danwel nog erger, een selektie op Chargenummer, Magazijn of Leverdatum triggert dat we alle afzonderlijke "Geleverde Charges" moeten doorlopen.
Eenheden weergeven in */KG/L/ST/M1/M2/M3/TN etc. Zodra eenheden worden weergegeven in * is deze hoeveelheid rechtstreeks beschikbaar in de Faktuurregels. Weergave op basis van "ST,CO,V" betreft allen een rapportage op basis van "het aantal Verschijningen" welke eveneens eenvoudig bepaald kan worden. Zodra we echter op een andere eenheid rapporteren, KG moet Liters worden, ST moet KG worden, of we willen de hoeveelheid in M3 weten, dan zal er 'berekend' moeten worden. Allereerst spelen bij dergelijke berekeningen het 'Gewicht per Voorraadeenheid' en de 'Soortelijke Massa' mee die op Artikelniveau geregistreerd staan. Maar, voor het gewicht telt ook het gewicht van de Verschijningsvorm mee, en e.e.a. nog wat complexer te maken, kan het gewicht-/volume ook berekend worden middels een formule die gebruik maakt van de Kenmerken die aan de orde zijn (lengte x breedte x dikte, of een gewicht bepalen op basis van een Artikel die als Kenmerkwaarde gesubstitueerd moet worden). Alle hiertoe benodigde informatie wordt automatisch bepaald (ook al zou er slechts op Debiteurniveau in KG gerapporteerd worden), maar zal extra tijd vergen.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| APLVGNDT | Omschrijving (nog) niet bekend | 18-02-2014 | 19-03-2014 |
| LOARAGRA | Raadpl. Artikelgroepen per Art | 03-01-2014 | 14-03-2014 |
| LOGARA | Raadplegen Art per Artikelgroe | 06-02-2014 | 14-03-2014 |
| LOOZPOBP | Omschrijving (nog) niet bekend | 09-01-2014 | 21-03-2014 |
| LOOZVFBP | Omschrijving (nog) niet bekend | 09-01-2014 | 14-03-2014 |
| LOPGSQVA | Omschrijving (nog) niet bekend | 24-08-2012 | 17-03-2014 |
| LOPRVKO1 | Omschrijving (nog) niet bekend | 15-02-2013 | 13-03-2014 |
| LOPRVKOV | Printen Verkoopoverzicht | 19-10-2012 | 14-03-2014 |
| LORDGRZK | Omschrijving (nog) niet bekend | 23-01-2014 | 13-03-2014 |
| LOSTPOVK | Print Overzichten Verkoop | 28-02-2007 | 10-03-2014 |
| LOVKOV | Print Verkoopoverzichten | 25-06-2009 | 10-03-2014 |
| LOVKOVMN | Omschrijving (nog) niet bekend | - - | 10-03-2014 |
| LOVKOVNO | Omschrijving (nog) niet bekend | 25-06-2009 | 07-03-2014 |
| LOVKSQ | Omschrijving (nog) niet bekend | - - | 10-03-2014 |
