Heart-Profit ERP

We hebben er een paar
De vervelendste is de eerstgenoemde in het lijstje, welke optreedt bij printen PO

Ik print vanuit LOPORA, taggen en shift F8


Dan klapt heart er keihard uit.

zie winword doc en vp8 error log

Probleem treedt ook op bij printen etiket voorraad item
functie LOPRVBEV !!!!!!

Ik krijg het hier even niet voor elkaar om een Produktieorder toe te voegen  :( om iets te testen...
maar voor zover ik weet is Shift-F8 het uitzetten van de Nakijkvlag... Toch ?  :wink:

Om erachter te komen waar het vandaan komt...

Druk eens gewoon een Produktieorder af. Eentje... Via het menu... Knal je er dan ook uit?

Hmm... bevat jouw afdrukken Produktieorder soms ook het afdrukken van een etiket?

nee, afdrukken PO is niet gelijk aan printen label

en sorry iunderdaad geen shift F8 maar F7

Heb het nu al van een stuk of 7 gebruikers op verschillende machines dezelfde meldingen mbt het printen bij voorraad item labeltjes

en van 2 mbt printen PO

Het is dat die eerste melding van jouw (Word Document) een DO nesting error bevat, hetgeen in de hoek van een programmafout wijst.

Het "zomaar eruitknallen" heeft ook vaak een kapotte index ten grondslag, en daar LODF ook gereorganiseerd moest worden, kan ik me afvragen of beide iets met elkaar te maken hebben. Hebben jullie bijv. ook een stroomstoring gehad? Stel dat het aan een kapotte index ligt, dan zou dat kunnen verklaren waarom 2 totaal losstaande funkties foutlopen; beide gebruiken dezelfde tabel.

De "DO Nesting" error rijmt daar echter nog niet mee.

ik kan vanavond een reorg all draaien

we hebben een maan dgeleden wel een stroomstoring gehad.
Maar toen is de server "gracefully down" gegaan op de UPS

Heb zojuist een Produktieorder bij je geprint (zowel getagd als via het menu) maar dit gaat gewoon goed; het gaat dus niet bij iedere P.O. fout.
Ook een Voorraaditem etiket van een truck wash artikel geprint, ging ook goed.

Kun je het reproduceren? Zo ja, welke order of welk voorraaditem?

deze gaat fout maar het is bij meerdere

Daar hebben we wat aan... er is geen voorraad van dit item.  :gotya:

Een kwartier vóór je post is dit item geleverd.

Ik zie dat als ik een ander item print met etiket layout SAMPL, dat het ook fout gaat...
Ik zal eens kijken...

maakt niet uit, kun je gewoon printen hoor, gewoon door-enteren na de melding

productieorder 30 van vandaag gaat ook iedere keer fout

Krijg nu ook meerdere malen de volgende meldingen

Variabele "HFDCHRGE_S" is not found (LOKR)
Variabele "GNPOEIND_S" is not found (LOAB)

zie geblokkeerde functies

V.w.b. het afdrukken van het etiket van een Voorraaditem, Artikel ART1013470/975AI2 loopt dit fout bij het beschikbaarstellen van de Layoutvariabelen van Technische Documenten. Hierbij wordt het Recept Top-Down uitgewerkt.

In ART1013470 zit ART10111240, en om ART1011240 te maken heb je ART1011240 nodig, die weer ART1011240 nodig heeft etc.
Loop dus.

NB: Maar al eerder zullen je de meldingen om de oren zijn gevlogen, immers je wordt ten strengste afgeraden je recept op deze manier te definieren.

Feit is wel dat het Recept van die ART1011240 niet gewijzigd is... voorheen kon het er schijnbaar wel tegen...

Ik denk dat ik weet wat het probleem veroorzaakt... nu de oplossing nog even...

Die meldingen krijg je totaal ergens anders... Heeft niets met dit onderwerp te maken.

Dit is gewoon fout. Is vermoedelijk veroorzaakt door Releasenote http://ha1.heartprofit.nl/profit/index.php?topic=19826.0
:13c:

Zou moeten worden veroorzaakt door http://ha1.heartprofit.nl/profit/index.php?topic=19758.msg26807#msg26807

Wat in die Releasenote foutging was feitelijk dat "als het Artikelnummer al een keer geraakt was, het niet nogmaals verwerkt werd". Zonder hierbij naar het niveau te kijken.
Maar ja... dat zorgde ervoor dat deze situatie van jou ook vanzelf niet in een loop raakte, immers de grondstof die je opneemt in hetzelfde recept, was al verwerkt, en werd sowieso de 2e keer niet nogmaals verwerkt.

Ofwel, die fout zorgde ervoor dat de échte fout (het écht in een loop hebben zitten van je Recept) niet gekonstateerd werd.

Misschien kan ik dit elimineren door niet verder te kontroleren i.g.v. een regel met 0,000.
:13c:

Klopt maar het topic was ook "geblokkeerde functies na upgrade", oftewel alle ellende die we nu hebben op 1 hoop

Yep. Dat elimineert de handel... maar... helaas in jouw voorbeeld niet...

Je werkt nl. met Recepten die écht in een loop zitten, en waarvan het systeem je meldt dat je een dergelijk Recept niet op deze wijze behoort toe te voegen.

Dus, wat opgelost is, is dat je een Recept ART1011240 hebt waar 0,000 Kg ART1011240 in zit.
Dit is een geaccepteerde truc om tijdens het produceren van ART1011240 nog een restantje (wat op voorraad ligt) erbij in de kuip te gooien, en daarna weer af te vullen. Hoe groot dat restantje is kun je toch op voorhand niet vastleggen, vandaar de 0,000 Kg.  Deze situatie wordt nu ook bij het Genereren van een TD document (hetgeen bij het printen van jouw etiket "onder water" gebeurd) toegestaan.

Wat niet is toegestaan, is de wijze waarop je Recept ART0008290 gedefinieerd hebt. Hierin is de hoeveelheid nl. geen 0,000 Kg.
Wat je hier feitelijk zegt is "Om een blik van 25 Kg te produceren, moet er 25 Kg ongeacht de Verschijningsvorm in".
Ja, maar je hebt maar 1 Recept.
Dus. Ik heb 4 blikken nodig, en heb daarvoor 100 kg ongeacht verschijning nodig, welke alleen geproduceerd kunnen worden als 4x25 Kg.
Dus... wéér een behoefte aan 4 blikken, waarvoor je 100 kg ongeacht verschijning nodig hebt, en dus wéér 4x25 produceren. etc. etc. etc.
Dit mág niet zo, en staat het systeem ook niet toe (d.w.z. het kán wel, met omwegen, en t.b.v. speciale doeleinden).

Merk op dat het in praktijk best kan voorkomen dat je een dergelijk Recept nodig hebt, maar m.i. betreft het dan puur een 'Opwerk-Recept'.
Ofwel, je hebt een produkt A op voorraad, welke "te dik" aan het worden is, je gooit er wat water bij, roert een beetje, en krijgt opnieuw A.
Recept A mag echter nooit getriggerd worden in een automatisch proces zoals 'Kostprijsberekening', 'Behoefterun', 'MSDS (Technisch Document)' etc., omdat deze daardoor in een loop raken, immers om A te maken heb je A nodig, waarvoor je eerst A moet maken, maar waarvoor je weer A nodig hebt etc.

Wat we kunnen doen (maatwerk) is dat we een indikator 'Opwerk Recept J/N' opnemen bij een Recept, en ervoor zorgen dat je via dat Recept wél handmatig een Produktieorder mag toevoegen, maar dat dit Recept wordt uitgesloten van alle andere soorten selekties-/berekeningen die in een loop kunnen raken.

Het printen van een etiket (of eigenlijk, de plek waar nu onder water het TD document wordt uitgewerkt) zal vanaf heden konstateren dat het Recept in een loop zit, een melding geven, en terugkeren naar het hoofdmenu. Middels het maatwerk zou dit Recept in het TD niet geselekteerd worden (doch misschien leiden tot een melding 'Recept niet gevonden', immers je hebt ook geen ander Recept waarmee ART0008290 geproduceerd kan worden).

NB: Merk tevens op dat je bij een Verschijningsvorm kunt instellen of deze kostprijsbepalend is, en feitelijk dingen kunt afdwingen dat als er twee Recepten zijn voor 1 produkt, een van de twee voorrang krijgt boven de ander. Bijv. als je een KUIP Recept en een PASTA Recept hebt, krijgt het KUIP Recept voorrang. Op die manier kun je het misschien ook zonder maatwerk voor elkaar krijgen dat het systeem niet het Opwerk-Recept selekteert, puur omdat een ander Recept een hogere prioriteit krijgt.

Hallo mdekraa,

Variabele HFDCHRGE_S not found is opgelost (http://ha1.heartprofit.nl/profit/index.php?topic=19832.0;topicseen) en staat inmiddels op je systeem.

Ik kom nu net uit vergadering:

Het lijkt nu weer te werken

Maar toch deze opmerking:
Met betrekking tot het probleem van ART0008290 is het wat anders.
Dit is een grondstof die we kopen in diverse verpakkingen.
Wij verkopen deze dan weer in in o.a. een 431AI verpakking.
Het probleem is dat ik het niet anders in het systeem kan krijgen, immers de input is niet vastgesteld (kan drums of IBC's zijn, met of zonder statiegeld)
Dus geef maar aan hoe je dat anders in het systeem wilt krijgen
Feit blijft dat het tot nu toe altijd zonder problemen gewerkt heeft.

Wij hebben erg veel van deze "repack - recepten"




PS morgen en overmorgen ben ik "buiten" dus kan ik alleen 's-avonds reageren

Profit-Omvorm is bedoeld om mee te kunnen omvormen. Om te kunnen omvormen heb je geen Recept nodig.

Natuurlijk kun je dat ook via een Recept oplossen (die je dan theoretisch voor al je duizenden artikelen nodig hebt die je wilt kunnen omvormen), maar neemt niet weg dat als je dat op deze manier doet, je Recepten in een loop zitten, en niets hiertegen kan.

Een Koop-artikel met een Recept maakt de boel op zich wel iets anders; dat verklaart denk ik waarom je niet eerder behoefte technische problemen hebt gehad, immers, aldaar wordt de behoefte omgezet naar een koop-behoefte en niet naar een produktie-behoefte. In theorie biedt dat ook mogelijkheden om de MSDS berekening niet in een loop te laten geraken, door bijv. bij ieder niveau dat we dieper gaan, ons af te vragen of het Artikel aangeeft dat het een koop-artikel betreft, en zo ja, nooit dieper te gaan, ook al is er een Recept. Maar ja... Ervanuitgaande dat je ook situaties hebt dat het Artikel als "Koop" gedefinieerd is en een specifieke Verschijning als "Produktie" kan ik niet 1,2,3 beoordelen of dit voor iedereen opgaat.
Misschien dat Menno een oordeel kan vellen vanuit het oogpunt MSDS.

Dat zal Menno wel kunnen, maar het is denk ik goed om eerst mijn reaktie te vernemen;

De MSDS module is oorsponklijk nooit gemaakt om theoretische veiligheidsbladen op te hoesten. Wel praktische. Het verschil ? de laatste werkt op basis van de Eigenschappen op Charges (hoe die ook onstaan zijn, bijvoorbeeld via een receptuur (Produktie !) + Bijstellingen tijdens produktie, of via keuringen of wat dan ook na Goederen Ontvangst (Inkoop !).

Nadat de module op deze wijze is opgezet, vonden mensen het "makkelijker" om e.e.a. op basis van Recepturen te laten werken. Dit werkt wat mij betreft *niet*, maar toch wel bij de gratie van gebruikers (ehh ... klanten van gebruikers ?) die er geen problemen mee hebben.

Wat Wouter noemt is een typisch gevalletje "zie je wel, werkt niet".
N.b.: Of dit nu werkelijk belangrijk is ("werkt niet") kan ik niet beoordelen, al was het maar omdat het misschien wel alleen Wouter's probleem is in zijn perceptie van alles. En, uiteindelijk heeft het ook nergens mee te maken (denk ik), want Marco werkt in de basis al verkeerd.

Aangaande dit laatste : ik kan het niet echt goed beoordelen, maar waar het Omvormen betreft behoor je dit met Omvorm Orders te doen, en niet met Produktieorders. We voelen wel : alles raakt hier aan het rollen omdat er een produkt A in een produkt A wordt gegooid, waarop het hele Produktie deel niet *hoeft* te anticiperen. Immers, Omvormen doet niet anders dan A in A gooien, en is er voor gemaakt (met alle verdere faciliteiten van dien).

Overigens lossen we nu voor jullie tijdelijk (betaald) iets op, omdat je anders slecht verder kan.
Ik neem aan dat dit beter is dan iedereen te laten ploeteren omdat jij (Marco) er zelf toevallig niet bent.

Peter

Aangepast, overgezonden, en getest bij het afdrukken van een etiket van een Voorraaditem.

Je krijgt nu eenmalig de melding die je erop attendeert dát de boel in een loop zit, waarna het systeem wel verder gaat, maar het Recept niet verder uitwerkt.

Zoals gezegd:
Ik ben alleen 's-avonds thuis

vandaag zat ik heel de dag in de UK (werkt trouwens als een speer die tunnel)

Het probleem is dat wij veiligheidsinformatie en instructies op onze werkbonnen willen hebben en ook dat de emballage goed geboekt wordt.
Dit was in het verleden niet mogelijk met omvormopdrachten en dat is de reden dat wij ooit in overleg met de toenmalige Heart adviseurs (ook betaald trouwens) geopteerd hebben om dit middels productieorders in te vullen.

Als jullie nu zeggen dat al die functionaliteiten er wel zijn bij het omvormen laat ik mij graag door jullie voorlichten.

mvg

Marco


PS bedank voor het inbouwen van die "uitweg" uit de gecreeerde loop.
 ;D

Sinds december 2000 bestaat er de mogelijkheid om via een Produktieorder om te vormen. Met Profit-Omvorm doen we eigenlijk niet anders meer dan dat. In plaats van dat je Omvorm Opdracht bij 5-3-1-1 terecht komt, wordt ze met een indikator 'is omvorm opdracht' opgenomen tussen je Produktieorders, en volgens dezelfde layout als je Produktieorder afgedrukt. Produktieorders bevatten de mogelijkheid om Bewerkingen op te nemen, om Emballage af te boeken, om Gedeeltelijk Gereed te melden, om tevoorschijn te komen in de PO planning etc.

Er is inmiddels een 2e methode Omvormen via Produktieorder, waarbij geen voorraad meer wordt gereserveerd (net als bij een normale PO). Behoeftetechnisch kun je de Omvorm Opdracht dan al uitschrijven nog voordat je goederen daadwerkelijk ontvangen zijn. Tevens zal die methode altijd een nieuw Chargenummer toekennen, waardoor je bijv. ook in staat bent om meerdere charges om te vormen naar 1 nieuwe, of van meerdere kleinere verschijningen naar 1 grotere.

Jij blij dat je niet op de veerboot bij Vlissingen zat   :scare:
http://www.dumpert.nl/mediabase/45471/b597ad5f/beetje_misselijk_.html

Merkwaardige uitleg Wouter ... Alsof Marco vraagt naar het verschil tussen "normaal" Omvormen en Omvormen via een Produktieorder ...

Marco schrijft nl. dat hij destijds niet met Profit-Omvorm uit de voeten kon, omdat een Omvorm Opdracht niet met Emballage overweg kon.
Sindsdien hebben we "Omvormen via een Produktieorder" waarmee dat wél kan (en nog veel meer).
Ik denk dus wel dat Marco daar wél naar op zoek is.

:oops:

Kun je me tonen hoe en waar dit in te richten is, en wordt dit dan ook meegenomen in de behoefterun (6.2)?
Ik wil dan met dezelfde opties werken als in een PO, zonder de reserveringen, want ook dat was juist 1 van de redenen dat het in het verleden niet goed ging. Dan blokkeerde heel mijn voorraadtank op een omvormorder voor volgende week.

Niet op jouw systeem i.i.g., want je hebt die module niet.

Maar, naast het setten van een aantal bedrijfsparameters, kun je een Omvorm Opdracht (via methode #2) maken vanuit Raadplegen Produktieorders (^F11), vanuit het Voorraaditemmenu (optie G) en vanuit een speciaal VTV scherm voor Artikel-/Verschijningen. Omdat er bij methode #2 niets gereserveerd wordt, mag je al een Omvorm Opdracht maken voordat je voorraad hebt.

Merk op dat je bij methode #2 niet het Chargenummer behoudt, doch dat er een nieuwe Charge wordt toegekend aan de output van de Omvorm Opdracht (maar ja, niets anders dan je nu al hebt als je hier een Produktieorder van maakt). Toekenning van het nieuwe Chargenummer stelt je wel weer in staat om meerdere partijen in 1 Omvorm Opdracht om te vormen naar een nieuwe partij.

Het methode #2 scherm is ontwikkeld vanuit de hoek "ompakken". Van de ene Verschijning naar de andere Verschijning. Je geeft bijv. aan dat je een partij dozen van 5 Kg wilt omvormen naar 40 dozen van 10 Kg. Het systeem vertelt je dan dat je hier 80 dozen voor nodig hebt (welke hoeveelheid je mag overschrijven, opdat je tijdens het ompakken anticipeert op verlies). Belangrijk is dat de input wordt afgerond op hele verschijningen, en bij bulk kon dat wel eens verkeerd uitpakken (omdat dan alsnog je hele partij verwerkt afgeboekt wordt). Houdt er rekening mee dat als je met methode #2 aan de gang wilt, je naast de module Profit-Omvorm ook nog een paar uurtjes maatwerk kwijt kunt zijn alvorens je kunt doen wat jij wilt.

Wouter
je hebt nu in de print PO functie een escape ingebouwd, wanneer een lus meer dan x keer wordt doorlopen.

Ik heb nog even zitten redeneren en zitten kijken hoe dit bij AD gebruikt wordt.
in 99% van de gevallen is er 1 van de 2 onderstaande modi van toepassing:

-1-
Het recept bevat een 0 kg regel ongeacht verschijningsvorm tbv opwerk restanten
Deze zou in het kader van de overerfbaarheid eigenlijk geskipped moeten worden, immers een 0-hoeveelheid mag geen eigenschappen geven aan het eindproduct. (als ik er geen rood in stop kan het i.p. ook niet rood worden)

-2-
Het recept bevat een koopartikel waarvoor een "ompakrecept" bestaat.
Hier zou de lus eigenlijk ook moeten stoppen, immers als de artikeleigenschap = "koop" ben ik al op het basisniveau en hoef ik niet meer naar recepturen te kijken, dan hoef ik alleen nog te kijken naar een eventuele stukslijst als dat nodig is vanuit de gevaarstoffen-artikel.

Volgens mij als je die 2 zaken realiseerd zal de "noodescape" alleen nog geraakt worden als ik een PO handmatig knutsel ivm opwerkmaterialen en hierin meerdere eindproducten plak, die een lus genereren. (Ik neem 100 kg oude rode verf en 900 kg grondstoffen om 1000 kg goede nieuwe rode verf te krijgen)

Kun je hier eens jouw gedachten laten gaan?

#1 is een formeel onderkende situatie, en is sowieso al afgedekt.

Je loop ontstaat bij #2.

En dit heeft niets specifiek met je PO print te maken, maar zit overal in. Kostprijsberekening, MSDS, jouw PO print etc.

Natuurlijk kunnen we best iets maken dat we op alle plekken gaan inbouwen "als het een koop-artikel betreft, dan niet naar de Recepten kijken", maar je zult niet alle situaties kunnen afvangen. Denk vooral ook aan situaties waarbij het Artikel misschien wel Koop is, maar je het in een andere Verschijning zelf produceert.

Als je naar een oplossing zonder Profit-Omvorm wilt, dan verval je op de eerder aangeboden oplossing waarbij we per Recept met een indikator gaan aangeven dat het om een zgn. Opwerk-Recept (of i.d.) gaat. Dié Recepten (ongeacht of het een Koop-/Produktie Artikel betreft) slaan we dan over.