Bedankt Wouter en Peter,

Inderdaad in alle gevallen niet gemakkelijk.
Ik denk toch de oplossing (meer) gevonden te hebben in een korte aanvulling op de code.
SA002 wordt voor alle leveranciers die wel algemeen gebruikt kunnen worden SA002A1
Voor die leveranciers die afwijken wordt het SA002A2 of A3 enzovoort.
Nou moet je dat enzovoort niet te letterlijk nemen want uiteindelijk gaat het maar om een paar stuks, maar toch.
Als een A3 alleen in een bepaalde formulering gebruikt magworden, dan kan deze dus ook als zodaning toegewezen worden.
Daarnaast alszijnde vrd is het natuurlijk in de basis een SA002 maar ik kan hem niet overal inzetten dus moet hij ook onderscheidend op vrd komen te staan.
Dat is nog beter zelfs omdat hij nu gewoon tussen de andere SA002 staat en dat mag feitelijk niet omdat deze niet algemeen inzetbaar is.

Is een eerste opzetje en we denken er nog even heel hard over na maar ik denk dat het in deze hoek moet zitten.
Jullie aanvullingen en adiezen zijn van harte welkom natuurlijk.

Gedeelte van grondstofcode gebruiken voor recept,
Onze grondstofcode is nu opgebouwd uit 5 karakters: voorbeeld SA002.
Deze code komt ook zo op onze recepturen naar voren.
Nu hebben wij meerdere leveranciers voor een bepaalde code zonder dat daar nu onderscheid in gemaakt wordt (en kan worden).
Het komt steeds vaker voor dat grondstoffen van een bepaalde leverancier over bijvoorbeeld 98% van onze recepten gebruikt kan worden maar op 2% dus niet.
Zie voorbeeldje:
Leverancier   Recept A   Recept B   Recept C
x               Y                N              Y
y               N                Y              N
z               Y                Y              N

Wij zijn voornemens om onze grondstofcodes aan te gaan passen dan wel uit te gaan breiden om bijvoorbeeld traceerbaarheid te verbeteren en om voornoemd probleem te gaan tackelen.

-   Hoe zou onze nieuwe code eruit moeten gaan zien zonder dat we daarbij de huidige broncode uit het oog gaan verliezen?. (is wel zo handig voor de historische kennis enz.)
-   Hoe zouden we dan onze recepten in moeten gaan richten of valt dit juist meer binnen de huidige functionaliteit?
-   Hoe houden we onze voorraden inzichtelijk per totaal op basis van broncode?

Ons eigen idee is om bijvoorbeeld de huidige broncode/leverancierscode/volgnummer toe te passen
Dus: SA002 D90620 A01 en dan aan elkaar dus: SA002D90620A01. Hoor graag van de mogelijkheden en jullie advies in deze.

Wij gebruiken klantspecifieke omschrijvingen en dat werkt op zich prima.
Onze code structuur is zo ingericht dat er bij de combinatie artikel-verschijning een klantspecifieke omschrijving bij komt en gelijk ook uniek is.
Bijvoorbeeld: 666VR2104 – 5.00LNF is gelijk aan de omschrijving “pietje puk nagelrood”.
Deze combinatie-omschrijving is uniek en komt dus nergens anders voor.
Dit wordt dan ook middels de klantspecifieke omschrijvingen conform weergegeven op bijvoorbeeld order bevestigingen en fakturen.

Wat enigszins lastig is is dat de juiste klantspecifieke omschrijving niet wordt weergegeven op het scherm wanneer je bijvoorbeeld in de order zef op de regels gaat kijken.
Pas bij het afdrukken komt de juiste omschrijving naar voren. Nogmaals, dit is lastig en niet meer dan dat. Opletten blijft geboden.

Waar het wel lastig is is dat wij de gegevens van artikel verschijningen gebruiken als master data voor onze warehouse partner.
Deze krijgt dus alleen de originele naam te zien en dus niet de klantspecifiek omschrijving.
Voorbeeld: Zij krijgen fysiek binnen 666VR2104 – 5.00LNF met de omschrijving “pietje puk nagelrood” op het label maar de masterdata laat alleen de originele omschrijving zien.
Zij maken pallet en verzend stickers met product codes en omschrijvingen op basis van de master data die dan dus helaas de verkeerde omschrijving bevat.

