Nee, maar die was ook niet aan jou gericht.
FSRT is "WY" in dit geval. Ook al eindigt de funktienaam op TV2.

Wat bedoel je daar nou mee ? (of moet "is" "wordt" zijn ?)

Ik vind dit best wel moeilijk. Ik bedoel, dan komt er een waarschuwing, en jij zou de allereerste zijn die vervolgens meldt dat het systeem het toestaat dat gebruikers het verkeerd doen (omdat het verkeerd gegaan *is* en niemand weet waarom).
Vandaar dat ik (eigenlijk behoorlijk overdreven) hier toch een bedrijfsparameter bij wil hebben. 2 uur + 4 uur.

Heart intern : in de helptekst van de parameter noemen dat deze parameter niet wordt gerespekteerd door Scanterminal funktionaliteit (en het aldaar dus ook niet aanbrengen hehe).

Tuurlijk wel ... FSRT = 'WY' ...
In Windows dan (en dat is echt voldoende)

Even voor de rest hier : je hebt het in je laatste post over "periode omschrijving" maar wat mij betreft gaat het gewoon om één van de geselekteerde rubrieken ("Faktuurmaand"). Toch ?

Hoe dan ook, ik heb nog een verschil gevonden : bij de ene wordt de grondstofkostprijs weergegeven, en bij de ander niet ...


De rest zoeken we uit.

Tja, maar daar moet je toch wel rekening mee houden. Zie het maar ongeveer zo dat het weergeven van een VO nu "2" duurt, terwijl het lezen van 1 VORegel "1" duurt. Heb je gemiddeld 5 VORegels, dan duurt het bij elkaar straks 7. Heb je gemiddeld 10 regels, dan wordt het straks 11. Die 7 is 3,5 keer zo traag en de 11 is 5,5 keer zo traag.
Het is aan jou om het werkelijke gemiddelde te hanteren en de juiste faktor uit te rekenen.

Als jij gemiddeld 3 regels hebt, kan een andere klant nog steeds 50 regels hebben. Om die reden zal e.e.a. helaas vergezeld moeten gaan van een Bedrijfsparameter. En dan ... dan kan je zelf nog tot de ontdekking komen dat je het te langzaam vindt geworden.

Ik wil wel het volgende voorstel doen :
Initiële aanpassing : 2uur, inkl, eventueel weer elimineren.
Nadat je het hebt bekeken en hebt goedgekeurd : + 4 uur voor de Bedrijfsparameter.


Trouwens, wil je bruto gewicht of netto gewicht ? Als dit voor jullie toch geen verschil maakt (Verschijningsvorm weegt niets) dit dan s.v.p. ook melden (en dan maken we er bruto -> inkl VVorm van).

Een poging ...
N.b.: Ik schets hier een scenario met geïmpliceerde voordelen, uitgaande van een consistente werking van dat ene scenario. Dit zegt niet dat het niet anders kan, maar het moeten ook geen 10 A4 worden. Uiteraard denk ik wel aan jullie situatie.
De zaken die ik noem worden ook daadwerkelijk ondersteund met bestaande funktionaliteit , tenzij anders aangegeven.

Let op : Alles werkt real time en is/wordt dus onmiddellijk verwerkt; wat op de ene scanner wordt bewerkstelligd, is op de andere onmiddellijk zichtbaar.

• Efficiency Goederen Ontvangst.
  
  Een beetje afhankelijk van waar je de etiketten op plakt (zak vs. pallet met dezelfde zakken) liggen de etiketten reeds klaar bij goederen ontvangst, en wel dusdanig (weinig) van te voren, dat je niet omkomt in de etiketten. Deze worden afgedrukt vanuit de betreffende Inkooporders wat redelijk met 1 druk op de knop kan.
  
  Als de vrachtwagen komt voorrijden en de pallets zijn uitgeladen ga je deze voorzien van de klaarliggende etiketten, en ieder etiket wat je waar dan ook opplakt wordt gescanned.
  De funktionaliteit die hier wordt gebruikt weet over welke Inkooporderregels het gaat, en het uiteindelijke effekt is dat je met zo'n scan het produkt ook binnenboekt.
  Net als momenteel kies je zelf voor de methode van lokatie toewijzing. Bijvoorbeeld, ofwel het produkt ligt na binnenboeken bij Goederen Ontvangst (volgens het systeem dus), dan wel het ligt administratief meteen op de juiste lokatie (al dan niet in quarantaine wachtend op Keuring).
  In het eerste geval moet het produkt nog naar de uiteindelijke lokatie worden verplaatst, wat gebeurt middels een scan op het produkt (pallet) gevolgd door het verplaatsen zelf middels heftruck en dergelijke, en eindigend met een scan op de ontvangende lokatie.
  Merk op dat laatst bedoelde scan een barcode kan zijn die op een kaart is gedrukt, aanwezig in de heftruck. Dit laatste werkt alleen bij heel grove lokatie indeling, maar werkt in dat geval ook sneller / gemakkelijker.
  
  
