Zojuist Richard gesproken en gekeken naar zijn schermgrootte. 
Deze gebruiker gebruikt wel het hele scherm en ik kan zijn schermresolutie ook niet aanpassen.

En hij houdt deze melding nog steeds.
Willen jullie er daarom nog eenmaal naar kijken en iom Richard is dit meer iets voor Peter of Wouter.

Heren,

Een van onze werknemers wil via 2-1-1-1-ShftF5 de CRM module openen. Heart profit gaat dan eerst eea berekenen zoals het lijkt en loopt dan vast.
Zie de melding in de bijlage.
Euvel is dat het bij anderen wel goed gaat.
Wat nu?

Dank je wel.  En helder.
Tuurlijk nemen we de release notes door

Maar in het verleden kreeg ik een mail als jullie gereageerd hadden. Die krijg ik nu niet meer terwijl dat wel is aangevinkt

Goedemorgen heren,

Pascal heeft de update in de testomgeving gezet. Nu staat er op 6 mei 2025 bij release-notes dat de Log-registraties zijn verwijderd van boekingen. Dit zou op ons verzoek zijn. Maar we kunnen dat even niet thuisbrengen.
Weten jullie nog wat dit is of is dit niet meer relevant.

Hoor het wel even waarvoor dank.

Dinand

Willen jullie nog even reageren of een bewerking toevoegen bij een halffabricaat nadelen heeft? Op zich gaat het in de testomgeving allemaal goed, maar heb alleen geen ervaring met bewerkingen bij halffabricaten.
Bij voorbaat dank.

Als het bij de halffabricaten geen probleem is zijn het aantal recepten te overzien.

Nog een vraagje: Kan ik die bewerking ook zonder problemen toevoegen bij een halffabricaat.
Heb dat getest en de kostprijs wordt wel hoger en bij het afboeken van bewerkingen bij productieorders komt die bewerking ook wel weer terug.
En het gaat ook wel naar een apart grootboek.
Maar zitten er nadelen aan door een bewerking bij een halffabricaat op te nemen?  ( behalve dan dat je hem bij de kostprijsopbouw ve eindproduct niet ziet staan)

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.

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.

Bij onze locatie in Almelo hebben we drie productielijnen met daarbij één voorraadlocatie voor de grondstoffen.
Op zich gaat dat altijd goed omdat de juiste grondstoffen altijd bij de juiste fabriek worden gelost.
Maar....nu rijden we bepaalde grondstoffen met een eigen vrachtauto van de ene fabriek naar de andere zonder dat we daarbij een voorraadboeking doen.
Dat Heart Profit dan geen boeking maakt is helder.

Maar ja hoe krijg ik die extra kosten dan in Heart Profit?  Nu zat ik zelf het volgende te denken: We boeken dagelijks de werkelijke verbruiken per productie-order af en dacht misschien kan ik een receptregel toevoegen per recept waar die twee betreffende grondstoffen in voorkomen. (gaat om twee grondstoffen).  Daarmee wordt er dekking gegenereerd voor onze afdeling transport en wordt het product ook iets duurder, wat feitelijk ook zo is.

En misschien kan Heart dat ook berekenen bij het maken/genereren regels van een productieorder.
Mijn basisprincipe is: Als je "if-than" kunt zeggen is het te automatiseren. Bijvoorbeeld IF grondstof X in recept met hoeveelheid Y dan toevoegen bewerking Z van zoveel minuten.
En desgewenst kunnen we dan bij het handmatig boeken van alle grondstoffen nog e.e.a. aanpassen mochten de werkelijke verbruiken van die twee betreffende grondstoffen behoorlijk afwijken vd norm.
Maar wellicht hebben jullie een beter idee?  Maar wat we niet willen is interne voorraden per fabriek.

Maar begrijp ook dat dit misschien een lastige vraag is.
Hoor het wel even waarvoor dank.

Goedemorgen,

Normaal lost Pascal dit voor ons op, maar ivm zijn afwezigheid even via hier.
Bij het artikel GBV10GRIJM staat de beschikbare voorraad op nul, terwijl er wel voorraad is. Zie de bijlage.
Staan meerdere charges van op voorraad, maar bij twee charges is de voorraad niet beschikbaar.
Hoe kan dat?

Heren,

Gisteren de kick-off gehad van ons project om met Xtendis over te gaan naar de cloud-versie. Op zich voorzie ik daar geen problemen. Plan is om eind april helemaal over te zijn.
Nu wil het toeval dat er ook een project loopt om met de tabellen over te gaan naar ADS.

Nu is mijn vraag of die beide projecten elkaar ergens kunnen 'bijten'. 
Hoor het wel even.

Via 8-9-2-2 en dan bij deb-id VELHAS vullen en dan een paar keer F1 krijgen we de DKK's die voor deze klant van toepassing zijn.
Nu wil ik daar een einddatum aan koppelen, maar dan krijg ik een melding. Zie de bijlage.
Naar mijn idee heb ik dit ook al wel eerder aangekaart.
Maar hoe los ik dit op of doe ik dit sowieso niet op de juiste  plek.

Hoor het wel even waarvoor dank.

Goedemiddag Wouter,
Dank je wel voor de snelle service.
We gaan het eerst testen in de testomgeving.