Heart-Profit ERP

Waarom is LOBUTV2 geen mutatiefunctie? Ik controleerde even de werking van de budgetten icm autorisaties. Als je de scope opvraagt van de functie LOBU, dan zit toevoegen budgetten daar wel tussen.

Wellicht is het nog eens handig dat syscra gewoon toont of Heart iets al dan niet een mutatiefunctie vind. Het wijzigen en verwijderen van budgetten is overigens wel een mutatiefunctie.

Zie helptekst.

Het feit of een funktie al dan niet als mutatiefunktie beschouwd wordt, wordt slechts bepaald o.b.v. de naamgeving van de funktie. LOBUTV2 valt niet onder de mutatiefunkties, omdat ze niet eindigt op TV (toevoegen). Ervanuitgaande dat als het laatste character in een funktienaam een cijfer is, deze eigenlijk niet meetelt, zou LOBUTV2 v.w.b. die autorisatie eigenlijk LOBUTV zijn, en mag ze wel beschouwd worden als mutatiefunktie. Passen we aan. :17c:

Merk overigens op dat de beste manier zou zijn dat het systeem van iedere funktie "weet" dat ze wijzigingen aanbrengt in de database, en haar op basis dáárvan beschouwd als mutatiefunktie. Helaas werkt het zo (nog?) niet.

Tuurlijk wel ... FSRT = 'WY' ...
In Windows dan (en dat is echt voldoende)

funktiesoort (FSRT) is TV2 --> dus v2 en dat is geen mutatiefunctie per definitie. Dus als FSRT zich puur baseert op die laatste 2 karakters dan biedt dat wel enig soelaas, maar dan mis je dus dit soort voorbeelden. Of begrijp ik je opmerking niet goed?

Nee, maar die was ook niet aan jou gericht. :smile:
FSRT is "WY" in dit geval. Ook al eindigt de funktienaam op TV2.

De waarde FSRT weten we pas als een funktie uitgevoerd wordt, en het gaat er hier om dat die informatie "vooraf" bekend is (registratie van Elementaire Funktieaanroepen). Ofwel, we zullen in een tabel moeten gaan bijhouden of een funktie een mutatiefunktie betreft ja of nee.

Hoe we dat "mutatiefunktie" verder moeten bepalen zal (als we besluiten dit zo te doen) uitgewerkt moeten worden.

In veel gevallen zal het op zoek gaan naar commando's die iets wijzigen in de database effektief zijn, maar niet altijd, omdat er ook talloze funkties zijn waarbij het verwerkingsdeel in een separate funktie zit (LOVRTVF1) in plaats van in de schermfunktie (LOVRTV).

Kijken naar FSRT = WY zou een mogelijkheid zijn, maar moeten we ook eerst verder onderzoeken, immers, om te beginnen is ieder printoverzicht van het type FSRT = WY. Een standaard print die alleen maar data weergeeft, is geen wijzigfunktie. Toch zijn er ook printjes die een orderstatus aanpassen, of zoals een rappellist, die alle regels als 'geprint' kenmerken. Daar wijzigt wél wat in de database.

Kortom, hier komt nog wel wat meer bij kijken.

Ho !

Ten eerste heb je in alles best gelijk. Maar vervolgens sla je door.
Gewoon de "TV" enz. bepalen op de manier zoals FSRT wordt bepaald, printjes daargelaten. Zo moeilijk is dat niet zeg.

Dan begrijp ik niet waarop je precies reageert. Dat is nl. juist de aanpassing die ik beschreef.
FSRT wordt óók gebaseerd op de naamgeving, maar houdt er rekening mee dat als een funktie eindigt op een cijfer, naar de voorlaatste 2 posities gekeken moet worden.

Aangepast.

Indien een funktie kwa naamgeving eindigt op een cijfer (zoals LOBUTV2), dan wordt naar de laatste 2 posities vóór dat cijfer gekeken.
Voldoet die aan TV (Toevoegen), WY (Wijzigen), VW (Verwijderen), OP (Opnemen), AF (Afvoeren) dan betreft het een Mutatiefunktie.

Aanpassing zit in de Systeemprogrammatuur; komt vanzelf wel weer eens mee in een volgende versie.