Heart-Profit ERP
November 27, 2024, 07:30:33 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Aanpassing decimalen op recepten,  (Read 1521 times)
0 Members and 0 Guests are viewing this topic.
wiliam01
Poster
*
Offline Offline

Posts: 26


View Profile
« on: January 17, 2012, 09:25:47 am »

Onze recepten worden nu weergegeven met 3 decimalen.
Dat betekend in ons geval ook dat er 3 decimalen op een uitgeprint recept worden weergegeven.
Om de leesbaarheid te verhogen en om ook de foutkans op de afwegingen te verkleinen, zijn wij op zoek naar een mogelijkheid om de weergave terug te brengen naar 2 decimalen.
Indien hiervoor de recepten ook aangepast dienen te worden naar 2 decimalen, dan is dat ook geen probleem maar willen dan wel weten hoe.
Logged

Heart-Profit company ID : CH
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5367


View Profile WWW
« Reply #1 on: January 18, 2012, 10:02:20 am »

zijn wij op zoek naar een mogelijkheid om de weergave terug te brengen naar 2 decimalen.

Je zou hiermee kunnen bedoelen dat je wilt dat het systeem niet toestaat dat je nog data kunt invoeren in meer dan 3 decimalen. Maar ja... die 3 decimalen kom je overal in het pakket tegen, niet alleen bij je Recepten en Produktieorders, maar ook op Voorraad, in Verkooporders, Inkooporders etc. gewoon, in het hele pakket, en dat kunnen we niet zomaar even aanpassen.  Los van de problemen die je er w.s. mee uitlokt zou de aanpassing veel te duur worden.  Sad

Bij het inrichten van je Recepten ben je natuurlijk zelf bij. In je Receptregel geef je immers zelf aan hoeveel eenheid grondstof je nodig hebt, en als je 5,570 Kg opneemt op de 100 Kg, dan heb je natuurlijk "mooiere cijfers" dan als je 5,565 Kg opneemt. Maar ja... toch zal dat niet in alle gevallen je probleem oplossen.

Ga bijv. een Produktieorder toevoegen voor 50 Kg, en je hebt de helft van de opgenomen grondstof nodig: 2,785 Kg; welk effekt nog groter wordt als je weet dat je bij het Toevoegen van een Produktieorder ook in staat bent om een te produceren hoeveelheid in decimalen op te nemen.

Zo ben je ook in staat om bij een Liter Recept een grondstof in KG op te nemen, danwel bij een Recept in KG een produkt in Liters op te nemen. Er wordt dan omgerekend via de Soortelijke Massa, welke in 6 decimalen is. Kortom, ook dan heb je je 3 decimalen in je P.O. zo weer terug.

Een Produktieorderlayout betreft normaliter "maatwerk" voor een klant, en kunnen we dan helemaal specifiek conform jullie wensen aanpassen. Dus, in theorie zouden we kunnen stellen dat we op jullie P.O. layout alles gaan afronden op 2 decimalen. Maar ja... of dat gaat werken kun je je ook afvragen, want "op je P.O. staat dan iets anders dan wat er in het systeem staat". Ofwel, in theorie kun je de situatie krijgen dat je van een produkt 5,573 Kg moet afboeken, je P.O. dit afrond naar 5,570, iemand gebaseerd daarop een vervolgorder toevoegt voor 5,570 Kg, en vervolgens de Produktieorder niet automatisch gereedgemeld kan worden "omdat je 0,003 Kg teweinig op voorraad hebt liggen", en niemand er wat van snapt, omdat iedereen precies doet "wat er op de bon staat".

Pas je echter geen omrekeningen via de Soortelijke Massa toe, en zijn je Recepten gebaseerd op het produceren van volle kuipen, en produceer je altijd volle kuipen, tsja... dan zal e.e.a. misschien wel kunnen werken (maar moet je hooguit weer gaan oppassen dat je produkt danwel je MSDS daardoor niet ingrijpend wijzigt).
Logged

Heart-Profit company ID : HA
wiliam01
Poster
*
Offline Offline

Posts: 26


View Profile
« Reply #2 on: January 18, 2012, 11:16:02 am »

Dank je Wouter,

We nemen een en ander hier verder in overweging en zullen contact met jullie opnemen als er aanvullende acties nodig zijn.

M.vr.gr.,

wim burgers
Logged

Heart-Profit company ID : CH
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.037 seconds with 19 queries.