Heart-Profit ERP

Bedrijfsbureau komt met het volgende probleem:

Een D0S000070  receptkaart maken uit een verkooporder:
3.2.1.1
ga op de juiste verkooporder staan: 20110502026
Shift F7
7
verander de datum in 11.05.11

hoofdmenu
Shift F4
ga op de regel van 14S0062 staan (er is niet genoeg van deze grondstof op voorraad)
Shift F6
aantal eenheden: vul 60 in

Dan krijg je de melding:
Sorry, gevraagde functie geblokkeerd
doe dan enter
en ga reorganiseren

doe daarna
5.2.1.1
Shift F4
en dan zie je dat de kg wel zijn veranderd bij de 14S0062 in 60 kg!!!!!!!!!!!!!!????
doe 3x Esc om de receptkaart uit te printen
8 print overzichten
1
F1 
dan begint er boven in het scherm een regel te knipperen en moet je via taakbeheer het proces beëindigen

Daarna Profit opnieuw opstarten en reorganiseren

Dan maar proberen om in ieder geval de verpakking aan te passen (omdat Profit het na een Shift F6 of herberekenen het nodig vind
om de inhoud van de blikken te veranderen!!!)

Dan krijg je de melding:
Alg. fout index TAGB ? 9999 =>
index does not match the table.
Delete the index file and re-create the index

druk op door

Dan krijg je weer de melding:
Na [enter] wordt teruggekeerd naar het hoofdmenu en zal reorganiseren TBC worden opgestart

Nog maar een keer de verpakking proberen aan te passen:
shift F5
verpakking weggooien, ga op regel staan
F6
F1
enter

dan krijg je de melding:
Functie geblokkeerd [enter] = hoofdmenu
[F9] reset [esc] systeem stop [F7] toon data

Dan moet je weer reorganiseren en kun je beter proberen een kaart te maken zonder verkooporder dat lukt dan weer wel!

Nou... dat zijn wel een heleboel meldingen / vragen in 1 topic, waarbij iemand dit alles vast niet helemaal zo gaat volgen... Hoofdmenu, Shift-F4 ??

Laten we ons eens concentreren op de melding in je topic: een numeric overflow.

Aan de hand van je opmerking niet voldoende grondstof, denk ik dat je een Produktieorder aan het herberekenen bent op basis van de beschikbare hoeveelheid grondstoffen, en loopt dat fout op een numeric overflow. Alles wat er daarna fout gaat kan een gevolg zijn van een half af situatie, dus, eerst dát probleem oplossen.

De numeric overflow kan een gevolg zijn van een programmafout, het kan ook worden veroorzaakt door een bepaalde indeling van je Recept waar we niet op anticiperen (waardoor er bijv. ergens een deling door 0 ontstaat).

Hoe dan ook, zie http://ha1.heartprofit.nl/profit/index.php?topic=22882.0, en post even de inhoud van de geblokkeerde funktie (die van de Numeric Overflow), dan kunnen we eens kijken waar dat optreedt. :smile:

Merk overigens op dat het best mogelijk is dat alle ellende wordt veroorzaakt doordat je een P.O. aan het herberekenen bent die uit een V.O. gegenereerd is, en e.e.a. niet voor die situatie gemaakt is. In dat geval kan het ontbreken van een foutmelding "herberekenen niet toegestaan, P.O. komt uit Verkooporder" de fout zijn.

Immers, een klant bestelt 100 Kg, wij produceren 1:1 met de Verkooporder (en daarmee de Debiteur) deze 100 Kg, en tijdens het produceren bedenkt iemand dat er een partij grondstoffen ligt die ze willen opmaken. De P.O. wordt herberekend o.b.v. de aanwezige hoeveelheid grondstof, en stel, dat impliceert dat we 500 Kg gaan produceren. Maar... de P.O. zegt van zichzelf dat e.e.a. specifiek voor dié ene Verkooporder wordt geproduceerd, en als je niet oppast, houdt opboeken van de P.O. in dat er 500 Kg op de Raaplijst van die order wordt geplaatst (immers, dat is toch specifiek voor die order geproduceerd).

Je opmerking over het moeten aanpassen van de Inhoud na herberekenen kon nl. wel eens indikatief hiervoor zijn (dat er niet naar de V.O. gekeken wordt).

Vandaag werk ik vanuit huis dus ik kan zo snel even niet een schermafdruk posten. De tekst uit de geblokkeerde functie is ook niet te kopieren dus ik hoop dat jullie hier genoeg aan hebben:
Appkde LO
Kode 39
Omschrijving Numeric overflow. Data was lost.
Regel
Reg-nr. 171
Alias LOVR
Index A1
Warea 70
User AFI
Event
Stack SYRAH SYER ON...enz.