• Aannemend dat je op pallet niveau hebt geëtiketteerd (en daar blijf ik even vanuit gaan) kan om willekeurige reden een zak van die pallet nodig zijn, en middels betreffende funktionaliteit kan 1 zak, meer zakken of de hele pallet met een simpele handeling worden verplaatst. Dit verplaatsen kan om meerdere redenen gebeuren, en ik heb het hier alleen over het eerste deel van die verplaatsing : zeggen dat je een bepaald produkt in een bepaalde oeveelheid oppakt.
  N.b.: Als dit niet de gehele pallet betreft, blijft er dus een deel achter, en splits je in feite onderwater de pallet;
  Het systsem weet ook steeds hoeveel er op een pallet ligt. N.b.: Dit betreft geen Omvormen.
  
  
• Aannemend dat je produktie niet als een black box ziet, c.q. op de produktievloer ook de voorraad wilt kunnen zien, zal het kunnen gebeuren dat je "halve" pallets de produktie in rijdt. Dit gebeurt op zich middels voornoemde funktionaliteit, doch in dit geval leg je 20 zakken op een lege pallet, en dient deze pallet weer van een etiket te worden voorzien;
  Dit etiket had je nog niet, maar het systeem weet dat en print een etiket voor je uit. Dit gebeurt in principe op de dichtsbijzijnde printer, en wat kan worden aangegeven door de operator heftruckchauffeur etc.).
  Als de pallet op z'n bestemming is, wordt dit weer aangegeven middels eerder genoemde funktionaliteit, en wat voor produktie goed met een kaart in de heftruck kan (je zult hooguit verschillende lokaties voor de fysiek verschillende produktieruimtes hebben).
  Merk op dat het systeem weet heeft van de twee pallets met zelfde produkt en initieel zelfde chargenummer. Het blijft ook weten hoeveel zich op welke pallet bevindt.
  
  
• Inventariseren is volledig geoptimaliseerd.
  
  Inventariseren kan via een aantal invalshoeken plaatsvinden, waarbij het altijd de basis is dat het systeem in principe weet wat waar behoort te liggen. Bijvoorbeeld, als ik 3 pallets van een produkt zie staan, en ik scan 1 van die pallets, toont het systeem op de scanner dat het er 3 kent. Klaar.
  Zie ik er toch 4, dan zal het simpel scannen van de 4 pallets als resultaat die 4 pallets hebben. Klaar.
  Zie ik er slechts 2, dan zal het simpel scannen van die 2 pallets ook als resultaat die 2 pallets hebben. Klaar.
  Zie ik niets, dan scan ik niets.
  
  Met name het laatste is redelijk vernunftig opgezet, omdat niets doen normaliteir geen "reset" van een situatie betreft. Dus, als het systeem ergens een pallet (of blik) kent, en jij scant die pallet niet, dan zou je denken dat die pallet administratief blijft bestaan. Toch is dit niet waar. Dit heeft van doen met bijbehorende funktionaliteit waarbij je op voorhand zegt dat je stelling A, B en C gaat inventariseren, en waar het systeem in stelling C ergens een pallet kent die jij nooit scant, zal die pallet aan het eind blijken afgeboekt.
  
  Zonder mij eraan te mogen houden moet je er een beetje aan denken dat waar je nu met 20 mensen aan het inventariseren bent gevolgd door een hele dag met alle capaciteit die briefjes ook invullen in het systeem, je nu met 1 persoon wel eens na een dag goed doorwerken helemaal klaar kan zijn. Merk dan ook op dat er na het inventariseren ook niets meer behoeft te worden verwerkt. Dit is allemaal al gebeurd.
  
  
