Ok, mooi !
Het zal dan voor de rest ook wel goed gaan (ik zou niet weten waar het nog fout kan gaan), maar houd het wel even in de gaten.

Ik zou maar oppassen (Wouter) ...

Dit is niet gemaakt voor "zo maar gebruik" binnen Profit. Vraag me niet wat je er allemaal voor moet gebruiken c.q. inrichten, maart ik wil niet dat we hier zodirekt eeuwig bezig zijn om iets te maken voor iemand die het toevallig wat anders toepast.

Zie de Help van de Rubriek ...

(Hierarchische Artikelgroepen, Webshop enzo ...)


PS: Wat niet wegneemt dat het vast kan worden gemaakt voor de normale omgeving (als dat als niet gewoon kan !). Maar dan tegen $ hier en daar.

Twee antwoorden / reakties:

1.
Het Via Assortiment is uietraard weers eens speciaal gemaakt voor iemand die het wilde laten werken zoals het nu werkt Groepsdebiteur bepaalt assortiment).
Dit houdt niet in dat het niet anders kan. Kwestie van een Bedrijfsparameter (4 uur) en wat coding aanpassen (3 uur) en het doet wat je wilt (Assortiment van Groepsdebiteur wordt dan domweg nooit gebruikt, al vul je het 100 keer in).

2.
Dat het lijkt te werken via Esc is denk ik een fout. Is gewoon niet zo bedoeld (ook hier : denk ik). Maar goed, je kiest dus eerst iets om daar toch weer uit te gaan (Esc) om vervolgens langs een heel andere weg te gaan die al niets meer met Via Assortiment te maken heeft. Op zich mag dit denk ik ook, omdat de betreffende klant "Via" en "normaal" door elkaar gebruikt, al weet ik nu even niet hoe "normaal" is in dat geval. Is ook niet belangrijk.

Nou, dus dit was alles ?
(komt die aanpassing in de kop er dus ook niet lijkt me ! (??))

Ok, duidelijk (maar ook logisch hoor).

Laten we eens verder kijken, en ook dit nog eens tot ons nemen :


Dat zei ik dus al, en daar zijn we het denk ik ook wel over eens.
Punt is nu een beetje : ik word gehinderd door de kennis van Profit en weet dus de mogelijkheden en onmogelijkheden. Jij (nog) niet, en dat is ook moeilijk. Maar zo kost als mogelijk samengevat : ga werken met Scanners en dit werkt allemaal.

Het lastige hier is dat
a. je moet behoorlijk anders gaan werken (m.n. op de vloer);
b. de funktionaliteit van alles wat intussen voor de vloer is gemaakt vind je niet elders in Profit. Het is een kompleet nieuw systeem eigenlijk.

Mijn "dicht erop zitten" wordt uiteraard gerealiseerd middels het Scannen (je beheert alles dan 100% in realtime), maar :

Dit dicht erop zitten is eigenlijk geen echt "doel" om e.e.a. voor jou te laten werken; het is een middel. Niet zo gemakkelijk uit te leggen, dus maar een klein voorbeeld uit andere hoek : als je 100% goed *en* automatisch wilt weten welke charge je aan wie hebt geleverd, moet je scannen gebruiken. Niet omdat het zo lekker realtime is, maar wel omdat je domweg scant wat je doet (wat op zich realtime gebeurt). Het middel is de Scanner, en het doel het het "goed leveren".

Nu krijg je de volgende mogelijkheden voor je kiezen : Omdat je alles meteen registreert, kan je daar ook ongestraft mee doorgaan. Ik bedoel, je hoeft niet eerst ergens forumulieren in te vullen en dan ook nog eens te laten verwerken in het systeem, ofwel, dat gaat je niet tegenhouden van welke additionele logistieke stap ook. Je bent eigenlijk geheel vrij is het kiezen, en als argument hanteer je alleen de handeling met het produkt zelf.

