Heart-Profit ERP

Onder menu 1-3-1-1 staan onze recepten.
Wanneer ik een deklaag of onderbeton (met daarin de grondstoffen) opzoek en ik doe SHIFT-F4 dan staat daar in kolom 'Perc.' heel mooi het percentage grondstof per recept.

Zijn deze percentages mbv een query uit HeartProfit te halen? Daar zou ik erg mee geholpen zijn!
Wanneer ik weet welke database en welke velden (rubrieken) ik moet hebben dan kan ik daarmee aan de slag.

Doel van dit alles: ik wil een overzicht maken met daarin het aantal kilogram grondstof per kilogram recept, voor alle deklagen en onderbetons.
Dank bij voorbaat!

EDIT: zie toelichting hieronder.

Toelichting: ik wil graag uit Profit halen hoeveel kg van elke grondstof er in een kg van een recept zitten.

Via 1-3-1-1, SHIFT-F4 zie ik de grondstoffen die er in een recept zitten.
In geval van ZZADL1-GENO1 zit er 0,25 liter van de grondstof A-LENTAN VZ33 in het recept. Hoeveel kg A-LENTAN zit er nu in 1 KG ZZADL1-GENO1 ?

Er moet ook rekening gehouden worden met de soortelijke massa (hoeveel kg is een liter van deze grondstof?). Deze staat bij de artikelgegevens onder tabblad 5, veld 'Soortelijke Massa KG per L' en is in dit geval 1,04

Wanneer deze waarde 'KG grondstof per KG recept' in HeartProfit opgeslagen kan worden en ik kan dit veld weer in een query gebruiken dan ben ik erg gelukkig!

Voor ZZADL1-GENO1 moeten de waardes van alle gronstoffen in totaal op 1 KG uitkomen. Het mooist is wanneer de waarde niet afgerond wordt zodat, wanneer je de gewichten optelt, je altijd op 1 KG totaal uitkomt. Dan kunnen wij er goed mee rekenen.

Hopelijk is mijn verhaal duidelijk. Hoor graag of dit te maken is en wat dit zal kosten.
Heb er veel belang bij, dus hoe eerder ik bericht heb hoe gelukkiger ik ben :)

Met één voorbeeld lijkt hij simpel uit te leggen, maar, als we een dergelijke berekening in één Query moeten opnemen, hebben we met wat meer factoren te maken, zoals:

* Een Receptgrootte Faktor (omdat je kunt aangeven dat een Recept waar 100 Kg in gaat maar 98 Kg uit komt)
* De eenheid van het Recept (Liters, KG, ST maar in theorie ook andere vormen, denk aan jullie Stuks 1000)
* Soortelijke massa's
* Hoeveelheid Bijprodukt wat in een Recept ontstaat
* Uitvalpercentages die op regelniveau en op headerniveau kunnen zijn ingesteld

Wil je de Query "goed" hebben, dan zullen al die komponenten er in moeten zitten, maar moet je ook niet gek staan te kijken als we hier straks 2,5 dag mee bezig zijn om die Query uit te werken. Als de Query gemaakt kan worden met bepaalde "uitgangspunten", zoals je zelf eigenlijk al impliceert "alléén voor KG Recepten", dan kan hij al weer eenvoudiger worden.

Resumer, houdt het ergens tussen 1 en 20 uur.

Strikt genomen vraag je ons niet de Query te maken, maar te melden welke velden je daarbij nodig hebt. Komt eigenlijk op hetzelfde neer, en vereist eerst een onderzoek van welke velden in jullie situatie wel of niet geraakt worden. En daarna kunnen wij een hele lijst met velden ophoesten en zal de volgende vraag alsnog zijn "en wanneer gebruik ik dan veld x of y" ?

LET OP! onder de streep staat mijn toelichting en uitleg.

Maar wanneer ik kijk naar het 1e schermafdruk in de 1e post, dan staat daar het percentage grondstof in het recept.
Wanneer je dit percentage deelt door 100 dan heb je feitelijk het 'aantal kg grondstof per kg recept'. Hij houdt bij het percentage nl ook netjes rekening met het soortelijk gewicht (dit heb ik nagerekend).
Als deze waarde 'aantal kg grondstof per kg recept' kan worden opgeslagen als waarde in een veld in de database van de receptregels, en jullie maken deze beschikbaar zodanig dat ik deze kan gebruiken in een excel-query, dan ben ik geholpen.

