Jawoor. Dus nou is het Fax, en hoeft er weer geen kontaktpersoon + faxnummer op ?
Ik geef het op hoor.

Om te beginnen die de post die je intussen al gelezen zult hebben : Re: Keuringsrapport ook meertalig voor keuringsvoorschriften?.



Fijne konklusie, maar ik zou het zo niet willen.


Snap ik dit ? ... niet echt.

Nou ja, ik ben wel begonnen met typen, maar eigenlijk kan ik er niet verder mee.

Na telefonisch overleg blijkt dit wat anders in elkaar te zitten dan het leek :

1. Produktieorder wordt gegenereerd volgens de Receptuur. Hierin bevindt zich de grondstofbehoefte volgens "norm".

2. Op basis van de verwachte hoeveelheid Output wordt de PO hergegenereerd (hoeveelheid grondstoffen wordt mee-aangepast.

3. Bij 2 wordt de typefout gemaakt. Daar wordt 30.000 ingetypt i.p.v. 100.000.

4. Na (tijdens) produktie wordt het werkelijke grondstofverbruik afgeboekt. Dit is dus ruim 3 x hoger dan de "norm" op dat moment aangeeft (de gebruiker had hier al een rode lamp willen zien, want zelf zet 'ie 'm niet aan).

5. Als de output klaar is (gedroogd, een dag later) wordt de output opgeboekt. Dit gebeurt 1e en 2e keus, en elk van die regels is niet direkt gerelateerd aan de ene "norm" regel die op 30.000 staat. Hier wordt de 93.000 resp. 7.000 ingetypt. Ook hier had bij de gebruiker een lampje moeten gaan branden (die dus het liefst automatisch moet aangaan).

... en als klap op de vuurpijl doet het systeem het dan ook nog eens fout. Immers, je zou toch zeggen dat de totale opgeboekte hoeveelheid van 100.000 ook in de header zou moeten staan. Daar staat echter nog steeds de 30.000. Gevolg : kostprijzen onjuist.

Op National Geografic heb ik gezien dat een ongeluk eigenlijk nooit door één oorzaak ontstaat. Dat lijkt me hier wel op van toepassing.

O nee ?


Jawel, dat snap je dus wel. Het betreft alleen een omgeving die je even niet kent;
Menno zegt het ook al (doch vergeet het te benadrukken) : die module is net zo goed bruikbaar (en ook bedoeld) voor produkt specifikaties. En zéker in dat andere topic heb je het daar over.
Zie het maar zo :

Produkt specifikaties ontstaan feitelijk na Keuren. Althans, als je "specifikaties" in deze even niet ziet als te stellen eisen (laten dat je Keuringsvoorschriften maar zijn). Nadat dus alle specifikaties van een produkt bekend zijn, kun je deze afdrukken op een "specifikatie blad". In de gevaren wereld noemen ze dit in de wandelgangen een Material Safety Data Sheet, maar dat is kwa bedoeling hetzelfde als bijvoorbeeld de "specs" op een pot pindakaas (immers, ook dat behandelt feitelijk gevaren).

Je ziet dus dat uit het Keuren de specs volgen, en dat de specs kunnen worden bijgehouden in de SafetyData module. Dit is ook letterlijk waar, want de specs die uit Keuringen volgen kunnen terechtkomen in de Eigenschappen op een Charge, en daarvan maakt SafetyData weer gebruik (maar, Eigenschappen zitten all over ze place, bijvoorbeeld ook op Artikelgroepen ... ... zie weer andere topic).

Eén niet onbelangrijk linkje mis je nu nog, namelijk het gegeven dat de SafetyData module die specs ook kan berekenen. Dus, als jij nu maar netjes bijhoudt wat er allemaal in je grondstofjes zit, weet die module later wel of het geschikt is voor een diabeet.

De werkelijke crux, en daarmee het antwoord op je vraag (ook al stel je die zo niet letterlijk) is dat dit hele systeem aan specifikaties (overigens de grootste module uit het hele pakket) tot in de puntjes kwa "document" door jou zelf kan worden samengesteld, en dat de gegevens erop voor een goed deel door het systeem worden bepaald, en waar jij wilt uit vaste (ongelimiteerd grote) teksten bestaat. Bijvoorbeeld de tekst uit de Artikelgroep (die je dus ook alleen op dat niveau definieert). En dit alles uiteraard (haha) in de taal van de ontvanger (wat in deze module nog iets anders is als de taal van het land, immers, de kopert MOET het kunnen lezen, want het betreft "gevaren").

De module is zo groot dat ze nooit wordt meegenomen bij de standaard inrichtingsdagen, ook omdat je feitelijk zelf bepaalt hoe mooi je het wilt inrichten, en hoe mooier hoe meer tijd het kost om uit te leggen. In dit bestek is het dan ook werkelijk onmogelijk om duidelijk te maken hoe je ermee zou kunnen omgaan. We beginnen echter wel te herkennen dat je deze richting op zou moeten, en dat heeft (echt waar) niets met die talen te maken.

Misschien heb je hier nog iets aan : het deel "produkt specifikaties" uit de SafetyData module zoals bedoeld voor de food, is ontstaan bij een club die bakkerij benodigdheden maakt.

Laat ik voor nu maar met het volgende eindigen :
Ook dit is output van die module : geen brief, geen fax, geen email maar een webpagina. (layout kan je dus maken zoals je wilt).

1. en 2. : 2 uur.


1 uur, plus er rekening mee houden dat je landscape zult moeten (gaan) printen.
Layoutvariabelen zijn niet meegenonen (want onbekend); weet ook even niet wat je daarmee wilt.


Nog even niet, want je hebt geen email adres(sen) "Keuringsrapport".

EDI lukt wel met een uur of of 6.
Her "direct" moeten we dus iets voor verzinnen, waarbij je er rekening mee moet houden dat je (de gebruiker) toch zelf op een button duwt.

Fax moet je als redelijk onmogelijk zien. Zie ook hier : Re: Wijze versturen Keuringsrapporten registreren en kontaktpersonen daarvoor.

Ten eerste, er is geen reden om de differentiatie fax/email niet voor verschillende Afleveradressen (van een Debiteur) anders te kunnen hebben (lees : beiden moeten toch worden onderkend, dus sta beiden ook toe bij één Debiteur).

Dan, emailen aan meerdere personen is geen probleem, maar het is wel zinvol om een "Aanhef" weg te laten. Merk ook op dat een Keuringsrapport geen brief als zodanig is, en het gegeven dat een geadresseerde het ontvangt wel voldoende is, lijkt mij.
Maar, omdat het Keurigsrapport (waarschijnlijk) een bijlage in de email zal zijn, zit je met de body van de email, en daar zou je toch iets in moeten zetten. Is dit inderdaad enorm gewenst, dan wordt het hierdoor siginificant duurder. Echter :
Voor de juiste interpretatie hiervan, zie ook het volgende aangaande faxen;

Het willen faxen is verre van handig. Immers, dit vereist een omgaving die dit ook kan (technisch) en daarbij komt van alles kijken wat praktisch iedereen tot op heden heeft weten te vermijden;
Om te beginnen word je gekonfronteerd met een interface naar de fax (driver) en waarvan we er momenteel slechts één onderkennen. Denk bijvoorbeeld (maar ook als belangrijkste) het moeten kunnen oppikken van het telefoonnummer ergens vandaag, en wat de meeste fax software niet zo maar doet (een popup geven waarin je zelf e.e.a. kunt intypen kunnen ze allemaal wel).
Dus, wil je automatisch kunnen faxen, dan ben je gebonden aan wat wij daarvoor ooit hebben ontwikkeld, en ik vraag me zelfs af of die software nog wel bestaat. Daarna is het simpel : zo'n interface voor nieuwe (lees : andere) software ontwikkelen komt je al snel op een week, voorafgegaan door alle dagen die zijn benodigd om software te vinden die alles doet wat je wilt.
Het is ditaangaande ook niet veel anders als het PDF geneuzel : als je wilt dat de fax (aan de andere kant) de boel enigszins uitspuugt zoals je had bedoeld, dan ben je nog niet jarig met zoeken naar die software (maar, voldoet/bestaat dat ene pakket wat wij onderkennen nog steeds, dan ben je klaar wat dit (de hele interface) betreft).

Gouden tip aangaande faxen is sowieso : probeer klanten die fax uit het hoofd te praten.

Lukt dit niet, dan zie je dat je omwille van het faxen plots sowieso de kontaktpersoongegevens nodig hebt, waar dit bij emailen slechts email adressen betreft die je -zoals gebruikelijk- gescheiden door ";" in een stringetje kunt opgeven. Niets van dit alles bij faxen, waar je immers de kontaktpersoon adressert middels het telefoonnummer en daarnaast een (voor de ontvanger) begrijpelijke naam.

Het laatste is op zich betaalbaar als je *dat* bij 1 (Kontaktpersoon) houdt.

De ellende gaat bij faxen voort als je ziet dat je -ongelijk email- echt moeite moet doen om een bestaand dokument "Keuringsrapport" moet integreren tot één dokument dat wordt begrepen door een fax-verzend geval. Ofwel, daaraan moet software matig iets gebeuren, waarvoor je maar een dagje moet rekenen (dit dagje treedt domweg niet op bij emailen).

Verder :

Je zou kunnen bedenken dat alles redelijk makkelijk oplosbaar wordt door te volstaan met een indikator "wat" de klant wil hebben (fax, brief, email). Technisch is dit juist (stelt niets voor) maar procedureel ga je hier nou net de mist in (verwacht ik). Immers, wanneer moet worden duidelijk gemaakt dat iemand de brief/fax/email in elkaar moet gaan knutselen ? Ga het zelf maar na : als het net te laat is, of het lukt helemaal niet. Alleen het Levermoment leent zich ervoor (Rapen zou ook nog mogen) en niemand zit er bijvoorbeeld op te wachten dat je dit dus meteen moet doen (wanneer het ook later mag) dan wel het gele briefje hanteren om het later niet vergeten te zijn. Dus let wel, hier ben je vanaf als het automatisch zou kunnen gebeuren, met hooguit nog iets van "gaat et de zending mee" als aandachtspunt (-> is vast geen email en ook geen fax, maar moet er in elk geval uitkomen samen met de Pakbonnen o.i.d.).


Emailen en brieven (de laatste 1 Kontaktpersoon per Afleveradres) lijkt me te realiseren in 18 uur.
Faxen is totaal onbekend, er vanuitgaande dat de software die wij ondersteunen niet meer bestaat, of anders een dusdanig andere interface kent dat we opnieuw mogen beginnen (denk voor de lol aan een uur of 40 daarvoor (totaal 58 dus), dan weet je het een beetje).

Als laatste :
De software die wij onderstenen heette ooit QP-Fax (en ooit is bijna 20 jaar geleden) waarvan ik in elk geval weet dat de naam intussen is veranderd (jaar of 8-10 terug ?) en het kwam uit Leeuwarden. Misschien kan je zelf achterhalen in hoeverre het nog wordt geleverd.


Ik heb nu even mijn best gedaan, en wil daarmee niet zeggen dat ik er ook klaar mee ben. Ik ben alleen even niet aan de beurt ...

Johan, ik weet niet of dit de beste reaktie is, maar ik kom op weinig anders :

Verlengde Teksten (en de manier waarop die in elkaar zitten) zijn "raar". Het *zijn* uiteindelijk ook geen verlengde teksten, maar teksten per taal. Inderdaad, binnen de SafetyData module vind je dat overal terug, is zo ook genoemd, en is precies waarom je eigenlijk vraagt. Dat het daarnaast zo is dat SafetyData en Keuringen behoorlijk verwant zijn, is dan nog iets anders.

Met voorgaande als overweging(en) is het onmogelijk omdat voor jou - in die hoek - erbij te maken. Daarnaast zou je net zo veel kwijt zijn als dat de module SafetyData kost.
Anders gezegd, je dient die module aan te schaffen, waarbij wij hier alleen nog het volgende probleem hebben :

Hoe integreer je die module (of beter : de hier gewenste faciliteiten) met de Keuringen; dit is heel slecht te overzien, en wel dusdanig dat ik er liever niet eens aan begin. Maar ja ...

Misschien dat we van alles af zijn als ik jou eerst de prijs noem voor die verschillende talen (en of dit Verlengde Teksten zijn of gewoon "bla bla per Taal" maakt niet uit) : 3 x TV/WY/VW/RA = 66 uur plus het echt laten werken (ruim 10 uur denk ik).

Zeg gerust dat je dit veel te duur vindt, en we zijn klaar.

?

Andries, ik ben geneigd om dat in de context van Analyse Certificaten te plaatsen (lees : jullie maken m.i. helemaal geen Keuringsrapporten anders dan die Certificaten). Als dit juist is, is jullie wereld net iets anders ...

In het stadium van het zo ongeveer kunnen gaan inlezen van de orders.
Het grafische deel is (relatief gezien) op een oor na gevild.

Nou moe, ik heb toch EDI zien staan in jouw eerste post ? zeker gedroomd ...
Sorry.

Aangaande EDI : ik zou denken van wel ja.
"Direct" is dan nog iets wat ik me momenteel afvraag, maar wat ook komt doordat je in principe niet weet wanneer dat "direct" dan zou moeten zijn (dit, gezien de formele status "Order is volledig ingevoerd" die wij niet hanteren).
Maar daar is dan wel iets voor te maken zou ik denken.

Dinand, je moet hier toch eens over nadenken, maar dan in een wat andere context dan Normatief Afboeken zoals Wouter het bedoelde;

Ik denk dat de procedure die je toepast zich ervoor leent om een soort "kontrolerend" (inderdaad) voorloopscherm te hebben wat erop toeziet dat je e.e.a. alleen kunt invullen zoals het bij jou consistent moet werken. E.e.a. wordt (denk ik) uitgelokt doordat je eigenlijk altijd die output opboekt onafhankelijk van hoe het is voorgekookt (i.v.m. 1e en 2e keus) terwijl het systeem in principe toestaat dat je meer opboekt dan dat de grondstoffen toestaan, maar wat (alweer, denk ik) in jouw geval niet zomaar valt af te leiden uit die grondstoffen.

En ik zeg het maar even (ook voor iedereen hier) : e.e.a. zo maar relateren aan bijvoorbeeld de oorspronkelijke hoeveelheid output (in stuks ?) zal moeilijker blijken om goed te krijgen dan we willen, wat m.n. komt door alle kontroles die er al in zitten, en die feitelijk gerespekteerd moeten blijven worden. Die kontroles zou je dus vóór kunnen zijn, en dat doet zo'n voorloopscherm wellicht.

Je mag nog wel even vertellen wat voor een "soort" fakturering je gebruikt c.q. op welke wijze je verzamelt àls je al verzamelt (denk ook aan Weekfakturering). Doe s.v.p. ook maar een schermkopietje van LOUFGN, wat representatief is voor hoe je ALTIJD faktureert (lees : niet zelf iets knutselen, maar het de betreffende gebruiker even laten voordoen). Als er een voorbeeld aankomt met ingevuld Debiteur-ID (van t/m) dan wil ik daar graag uitleg over.

N.b.: Bovenstaande is niet benodigd om erachter te komen "waar" e.e.a. moet worden ingebouwd, maar om erachter te komen of het wel gaat werken ...

Mocht ik er tijd voor hebben, dan zal ik er toch nog eens naar kijken.
Het is in elk geval aardig knullig zo.