Mijn vraag is concreet:
Kan het zo gemaakt worden dat je bij een artikel-verschijning combinatie altijd de juiste omschrijving krijgt te zien ipv dus  de originele omschrijving?
(Ja, ik weet dat de naamgeving feitelijk gebeurt op het niveau van artikel code en dus niet op de combinatie met een verschijning maar toch)

Mijn vraag is welke tabel dat weergeeft. Hoe ik dat doe is toch mijn zaak neem ik aan.

Dan geen antwoord, ook goed.

Ik wil graag middels een query gegevens van orderregels ophalen waarbij ik ook het afleveradres kan zien.
Wat ik vooral wil weten is het land van leveren en natuurlijk de artikel gegevens.
Rest van de adres gegevens is niet belangrijk. Koppelen met afleveradressen heeft weinig zin omdat er vaak 9999 gebruikt wordt.

Dank je Wouter,
Een en ander getest en we passen het nu als bijstelling op recept toe.
Moeten wel ST / ST aanhouden en dynamisch wordt dan Statisch. KP getest en komt goed terecht.
Hierbij hoeft er overigens geen (automatische link) naar de out put te zijn omdat we een opslag van x% doen ivm verlies bij het instellen van de printer ed.
Bij deze eigenlijk opgelost. Zij het niet direct op de manier die ik graag had gewild maar wel op een goed werkbare manier.

Kwestie bij deze opgelost dus.

Bij de opgave van het maatwerk is dit eigenlijk helemaal stil gevallen. Is ook nogal wat voor een toch redelijk onbeduidend iets als ergens een specifiek label kwijt kunnen.
Met dat onbeduidende bedoel ik dat het feitelijk alleen er maar om gaat om ergens bij het boeken een specifiek label vrd technisch en kostprijs technisch te boeken.
Dit probleem wordt nu weer heel actueel bij ons dus vandaar dat ik het nog maar eens probeer om een of andere "simpele" methode te vinden om dit boeken mogelijk te maken.
Wij werken namelijk met heel veel van dit soort specifieke gevallen dus is niet iets wat je even kunt weg moffelen.
Is het mogelijk om de labels bij het afboeken van een normaal productie recept achteraf toe te voegen als een recept regel?
Dit zou voor ons voor nu in ieder geval meer dan voldoende zijn.

Peter,
Wij werken inderdaad met een externe partij (en wij zijn blij van wel) en onze vrd registratie loopt 1 op 1 en dat zal straks ook het geval zijn igv pallets.
Zij werken namelijk al met pallet registratie en daar ontstaat nu juist de kneep.
Wij stellen eenheden voor en zij moeten pallets rapen.
Dat doen zij dan binnen die eenheden/charge die wij gereserveerd hebben en dat laat dan weer te weinig ruimte voor hun.
Als wij dus van meet af aan de pallets goed kunnen voorstellen(reserveren dus), dan ontstaat er voor hun meer ruimte mbt economisch rapen.
Let wel: Wij stellen straks pallets/sub- charges voor en niet de locatie waar vanaf geraapt moet worden want dat is juist de eco slag die zij dan kunnen maken.
Ik hoor je al denken: kunnen zij dat dan niet anders inrichten? Dat kunnen zij wel maar nog steeds binnen die range van eenheden die wij gereserveerd hebben.
M.a.w.: zij mogen in principe nooit afwijken van datgene wat wij reserveren dus kunnen ze ook niet vrijelijk een andere charge rapen om zo een pallet te pakken wat passender is.
Daarnaast kan ik het "NIET consequent FIFO" reserveren niet aan hun verantwoording overlaten want dan krijg ik het zekers niet uitgelegd.

Resumé:
Aannemende dat beide vrd gelijk zijn.
Vrd artikel/verschijning/charge1 = 92 stuks / onderverdeeld in 4 pallets van 22 stuks en een restant van 4 stuks
Vrd artikel/verschijning/charge2 = 50 stuks / onderverdeeld in 2 pallets van 22 stuks en een restant van 6 stuks
Vrd artikel/verschijning/charge3 = 132 stuks / onderverdeeld in 6 pallets van 22 stuks

