Overigens heb je wellicht ook niets opgegeven kwa selektie. Dus, je kunt ook nog eens proberen H1, P10, 100 op te geven (bij de vraag voor Artikelgroepen) maar vraag mij niet wat er dan (raar) gebeurt.

De rest zit onder ZZ, want is dubbel (redundant).

Zie ook de optie voor Artikelgroep Hiëarchie.

Deze Expeditie Parameter lost het eigenlijk aloude probleem op van de contradictie tussen de instelling "Halfvolle Verschijningen zijn te Leveren" Ja en Nee.

Eigenlijk moest eenieder die met containers werkt (of niet-altijd voor dezelfde hoeveelheid gevulde drums etc.) werken met Ja, terwijl dit tegelijk impliceerde dat een blik waar (bijv. t.b.v. produktie) iets is uitgenomen formeel als Te Leveren werd aangemerkt. Dit, terwijl het voor een Te Leveren blik van 5Kg toch niet zo kan zijn dat als er nog 2Kg in zit dit mag worden aangemerkt als voldoende vol om de klant tevreden te houden ...

Middels bovengenoemde Parameter kan nu worden ingesteld wat als "voldoende vol" wordt aangemerkt, om formeel zichtbaar te worden als Te Leveren Voorraad.

?

Kijk je de IF bij Verwerken nog na ? (of YK)

Min of meer OffTopic

Eigenlijk wel grappig, want ik heb nog geen 3 minuten dit topic geplaatst, of eigenlijk heb je alhier al een voorbeeld.

Bel de OB inspecteur maar eens op, en vraag of hier BTW bij komt kijken. Het antwoord : Ja. Sterker : daar moet een faktuur bij.

Nou ... echt niet heh. Wat er v.w.b. export (en Verplaatsen) wel bij komt kijken is een Proforma Faktuur (waar dan ook maar BTW op staat).

Wouter, wat ik net wilde vragen is om eens te kijken naar het Verwerken bij Wijzigen VOregel, omdat je zonder iets te wijzigen wel "Verwerkt" aantreft. Dàt is al niet pluis, en leidt wat mij betreft inderdaad tot jouw konstatering / verwachting.

Edit : Met daarbij maar de opmerking dat er kennelijk (ooit) iets niet goed is gegaan bij het genereren van ... ehh ... Voorraad ? aangezien we al eerder hebben gekonstateerd dat de Kenmerken ontbraken. Dit treedt heus bij niemand op maar hier (bewezen) wel. Het wordt wellicht dan ook tijd om middels een runnetje die Kenmerken in alle bestaande Voorraad erin te schieten (tenzij die er al staan natuurlijk, want afhankelijk van het produkt worden ze daadwerkelijk gebruikt).
Dan sluit dat in elk geval alle toekomstige rariteiten ditaangaande uit.

Ik heb je smiley gezien hoor, maar rustig nou. Je trekt konklusies voor een ander. Geef Dirk-Jan svp eerst de gelegenheid weer aan dit maatwerk te denken ...
De frustratie snap ik ook, maar een klant niet (altijd). 

Dit betreft een relatief drastische wijziging in het pakket, en behelst het kunnen omgaan met Prijsafspraken in een valuta die niet de eigen valuta is, terwijl de uiteindelijke faktuur wèl in de eigen valuta is, en daarmee tegen veelal vooraf afgesproken Koers (Koerstype) wordt afgerekend. E.e.a. speelt zowel aan de Inkoopzijde als aan de Verkoopzijde.

Het speelt met name in landen die wel graag met een harde(re) valuta als de euro werken, maar zelf zo'n valuta niet bezitten (veelal dalend t.o.v. euro (e.d.). Als voorbeeld mogen we Polen hanteren, waarvoor de funktionaliteit overigens ook is ontwikkeld;
Omdat het hoogstwaarschijnlijk zo is dat dit in een land als Nederland niet zal worden toegepast, wordt e.e.a. vooralsnog niet alhier als "handleiding" uiteengezet (die kan maar beter in het Engels worden opgesteld), maar omdat er enkele Nederlandse klanten zijn met zusters / dochters in landen zoals Polen, lijkt het nuttig om in elk geval het bestaan van deze funktionaliteit uit te duiden.

Algemene uitleg

