Marco, dank je voor je uitgebreide antwoord. Helaas zie *ik* niets nieuws, maar misschien dat andere gebruikers het wel begrijpen.

Zou het niet handig zijn om hoe jij werkt op z'n merites te beschrijven ? Al dit relatieve gedoe zegt m.i. niet veel mensen iets.

Iets van

1. Ik maak een Produktie Order.
2. Ik lever die Order.
3. Dan druk ik op een knop en dan komt "het" in Chemches terecht.
4. Daarna begint m'n printer te rammelen, en komt er zus en zo en dit en dat uit.
5. De gegevens op m'n vrachtbrief zijn ook puik in orde, want ...

Maar dan met detail waar ik zelf iets mee zou kunnen, en dan maar denkend dat de rest het zeker moet begrijpen.
Als je dan ook nog even wilt voelen dat ik denk dat het voor een ander niet werkt omdat jij dingen in Profit bijhoudt waar een ander geen behoefte aan heeft, dan kan je daar misschien de nadruk op leggen, zodat een ander dat ook kan beoordelen (wordt niets, dan wel dan ga ik dat beetje gegevens nog wel bijhouden en ben ik overal vanaf).

Ik wilde het daarstraks al toelichten, maar dacht dat je het wel zou weten. Ok, nu dan :

Nee, zo werkt het niet helemaal. De datums (of eigenlijk berekende dagen op basis van doorlooptijd) die je nu ziet, zijn allemaal produkt gerelateerd. Dus, inkooptijd van 10 dagen, en jouw inkoopdatum komt 10 dagen eerder te liggen dan je (betreffende) Behoeftedatum.

Dit heeft helemaal niets met de produktieplanning te maken, ook al zeg jij 100 keer dat de produktietijd 3 dagen is, die er alleen maar voor zorgt dat de inkoop 3 dagen eerder gebeurt dan de leverdatum (ong., je snapt dat wel).
Dus, voor de verdere keten zeg je "3 dagen", en voor produktie zelf geldt je Receptuur (en dus de Plankritische Bewerkingen).

Wat er nu verder gebeurt (of behoort te gebeuren) is dat doordat jouw produktieorder 6 dagen vergt a.g.v. de hoeveelheid, ermee moet worden begonnen 6 dagen voor de leverdatum (ik laat jouw 1 extra dag even weg). Dat doe je dus feitelijk al door de order "langer" te slepen zodat ze 6 dagen gaat duren. Verder naar rechts mag niet (want Leveren), dus dan maar naar links.
De Startdatum wordt nu (in Profit !) 6 dagen voor de Finishdatum,en je Behoefterun gaat met een beetje geluk op -16 dagen inkopen (levertijd is weer 10 dagen). Dit is niet anders als je al kent, en alleen het veranderen van de Startdatum is dus wat via de planning gebeurt.
Zelfs de jouw bij het Artikelmenu opgegeven Produktietijd doet niets meer, want die bewerkstelligt slechts de "in eerste aanleg" Startdatum, die dus DAARNA door de planning wordt aangepast. Schuif de hele order 20 dagen naar links, en de Startdatum neemt met 20 dagen af.

Snap je ?

Marco - goed geslapen ?

Wat maak je er nou toch voor 'n verhaal van ? Als ik zoiets lees stel ik altijd voor dat ik de volgende keer eerst meer gedronken moet hebben om het te begrijpen of mee eens te zijn ...

Maar voor de goede orde :


Als we dit buiten de verdere context trekken is het domweg waar. Wij zijn geen laboranten c.q. opgeleiden in die richting, en hebben uiteraard niet iemand in dienst om die hele soepzooi (want dat is het) bij te houden. Tel hierbij dat dit aan "jullie" kant veelal ook al niet het geval is, en er gebeurt gewoon niets meer. Zelfs als je erge je best doet (Marco) is er nog steeds niet uit te komen, omdat we samen alsnog voor betreffende aspekten de antwoorden niet kunnen verzinnen, of wij ze in elk geval (!) niet krijgen. Het forum is daar hier en daar wel getuige van, met ook no weer zo'n ("1 juni") onderwerpje pending.