• Naast bovenbedoeld expliciet inventariseren, kan je net zo goed in een verloren kwartiertje een stelling waar je toevallig naast staat even inventariseren. Je begint wanneer je zin hebt, en je stopt ook weer net zo hard wanneer je geen zin (tijd) meer hebt.
  En intussen is die stelling weer op orde.
  Uiteraard kan je hiervoor zelf scenario's maken, die er voor zorgen dat eens in de maand alles een keer aan de beurt is geweest.
  
  
• Ik kan niet helemaal (meer) overzien of het voor jullie (nog) van toepassing is, maar met een druk op de knop plus een scan herwaardeer je een produkt naar een andere kwaliteit. Dus, een produkt veranderen naar een produkt wat alleen nog voor opwerking kan worden gebruikt, is expliciete funktionaliteit. Let wel, een aktie "we gaan even het hele magazijn door op zoek naar dit soort spul" doe je normaliter niet even, met name omdat alles ook tegen het systeem moet worden verteld. Nu wel, want nu hobbel je een beetje door het magazijn heen, en alles wat je ziet wat moet veranderen kwa bedoelde kwaliteit, schiet je aan en klaar.
  Of je het intussen ook meenmeent op je kar om naar elders te verhuizen is weer iets anders, en dat gebeurt op zich middels de reeds beschreven funktionaliteit.
  
  
• Aangezien ook de volledige produktie is geïntegreerd in de scanmodule, kan je dit net zo goed "even meenemen";
  
  Let op : op dit moment kan niet worden overzien of dit zonder aanpassingen voor jullie overal goed gaat.
  
  De produktie zit in haar grootste basis zo in elkaar dat betreffende operators mogen doen wat ze willen. Hiermee wordt bedoeld dat als het aan het produktie personeel wordt overgelaten hoe een verf uiteindelijk "goed op kleur" komt, d.w.z. zonder dat er steeds formele produktiereceptuur aanpassingen moeten komen, anticipeert het systeem daar expliciet op. Het maakt werkelijk niet uit wat door wat wordt vervangen of erbij wordt bedacht t.o.v. de eigenlijke produktiereceptuur, het kan worden gedaan en het systeem weet het daarna ook, omdat met wederom super simpele handelingen kan worden afgeboekt. Het systeem weet met welke Produktieorder je bezig bent, en in principe mag je daarna doen wat je wilt. Als je het maar scant, en ook even vertelt hoeveel je gebruikt (waarvan het systeem meestal de juiste default wel kent).
  
  
• Produktie Opboeken werkt soortgelijk flexibel, en er weer vanuitgaande dat het eindprodukt op pallets komt, is het aangeschieten van de Produktieorder barcode (die op de papieren produktieorder staat) gevolgd door het intypen (op het numerieke toetsenbord van de scanner) van een hoeveelheid die default al goed zal staan (en er dus ook niets getypt behoeft te worden). Het produkt is nu opgeboekt en gereed voor verplaatsing. Wel even een etiket erop natuurlijk, welk etiket ter plaatse kan worden geprint (via de scanner) indien nodig.
  
  
• Omvormen werkt op soortgelijke flexibele wijze als bij Produktie.
  
  
• De meeste (of meest complexe omwille van de vriendelijkheid) funktionaliteit bevindt zich rond het Rapen;
  
  Het uitgangspunt is dat er geen Raaplijsten meer worden gehanteerd, en hooguit opdrachtbladen per Afleveradres. De scanners weten de rest, en voorafgaand aan de opdrachtbladen zijn er voorzieningen voor het door de operator(s) kunnen bepalen van het rendement van een rondje rapen. N.b.: Als alleen pallets worden geleverd is deze rendementsbepaling minder nuttig t.o.v. het moeten rapen van verschillend produkt wat op één pallet of kar zou passen, en wat gedurende het raaprondje bij elkaar wordt geraapt.
  Het gaat ver buiten het bestek van de grove uiteenzetting hier, maar kortweg komt het erop neer dat verschillende raapmethoden door elkaar kunnen worden gebruikt, en dan met name denkend aan het rapen van orders versus het rapen van produkt. In het laatste geval kan een goedlopend produkt (wat op bijvoorbeeld 15 orders voorkomt op enig moment) efficienter worden geraapt als eerst dit produkt wordt verzameld (en wordt geplaatst bij de betreffende "docks" die het systeem kent als je ze zelf inderdaad ook hebt), gevolgd door het restant uitlopen per order.
  
  Ook hier blijkt alles administratief te zijn geboekt nadat het produkt bij de docks is geplaatst, of meer letterlijk : als is aangegeven dat de vrachtwagen de deur uit is.
  
  