In landen zoals bedoeld, met als voorbeeld Polen, maakt men de prijsafspraken in euro. Dit doet de leverancier met "jou", en dit doe jij met de klanten. Het gevolg is, dat je weliswaar je prijsafspraken in een harde valuta vastlegt, maar je intussen wel fakturen krijgt / stuurt in de eigen (dalende) valuta. Om dit administratief bij te houden zonder onderhavige funktionaliteit is een komplete afdeling met rekenmachines nodig ...

Inkoopzijde

Is relatief simpel, en behelst het kunnen opgeven van de Koers op het moment van Goederen Ontvangst. Let wel, letterlijk kan dit zo niet (bij Goederen Ontvangst) omdat dit dan zou worden overgelaten aan Magazijn personeel, die ofwel de benodigde kennis niet heeft (hoort te hebbenm, hoeft te hebben) dan wel de informatie niet heeft (welke Koers wanneer toepassen).
Aldus loopt de Goederen Ontvangst in zo'n omgeving min of meer gedwongen via Inslaglijsten;

In zo'n omgeving zal de Leverancier verplicht voorafgaand aan de Levering
a. een Voormelding daarvan doen;
b. dit vergezeld doen gaan van een faktuur, waaruit de gehanteerde Koers blijkt.

N.b.: De gehanteerde Koers kan op zich zijn ontstaan uit afspraken, denkend aan dagkoers, gemiddelde koers, enz. Dit is verder voor de Inkoopzijde niet relevant (in het pakket).

Op basis van de Voormelding wordt een Inslaglijst gemaakt (kan dus meerdere Inkooporders tegelijk betreffen voor dezelfde Leveranciers), terwijl één Inslaglijst kan worden voorzien van een Koers.
Dit betreft dus een relatief simpele administratieve handeling die plaatsvindt voordat de goederen arriveren.

Bij de daadwerkelijke Goederen Ontvangst wordt dit gedaan via de Inslaglijst, en voor de Voorraadwaarde wordt de (prijs en) Koers gehanteerd zoals bekend gemaakt op de betreffende Inslaglijst.

Administratief is hiermee voor de Inkoopzijde alles geregeld.

Verkoopzijde

Aan de Verkoopzijde moet enorm veel meer (in het pakket) gebeuren om dit vloeiend te laten werken;

Eerst zijn daar de Prijsafspraken met de klanten, die in euro (enz.) worden geregistreerd, terwijl de klant in Zlotty (enz.) zal worden gefaktureerd. N.b.: Voor bepaalde soorten Prijsafspraken was iets dergelijks voorheen niet mogelijk (en ook niet nodig), terwijl het geheel aan funktionaliteit nu dus meegeeft dat dit intussen kan. Dit betreft dus feitelijk de algemene Prijsafspraken met een klant die (stel voor Nederland) gewoon in euro wordt gefaktureerd, terwijl alles met deze klant in bijv. USD wordt afgesproken. Let wel, zulks kon voorheen wel, maar dan ontving de klant ook een faktuur in USD.

Het eerstvolgende wat in zo'n omgeving optreedt, is dat een klant toch niet afhankelijk wil zijn van de grillen van de koerschommelingen, en dat je aldus daarover "prijsafspraken" maakt. Je legt bijvoorbeeld de Koers vast ten tijde van het maken van de Verkooporder. Ook hier geldt dat dit voorheen niet mogelijk was maar ook niet hoefde (tenzij je op de termijnmarkt zit met je valuta), mits je maar met de klant afsprak dat de afgesproken prijs in de valuta ook in die valuta mocht worden gefaktureerd. Zo niet dan was er nog geen man overboord, want sprak je een prijs af in bijvoorbeeld DEM maar faktureerd je in NLG, dan schommelde de koers tussen DEM en NLG toch dusdanig weinig dat het je allemaal niet interesseerde. Dit zou heel anders zijn als je een prijs in Zlotty afsprak, en je op basis van een faktuur in Zlotty dus ook in Zlotty zou worden betaald (na 3 maanden ongeveer de helft van je geld kwijt, zoals het een aantal jaren geleden was).

Waar de klant aan de ene kant zich ingedekt wil zien, wil je je zelf net zo goed indekken aan de andere kant. Ik bedoel, de Koers vastleggen ten tijde van het maken van de Verkooporder is leuk voor de klant, maar niet voor jezelf ...
En zo kom je vanzelf tot allerlei gradaties van/voor het vastleggen van de te hanteren koers zoals die moet gelden ten tijde van de Levering.