De geblokkeerde functie staat ddiverse keren in het systeem onder user AFI en EHA.

Die Stack, daar gaat het nu precies om... Kun je de eerste 3 funkties even opnoemen die na die ON... komen ?



Is voor ons nog lastiger om te bekijken gezien de verbindingsperikelen bij jullie (en dan werken wij nog niet eens thuis, want dan was het al helemaal niet mogelijk geweest).  :(

Hele rijtje:
LOPOVPVW LOPOVPRA LOPORA LOPBRO LOPB LOWP LO SYSA LOIN PROFIT8

Thanks  :smile:

Bij een VO Regel wordt bijgehouden voor hoeveel Verschijningen er al een Produktieorder is gemaakt. Deze hoeveelheid wordt bij het verwijderen verminderd door het aantal eenheden van de PO outputregel gedeeld door de verwachtte inhoud, en die laatste staat op 0.

Nu even de vraag waarom?

Staat dit op 0 vanaf het moment dat er een P.O. werd gegenereerd vanuit de V.O.?
Staat deze 0 er in sinds je de P.O. een keer eerder herberekend hebt (welke mogelijk niet anticipeert op P.O., vanuit een V.O.)?
Of is er nog iets anders aan de orde? (bijv. definitie van een Bijprodukt in je Recept).

Ook hier weer een kwestie oorzaak en gevolg...

De geblokkeerde funktie die jij post, is het gevolg van een eerdere numeric overflow die ontstaan is bij een eerdere herberekening van de P.O. Daardoor zijn niet alle velden in de database gevuld, en knalt nogmaals herberekenen eruit op een deling op 0.

Als ik nu in jullie systeem kijk, dan is VO regel 20110505026/1 gekoppeld aan PO 201105100026.
Toch is PO 201105100026 niet vanuit een VO gegenereerd, en wellicht schrijf je dat hierboven ook.

Ik zal die PO er nu uitgooien, en proberen na te doen wat jij hier beschreven hebt...

Nah, kan vast ook niet, want de PO is al geprint, je hebt allerlei charges toegekend etc.

Nou, dan maar proberen na te spelen in Test, als dat ook niet lukt, geef ik het even op  :(

Helaas. Niets geen geblokkeerde funktie !

Probeer e.e.a. maar eens na te spelen in test, en beschrijf alle stappen t/m waar het fout gaat.

Mogelijk verzuim je andere dingen te vermelden, en heeft de klant er iets mee te maken, of baseer je de te genereren produktieorder op een eerder geproduceerd recept, en staat er in dát Recept iets verkeerd (waardoor er een deling door 0 optreedt).

Nb: Wat ik wel konstateer is dat de inhoud van de output na hergenereren niet overeenkomt met de inhoud die is opgegeven op de Verkooporderregel. Daar kan ik nog wel even naar kijken...


:17c:

Kan het te maken hebben met het feit dat wij bij verschijningsvormen de inhoud 0.001 gebruiken.
Of zoek ik nu verkeerd??????

Verschijningsvorm 1,1,2,1....

Zomaar een gokje....

Uiteraard kan dat ermee te maken hebben. Als je 1000 Kg zou produceren met inhouden van 0,001, heb je al 1.000.000 Verschijningen te pakken, en zoveel krijg je 1:1 vanuit een VO dacht ik al niet eens geproduceerd. Met welke reden gebruik je die 0,001 ?

Deze vreemde waarde had te maken met dit probleem:
*Wanneer je een “spontane” kaart maakt met bv. B25V 1x25 ltr dan vind Profit dat er 25 kg in een blik moet en moet je de verpakking weggooien en er opnieuw aanhangen. Extra werk, net als met herberekenen of kg aanpassen met Shift F6. Vergeet je het aan te passen dan wordt misschien de verkeerde hoeveelheid getapt. Kan het niet zo worden dat er dan bijvoorbeeld “lege” inhoud aan het blik gehangen wordt? Dan moeten ze in ieder geval terugkomen als er iets niet klopt. Staat er helemaal niets, dan kun je nergens zien dat er een kaart onderweg is, dat is ook niet handig.
Doordat de inhoud op 0,001 staat krijg je inderdaad een belachelijk aftapvoorstel zodat deze niet per ongeluk verkeerd zal worden uitgevoerd...

Ik begrijp je niet.  :(

Zal je wel even bellen, want de scenario's kunnen divers zijn.

Dit puntje is opgelost.

Nb: Aanpassing vereist een Upgrade.

Oké, ik zal een upgrade gaan inplannen.