O ... zo begrepen wij hem niet. Maar ja, het *is* ook niet zo. Alleen ... ga er maar vanuit dat als ik na een half uur zoeken er nog niet achter ben waar je dat instelt dat alleen Wouter het weet. Haha.

Hoe dan ook, de Layout zou dat moeten sturen wat mij betreft, maar zo werkt het kennelijk toch niet. Is ook iets ingewikkelder, want jouw Briefsoort "ENG" zou zo'n Layout moeten zijn, terwijl ik zou denken dat er "Briefsoorten" bestaan, maar *die* kan ik niet vinden.
Snappu ? nee natuurlijk.

In elk geval hangt het hier van de Briefsoort af of je de verplichting hebt een email adres in te vullen. Ofwel, de Briefsoort bepaalt of je een email gaat versturen, een brief de deur uit gaat doen, of een fax gaat maken.

Wouter moet je verder maar even vertellen waar je dat nou instelt; ik kan het niet vinden.

Eigenlijk al tijden. Alleen ik (ikke dus) moet een versie genereren die bij jou kan worden geïnstalleerd.
Ligt pas een paar weken op m'n bureau.

Nee joh. Ten eerste mis je dan alles wat in de toekomst wordt toegevoegd (door anderen zeg maar), en ten tweede ben je dan echt wel duurder uit. Niet omdat een keer kopiëren zo veel moeite is, maar omdat een eerste keer voor zo'n print diverse aanpassingen op hoger (aanroep) niveau behoeft. Is ook nog helemaal nooit gebeurd, behoudens helemaal in het begin voor alles wat naar een klant of leverancier gaat (en wat tegenwoordig via de Variabele Layouts gebeurt).

Die regels zullen wel (een keer) niet leeg blijken.

Maar goed, indien de ruimte er is (onder dat voorbehoud dus) mag het niet "zo maar" en zal het via een Bedrijfsparameter moeten. Sorry.
Totaal 6 uur.

Topic afgesloten wegens totale weigering om mee te denken.
Wat mij betreft van beide kanten.

Johan, zo af en toe is je disk vol ...

Kijk dan eerst maar eens naar de Ctrl-F2 toets bij een willekeurig printje; die stond er al een jaartje, maar tegenwoordig doet die ook iets.

Enneh, dat je PDFs automatisch kan opslaan op disk en zo ...
Of als Kontakt (alleen Variabele Layout prints)

Maar goed, van jou heeft voorlopig niemand last begrijp ik ?

Maar Bas ... Ik weet het niet helemaal zeker, maar het lijkt erop dat je "VeryPDF" nog niet gebruikt zoals wij het voorstaan ? Dus :
Als we als voorbeeld de Opdrachtbevestiging nemen, dan print je net zoals altijd. In dit geval of rechtstreeks uit een zojuist toegevoegde Verkooporder, of gewoon een reeks bij expliciet printen van Opdrachtbevestigingen. Middels Profit-Print-3 echter, wordt ervoor gezorgd dat wat naar de printer moet naar de printer gaat, en wat naar email moet, naar email gaat. Ehh ... lees : als je ervoor kiest dat de email moet gebeuren "van" een PDF, dan worden er dus automatisch eerst PDFs gemaakt, die vervolgens worden ge-emailed. Of er worden eerst HTML's van gemaakt, verder idem.

Uiteraard kan dit niet vanzelf gaan (hoe per klant) en dat moet je inrichten (het belangrijkste stuk zit bij de Kontaktpersonen).

Als je dit toch wel wist, begrijp ik kennelijk niet wat je bedoelt (zie quote).

Voordat Bas het zegt, zeg ik het wel : Gooi je voorbedrukte papier gewoon weg, dan kan je ermee werken.



Het lijkt me dat als je dit "normaal" benadert (zoals ik zojuist deed) je ook niet een redelijk krom verhaal nodig hebt om iets te verantwoorden wat niet te verantwoorden *is*.
Onder het voorbehoud dat ik het goed begrijp natuurlijk. Dat aannemend, zou ik er graag dit simpele verhaal van willen maken :

Het geheel van printen/emailen/PDF/PDF Emailen/HTML/HTML Emailen (enz. ?) was voldoende moeilijk om er "jaren" over te doen het op de rit te krijgen. Dat hebben we allemaal wel gezien (en wij vonden het *echt* moeilijk);
Het geheel zoals het er nu is, is ontstaan uit diverse kleinere stukjes en beetjes waarbij de betreffende belanghebbenden redelijk netjes allemaal hebben bijgedragen. De één misschien iets meer als de ander, maar zeg maar dat ik dat "leuk" en ook sportief vind zoals dit is gegaan. Waar mogelijk hebben wij zelf ook bijdragen geleverd, door iets net nog wat mooier of uitgebreider te maken dan we op voorhand konden voorzien. Maar, wat hier nu aan de orde is heeft niemand aan gedacht, en ook wij hebben het niet voorzien. Het geldt ook voor al dit soort dokumenten, en allen moeten ze separaat worden opgelost (denk ik). Aldus :

Waar dit (per dokument) moet worden opgelost, mag de belanghebbende ervoor betalen. Dat zou in dit geval SC zijn. Een ander voorziet hopelijk weer in het volgende dokument.
Makkelijker is het natuurlijk indien je helemaal geen voorbedrukt papier hebt, en kan doen wat Wouter voorstelt. Dus, daar hopen we dan maar op, want dat klinkt toch net iets vriendelijker. Maar anders ... anders zij het zo.