En dan nog 1 vraag: bij wijziging van recepten, hoe borgen wij dat die waarde actueel blijft/wordt ge-update?


------------------------------------------------------------------


Dit is inderdaad niet de handigste manier van werken. Dan moet ik alsnog met allerlei formules aan de slag om de juiste waardes te krijgen.

Vandaar dat ik in mijn 2e post probeer uit te leggen wat ik daadwerkelijk nodig heb, nl het aantal kg grondstof wat in een kg recept gaat.
Wanneer deze 'waarde' (kg grondstof per kg recept) net zoals de geel gemarkeerde percentages in het schermafdruk in Profit zelf berekend kunnen worden en dat ik dat veld ook nog eens in een eigen excel-query kan gebruiken dan is dat ideaal > optie 1.

Wanneer dit niet kan, omdat er nogal wat rekenwerk nodig is, dan zou een overzicht/export naar excel een optie zijn > optie 2.
Wel is het zo dat optie 1 makkelijker te vernieuwen/gebruiken is; het veld (kg grondstof per kg recept) kan ik dan in eigen queries opnemen en ermee rekenen.
Een export (optie 2) is wat minder flexibel, want altijd een export met kolommen in een vaste vorm. Ik hoop dat deze toelichting duidelijk is?


Wat betreft de benodigde velden (heb ze even genummerd):

1 Waar vind ik deze waarde? Als het veld Receptgrootte in tabblad in van de receptgegevens betreft (veld RECGRTE in tabel LORTWY), dan varieert deze waarde per recept. Maar ik betwijfel of dit het juiste veld is? Dit lijkt me de 'Receptgrootte' en niet de 'Receptgrootte Faktor'? Zie veld '1' in het schermafdruk.
2 Eenheid van het recept: Is dit veld 2 in het schermafdruk? Deze is igv recepten altijd KG.
3 Soortelijk massa van de grondstoffen verschilt inderdaad. Er zijn kleurstoffen in Liters, bij de artikelgegevens staat de juiste soortelijke massa gevuld (artikelgegevens, tabblad 5, veld Soortelijke Massa). Hier moet zeker rekening mee gehouden worden.
4 Bijprodukt hebben we niet.
5 Uitvalpercentages staan bij ons altijd op '0', zowel in de header als de regels. We hebben wel 2e keus, dit hoeft voor deze berekening echter niet meegenomen worden: we willen nl alleen weten hoeveel kg grondstof in 1 kg recept zit bij de recepten, eindprodukten zijn in deze niet relevant.

Nogmaals, we hebben het liefst een veld in Profit waarin deze waarde gevuld wordt (optie 1 hierboven beschreven) en niet een export naar Excel waar de gegevens in komen te staan.

Dank bij voorbaat!