Maar goed, punt is : dit zit er allemaal al in, en je moet er niet op rekenen dat we dit zonder Scannen ook nog een keer gaan maken (maar dan werkt het ook niet -> te veel extra handeling aan jouw zijde).

Eigenlijk ben ik je dus een totaal anders werkwijze aan het aanpraten, maar die is ook best wel goed hoor. Kan je je grafische planning ook weer eens uit de kast trekken, want dit onderdeel wordt zelfs daar in ondersteund (trefwoord : Lever/Dokplanning, Buffer Lokaties).

F2 ?
(wel eerst voldoende invullen in de Header, dus, stukkie naar beneden enteren)

Dit zeg je vast niet zonder reden ...

?

Ok, voordat ik met andere ($) oplossingen kom - wacht even ...

Wat je dus bedoelt is dat al die schermpjes blijven staan eh ? Dus voor mijn duidelijkheid : als je vanzelf verdwijnen is het eigenlijk opgelost ?

Beetje laat ... Sorry.

Ik denk dat het (intussen) verstandiger is als je eerst laat weten wat je wilt; wij hebben "tig" van die Webshops nu, en ze gedragen zich allemaal anders. Dus, wat wil je dat een klant ermee kan, hoe wil je dat die bestelt, betaalt, fakturen (enz. enz.) ontvangt. Ennehh, ben je hier wel op voorbereid ?

Ik weet het, je moet ergens beginnen, maar om zoiets op te zetten moet je redelijk serieus zijn en er tegenkunnen dat je meer verkoopt, afhankelijk van de opzet. Dus bijvoorbeeld : de opzet kan ook zo zijn dat je alleen je normale klanten ermee bedient; dan verkoop je helemaal niet meer (ook weer opgelost ). Maar ... ik zou eerst maar eens onderzoeken of je wel één klant hebt die via de Webshop zou gaan bestellen (met de suggestie : niet één). Wat dit betreft, denk ook eens na : zouden jullie dat zelf graag doen ? ik vermoed van niet ...

Wat je vergeet is hoe het heet,
wat je moet doen is nog van toen.
Wat niet niet zegt is hoe het belegt,
wat je niet deert is ... wat je niet leert.

Ofwel, uitslag ?

Dat die Sorteercodes niet uniek zijn zal expres zijn. Dus, daar tornen we niet aan, tenzij je er 4 uur voor wilt betalen voor een Bedrijfsparameter dit aangaande (dan kunnen de anderen blijven werken zoals ze wereken). Verder 0,5 uur voor inbouwen van de kontroles.

Die "print" kunnen we eenmalig voor je ophoesten (0.5 uur zeg maar), en nadat je bovenstaande hebt, is eenmalig ook voldoende. Wil je 'm toch regelmatig draaien (kan ik me voorstellen, gewoon, voor welke Sorteercodes er zoal zijn) dan wordt dit 5,5 uur. Dan heb je "enigszins" het voorgaande ook niet meer nodig natuurlijk.

N.b.: Ik heb niet naar de betreffende funkties gekeken, dus ik baseer me misschien iets te veel op wat je zelf zegt. Aldus hoop ik dat de reaktie een beetje juist is ...

Ik zou het even vergeten dat je hiervoor iets kan gebruiken wat er eigenlijk niet voor is gemaakt. Kan denk ik ook nooit met de "slome achteraf verwerking" dit je op best een aantal plaatsen aan de orde hebt.

Als je dit goed wilt doen dan moet je veel dichter op alles zitten en ook ècht weten wanneer iets de deur uit kan;
Als je meent dat je dat kan juist zonder dat je al hebt geraapt, dan gaat bij mij het licht uit. Lees : ik geef je geen gelijk.