Probeer -terzijde- ook eens te denken aan de pure onmogelijkheid om in zo'n omgeving te werken met vooraf vastglegde Prijzen, omdat je te maken krijgt met Prijzen die domweg veranderen op het moment dat je Levert. Gevolg : rekenmachines erbij, en alvorens je Faktureert alle Prijzen omrekenen middels de afgesproken Koers (die elke dag anders is) om daarna eerst alle Verkooporderregels te voorzien van de te Faktureren prijs. Ja ja ...

Na een uitermate komplex ontwerp (nou ja, 12 A4 of zo) is het fenomeen Koerstypen ontstaan, waarbij het ontwerp met name komplex was omdat e.e.a. zo transparant als mogelijk moest werken, en je je niet suf moet zitten te registeren om e.e.a. aan de gang te maken.
Koerstypen gelden voor een valuta, en er kunnen er net zo veel van worden gedefinieerd als gewenst, met als resultaat dat een Koerstype een afgeleide is van een Valuta (met haar Koers).

Een Koerstype kent onder meer rekenfunkties op basis van typen gemiddelden, denkend aan de gemiddelde koers van de afgelopen maand, de afgelopen kalendermaand enz. enz., de perioden (minimaal op dagbasis) net zo in te delen als gewenst (tot jaren aan toe). Dus, naast het kunnen ingeven van de aktuele dagkoers (wat er op zich meerderen kunnen zijn, bijvoorbeeld afhankelijk van de instantie die ze afgeeft), kunnen er daarvan (zelf op te geven) afgeleiden worden gedefinieerd.
Het geheel staat aldus toe om welke "afspraak" er in deze met/door een klant is gewenst, deze zo gemakkelijk als mogelijk te registeren en haar werking te laten hebben.

Waar bovenstaande de helft van het verhaal is, onstaat de andere helft omtrent het moment van de Koersbepaling. Denk ten eerste weer aan het inleggen van de Verkooporder, maar denk ook aan het moment van Leveren, denk aan meerdere Leveringen voor een Verkooporder (en dus indien gewenst meerdere Koersmomenten), denk aan het handmatig willen overschrijven van de berekeningen, de registraties bij de Debiteur (wat is de afspraak eigenlijk).

Het geheel zorgt er uiteindelijk voor dat alles zonder er naar om te kijken kan gebeuren, en waar er (werkelijk !) uren werk nodig waren om één Verkooporder van enige omvang af te handelen, kost het nu niets meer dan het dagelijks registeren van de Koers (wat toch al wel gebeurde).

N.b.: De Faktuurlayout kan op regelniveau worden voorzien van de gehanteerde Koers (want meerdere Leveringen op meerdere dagen leiden tot verschillende Koersen voor de ene Faktuur die uiteindelijk wordt gestuurd (omdat Faktureren niet verplicht dagelijks gebeurt)).

Let op : Van dit geheel is niets zichtbaar als de Parameter zoals onderstaand weergegeven niet is aangevinkt.
Merk op dat dit op deze wijze aktief is gemaakt omdat het verregaande gevolgen heeft voor de werking van het geheel, welke werking echter niet behoort te veranderen als er verder niets wordt ingesteld en e.e.a. dus veiligheidshalve zo is gedaan.

Jongens, kunnen we to the point blijven ? ik bedoel, DKN, als ik vraag naar die sterretjes, dan vraag ik uiteraard naar de konstatering van hetzelfde. Anders gezegd : je hebt dit niet getest zoals je met het TS wel doet/deed.

N.b.: Dank voor de response Wouter, want ik was er wel ingetuind. 

En DKN, ik snap ook wel weer dat je er zelf intuint. 

Dirk-Jan, ik heb keurig netjes je scherm weggehaald;
Kun je die svp opnieuw maken volgens de geëigende methoden ? (en wat geen Dos inhoudt)
Sorry, maar ik vond het niet kunnen (had je bij SE wel gemogen, als je begrijpt wat ik bedoel).

... voor zaken zoals in dit topic worden behandeld ?

Maar feitelijk alles wat ons wel eens zou kunnen aangaan ?

Het is natuurlijk niet lekker dat wij afhankelijk zijn van meldingen van gebruikers achteraf.

N.b.: Het navragen bij welke instantie ook, betreft een ten ene male onmogelijkheid. Of het nu ABN/Amro, Microsoft, CBS, Belasingdienst, OB inspecteur of wat/wie dan ook betreft. Niemand weet (meer) antwoorden.

