tuurlijk

Oh, krijg nog steeds geen mail zodra er door jullie iets gepost wordt....
Maar het verhaal is helder en klopt. Zal Pascal vragen om hoeveel recepten dit gaat.
Had gehoopt dat dit dmv een formule kon. Bijv per ton grondstof X is de eenheid bewerking y. Bij bewerkingen kan dat ook nl per formule. Maar begrijp ook dat dit lastig is.
En het klopt dat we dat niet per productie-order willen doen met een rekenmachine, maar eenmalig obv de recepturen is acceptabel. Maar als het heeeeeeel veel recepten zijn moet ik er even over nadenken.
Want stel dat het mengsel iets wijzigt dan moet ik ook weer al die recepten handmatig door.  En juist het onderhoud van recepten moet behapbaar blijlven.

Maar ga eerst Pascal vragen.
Dank hiervoor.

Funktie	Omschrijving	Dtm.Vl.Wyz	Dtm.L.Wyz
CLASSES	Geen standaard funktie	06-03-2025	06-03-2025
LOMGBR	Omschrijving (nog) niet bekend	28-02-2007	07-03-2025
LOMGRA	Raadplegen Management-defaults	20-06-2016	07-03-2025
LOMGTV	Toevoegen Management-defaults	05-01-2018	07-03-2025
LOMGWY	Wijzigen Management-defaults	27-02-2007	07-03-2025
LOPRVKO1	Omschrijving (nog) niet bekend	21-03-2022	06-03-2025

Als we in de Statistieken rapporteren op Faktuurmaand, dan betreft dit altijd een kombinatie van Jaartal en Maand. De omschrijving van "de sleutel" bevatte tot op heden echter enkel de naam van de maand zelf, dus Januari, Februari, Maart etc. M.i.v. heden wordt die omschrijving uitgebreid met het jaartal waarin die maand bedoeld is, dus, Januari 2025, Februari 2025 etc. Dit, omdat als we een statistiek opvragen over een periode van meerdere jaren, en waarbij er niet in iedere maand omzet is geweest, duidelijker zichtbaar is dat het om bijvoorbeeld Februari 2023 gaat.

Funktie	Omschrijving	Dtm.Vl.Wyz	Dtm.L.Wyz
LOPRSTOB	Omschrijving (nog) niet bekend	11-01-2023	07-03-2025

Na ampel overleg :

Uitgangspunt is dat alle betreffende Recepturen een extra Bewerking krijgen per grondstof waarop dit aan de orde is.
Is dit niet het geval (c.q. heb je daar geen zin of tijd voor) dan niet verder lezen, maar opnieuw bellen.