Ik hoop dat het zo even mag kwa antwoord, maar vooral dat je uit de voeten kan met Wouter's oplossing.

?

Ok. Laten we dan beginnen met mijn (!) konstatering dat het erg fout is wat je doet. Dus, nu ben je zelf van het onjuist opboeken van de PO afgestapt (erover uitwijden doe je verder ook niet), en dus ga je doodleuk artikelen veranderen. Let wel, dit is dus iets heel anders dan een foutje bij het opboeken van een PO wat je achteraf korrigeert.
Alles anders gezegd : je wilt gewoon gelijk hebben in dat het goed is wat je doet, maar van mij ga je dat gelijk niet krijgen.

Als je vindt dat produkten erg op elkaar lijken, dan zijn dat wat mij betreft "Alternatieven", en dat zit ook wel ergens diep ver weg in het systeem. Tenminste, dat dacht ik, en als dat niet zo is, is er wel een ontwerp voor. Maar ook als het wel zo is, moet er wellicht het e.e.a. worden aangepast. Dus stel :

Je hebt twee van die artikelen met ongeveer gelijke straal, en omdat je doet zoals je doet, stel je die twee als Alternatief van elkaar. Dit houdt in dat als de ene wordt gevraagd, de andere kan worden geleverd;
Aannemend dat dit er inderdaad in zit, wil je in dit geval dat de klant daar niets van merkt. Ofwel, op de Pakbon e.d. moet het oorspronkelijke artikelnummer staan, terwijl je in werkelijkheid het Alternatief levert (dus op de Raaplijst staat dat Alternatief). Het stuk "dat de klant het niet merkt" zal er niet inzitten, maar kan wel worden gemaakt; Vraag me op dit moment niet hoeveel moeite dat kost, en of het stelt niets voor (uurtje of wat), of het is veel moeilijker omdat de logistiek er aan hangt (dan kan het wel twee dagen worden).

Als je op deze wijze tewerk gaat, gaat alles gewoon zoals het hoort. Hieronder dus ook het leveren van een produkt met hogere Kostprijs dan bedoeld, met dus minder marge als bedoeld. Dit is iets anders dan zoals je het nu doet, waar je al niet eens hebt geleverd wat je statistieken zeggen. Sterker, het is zo krom dat het nauwelijks kan worden uitgelegd, maar ik vermoed zelfs dat je dit niet aan een belasting inspecteur moet duidelijk maken (het "overboeken", met hoe dan ook financiële gevolgen).

Dat je hiermee juist je PO onjuist opboeken niet oplost ligt aan jezelf, want ook dat schijn je onvoldoende belangrijk te vinden om uit te leggen, ook al vraag ik er twee keer naar.

Je bent heus de baas hoor, maar iets maken wat meewerkt aan onjuistheden doen we gewoon niet. Je probleem oplossen doen we daarentegen wel, al kost het soms wat moeite.

Maar goed, wat vind je van die Alternatieven ? Je merkt daar verder weinig van, maar je moet wel de "definities" maken. Desnoods maak je die ter plekke wanneer het nodig is, alhoewel je dat dan op dat moment weer de tijd kost natuurlijk.

?

Ik zal wel blind zijn, maar daarin staat volgens mij niets over dat onjuiste Opboeken bij Produktieorders.

De BRON aanpakken ... niet het probleem dat je eerst zelf hebt gekreëerd. Totdat het niet anders kan. Ok ?

Sorry, ik ben gewoon vergeten te reageren.


Hoe doe je zoiets ? toch niet via een onjuiste Kenmerkwaarde ? of ? ...

Ja ehh, dat vraag je maar aan de persoon die het heeft ontwikkeld hoor.
Zie ook de CR aan het eind.

Het klinkt altijd wat zwak van onze kant, maar het is gewoon zo hoor. Ook in dit geval;
De print kan zowel Debet als Credit Orders printen, en wordt daarvoor gevoed met een "parameter". Dus, zo'n parameter wordt meegegeven door de aanroepende funktie (in dit geval het menu waar je zojuist vandaan kwam), en als die aanroepende funktie er niet is, tja ...

Overigens zou dit in veel gevallen kunnen worden opgelost door de waarde van die parameter (die je zoals in dit geval domweg als "C" zou kunnen invoeren) op te slaan bij de betreffende UserButton. Kwestie van een veldje erbij in onderstaand formpje. Verder (denk ik) een dagje zoeken waar dit allemaal zit c.q. waar het moet worden aangepast, en dan kan je "een aantal" funkties meer opstarten. Echter, het zal altijd bij ons vandaan moeten komen wat je dan moet (of mag) invullen, want geautomatiseerd kan dit niet. Dus het is misschien wel een leuk idee, maar toch niet helemaal praktisch.
Overigens zal iedere individuele gebruiker nooit (zoals in dit geval) een UserButton kunnen maken voor zowel de Debet als de Credit versie, omdat de "identifikatie" de funktienaam betreft (LOPRVBCR).

Alles bij elkaar, mocht iemand denken 9 uur te kunnen terugwinnen door het vermijden van een extra toetsaanslag hier of daar, dan kàn het dus wel (binnen de kondities zoals boven gesteld), en zullen wij wanneer nodig de mogelijke parameter waarden wel doorgeven.

Trouwens, hiermee stel je de Taal per Gebruiker in (zie de blauwe "E").
Dat weet je dat alvast.