E.e.a. is natuurlijk een beetje gevoed door onze eigen kennis en eigenwijzigheid, maar antwoorden kloppen NOOIT.

Mocht iemand (van ons zelf) een vraag + antwoord kennen wat een keer wel juist was, dan is dat ook wel leuk om te weten.

Ok. Best wel nuttige vraag denk ik. Ik hoop dat ik e.e.a. middels het volgende kan verduidelijken.

Je zegt het terecht : "na aankoop". Wat je niet zegt, is of dit na JOUW aankoop is, of na de aankoop van jouw klant.
Wat je in deze moet doorgronden, is dat de door jouw gemarkeerde rubriek de "standaard", of zo je wilt default betreft, en dat dàt alleen al informatief zou kunnen zijn (dan : door jou gewenst), maar dat het weinig zegt over die partij ananas die je op dit moment in de verkoop hebt. Immers, hoe lang heb jij die al liggen ? ...

Nu wordt het moeilijker (voor jou, om te besluiten wat je wilt), want het pakket is (uiteraard) in staat om de huidige (op ieder moment) nog geldende houdbaarheid te tonen. Dit overigens, na aanpassing van de default (zie hierboven) die je bij Goederen Ontvangst bepaalt (er bestaat een speciale Keuring om de THT te overschrijven bij GO).
Dus, als jij een partij hebt liggen die keurig aangeeft dat de houdbaarheid volgens jouw normen nog twee dagen houdbaar is, moet je je eerst afvragen of je wel wilt dat een klant daar inzage in heeft.

N.b.: Voor bovenstaande zou ik (als ik jullie was) niet bang zijn, omdat je eerder een langere "momentele" houdbaarheid zult hebben dan een kortere. Laat ik het zo zeggen : jullie bloemkolen blijven bij mij in de koelkast nog 3 weken goed, terwijl ze bij de AH al bruin(ig) zijn als ik ze koop ... 

Vervolgens mag je te maken hebben met iets wat nog veel mooier is : het per klant definiëren hoeveel dagen *die klant* als minimale houdbaarheid vereist (vraag me even niet waar je dat instelt, maar dat kan). Dus, je hebt een partij ananas die volgens jullie (en onder jullie koelkondities enz.) nog 4 dagen houdbaar is, maar je hebt een klant die als minimum 8 dagen stelt (want : per hoeveelheid dat hij inkoopt raakt hij ze niet binnen 3 dagen kwijt, en bij de uiteindelijke afnemer moet het ook nog 5 dagen goedblijven). Dus, bij jou ligt 4 dagen maar de klant wil 8 dagen, en dus heb je geen voorraad.

Merk op dat kwa VTV en Behoefterun enz. je de ananas voor die 8 dagen klant zult gaan inkopen, en aannemend dat jij na GO nog 2 weken hebt voor de betreffende ananas (denk nu ook aan land van herkomst enz. !) heb je voor de 8 dagen klant nu dus voorraad.

Aangaande de VTV geldt dan nog dat je vanzelf de ananas ziet verdwijnen per datum dat 'ie verlopen zou zijn ...
Probeer (in Test) een Voorraad Item maar eens een THT te geven (kun je bij Wijzigen Voorraad Items dacht ik wel doen, eventueel na invullen van de door jou gemarkeerde rubriek), en vraag vervolgens de VTV op ...

Nu voel je wel (als je wat verder denkt) dat ik het hier intussen heb (moet hebben) over het werken met THT op basis van de voorraad die je hebt, terwijl je tot heden (beter : oorspronkelijk) ervoor hebt gekozen om dit via de webshop niet kenbaar te maken. Wel sluit dit aan bij de intussen veranderde werkwijze (ik hoop dat je snapt wat ik bedoel), en dus mag je wat mij betreft alvast in die richting gaan denken.

Wil je dit allemaal niet, ofwel, zou je slechts de default kenbaar willen maken, dan moet je je het zinvolle (of niet) wel realiseren. Of zo je wilt : de misinformatie die je geeft. Immers, als je voor de ananas 2 weken toont, maar door omstandigheden (bijv. minder verkocht dan je wilde) is het intussen 1 week, dan ziet de klant nog steeds twee weken. Volgens mij kun je daar wel boetes voor krijgen (maar daar ga ik niet over).

Onduidelijkheden op dit moment ?