• Als laatste punt apart nog genoemd : alles is ook administratief verwerkt als het fysieke werk in werkelijkheid is gedaan.
  
  De impact hiervan moet niet worden onderschat. Immers, er hoeft nu ook ècht niets meer administratief te worden verwerkt, terwijl alles zo in elkaar zit dat de betreffende operators eigenlijk niet door de scanwerkzaamheden worden gestoord. Het houdt ze dus niet op, en daarnaast hebben ze er zelf profijt van (bijvoorbeeld, je kunt waar je ook bent zien waar iets ligt, terwijl je anders iemand zou moeten bellen og naar een terminal elders zou moeten lopen).
  
  Nog belangrijker dan bovenstaande, en een simpel neven effekt daarvan, is het gegeven dat er achteraf niets meer behoeft te worden uitgezocht aangaande zaken die eigenlijk "onjuist waren". Anders gezegd : zonder het real time scannen wordt het iedereen toegestaan om iets anders te doen dan eigenlijk gewenst, met als voorbeeld maar even dat er iets uit een schap wordt gehaald wat lijkt op het gewenste produkt, maar toch anders is, en wat wordt gedaan omdat er toch "iets" moet gebeuren. Dit is dus onjuist, en het wordt vooral niet aan het systsem duidelijk gemaakt, wat ook niet kan, althans, niet zonder relatief erg veel moeite. Echter, achteraf, tijdens de administratieve verwerking blijkt er wel degelijk iets niet te kunnen worden geboekt, en alvorens de oplossing kan worden gevonden hoe het dan wel moet worden geboekt, moet feitelijk eerst worden achterhaald wat er is gebeurd. Veel plezier, en mensen op de administratieve afdelingen hebben hier gerust een dagtaak aan.
  Zo niet met real time scannen, want bijvoorbeeld, iets wat er niet is kan ook niet worden gescanned. Iets wat er wel is maar niet het juiste produkt betreft, kan je weliswaar scannen, maar niet gebruiken volgens het systeem. De kontroles zijn in deze niet anders als gebruikelijk op de administratieve afdelingen, met wel degelijk een groot verschil : het kan nu fysiek ook niet gebeuren. En dus moeten de operators het probleem ter plaatse oplossen, en hoe die oplossing ook uitpakt, het systeem weet het nadat het opgelost is.
  
  

Ga nu maar tellen hoeveel mensen andere leuke dingen kunnen gaan doen ...


PS: Sorry voor alle waarschijnlijk aanwezige typefouten.

Nee fout. Tuurlijk niet. Als ik beter lees () doet die Leverancier op Artikelniveau uiteraard niets anders als default zijn voor het niveau Artikelverschijning.

Mooi. Nou kan Wouter dat nog bedoeld hebben (en voor mij mag hij !), maar nu blijkt er nog veel meer niet juist in deze. Hoe komt dat ?

Veel zaken golden in het verleden alleen op Artikelniveau, en zijn successievelijk ook op Artikel/Verschijning niveau gaan ontstaan. Makkie, je stelt hetzelfde gegeven op Artikelniveau aan als voortaan geldend als default, en na de aanpassing op A/V niveau ben je klaar. Wel, helemaal niet, want de kontrole op verplicht zijn op A niveau moet er nog uit !
En dat gebeurt denk ik nooit ...

Maar àls je iets invult op Artikelniveau moet het denkelijk toch wel bestaan. Zo niet, dan gaat er niets anders mis dan dat bij het maken van een A/V koppeling (en verder niets overschrijven) op dat moment een melding "... bestaat niet" volgt.
Dus bij al dit soort zaken op Artikelniveau alleen een waarschuwing ... er zou niets fout gaan. En als dit per saldo een stuk makkelijker werken voor de gebruiker oplevert ... van mij mag het.

