2-2-2-1-7 SHIFT-F4 SHIFT-F4 F1 geblokkeerde funktie

[pascal]

Gebruiker MH doet vanuit Testomgeving (staat een update in) 2-2-2-1-7 SHIFT-F4 SHIFT-F4, F1 Verkooporder genereren uit kontrakt
hij krijgt de melding 'LOAA reorganiseren'. Heb ik gedaan, vervolgens nogmaals geprobeerd, opnieuw dezelfde foutmelding
Zie onderstaande schermafdrukken

[Richard Masseling]

Pascal,

klopt je pad aanduiding wel??

[pascal]

Volgens mij wel? Misschien wat kort door de bocht?
menu 2-2-2-1-7, kies debiteur (TEMOLD), F1, kies afleveradres met openstaand kontrakt, SHIFT-F4, kies een artikel wat nog geleverd moet worden, SHIFT-F4, geef bestelling op en vul evt datum verzending in, F1
Nu moet er een verkooporder gegenereerd worden, hier loopt het vast.

correspondeert het niet met de gepostte geblokkeerde funktie?

[Richard Masseling]

Hallo Pascal,

e.e.a. heb ik gekontroleerd zoals de Stack het aangaf en het gaat niet fout. Ook samen met je het e.e.a. nagedaan en ook dan gaat het niet fout.

Mijn vraag is of je de gebruiker het nogmaals wilt laten doen en dan precies opletten wat hij doet.

ik wacht even af.

[pascal]

Gebruiker NL krijgt in dezelfde funktie ook een geblokkeerde funktie, maar niet in dit Testomgeving maar in Produktie.

Ze gebruikt geen gebruikersbutton maar gaat via menu 2-2-2-1-7 naar de funktie.
Vervolgens via F5 debiteur opzoeken (DYKGEN), F1, SHIFT-F4, SHIFT-F4, F1 waarop de Verkooporder wordt gegenereerd. Ze krijgt nu onderstaande geblokkeerde funktie. Wanneer ze herstart is de verkooporder wel gegenereerd.

[Richard Masseling]

Hallo Pascal,

Zoals ik je gisteren vroeg of het in Test/Produktie zat en je zei dat het in Test was, ging ik ervan uit dat je met de nieuwste Programmatuur werkte. Nu je aangeeft dat je in Produktie deze foutmelding krijgt, ga ik ervan uit dat je programmatuur aldaar ouder is dan in Test. Immers in Test heb je al een nieuwe Upgrade door gevoerd. Ik weet dat er in die hoek e.e.a. is aangepast, ik zal kijken of ik de Funktie(s) los erneer zetten kan, anders moet je de upgrade naar Produktie overzetten.

[pascal]

Ok, wanneer het met de upgrade mogelijk opgelost is, ga ik die wel eerst overzetten. Mocht het dan nog fout gaan post ik het hier wel even.

[pascal]

Nu je aangeeft dat je in Produktie deze foutmelding krijgt, ga ik ervan uit dat je programmatuur aldaar ouder is dan in Test....
... anders moet je de upgrade naar Produktie overzetten.

Tijdens het testen van de upgrade loopt user MH ook steeds vast, via de hierboven omschreven procedure. Ik ben nu ingelogd via RDP onder user Heart, in Profit ingelogd als MH. Hier gaat het ook fout, de foutmelding staat op het scherm.
Kunnen jullie het scherm overnemen om te kijken?

[Richard Masseling]

Hallo Pascal,

ik heb het scherm overgenomen, maar zoals telefonisch besproken, bij de eerste de beste toets aanslag sloot Profit kompleet af en heb dus verder niets kunnen zien. Opnieuw opstarten en reorganiseren van TBC, inloggen als WR daarna uitvoeren van de gegevens leverder geen geblokkeerde Funktie op. Inloggen als gebruiker MH en hetzelfde nogmaals leverde eveneens geen geblokkeerde Funktie op. 

Dit wil niet zeggen dat er niets aan de hand is, want dat geloof ik wel, alleen wat? Met je afgesproken dat de gebruiker gewoon weer verder gaat en dat zo gauw als het weer fout is je me een mailtje stuurt zodat ik weer direkt kan kijken bij je (het scherm kan overnemen).

[Peter Stordiau]

Volgens mij wel? Misschien wat kort door de bocht?
menu 2-2-2-1-7, kies debiteur (TEMOLD), F1, kies afleveradres met openstaand kontrakt, SHIFT-F4, kies een artikel wat nog geleverd moet worden, SHIFT-F4, geef bestelling op en vul evt datum verzending in, F1
Nu moet er een verkooporder gegenereerd worden, hier loopt het vast.

correspondeert het niet met de gepostte geblokkeerde funktie?

Nee !!
De geblokkeerde funktie toont het gebruik van User Buttons ... Jouw becshrijving niet.
Geen idee of dat uitmaakt.

[Richard Masseling]

Pascal,

ik heb niets meer van je vernomen, betekend dit dat het gewoon niet meer opgetreden is, of betekend dit dat er niet mee verder is gegaan?

[pascal]

Ik heb het gisteren 3x achter elkaar getest: dus zonder voorafgaande acties inloggen als MH in Test-omgeving en zonder userbutton maar via volgende werkwijze:

menu 2-2-2-1-7, TEMOLD invullen, F1, SHIFT-F4, SHIFT-F4, invullen bestelling 1 stuks, Toevoegen op bestaande order uitvinken, F1 en vervolgens krijg je onderstaande foutmelding.
Vervolgens kom je weer in het hoofdmenu. Ik sluit af, start Profit opnieuw en doe reorganiseren TBC. Opnieuw de procedure en weer loop ik vast. Dit ook voor de zekerheid een 3e keer geprobeerd, zelfde resultaat.