Dit bewerking heeft een tarief per eenheid eindprodukt. Die bewerking is tevens gerelateerd aan de hoeveelheid eindprodukt. En dit dus per grondstof waar het op betrekking heeft, anders.
Ja, je zal dan per Recept waarop dit betrekking heeft de rekenmachien eenmalig moeten hanteren (bij het wijzigen van zo'n Recept). Maar daarna (bij produceren) merk je er niets meer van. De kostprijs van het eindprodukt wordt dan navenant hoger; bij het opboeken zullen deze extra kosten worden gejournaliseerd aan de hand van de betreffende bewerkingen op rekeningen die je leuk vindt. N.b.: Je kan een andere bewerking hanteren per zo'n grondstof (met dan ook aparte journaliseringen), of je hanteert dezelfde bewerking voor al zulk soort grondstoffen. Merk op dat de hoeveelheid bewerking "per kg" eindprodukt anders kan zijn per grondstof. Dus je mag 1 Bewerking voor alles hanteren (je hebt dan meerdere bewerkingen van hetzelfde ID voor de verschillende grondstoffen in die Receptuur). Maar financieel zie je dan niets terug per grondstof. Ik weet niet goed of dit laatste al dan niet gewenst is en zo ja, of het dan niet raar rapporteren wordt (maar misschien is er dan onderscheid naar Financiële Groep mogelijk).

Voor de zekerheid : je hebt me via de telefoon verteld dat je niet iedere keer de rekenmachine wilt gebruiken; ik heb dat opgevat als "per Produktieorder". Dus wel alles eenmalig doorakkeren per Receptuur. Als je dat eveneens niet wil, weet ik het even niet.

Om een lang verhaal kort te maken :

Dit doe je met Profit-Pickorder (die moet je dan wel hebben - en die hebben jullie), waarmee je meer-dan-formeel alles regelt wat je vraagt. Inklusief de kostprijsopslagen die je via DKK's regelt.

Als je hierover verder wil discussiëren, dan graag via de telefoon. Dan zet ik zelf het resultaat hiervan wel in dit topic.
Dus tot zo.

Dit was vorige week al telefonisch besproken. Nog even formeel alhier :

Ja, dat kan elkaar bijten. Dit is het gevolg van het bij XTendis hebben van meerdere versies zoals gemaakt voor onze meerdere klanten, maar die "chaotisch" in elkaar zitten omdat wijals Heart feitelijk steeds de aanpassingen moesten doen (in plaats van dat ze bij XTendis er een alles-kunnende oplossing voor maakten).
Maar het zal wel weer goed komen, toch ?

Voor iedereen die het nog niet had gemerkt :

De Notepad versie van Windows 11 heeft de onhebbelijke gewoonte om bijvoorbeeld de meerdere prints (PRFILE.PRN) in een enkele Tab van Notepad te overschrijven. Dit gebeurt dan niet alleen bij meerdere prints die u zelf opstart (bij "printen naar file"), maar tevens bij programmatuur die intern meeerdere prints start (eveneens "naar file"), waardoor je steeds alleen de laatste ziet/krijgt/hebt.

Wij werken momenteel aan een oplossing hiervoor.
Overigens de opmerking dat de nieuwe Notepad "App" is uit te  schakelen onder Settings - Apps - Advanced App Settings - App Execution Aliases - zet Off voor Notepad, maar dat hoeft niet voor iedereen de beste oplossing te zijn.

Tsja, een Bewerking zal je kostprijs doen verhogen en zal een dekking kreëren op een grootboekrekening waar je de werkelijke kosten op kunt tegenboeken.
De werking valt en staat bij hoe je het toepast. Voor wat je nu beschrijft zou het in die specifieke situatie de job kunnen doen.
Probeer het zou ik zeggen (en je hebt ook Testbestanden waarin je kunt kijken of het doet wat je wilt).

Goedemorgen Wouter,

Inderdaad willen wij die interne verplaatsing van de grondstoffen niet registreren omdat we de voorraad niet per locatie registreren.
Maar niet de werkelijkheid na doen is eigenlijk wat ik dus wel wil. De werkelijkheid nadoen dus, maar dan via een omweggetje.
En daarom dacht ik dus aan een extra receptregel, geen artikelregel inderdaad, maar een bewerking en dan in eenheid 'uur'. Doe dat nu ook bij sommige recepten in de vorm van een extra manuur.
In dit geval zou het dan gaan om een extra vrachtauto-uur.

Bij ons worden de productie-orders aangemaakt zodra bekend is hoeveel stuks er gemaakt zijn, maar uiteraard kan het echte verbruik afwijken vd norm.  Wordt het daar anders van?  Feitelijk wel want als je bijv. 3% meer van die twee grondstoffen hebt gedoseerd dan de zou er strikt genomen iets meer dekking moeten komen voor het vrachtauto-uur. Maar dekking blijven toch vaak een goede inschatting en als het makkelijk is dat die dekking gegenereerd wordt o.b.v. de norm is het wat mij betreft ook goed.

Die vrachtwagen moet inderdaad toch rijden en voor 100 kg net zover dan voor 5000 kg. Maar we hebben een intern doseersysteem die altijd dezelfde hoeveelheid doseert. De vrachtwagen rijdt derhalve altijd met dezelfde hoeveelheid van A naar B.

Een percentage kostprijsopslag lijkt me te grof en kan ook niet inschatten of er dan een separate dekking kan naar een apart grootboek.

Zijn inderdaad maar twee grondstoffen, maar begrijp wat je zegt.
Dacht ook om het dan evt. elke dag handatig toe te voegen, maar ja dat komt wel elke dag bij meerdere productie-orders terug.