Dat begrijp ik ja, er daarna zitten wij zeker met de gebakken peren.  :(

Een hoeveelheid wordt niet voor niets in Liters opgenomen. Dus, als ergens om welke reden dan ook een Soortelijke Massa wijzigt, kunnen we zeker al je Recepten opnieuw gaan uitrekenen om jouw redundante veldje in de database op te nemen. Nope. Gaan we niet doen.



Je vraagt niet om een Query, maar, dat zijn dus juist de dingen waar die Query rekening mee moet houden. Als jij je Recept wijzigt, veranderen ook de percentages. Jouw Query zal daar tegen moeten kunnen.

Tsja... en met het resterende verhaal begrijp je misschien ook de grote marge tussen 1 en 20 uur  :wink:

Een export naar Excel zal je denk ik ook niet gaan helpen. Ik zie daar voor je dat jij e.o.a. rapport wilt maken (en dan ga ik er maar even vanuit dat dat in Excel is), je op een 2e Tabblad een "export" inleest die alle percentages van al je recepten bevat, je dan via lookup's in dat 2e tabblad gaat opzoeken wat het percentage is, om daar vervolgens mee te rapporteren.

Vervolgens :
- voegt iemand een één van je Recepten een regel toe (of verwijdert of wijzigt er een)
- wijzigt de soortelijke massa van een produkt (desnoods omdat je het met hetzelfde artikel elders gaat inkopen)

en je hele 2e tabblad bevat oude data waardoor al je berekeningen de mist in lopen. Het bijhouden wanneer jij die export opnieuw moet doen en jouw 2e tabblad moet aktualiseren ga je zelf niet bijhouden.

Een heel ander verhaal is waar je concreet die Query op los wilt laten. Op 1 specifiek Recept? of op allemaal?
En, houdt er rekening mee dat als je bijv. Advantage Database Server als onderliggende database hebt, alles erop gemaakt is om met Query's op te vragen, gebruik makend van de indexen die op de tabellen gedefinieerd zijn die een optimale performance moeten garanderen. Als jij andere toepassingen gebruikt (zoals bijvoorbeeld Excel), dan stellen wij al snel dat je die niet rechtstreeks op de database moet loslaten, maar op een kopie van je database, omdat al die externe tools de neiging hebben de database gelockt te houden en voor ellende richting Profit te zorgen. Maar, stel dat je dat al via een kopie van de database doet, dan is het eerst volgende dat je bijv. in Excel weliswaar een SQL Query kunt uitvoeren, maar, een DBF weet niet van zich zefl welke index er bij hoort, en in een SQL opdracht kun je dat niet aangeven. Resumer, het kon wel eens niet vooruit te branden zijn, wat het ook is wat je wil.

Maar goed, los daarvan, het enige wat dus echt werkt, is als je een SQL Query hebt, die met allerlei JOIN's andere tabellen zoals je Receptheader en Artikelen er bij sleept, om zodoende iedere keer dat je de Query uitvoert, de data opnieuw berekent...

Nb: Ondertussen zijn er al 0,75 uur van de 1-20 uur voorbij.

Nb2: Ik weet nog steeds niet om welk rapport het gaat, maar, het kan ook nog een optie zijn dat wij het rapport welke je wilt hebben rechtstreeks in Excel maken.

Even van mijn kant : ik weet niet waar de 1-20 op slaat. Ik heb meteen al gezegd "dat kan wel 20 uur worden" en dat is bij deze dus 20,75 uur, maar erger : je draait jezelf (met z'n tweeën) de grond in. Uiteraard is dit Wouter z'n schuld die er probeert 1 uur van te maken.

Wat er moet gebeuren is duidelijk (een veld waar het resultaat in komt te staan) en daar zal alles bii moeten worden meegenomen. Ik houd het dus op 20 uur, plus de verdere discussie. Als het minder wordt is het mooi meegenomen. Als het meer wordt, is het ook mooi meegenomen (voor ons dan, want wat we hebben besteed brengen we in rekening).


Dat bepaal ik wel. En jij gaat het sowieso niet doen, want na 22 uur ben je nog steeds bezig** er 1 uur van te maken. :smile:

**): Voortaan gewoon doorgeven wat ik zeg is het beste idee. :wink:

PS:

Pacsal, we maken er een gelegenheid van zoals die is bedoeld : kijken hoe je waar andere middelen kan inzetten om de stijgende grondstofprijzen aan te kunnen.
Of heb ik dat laatste mis ?

Dit punt staat los van het hele toeslagen-verhaal.
Aanleiding voor dit verzoek is het berekenen van de MKI-waarde (Milieu Kosten Indicator, berekening van alle milieueffecten op een artikel) van onze artikelen.
Hiervoor moet ik precies weten hoeveel kg van een grondstof er in een kg recept zit.

Het gaat echt alleen om de recepten in KG (dat zijn de deklagen en onderbetons).
1 niveau hoger heb je de artikelen, die weer een recept met een deklaag en/of onderbeton hebben. Maar hier hoeft niks mee te gebeuren, die kan ik uit Profit halen (artikel x heeft y kg deklaag en z kg onderbeton, dit gaat goed).

Queries in Excel leveren trouwens geen probleem op qua locken van databases.
Een veld wat er een beetje op lijkt is de voorgekalkuleerde kostprijs van een artikel. Dit is ook een waarde die ik middels een query periodiek uit HeartProfit haal, zodat men kan controleren of deze nog ok is.
Voordat ik de query draai kan ik funktie 1-5-1 'Herberekenen Voorgekalkuleerde Kostprijzen (Massaal)' uitvoeren zodat evt wijzigingen in artikel en recept worden doorgerekend.
Ik kan me voorstellen dat zoiets ook voor de 'kg grondstof per kg recept' gaat gelden - een massale herberekening van de waardes voordat ik de query in Excel uitvoer.

Ja, goed. En nu ?

Goede vraag. Ik zie veel tekst, veel bomen, weinig zicht op het bos?

Ik moest even denken aan iets wat je me eens hebt geadviseerd - ga niet de oplossing bedenken voor een probleem wat je hebt, maar geef aan wat je probleem is, wij zijn er om te bedenken hoe het opgelost kan worden in HeartProfit.

Ok, komt-ie, mijn probleem:
Ik wil graag het aantal KG grondstof weten per KG recept.
Dit alleen voor de recepten Deklaag en Onderbeton, welke altijd de eenheid KG hebben (dit in tegenstelling tot de grondstoffen die bv de eenheid Liter kunnen hebben en ahv de soortelijke massa omgerekend moeten worden naar KG).

Dit wil ik graag in Excel (middels een query die ik maak of een export/printje vanuit Profit?).
Wat ik dus nodig heb zijn de volgende gegevens, in het geel de waarde die ik niet uit Profit krijg. Is hier ook niet kloppend, want opgeteld moeten de gewichten van de geel gemarkeerde grondstoffen samen 1 zijn voor het recept en dat is het niet.

Hopelijk verduidelijkt dit mijn vraag.

Ja maar ...
Dit was wat mij betreft meteen al duidelijk. Maar of je even 20 uur of eventueel nog meer wilt goedkeuren voor het geval dat dat nodig blijkt. :sorry:
En je kent ons - we maken het heus niet onnodig duur.

Belangrijk is dat alle grondstoffen worden meegenomen en wanneer je de gewichten van alle grondstofen van een recept optelt je altijd in totaal op 1 kg uitkomt.
Ik heb het met Dinand overlegd en onder deze voorwaarde is het akkoord.

Alvast bij voorbaat dank!

Nou, we gaan ervoor !

Nog steeds het liefst dus een veldje met de hoeveelheid Kg van de grondstof (als zou het te maken produkt 1Kg zijn) in de Receptregel ?

Enneh, weet je zeker dat je dat op zich in Kg wil opslaan ? dus ook voor de Liter grondstoffen ?
Ik vraag dit, omdat ik nog even niet zeker ben van de complicaties als je het SG van het eindprodukt gaat veranderen.
(en ja, het aktueel houden van het nieuwe veld is echt wel een dingetje - of is dit teveel meisjestaal ?)

Trouwens, als je toch aan het typen bent, vertel nog eens waarom je dit veld wil hebben ? Dàt je het wilt hebben is duidelijk, maar wat ga je er mee doen ?

Zeker.

Ja.

Misschien dat ik, net als bij de voorgekalkuleerde kostprijzen, een funktie als 1-5-1 'Herberekenen Voorgekalkuleerde Kostprijzen (Massaal)' moet uitvoeren zodat eea opnieuw bepaald wordt? Dan weet ik dat het veld de juiste waarde bevat.

Dit heb ik nodig voor het bepalen van de MKI-waarde van onze artikelen: MKI staat voor Milieu Kosten Indicator - wat is de milieu-impact van je artikel op het milieu.
Gebruik je bv veel cement in je artikel dan is de impact groot, vervang je dit (deels) door zand dan is de impact kleiner.
Het gewicht van de deklaag en onderbeton van een artikel kan ik uit Profit halen (en is altijd in KG).
Het onderliggende recept van de deklaag of onderbeton bevat vervolgens de grondstoffen - hiervan moet ik weten hoeveel KG grondstof er in 1 KG van het recept zit. Dit vormt nl de basis voor een tool waarmee we de MKI-waardes van onze artikelen kunnen berekenen. Dit is interessant voor onze klanten - hoe 'groener' ons produkt is hoe liever onze klant het heeft.

OK, dank je.
Een (bijna) losse flodder opmerking, omdat ik er niet al te veel van weet : aan percentage VOS heb je niets ?

Ehm, waar staat dit percentage VOS?
Is dat het percentage dat in de openingspost op het schermafdruk geel gemarkeerd is?

Naa, laat maar; slaat nergens op denk ik. Zie het maar als het percentage niet-vluchtig bestanddeel in een produkt (grondstof). Ook hier worden de dingen aan opgehangen waar jij het over hebt, maar dan (denk ik) veel meer geörienteerd op eigenlijk vluchtige stoffen. Het zal erop lijken, maar niet voldoen.

N.b.: Dit kan ook "bij elkaar worden geteld" maar dat kan de Kostprijs ook wel (zei je zelf meen ik ook). Dus daar gaat het niet eens om. Wel om de "Kg per Kg" en dat is het nieuwe eraan.

Ok - nee, denk idd niet dat we iets aan die VOS hebben helaas.

Pascal, ik heb het gevoel dat er iets niet lekker zit;

Je stelt dat je Uitval overal op 0 staat. Maar dit zou je als eerste niét op 0 mogen hebben, omdat het bij de (uiteindelijke) MKI voor een goed deel juist daar om gaat. Ik snap wel dat de Uitval je niet interesseerDE (moet je zelf weten), maar aannemend dat je wel degelijke Uitval hebt, belazer je de boel als je het weg laat.
N.b.: Voor ons maakt het niet (meer) uit, want wij nemen het toch wel mee, het is immers nog steeds een "pakket" (en het meeste van wat Wouter heeft genoemd is dus wel degelijk aan de orde).

Met de uitval wordt wel degelijk rekening gehouden voor het berekenen van de MKI-waarde, dit gebeurt echter in de MKI-tool die we hebben. De aangevraagde 'kg grondstof per kg recept' dient als input voor deze tool.
Maar je hebt zeker gelijk dat hier rekening mee moet worden gehouden.

Pascal - helaas. Als je dit niet conform het pakket doet, werkt het niet. Alleen als je mij garandeert dat je geen halffabrikaten gebruikt kan je die tool gebruiken zonder uitval in Profit. En heb je wel halffabrikaten :
Dan kan ik je wel vertellen dat je alleen op die halffabrikaten Uitval moet registreren en je het op het eindprodukt mag weglaten omdat je daar die tool voor hebt, maar dat is onzin en werkt fouten in de hand.

Trouwens, als je geen Uitval in profit registreert maar het wel hèbt, dan klopt er nog wel meer niet. Je marge klopt niet, je voorraad klopt niet en je cijfers kloppen niet. Maar dit moet je allemaal zelf weten.

---

Zoals je weet kunnen wij ons alleen baseren op "logika" en baseren we ons nooit op grillen of half-waarheden of andere arbitraire zaken. Dit houdt ook in dat als je nu via een andere weg zaken consistent probeert te krijgen, dat we er niet meer gezamenlijk over kunnen communiceren.
Dat ik het wel heel merkwaardig zou vinden dat je "extern" wel even aangeeft hoe het zit met het produktieverlies (waarbij je kan verzinnen wat je leuk vindt) is nog weer wat anders. Het lijkt ook erg op jullie Energietoeslag die op eigenlijk eenzelfde wijze leidt tot wat ik onkontroleerbare manipulatie noem; Ik ben meteen weg als klant (ja, ik weet het, iedereen in de markt doet het zo, zeg je - en Ja ik weet het, dat is uiteindelijk niet doorgegaan).

---

Trouwens, het is gereed. :-)
Dus als je wilt zetten we een upgrade voor je klaar. Als je die hebt uitgevoerd in Test kunnen we (ik denk telefonisch) toelichten wat er zoal waar speelt.

Ik neem aan dat de upgrade dan ook de aanpassingen bevat sinds de laatste upgrade en niet alleen deze aanpassing?
Want dan moet ik even kijken of er komende week getest kan worden voordat we het naar de produktie-omgeving overzetten.

Ja hoor - bevat gewoon "alles".

Top - ik heb akkoord om te testen, dus kun je bij deze de upgrade aub klaarzetten?
:13c:

Hallo Pascal,

tbv de upgrade heb ik je een mail gestuurd.

Dank! Ik meld me nog.