Wat wij dan aangeven aan derde partij:
Order = 112 stuks en resulteert in 4 pallets van charge1 en  1 pallet van charge2 en 2 losse eenheden van charge1
Order = 94 stuks en resulteert in 4 pallets van charge1 en 6 losse eenheden van charge2
Order = 188 stuks en resulteert in 4 pallets charge1 en 2 pallets charge2 en 2 pallets van charge3 +4 losse eenheden charge1+6 eenheden charge2 + 2 eenheden charge3
Order = 7 stuks en resulteert in 4 stuks van charge 1 en 3 stuks van charge 2
Order = 11 stuks en resulteert in 4 eenheden charge1 + 6 eenheden charge2 + 2 eenheden charge3

De laatste 2 voorbeelden zijn dus gebaseerd op wel FIFO met inachtneming van 22-3 principe wat ik eerder aangaf en wat er dus mede voor zorgt dat FIFO nooit langer dan 3 charges duurt.

Goed weekend alvast,

Klopt Peter, ... ik kon je overigens helemaal volgen tot het eind en zelfs verder en je hebt inderdaad een punt.
Alhoewel ik die kans niet zo heel groot acht, heb ik hier natuurlijk wel wat te verdedigen inderdaad als het gaat om FIFO.
Daarentegen als we nu kiezen om eerst de hele pallets voorrang te geven en daarna altijd eerst het oudste restant te pakken, dan heb ik in ieder geval al veel gewonnen.
Betekend dan wel dat er een mogelijkheid bestaat dat er meerdere restanten worden aangesproken maar zo blijf ik wel dicht bij FIFO en heb ik de garantie dat de oudste charge altijd binnen een bepaalde tijd is opgelost.

We zouden ook kunnen zeggen, en nu ga ik misschien wel heel ver(dwalen zelfs): als het een artikel/verschijning betreft die alleen uit pallets van 22 stuks bestaat(muv restant) dan zouden we ervoor kunnen kiezen dat alles binnen een range van 22 -3 of minder eerst het eventueel passende pallet wordt gekozen van elke willekeurige charge en als het daarbuiten valt dat dan eerst het oudste restant gekozen wordt. Hiermee wordt de kans wel heel erg verkleind en vind ik het evengoed verdedigbaar. Ook hier geldt dan weer dat er opnieuw eventueel meerdere restanten worden aangesproken.

Al denkende in oplossingen bedenk ik me zo dat het niet eens zo heel ver van de basis af is als dat het lijkt, toch?

Het is geenszins de bedoeling om FIFO onderuit te halen maar verder uit te breiden met voorwaarden die FIFO niet altijd leidend laten zijn. Als je logisch beredeneert, en dat kan jij beter dan ik, dan zul je tot de ontdekking komen dat de oudste charge in principe nooit langer op vrd zal staan dan een tweede charge daarna. Veelal door de hoge omloopsnelheid. Kortom ik vind dit verdedigbaar naar ons SOX programma. (dat is waar jij op doelt neem ik aan) Uiteraard zal het definitieve ontwerp daar eerst aan getoetst worden en waar nodig ook voorgelegd worden aan de auditoren.

Laat maar horen wat er van mijn gedachten, in combinatie met jullie kennis der programmatuur, mogelijk is op dit gebied zonder dus al op voorhand zaken uit te sluiten.

Automatisch reserveren op basis van sub charges,
Actueel  reserveren wij op basis van eenheden en met eenzelfde charge.
Dat wil zeggen dat als wij een partij na productie gereed boeken van 115 stuks, dan krijgen zij allen hetzelfde charge nummer. 
Als we op basis van FIFO automatisch gaan reserveren, dan worden de oudste charges het eerst geselecteerd zonder dat daarbij naar een eventueel economisch voordeel gekeken kan worden.
Het economische voordeel zit hem voor ons voornamelijk in hele pallets en met als resultaat zo weinig mogelijk restant pallets. Wat wij nu graag zouden willen is het volgende:
We hebben een order voor 22 stuks. Een vol pallet is 22 stuks dus zou het economisch zijn als er een vol pallet gereserveerd gaat worden. Echter: Onze vrd is,
Charge A met charge datum 01-05-2014 1 pallet met 16 stuks
Charge B met charge datum 01-06-2014 1 pallet van 22 stuks en 1 pallet van 9 stuks

