De module
Profit-Key is een module waarmee de gebruiker zelf sneltoetsen kan maken naar talloze funkties. Stel dat we naar Gereedmelden Produktieorder willen, dan kunnen we voor die funktie (LOPOGM) een Userbutton aanmaken, en vervolgens zal een click op de betreffende button direkt die Funktie aktiveren.
Niet iedere Funktie laat zich aanroepen met een Userbutton. Om even een voorbeeld te geven: Stel dat we een nieuwe Verkooporder toevoegen, dan kent het systeem een ordernummer toe. Vervolgens komen we in Toevoegen Verkooporderregels terecht, en gaan we regels toevoegen aan die Verkooporder. Niets weerhoudt ons ervan om een Userbutton aan te maken voor Toevoegen Verkooporderregel, maar, zodra we die button vanuit bijv. het Hoofdmenu aanroepen terwijl er géén ordernummer is geselekteerd, gaat dit fout. Ook kan dit al fout gaan omdat Toevoegen Verkooporderregels alleen wordt aangeroepen vanuit Raadplegen Verkooporderregels en dáár allerlei kontroles worden uitgevoerd die kontroleren ňf LOVRTV wel mag worden aangeroepen. Immers, als de order al is afgesloten, mogen er geen nieuwe regels worden toegevoegd.
Een rechtstreekse aanroep via een Userbutton zou dit soort kontroles omzeilen, en zou toestaan om regels toe te voegen aan een order die al afgesloten is. Mogelijk wordt zoiets pas veel later in het trajekt gekonstateerd, omdat we bijv. wel in staat zijn die regel te leveren, maar, zodra we gaan faktureren, blijkt dat de hele order niet meer verwerkt wordt omdat ze al een status "F" (volledig gefaktureerd) heeft.
Als we Userbuttons gebruiken om zijstapjes te maken, is het ook onze bedoeling om hetgeen wat in het zijstapje geselekteerd wordt, mee terug te nemen naar de gelijknamige rubrieken in de aanroepende funktie.
Wederom bijzonder handig. We worden ergens gevraagd om een Relatie in te voeren, er bestaat geen formele toets naar Raadplegen Relaties, maar middels een Userbutton selekteren we alsnog de Relatie, keren met [font color="#808080"]Esc__[/font] terug naar de oorspronkelijke funktie, en de Relatie-Id staat ingevuld.
Toch kan ook dit juist weer tot problemen leiden. We wijzigen een Debiteur, en moeten een IBAN rekeningnummer maar ook een Opdrachtgever invullen. Ondanks dat er formeel een toets bestaat naar Raadplegen Opdrachtgevers (die voor een juiste terugkeer zorgt), roepen we Raadplegen Opdrachtgevers met een Userbutton aan. Een Opdrachtgever kent ook een IBAN nummer, en, waar het ons doel was om middels het zijstapje een Opdrachtgever te selekteren, nemen we ook vanzelf de gelijknamige rubriek IBAN nummer mee terug naar de aanroepende funktie, en staat het IBAN nummer van de Opdrachtgever ineens bij de Debiteur ingevuld.
Al zouden we maar 5000 Funkties hebben (het zijn er veel meer) dan geldt dat 5000 Funkties 5000 andere Funkties kunnen aanroepen, waaruit al 25M aan kombinaties volgt. Het is derhalve niet op voorhand te zeggen welke kombinaties wel of niet toegestaan zijn danwel mogelijk tot problemen leiden. Het gebruik van Userbuttons is derhalve "as is". Werkt het, mooi dan kunt U het gebruiken, werkt het niet, dan de Userbutton verwijderen en niet meer gebruiken.
Veel klanten zijn echter zelf heel goed in staat om te bepalen welke kombinaties tot problemen leiden, en welke niet. We horen ze amper m.b.t. problemen die veroorzaakt worden door onjuist gebruik van Userbuttons. Er zijn ook klanten die klakkeloos heen en weer springen met Userbuttons, zich niet realiserend wat voor een problemen hun akties mogelijk veroorzaken.
Zo hebben we recentelijk een situatie gehad waarbij iemand bezig was met het inboeken van de Faktuurkontrole, was het Faktuurbedrag afgeletterd op alle Inkooporderregels, werd de Faktuur gejournaliseerd (waarbij het afbreken van de Journalisering nog kan zorgen voor het afkeuren van het inboeken van de Faktuur + daarmee de hele Faktuurkontrole) en werd vanuit het Journaliseringsscherm met een Userbutton een zijstap gemaakt naar Raadplegen Fakturen om uit te zoeken op welke Kostenplaats een andere Faktuur van dezelfde Leverancier was geboekt. Resultaat: het Faktuurnummer welke in de zijstap werd geselekteerd overschreef het Faktuurnummer die we aan het inboeken waren...
Ook zijn er situaties bekend dat vanuit Gereedmelden Produktieorders zijstapjes gemaakt worden, en daardoor kostprijsgegeven onjuist berekend worden. Dit uit zich mogelijk pas weken later, omdat marges in de statistieken niet kloppen.
In veel situaties leidt een vraag "het systeem heeft iets fout geboekt, maar wij weten niet wat we fout gedaan hebben, zouden jullie dat eens kunnen uitzoeken" tot dezelfde oorzaak: het onjuist gebruik van een Userbutton.
Om derhalve veiliger met Userbuttons overweg te kunnen gaan hebben we nu een Systeemparameter waarmee kan worden aangegeven dat Userbuttons alleen mogen worden uitgevoerd vanuit een menu. Of beter, indien er alleen maar menu's op het scherm staan. Een Userbutton gebruiken als er 4 menu's geopend zijn lijkt nog steeds geen kwaad te kunnen; een userbutton uitvoeren als er ná een verwerkingsfunktie een menu ontstaat (bijv. een popup met een keuzescherm) welke vanuit LOVRTV wordt aangeroepen, zou dan alsnog weer niet toegestaan zijn.
Weliswaar vervalt hierdoor voor sommige situaties het voordeel dat de Userbutton gebruikt kan worden om een zijstap te maken om iets te selekteren wat na terugkomst ingevuld is, maar, sinds de introduktie van het SideGrid kunnen we ook de Spatiebalk gebruik om een bepaalde sleutelwaarde van bijv. een Relatie-id te vinden.
Userbuttons worden tegenwoordig dan ook veel meer gebruikt om niet allerlei moeilijke menustrukturen te doorlopen. Gereedmelden Produktieorder doen we door 1 click op een button, en niet door 5-2-2-4 te moeten intypen.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| APOK | Omschrijving (nog) niet bekend | 13-11-2012 | 09-01-2013 |
| SYBHSYPA | Instellen Systeem Parameters | 02-03-2012 | 09-01-2013 |
| SYINM | Omschrijving (nog) niet bekend | 23-01-2012 | 09-01-2013 |