Middels het laatse zeg ik niet dat je niet op deze wijze zou kunnen werken, maar wel dat je iets mist. Een logistieke stap.
Denk simpel : Op basis van deze print of wat dan ook, komt de vervoerder of deze komt niets (omdat je niets voor hem hebt). Dus uitgangspunt : speciale vervoerder voor betreffend produkt A. Je plant vandaag het leveren van A voor a.s. vrijdag. Rape nheb je geen zin in, dus het systeem weet niet dat A er is, dan wel dat A er is voor de betreffende order. Nu de hamvraag :

Hoe vaak zal de vervoerder voor niets op de stoep staan op vrijdag ? (ik hoop dat je de vraag begrijpt)

En zo "nooit", dan wil ik graag weten hoe je dat dacht te regelen via het systeem (wat niet betekent : ik bel de vervoerder wel af)

Johan,

Ik weet het niet. Dit soort dingen zitten gewoon niet goed in elkaar bij de gratie van dat het voor specifieke toepassingen (bij klanten van ons bedoel ik) is gemaakt; Bedenk eerst maar eens dit :

- Een Verkooporder kent maar één Afleveradres, toch ? raden waarom dat is.
- Een Verkooporder mag wel ook tegelijk Afhalen voor een regeltje hier en daar. Wel, dit noem ik ook een "afleveradres" (bij jou onder de brug zeg maar).

Dit klopt dus niet.
M.i. is de oplossing dat dit (Leveren/Afhalen) op Header niveau moet. Of in elk geval bij jullie. Krijg je wel twee Fakturen (tenzij je verzamelt natuurlijk).  Maar ja, bedenk maar eens hoe je anders iets als DKK-Vrachtkosten wilt toepassen op "ultieme" wijze met alles wat Profit in deze kan. Dat worden een stapeltyje beperkingen ...

Dus Leveren/Afhalen voor jullie op Header niveau. Is dit een domme gedachte ?
(en daarna krijgen we die print wel in elkaar geprutst, dat snap je ook)

Het probleem is dat je feitelijk twee Assortimenten gemixed wilt hebben, ook al heb je dat zelf nog niet even door. Dus bijvoorbeeld :
GROEPA : A, B, C, D, E, F
LIDGR1  : B, C, F

Dit moet dan worden opgelost door bij LIDGR1 aan te geven dat A, D, E er *niet* zijn (exlusive). Dit hanteert dus het uitgangspunt dat als er niets wordt gezegd over een produkt, het er wel is (anders is het te "redundant").

Maar ja, nu zeg jij natuurlijk dat dit ook moet kunnen :

GROEPA : A, C, D, E, F
LIDGR1  : B, C, F

wat inhoudt dat LIDGR1 een extra B toegevoegd moet kunnen krijgen. Wel, dit zou ik niet doen, want het zal niet manipuleerbaar ziin.

Om dit technisch in elkaar te draaien moet je rekenen op een 26 uur en dan heb je het laatste voorbeeld ook erbij.
Als het met name bij het laatste voorbeeld ook goed inzichtelijk moet werken (en daar zou ik maar Ja op zeggen als ik jou was) komt er gerust een 8-10 uur bij.

N.b.: Waar je volgens mij de mist in gaat, is dat je een Assortiment op de Groepsdebiteur hebt. Dit lijkt me dit/jouw geval niet terecht. Dus, laat je dit achterwege, dan werkt het nu al - eh, bijna denk ik. Want, er zal nog steeds iets moeten komen dat het Assortiment van de Groepsdebiteur links laat liggen als een lid een ordertje plaatst. Dit, aannemend dat de Groepsdebiteur zelf ook wel eens een bestellinkje doet. Als dit laatste niet het geval is werkt het nu 100% (bij veranderde inrichting).

Reageer maar weer eens ...

Overigens had ik intussen nog bedacht dat dit "Recall" heet in meer officële termen.

Probeer eens

MyBat.bat >weg.txt

Ik weet niet hoe dat bij jou uitpakt, want het hangt een beetje van het begin van het "proces" af. Maar probeer eerst dit maar eens en laat weten wat er gebeurt.