Op basis van de huidige voorwaarden wordt eerst charge A met 16 stuks geselecteerd en vervolgens het restant van charge B. 
In dit geval zou het economischer geweest zijn als eerst de charge B en pallet met 22 stuks was geselecteerd.

Een ander voorbeeld met dezelfde order is:
Onze vrd:
Charge A met charge datum 01-05-2014 1 pallet met 16 stuks
Charge B met charge datum 01-06-2014 1 pallet van 20 stuks en 1 pallet van 9 stuks

Omdat er hier nu geen vol pallet aanwezig is zal er dus over meerdere charges geselecteerd moeten gaan worden.
In dit geval zou dus de voorwaarde FIFO wel afgedwongen moeten worden en zal het restant van het pallet met 9 stuks geselecteerd moeten worden.

Bijkomende zaken zijn:
We hanteren diverse aantallen met eenheden op pallets
Per artikel/verschijning daarentegen staan deze wel vast.
Bijvoorbeeld bij artikel/verschijning  X staan er altijd als basis 22 stuks op een pallet.
Zo kunnen er voor Artikel/verschijning Y altijd als basis 100 stuks op een pallet staan.
Uiteraard kunnen er in alle gevallen restant pallets ontstaan met afwijkende aantallen.

Ben benieuwd.

Dank je Wouter en dank je Peter,

Allereerst Peter, we rapen wat we reserveren dus dat gaat prima.(geen chaos meer dus)
We reserveren nu alleen op basis van eenheden vanuit een totale charge en niet op basis van aantal pallets op basis van sub charges.
Daarom zie ik wel brood in het verhaal van Wouter maar moet even goed overdenken welke definities dan wel voorwaarden wij nodig hebben.
Ik zal een en ander nader uitwerken met ook gelijk een aantal voorbeelden van hoe het wel zou moeten gaan werken.
In mijn overwegingen ga ik dus gemakshalve alvast uit van sub charges(hoewel dit voor ons een nieuw fenomeen is).

Kom er dus z.s.m. op terug.

Wij werken nu bij het reserveren van artikelen op een verkooporder door middel van FIFO waarbij dus het systeem zelf de charges bepaald.
Is het mogelijk om extra voorwaarden op dit principe toe te passen?
Bijvoorbeeld eerst binnen een opgegeven aantal overeenkomstig het aantal hele pallets, eventueel van meerdere charges, en als laatste om het aantal compleet te maken een selectie uit de restant pallets.
Uitgetekend: Benodigd 72 stuks = 3 pallets van 22 stuks met eventueel ieders een andere charge en aangevuld met een restant van 6 stuks.deze laatste 6 stuks dan van zo weinig mogelijk verschillende charges.

Dit kan natuurlijk wel handmatig maar dat is nogal veel werk gezien de onder handen zijnde orders waarbij telkens ook dezelfde producten geraakt worden.

Half jaar geleden? Denk dat je mogelijk hiermee refereert aan iets dat een eigen leven was gaan leiden.

Wouter, Dit zou inderdaad de juiste oplossing voor ons zijn.
Heb je eventueel een richting mbt het maatwerk voor ons?

Het zelf aanmaken van labels vanuit HP is voor ons vooralsnog geen optie.

Ok, bedankt Wouter.

Ik denk niet dat dit de oplossing is: Bijgevoegd een voorbeeld.
Je ziet dan de artikelen die onder Vvorm, 0.75LEU, in dit geval worden afgeboekt bij productie.
Artikel Y8003 betreft het label. Dat label echter is product specifiek.
Zo zouden er ook in de toekomst nog meer product specifieke zaken kunnen ontstaan bij private labels bijvoorbeeld.

Wat wij zoeken is een mogelijkheid om de artikelen middels een emballage set te boeken maar dan op een product specifiek niveau.
Dus zodanig dat voor product X gebruik je Vvorm 0.75LEU met label Y8003, en voor product Y gebruik je Vvorm 0.75LEU maar dan met label Y8004.