Wat feitelijk erger is -en waarom ik vindt dat jullie er goed aan doen om niet meer van betreffende (zie verderop !) Heart funktionaliteit gebruik te maken, is dat ik zie/claim/weet dat er zaken domweg onmogelijk zijn. Ik ben daar nu vanaf. Ja, ik heb het maar even vet gedrukt, en ik doel dus op zaken die niets met Heart te maken hebben, maar zaken waar jullie aan moeten voldoen, en die "ik" voor elkaar zou moeten zien te krijgen - met dus de wetenschap dat dat niet kan.
Mijn moraal : laat maar lekker over Chemches et al lopen, en je kan bijna zeggen dat jullie het dan ook niet hebben gedaan (wie wel ? we gaan het zien).

Over dat vetgedrukte ... er is bij deze dus ook niemand meer die MSDSen in Heart *wil* maken (ook hier, zie verderop), en samengevat moeten we daar allemaal blij mee zijn. Ik vooral, waar ik de oplossingen niet zie (opgelegd door regelgeving die iedereen (jullie (heel algemeen als bedrijven) uiteindelijk ook - heel indirekt) wel even goedkeuren). Niemand gaat dit ook meer doen, want ik sta het niet toe ...

Dit alles gezegd hebbende ... dit hèb ik alleen maar gezegd als een soort van uitleg van Marco's tekst, die op zich niets te maken heeft met de vraag van Jim. Het waarom van die tekst ontgaat me aldus, ook al is ze feitelijk waar en terecht. Toegelicht dus.


Terug naart de vraag van Jim;

Je zou kunnen zeggen dat de reaktie van Marco een goede is in de zin van "nuttig voor Jim", maar zo is 'ie niet helemaal, denk ik.
Laat ik in deze ook maar eens verwijzen naar het onderwerp van dit topic, wat toch echt wel gaat om het in Heart weer binnenhalen van diverse gegevens vanuit Chemches. Jim weet dat denk ik wel, maar Marco's antwoord anno Juni 2011 gaat intussen uit van het voor hem ontwikkelde maatwerk door Chemches, wat even niets heeft te maken met het door ons ontwikkelde maatwerk om juist vanuit Chemches terug te lezen. Of Marco dit zou kunnen gebruiken ontgaat mij op dit moment (maar zie eerdere posts over de labels), en of het geheel te kombineren is to iets wat Jim wil - dat weet ik op dit moment niet, maar ik zou niet weten waarom niet.

