Operator/operand type mismatch bij Gebruikersbutton 3-2-7-8-9-8-1 LOPRVBCR

[pascal]

Ik heb voor funktie 3-2-7-8-9-8-1 Printen Vrachtbrief Credit-Verkooporder (funktie LOPRVBCR) een gebruikersbutton aangemaakt.
Wanneer je deze aanklikt krijg je echter een melding Operator/operand type mismatch.
Via het menu kom ik er wel gewoon in.

(ik heb een update in Test-omgeving, wordt vanavond overgezet)

[Wouter Rijnbende]

Helaas, niet iedere funktie leent zich ervoor om middels een Userbutton aangeroepen te worden.
Probeer het menu ervoor op te nemen als userbutton.

[Peter Stordiau]

Het klinkt altijd wat zwak van onze kant, maar het is gewoon zo hoor. Ook in dit geval;
De print kan zowel Debet als Credit Orders printen, en wordt daarvoor gevoed met een "parameter". Dus, zo'n parameter wordt meegegeven door de aanroepende funktie (in dit geval het menu waar je zojuist vandaan kwam), en als die aanroepende funktie er niet is, tja ...

Overigens zou dit in veel gevallen kunnen worden opgelost door de waarde van die parameter (die je zoals in dit geval domweg als "C" zou kunnen invoeren) op te slaan bij de betreffende UserButton. Kwestie van een veldje erbij in onderstaand formpje. Verder (denk ik) een dagje zoeken waar dit allemaal zit c.q. waar het moet worden aangepast, en dan kan je "een aantal" funkties meer opstarten. Echter, het zal altijd bij ons vandaan moeten komen wat je dan moet (of mag) invullen, want geautomatiseerd kan dit niet. Dus het is misschien wel een leuk idee, maar toch niet helemaal praktisch.
Overigens zal iedere individuele gebruiker nooit (zoals in dit geval) een UserButton kunnen maken voor zowel de Debet als de Credit versie, omdat de "identifikatie" de funktienaam betreft (LOPRVBCR).

Alles bij elkaar, mocht iemand denken 9 uur te kunnen terugwinnen door het vermijden van een extra toetsaanslag hier of daar, dan kàn het dus wel (binnen de kondities zoals boven gesteld), en zullen wij wanneer nodig de mogelijke parameter waarden wel doorgeven.

[Wouter Rijnbende]

Houdt er wel rekening mee dat je ook daar weer slechts een deel van de situaties zult oplossen...

Zo zal bijv. een Userbutton naar "Raadplegen Verschijningsvormen v/e Artikel" veronderstellen dat we éérst een Artikel geselekteerd hebben.

Nu is dit niet helemaal het voorbeeld van "de parameter", maar je kunt je voorstellen dat er zo ook funkties zijn waar een Relatie-Id wél als parameter wordt doorgegeven... Hoe dan ook, mijn punt is dat we weliswaar iets kunnen maken dat de parameterwaarde bij de Userbutton wordt opgeslagen, maar of je dan wel voor ieder Artikel of Relatie een andere button wilt maken...

Voor meer statistische kombinaties, zoals debet-/credit, of zoals bij keuringen: inkoop-/produktie zal e.e.a. wel werken.

[pascal]

Bedankt voor de uitgebreide toelichting. Voorlopig zal ik het oplossen door een menu ervoor te gebruiken in de button.

Mocht ik in de toekomst button werkend willen hebben meld ik dit wel, kunnen we altijd nog kijken of we hier een x aantal uur voor willen betalen

[Wouter Rijnbende]

Trouwens, even specifiek deze funktie...

Als dit scherm zelf om een Verkoopordernummer vraagt, waarom moet dan een hogerliggende funktie deze funktionaliteit aanroepen met Debet- of Creditorders? Ik bedoel, als de funktionaliteit "Printen Vrachtbrief Verkooporder" heet, en we een Verkoopordernummer invullen, dan kan dát toch ook bepalend zijn of er in het verdere verwerkdeel "Debet" danwel "Credit" wordt afgehandeld??

Het enige wat daarmee gebeurd is als dat ze met "Debet" wordt aangeroepen, je geen Creditorder mag invullen, en andersom.  

[Peter Stordiau]

Ja ehh, dat vraag je maar aan de persoon die het heeft ontwikkeld hoor.
Zie ook de CR aan het eind.