Je zei het zelf al ... Behoefterun.

Nog even een verduidelijking van mijn kant (die kennelijk plots nodig is in een situatie als deze) :

Nooit, NOOIT is het toegestaan dat er een niet-consistente database op enig moment bestaat. Soms is dat niet makkelijk, en misschien is dit wel zo'n situatie. Maar die gaan we nog steeds NOOIT oplossen door er dan maar willens en wetens een zooitje van te maken. Die zou wel heeeel erg nieuw zijn.

Normaliter wordt e.e.a. procesmatig gedaan, waar je niet van de gebruiker kan verwachten dat deze alle paden in de juiste volgorde weet te vinden om iets eruit te krijgen. Voorbeeld : na een aantal jaren een Leverancier eruit gooien. Lukt nooit. Maar je snapt ook wel dat wij er iets voor zouden kunnen maken, met een soort "eindpunt" in Statistieken die alleen nog maar een ID weergeven.

Dat je, zoals in dit geval, even lastig bezig bent met het Toevoegen van een Artikel waar je geen Voorkeurleverancier kan invullen omdat je de koppeling met die Leverancier nog niet hebt gemaakt - en ook nog niet kon maken ... het kan me wat. Dat gaat er toch echt niet voor zorgen dat je een ABC-Id kunt invullen waar later de Behoefterun over mekkert. Wat wèl zou kunnen (en ik zeg niet dat we dat nu doen) is dat je bij een eerste Leverancier koppeling de vraag stelt "Opnemen als Voorkeurleverancier ?" (procesmatig dus weer). En, niet toevallig gebeuren deze zaken ook, en precies in deze hoek (iets met levertijd of zo).
Let wel, dit maakt het makkelijker voor de gebruiker, en echt onwerkbaar was dit niet.

Als laatste voor nu : het barst altijd van de meldingen "Leverancier is niet opgenomen bij Artikel - F6 is opnemen" (o.i.d.). Deze zou je hier ook kunnen hebben als oplossing, maar dat slaat helemaal nergens op. Het had dan immers bij Toevoegen moeten gebeuren. En ook dat vind ik nergens op slaan (ik ben een artikel aan het toevoegen, en niet een leverancierskoppeling).

Blabla

Begrijp je zelf ook wat je hier zegt ? ik niet in elk geval.

Ik snap ook het hele probleem niet. Een Leverancier die niet bestaat mag je niet invullen (nergens), en als je dat eigenlijk toch wilt, zul je'm eerst moeten toevoegen.

Assortiment heeft er al helemáál niets mee te maken.

Ook dat er hier iets gewijzigd zou zijn ... zal best, maar rechtvaardigt niets.

Het enige wat hier aan de hand is, is dat op de e.o.a. manier die Leverancier daar terecht is gekomen, terwijl die niet bestaat.
Of dat de Leverancier kon worden verwijderd, terwijl 'ie hier stond ingevuld.

Er is hier denkelijk nog iets anders aan de hand, want als ik Demis was zou ik dat veld hebben leeggemaakt. Maar op de e.o.a. manier doet hij dat niet, terwijl het overduidelijk is dat dat het probleem oplost ...

Graag een reaktie van Demis, en *niet* van Wouter.

Nee fout. Samengeteld met dat andere topic is 7.5 uur.
Ik neem aan dat je dat bedoelt.

Als ik zeg dat 3.5 uur geen 1000 kost zeg jij zeker dat je per abuis een nieuw topic hebt geopend ?
hahaha

2,5 uur plus 1 uur.

Als je eerst dit geregeld zou hebben, 2 uur.

Ehh, ik neem aan dat je hier tegen jezelf aan het praten bent ?


Dit is je eigen tekst hoor, die ik alleen maar voor je heb opgeschreven. En niet zeggen dat je dat "retour" niet hebt gehoord, want naast dat ik dat heb gezegd stond het topic er ook al een halve dag.

Maar goed, het probleem is meteen mooi uitgeschreven zo, en daar gaat het om.