Sorry. Dit was geaddresseerd aan ons zelf.

Werny,

?

Dat komt wat mij betreft door de toevalligheid van het niet dubbel optreden van in dit geval de Artikelen.
Hoe je dit voor elkaar krijgt (het letterlijke printje zonder verdere selektie is onmogelijk) is weer wat anders, maar wat mij betreft ook niet van belang.

Johan,

Ik krijg wel eens de mededeling toegeworpen of ik niet "korter" kan schrijven. In dit geval zeg ik dat eens tegen jou.
Ik ben zelf in elk geval halfweg gestopt met lezen. Ofwel, ook van mij krijg je geen draaibol (want ik heb het niet voldoende gelezen) ...

tja, da's nou ook wat

Zie mijn eerste post van dit topic Pascal. Doen we niet ...

Marco,

Zou je je svp aan de redelijk ongeschreven regel willen houden mensen niet bij een naam te noemen die ze zelf niet kenbaar maken ?
Dank je !

Dit zou best kunnen, maar ik ben geneigd dit niet te geloven. Immers, België heeft er dacht ik al 4 (wat niet inhoudt dat een Profit gebruiker deze ook alle3 tegelijk gebruikt).
Ik kan me ook niet voorstellen dat er een "splitsing" bestaat voor Verkooporders met meer dan 3 tarieven (richting de Fakturen), noch dat dit bij Toevoegen Verkooporderregel wordt gekontroleerd.

Aldus, het zou waar kunnen zijn dat er maar met 3 tarieven rekening wordt gehouden (0, 6, 19 voor ons), maar dat is dan domweg fout.
... wat wat mij betreft fout blijft totdat iemand er daadwerkelijk last van heeft.

Wèl moeilijk doen ...

Wij hebben uit overerving diverse klanten waarbij dit zo is ingericht, en hebben meerdere keren meegemaakt dat dit onhandig is. Let wel, om funktionele redenen die bij jullie kennelijk niet of nog niet gelden, domweg omdat je de funktionaliteit nog niet raakt / gebruikt.

Echte voorbeelden kan ik niet geven, omdat ze (kennelijk) in alle gevallen niet zullen aanspreken, en dus maar een verzonnen voorbeeld :

Als je 25 Verschijningsvormen hebt waarvan 3 werkelijk, zul je niet voor all VVormen dezelfde EOQ etc. etc. hebben. Dus, of je gebruikt dat nu niet (Behoefterun), of je gebruikt het systeem verkeerd, of je hebt al die waardes verkeerd ingesteld ... of .... je hebt er maar 3 met werkelijke waarden ingesteld.

Of het voorbeeld aanspreekt of niet, het is FOUT, en eens kom je dat tegen. Bepaalde printjes (statistieken) zijn ook zo maar 8 keer te lang, of geven niet weer wat je wilt weten omdat je ze anders moet gebruiken.

... maar waarbij Wouter's tweede oplossing wat mij betreft niet werkt omdat dit bij de klant van SE niet zo werkt. Die klant zal nl. zelf geen 100.000 artikelnummers hebben voor die verschillende labels, er vanuit gaande dat dit labels zijn voor klanten van die klant.

In dat geval werkt Kenmerken wel, en betreffende funktionaliteiten daaromtrent zijn destijds (15 jaar terug ?) ook expliciet ontwikkeld (overigens voor een klant soortgelijk SE).

*Jij* bent gezellig ... Daar gaat het nou net allemaal om met al die BTW perikelen ... Dat je geen BTW berekent waar het ook niet hoéft. Of beter gezegd, dat je de klant geen BTW aan de broek smeert die hij nauwelijks kan terugvorderen (veel te veel moeite).


Voor de lol (en wat ik eigenlijk niet wist) deze : Als je produkt in het buitenland koopt (gewoon in de winkel), en je voert het uit, dan krijg je de BTW terug bij de douane. Bij het invoeren ("onze" douane) mag je dan je eigen btw tarief weer betalen.
Bij mijn laatste reisje heb ik het niet aangedurfd de verkeerde kombinatie te maken ... ...
en dus alleen de buitenlandse BTW betaald (9 % i.d.g.).

De oplossing behoort te worden gemaakt analoog aan de methode (plus printen !) die bestaat voor het kunnen hanteren voor meerdere afleverdatums plus tijden. En ik zou denken dat Afleveradressen daar ook bij hoort, c.q. dat het gewenste al bestaat. Zie NY.

Overigens zou ik denken dat de Afleveradressen Inkoop ook al bestaan, maar niet worden gebruikt (zijn niet benaderbaar vanuit een menu). Wellicht ben ik in de war met Ophaaladressen, maar ik bedoel hetgeen EM destijds (ruim 10 jaar terug ) als eerste (of tweede) heeft gemaakt.

Werny,

Volgens mij kan hetgeen wat Wouter voorstelt (opsplitsen) bij jullie niet. Immers, je zult toch delen in je MES systeem hebben die daar niet tegen kunnen ? of ? ...

Ik weet het niet zeker, maar vraag me af of dit wel juist is (opgelost);

*Of* het is formeel zo dat het Adres (zonder Huisnummer) formeel (zie KPN) 30 posities is, *of* dit is zo inklusief het Huisnummer;
Indien het eerste, dan e.e.a. s.v.p. konform aanpassen.
Indien het laatste, dan lijkt het me dat de goede oplossing onbekend is, en kan niet (formeel) worden bepaald hoe "leesbaar" het Adres moet zijn.

Daarom lijkt het mij dat het laatste niet aan de orde kan zijn.

Merk verder op dat er wellicht iets heel anders aan de orde is, waarbij het immers zo is dat (wat mij betreft) het Adres formeel 17 posities is. Hoe je dan ooit (inklusief Huisnummer) op 30 posities kan komen is mij een raadsel.
Ik heb eerder het vermoeden dat hier iets met het niet-Postadres wordt gedaan, waarmee niets hoéft te worden gedaan. Hoefdè.
Merk voor wat betreft het laatste op dat een niet-Postadres zo informeel is als het maar kan, c.q. (!) dat je met het Postadres alles moet kunnen doen wat maar is gewenst.

Al met al zal ik er wel meer woorden aan vuil maken dan nodig is ...

Zelf ben ik zo vrij om te denken dat de kans dat juist dit de dubbele Verkoopordernummers heeft opgelost, gering is (n.b. : zonder zelf in de coding te kijken). Met andere woorden :

Als dit niet zeker is, dat pleit ik ervoor om nu *standaard* dit sluiten en weer heropenen niet meer te doen;
Gaat het daarna weer fout, dan uiteraard terug aanpassen.

N.b.: Een bettreffende "het gaat weer fout" betekent niet veel meer dan wat ongemak voor een betreffende klant, met het "risiko" dat alles er veel veel sneller van wordt. Ofwel, het is het proberen zeker waard.


PS: Ook als kan worden bepaald dat het betreffende optrad onder VFP7 terwijl we nu onder VFP8 draaien, mag wat mij betreft de poging worden ondernomen.

... Vooralsnog is het de vraag in hoeverre dit type Voorraad de Behoeftebepaling onjuist beïnvloedt c.q. moet (vooralsnog) aandacht worden besteed aan het dusdanig inrichten dat betreffende Lokaties niet meetellen voor bruikbare Voorraad (Geëxcludeerde Magazijnen !).