Wat (denk ik !!) wel een onjuiste aanname is, is dat je vanuit Heart MSDSen zou blijven maken. Dit namelijk, zal te maken hebben met het moeten bijhouden in Heart van weer alles wat onmogelijk wordt geacht (zie Marco's tekst en mijn reaktie daarop hierboven), terwijl ik toch zou denken dat die dingen wel ergens uit Chemches komen rollen. Hier ga ik dus vanuit op dit moment.
Wat echter een heel ander verhaal is (maar toch het onderwerp van dit topic) zijn de labels en verdere gevarengegevens die je nodig hebt voor vrachtbrief enzovoort. *Die* komen dus terug uit Chemches, mits je dat maar domweg gebruikt (de interface is er). Om te weten wat je daar precies mee kan en hoe alles verder kombineert zonder maatwerk voor Marco, moet je bij Johan D. terecht.
Je hebt wat mij betreft dan alles binnen Heart wat nodig is voor je paperassen inklusief labels, en je hebt zelf toch niets bijgehouden (onderhouden) want dat doet Chemches.

Niet om het onnodig wazig te maken, maar meer omdat ik het niet kan volgen : waarom Marco die maatwerk interface met Chemches nodig heeft weet ik niet eens precies, ook al zou ik het denk ik wel moeten weten. Merk in elk geval op dat Marco (voor zover ik weet) nog nooit een MSDS uit Profit heeft laten komen, dus daar kan het niet om gaan ...
Niets terug laten komen uit Chemches in Profit ? ... ik snap al lang al niet meer waarom Marco dat niet doet. Maar ... wat ik wel snap (hoop ik) is dat Marco voor z'n produktieomgeving zelf weer zaken in Profit bijhoudt die anderen domweg niet nodig hebben (of dat in elk geval vinden) waardoor het wat mij betreft zo is dat Marco wellicht die gegevens uit Chemches in Profit wel zou kunnen gebruiken, maar hij het al lang zelf weet bij te houden - en dat mag zo blijven (ofzoietsofzoietsofzoiets).

Het echte belangrijke voor nu is denk ik dat
a. Je de MSDS via Chemches moet maken (c.q. je dit niet vanuit Profit moet *willen* omdat er geen reden voor is);
b. Je de transport enz, gegevens uit Chemches moet terugimporteren.
Ik heb dit zojuist nog geverifieerd bij Johan D.

Het lijkt me handig als Marco nog kan toelichten wat het voor hem door Chemches gemaakte maatwerk hieraan toevoegt, maar wat denk ik moet neerkomen op het printen van labels door Chemches, terwijl Profit dat ook kan. Zeker hierover kan ik niet zijn, vooral omdat ik niet begrijp hoe de rest die labels dan voorelkaar krijgt.

Ik zou toch denken van niet, omdat de Plankritische Bewerkingen e.e.a. juist bepálen.

Het probleem is dan ook (denk ik hoor) iets anders dan je beschrijft, en ook al komt er ergens een 0 uit, dit kan nooit door een doorlooptijd elders komen.

Wordt in elk geval spoedig opgelost.

Ik heb er net 10 minuten mee zitten stoeien, maar hier werkt iets niet (meer) hoor. Werkt gewoon voor geen meter. Kan wat mij betreft komen door een aanpassing begin dit jaar - ik weet het niet.

Wat ik wel weet is dat ik deze funktie liever zou weggooien omdat ze niet eens is gemaakt voor Vreemde Valuta.

Ik weet niet wat ik er mee moet, want aanpassen (voor goed algemeen gebruik) is niet mogelijk ...

Dinand, ik kan het maar moeilijk volgen. Wat je probleem is begrijp ik wel, maar hoe je het wilt oplossen niet. Bijvoorbeeld, eerst vergeet de Debiteur het faktuurnummer te vermelden, en daarna vind jij dat je "alles moet intypen" ? Deze laat ik nu even links liggen, want kreëert VOOR NU verwarring. Dus, gaan we later mee door.

Nu die andere ... Debiteur is een andere. Tja ...

Wat wil je hier eigenlijk, en hoe doe je dit normaal gesproken ? Ga je die ontvangst doodleuk op de verkeerde Debiteur boeken ?
N.b.: "Verkeerd" is vast wel een gerelateerde, dus het is niet verkeerd in de zin van "klopt van geen kant". Hier ga ik dan ook vanuit.

Volgens mij kan je niet zo maar een ontvangst boeken waar je geen order tegenover hebt staan, noch kan je de ontvangst boeken op een ander Debiteur-ID. Het laatste lijkt me evident, maar het eerste kon jij wel eens toestaan (lees : zo los je het nu op).
Ik vind aldus dat we wat dit onderwerp betreft eerst maar eens moeten uitzoeken wat hier wel en niet hoort/mag, om vervolgens de oplossing te bepalen. Oh, die zal je te duur kunnen vinden, maar dan hebben we in elk geval uitgewerkt wat er mogelijk is en/of nodig is - eigenlijk. En iets wat niet is toegestaan (inspectie e.d.) gaan we toch maar niet doen dacht ik ...

Hallo Berny,

Je mag die module proberen hoor (Profit-Fin-Betaal), maar ik vermoed dat we eerste te maken zullen hebben met die zaken uit dat andere topic. Bijvoorbeeld ... je zal die Debiteuren toch vaak nog niet in het systeem hebben staan (lijkt op Dinand's probleem) ?

Daarnaast verwacht ik best wel problemen met jouw klanten die maar een beetje wat doen met die omschrijving (9 van de 10 of zo) en dat werkt dat ook weer niet. Maar zeg dat zelf maar, want dat weet jij beter.

Ik vind het in elk geval wel een uitdaging om het aan het werk te krijgen, want als de wereld werkt zoals ze werkt, waarom niet (ook al lijkt het wat moeilijker). Maar vergeet ook niet dat je het eerst procedureel voor elkaar moet hebben, en dat heb je niet (andere topic).  Ik wil hiermee alleen maar zeggen dat het nu dus onnodig moeilijk doen is voor jullie. Tenminste, dat lijkt me toch ?

Goed, vragen voor nu :

1. Hoe vaak (aantallen en % graag) zit de Debiteur al in het systeem ?
2. Hoe vaak (idem) ziet de omschrijving er dusdanig uit dat het systeem er niets mee zal kunnen ?

Uiteraard. Ik weet alleen niet goed hoe je aan "eigenlijk" komt, omdat dit er eigenlijk best in zit. Alleen, met jouw testversie kan je sowieso niet exporteren ...

Ofwel, iedereen mag kijken, maar slechts één tegelijk kan wijzigen (slechts één ziet de "Exporteren" funktie aktief, die jij op dit moment standaard niet aktief ziet).
Hooguit weet ik op dit moment niet of dit geldt per Bedrijf. Dus, er mogen best 3 mensen Wijzigen (Plannen) als ze elk maar in een andere Bedrijf zitten.


Zie ook de Handleiding. Deze wordt steeds aangevuld (totdat ze klaar is ).
(maar stond daar als het goed is al in voordat je het vroeg)


Ja. Althans, deels. Het Exporteren.
Eerlijk gezegd ... we komen er naar aanleiding van jouw vraag op dat je wellicht niet wilt dat iedereen de planning kan zien. Tja, de rest (van Raadpleegfunkties e.d.) is ook autoriseerbaar, dus waarom dit niet.
We moeten alleen even diep nadenken wat hiervoor de meest handige methode is in deze.


Goede vraag, maar vooralsnog (!) houd ik het erop dat dit een typisch printje (ok, wat moeilijker) is zoals altijd. Ofwel, maatwerk net zoals ieder printje wat er niet in zit.
In breng dit op deze wijze omdat ik er op dit moment niet zeker van ben hoe algemeen dit kan worden gemaakt, en zo niet, hoe nuttig het is om iets algemeens te maken wat door niemand wordt gebruikt.
Je kan ook zeggen dat wij er niet erg vanuit zijn gegaan dat je hier iets print. Niet dat het de bedoeling is om het niet te doen, maar het geheel is natuurlijk wel bedoeld als het tegenovergestelde van het traditionele planbord. Merk in deze dan ook op dat er wel bijna expliciete voorzieningen zijn om het geheel zich te laten gedragen als een groot scherm aan het plafond wat continu automatisch wordt bijgewerkt. Het momentele echte voorbeeld hiervan je echter niet, maar bestaat wel ...


Vraag gerust verder, want het is voor ons zo'n beetje de eerste praktijk; we leren er graag van.

Ik heb ook een 20ct muntje opgestuurd, vandaar.

Goed. Afgesproken dat alle bedragen kleiner dan de ingestelde limiet automatisch worden doorgeboekt, en de grotere (of gelijke - of in elk geval waar momenteel de melding volgt) niet worden doorgeboekt. Die blijven dus gewoon staan. Ik zou zeggen : probeer er 1 melding van te maken (in plaats van 10 als het 10 te grote bedragen betreft) maar dat mag Dinand nog even belissen.

Let op :
Zonder te onderzoeken wanneer de melding nu precies komt, kan ik nu al stellen dat waar dit "onderwater batchboekingen" betreft (Voorraad Mutaties is volgens mij een voorbeeld), de melding nog mag blijven komen, maar het doorboeken aldaar *blijft* gebeuren. Immers, anders gaan er veranderende procedures optreden, dan wel kan het zelfs gebeuren dat men niet verder kan.

Afgesproken (ongeveer dan) dat het met een uur moet kunnen, en dat als het meer dan 1,5 uur dreigt te worden we eerst Dinand bellen.

Volgens mij moet je dit met DKK's doen, en wel een setje Opbrengst DKK die je gebruikt om de kosten door te belasten en een Kosten DKK om de kosten (financieel) te kreëren. Maar ja, dat zei ik destijds ook al (als ik het goed in m'n hoofd heb hoor). Die Opbrengst DKK heb je intussen via een Kostenartikel (wat je doorbelast) geregeld, alleen de Kosten DKK kennelijk niet. Als je die extra-comptabel wil houden kan dat, net zoals dat je DKK's kunt mee-rapporteren in je Statistieken dan wel kunt weglaten.

Vraag me even niet hoe je hier werkelijk mee moet omgaan, omdat je aansluitingsproblemen uitlokt. Immers, je hebt je werkelijke (transport) fakturen elders geboekt, waarmee je de marge weer naar beneden brengt. Nu echter ben je in staat om die marge nogmaals te beïnvloeden (theoretisch dan), en zelfs als je het extra comptabel houdt wordt het misschien een raar verhaal.

Dat ik het donkerbruine vermoeden heb dat je het hier niet over transportfakturen hebt maar helemaal geen fakturen, is iets anders, maar àls ik daar gelijk in heb kan je het denk ik vergeten (want je bent extra kosten of extra opbrengst aan het kreëren en over beiden betaal je extra belasting);
Als je wel degelijk normale fakturen er tegenover hebt staan, laat het laatste dan maar zitten. Heb je die niet dan weet ik wel zeker dat het nog wat toelichting behoeft (lees : het is voor nu even een belletje "voor het geval dat").

Dit doe je misschien het mooist met Voorraadgekoppelde Stuklijsten. Zie onder (bij het laatste scherm kon je middels Sh-F6). Aldaar zit wel een beetje help ook (Rubrieken).

Het algemene idee (in ultimo) is dat je je samengestelde produkt op een VORegel zet, maar er behoefte gaat bestaan aan zowel de shampoo en de spons (hoeft overigens niet 1 op 1). Allerlei tussenvormen zijn mogelijk, maar denk ik principe van het in het VVV kunnen zien van hoeveel produkt "shampoo fles + spons" je op voorraad hebt a.g.v. het aanwezig zijn van beiden (het geheel dus).

Met Artikel Sets lukt zoiets niet; je hebt daarbij alleen het generieke middel van het "hoofdprodukt" wat zorgt voor de VORegels (die stuk voor stuk voorbij komen waar je in eerste instantie het hoofdprodukt op de VORegel invoerde).

Zoiets ?

Oh, maar ik zeg niet dat ik het daar niet mee eens ben hoor. Wèl dat er mij net iets te veel gaatjes zitten in het geheel die aldus toestaan dat mensen die gaatjes uitnutten om het voor zover zij kunnen overzien legitiem te hebben voor zichzelf, terwijl dit soort voorstellen van ons - hoe goed bedoeld ook, want dat is het natuurlijk - ZAL leiden tot het (ook ongemerkt) dichten van die gaatjes, en daarna kunnen de betreffende bedrijven ineens niet meer werken en hebben wij het verknald.

Vandaar mijn reaktie, want ook dat laatste is de bedoeling niet van ons.

Geen bolletje, omdat ik niet tijdig de informatie heb gekregen die nodig is hier. Maar pending emails zijn hier ook "bolletjes".

Overigens "weet" ik dat ook pas sinds vandaag natuurlijk (01-06).

En dan heel eerlijk : Ik voel me wel verantwoordelijk om e.e.a. op tijd af te hebben, doe er zelfs m'n best voor om achter de info aan te zitten, maar ergens houd dat wel op. Dat blijkt dan eigenlijk vandaag.

266 produktieorders in de batchboekngen. Je boekt ze allemaal door. Het "filter" zorgt ervoor dat er 3 overblijven (want, bedrag te groot, weet ik veel). Tevoren heb je niets bekeken ... je hebt gewoon op F1 gedrukt.

Nu zie je dus 3 batchboekingen staan met grote bedragen;
Ik zou die temidden van de rest willen zien staan voor een mogelijk oordeel van "algemene problemen";
Zoals jij het wilt kan dat niet meer. Dan moet je heen en weer fietsen tussen batchboekingen en geboekte journaliseringen (die niet eens vergelijkbaar zijn).

Dinand, ik zal niet duidelijk genoeg zijn geweest. Zie mijn eerdere post ...
Ik bedoelde daar precies het konditioneel doorboeken (dank je Marco), maar waarna je in de batchboekingen (waar alleen nog de grote bedragen hebt staan) geen referentie meer hebt.
Dit lijkt me verre van handig.