Vanmorgen Nog 2x getest, opnieuw krijg ik de foutmelding zoals in onderstaand schermafdruk.

De reden dat ik dit gisteren niet gemeld heb, is dat het al later in de middag was en ik zeker wilde zijn en dus vanmorgen nogmaals (met een 'fris' systeem) opnieuw wilde testen. Want het is al 2x gebeurd dat jullie tevergeefs hebben ingelogd (geen geblokkeerde funktie).

Ik heb nu net nog 1x gereorganiseerd TBC, Profit afgesloten en opgestart in Test met usernaam MH.
Wanneer je nogmaals in wilt loggen moet de foutmelding wel verschijnen. Anders word ik gek...

[Peter Stordiau]

Voor Wouter :

Kijk eens in CLRAFRM.Resize of daar iets kan gebeuren met ofwel een SY tabel dan wel iets als LOVORA (LOKORA ?) (grid)tabel, met in gedachten dat die tabel niet wordt geselekteerd (en dus LOAA wordt gebruikt).

Voor Richard : dit zul je bij ons nooit kunnen nadoen.

Voor Richard : Wat Wouter vindt is wellicht minder van belang (maar toch goed om op te lossen), omdat er hier iets gebeurt met een RA funktie, terwijl deze niet aktief is (nog niet ? niet meer ?).
Als ik de stack zo bekijk, lijkt het erop dat het LOVOWY form meer expliciet moet worden verwijderd (dus, terugkeer is onjuist).


Zo. Ik weet niet of het wel de bedoeling is om alhier nog meer technisch in te gaan op zaken. Het valt me in elk geval wel op dat het onhandig (voor ons) zou zijn om het elders te doen.

[Wouter Rijnbende]

Kijk eens in CLRAFRM.Resize of daar iets kan gebeuren met ofwel een SY tabel dan wel iets als LOVORA (LOKORA ?) (grid)tabel, met in gedachten dat die tabel niet wordt geselekteerd (en dus LOAA wordt gebruikt).

Wat ik i.i.g. konstateer:

Na invulling van het scherm waarin om een Debiteur wordt gevraagd, wordt een overzicht met Afleveradressen getoond (LORDABRA). Dit betreft RDPGALIS = LOAA.
Vanuit deze Raadpleegfunktie vragen we met Shift-F4 een overzicht van de Kontrakten op, LOZKKRRA (RDPGALIAS = LOPD).

Op de plek waar het fout gaat, wordt het recordnummer (SYGR_REC_P) uit SYGR (LOZKKRRA) geselekteerd in RDPGALIAS (LOAA), dat recordnummer is echter een recordnummer uit LOPD. Kortom, het zal bij ons niet foutgaan omdat wij bijv. niet meer Kontrakten hebben dan we Afleveradressen hebben of i.d.

Nu wordt hier op een min of meer niet echt standaard wijze, vanuit een Raadpleegfunktie een Verkooporder gegenereerd. Dit roept eerst een popup aan (LOKKKZ), keert vervolgens terug naar de Raadpleegfunktie, genereert een Verkooporder, en vanwege een bedrijfsparameter (Projectstructuurkode = A of i.d.) wordt dan ook nog eens LOVOWY aangeroepen. Andere funktie aanroepen impliceert vermoedelijk "RDPGALIAS Resetten", en bij terugkeren wordt die misschien wel niet juist teruggeset.

Voordat we hier te diep op in gaan...

Op het scherm staat LOVOWY, ofwel een Wijzig Funktie...
Vanaf die wijzigfunktie wordt de Resize van een van de onderliggende Raadpleegfunkties uitgevoerd.
Ervanuitgaande dat dat niet standaard gebeurd, zou ik denken dat "iets" dat moet triggeren.

Niet geheel ontoevallig heeft gebruiker MH het scherm waarin de Afleveradressen getoond worden te weten LORDABRA gemaximaliseerd, en dat in formposities vastgelegd.

Ervanuitgaande dat:

a. dit alleen bij gebruiker MH optreedt
b. gebruiker MH de enige is die via formposities deze funktie maximaliseerd
c. deze funktie Afleveradressen toont, en het ook op Afleveradressen fout gaat

ga ik er even vanuit dat dat de boosdoener is.

Ofwel, laat gebruiker MH naar Raadplegen Afleveradressen (LORDABRA) gaan, en laat hem die formposities verwijderen (rightclick op formposities vastleggen button).

Nb: Overigens zal er dus vast wel iets zijn wat bij terugkeer onnodig dit form probeert te resizen, maar gezien de complexiteit van alle niet formele aanroepen dit hier plaatsvinden, denk ik dat je het beter kunt zoeken in het elimineren van die formposities. Ben benieuwd of dat helpt. 

[pascal]

Wouter, de gemaximaliseerde formpositie blijkt inderdaad de boosdoener.
Formpositie verwijderd: loopt niet meer vast, er weer opgezet: loopt vast, weer verwijderd: loopt niet meer vast.

Is hiervan nu de consequentie dat we nu de formposities niet meer naar eigen smaak kunnen instellen? Dit zou wel jammer zijn, aangezien het voor ons zeker meerwaarde heeft.
Of gaan jullie dit oplossen, zodat we op termijn die positie weer naar wens kunnen vastleggen?