Paul,


Het voorbeeld wat je hanteert (of wat ik gaf) is een beetje een vervelende, wat die doet het alleen als de Orderbevestiging automatisch volgt uit het maken van de Verkooporder (daar zou wel eens een Bedrijfsparameter voor kunnen zijn). En niet als je de print rechtstreeks opstart, dan is de rubriek disabled. Vraag me niet waarom, maar het heeft een reden.

Dit wordt niets zo. Het zal er toch wel op neerkomen dat we het zelf moeten doen.

Marco, je was het misschien vergeten, maar dit is een pakket. En aangezien dit niet "de" oplossing is, hebben we er straks twee. Dat je -dan- middels een Bedrijfsparameter je andere PDF printer kan opgeven is tot daar aan toe, maar dat de interne struktuur op z'n kop mag - en nog erger - dit twee strukturen zullen worden, is echt helemaal niets.


In plaats van dit te zeggen, had je je tijd wellicht beter kunnen besteden met het onderzoek van een converter. Ik heb dit nu (iets overdreven) 10 keer gezegd, en waarom je dat niet doet is mij een raadsel. Maar laat maar, van mij hoeft het nu niet meer.

Let op : Alles wat hierboven is genoemd door mij en op een aanbieding mag lijken, is hiermee vervallen.
Dat doe ik wel opnieuw als we hier concensus over hebben : Re: Afbeelding in koptekst layout verkooporder (SYLRRA).

De "konstruktie" weet ik nu misschien wel : onderbrengen in Profit-Print-3. Die gaat dan Basisprijs EUR 200 kosten (is nu 175), en Marco  heeft die toevallig al (bijbetalen niet nodig). N.b.: zie ook button print pdf bij afdrukken facturen.

Eenieder die deze module heeft zal PDFs kunnen maken van iedere print middels de reeds klaarstaande PrPDF button die net als de PrScr button toestaat om naar de vastgelegde instelling te printen. Hoe dat in dit geval moet lopen is mij nog niet helemaal duidelijk, maar wanneer je de gekreëerde PDF niet naar het scherm print moet ze eruit komen op de bestaande Queue/Funktie koppeling die elders is vastgelegd (zoals gebruikelijk en daaraan verandert niets). Het lijkt me dat we niets met drivers van doen hebben anders dan de bestaande (en ook die blijven gewoon in gebruik om de print te kunnen kreëren), omdat de omzetting naar PDF gebeurt nadat de print is gemaakt (converter type dus). Hieruit zal wel volgen dat er een PCL driver gehanteerd moet worden, of wat het ook is wat de gekozen converter biedt met als eis : transparantie voor de gebruiker.
Merk op dat ik met "transparantie" mag bedoelen dat je nog nooit eerder een print met PCL drivers hebt gemaakt, maar zodra je dat eenmaal hebt (voor alle vormen van prints die je gebruikt) het er ook hetzelfde uitziet in de PDF.

De keuze voor de converter maken wij, en als iets het niet helemaal doet is dat onze schuld c.q. ons werk om het werkend te maken.
Als ik hierboven terug kijk, dan zou het "veryPDF PCL Converter" moeten worden, maar zo niet deze, dan een ander.
Merk op dat de licentiekosten (indien aan de orde) voor de uiteindelijke converter niet bij de prijs van de module in zit.

Let op :
Wat hiermee wordt geboden is het principe van het kunnen omzetten van een feitelijk willekeurige print naar een PDF. Dit betreft een file. Gelijk aan de PrScr button die bij gebruik de print op het scherm zal tonen met (automatisch) gebruik van de juiste driver, zal de PrPDF button deze file aanmaken in de Troep directory als zijnde de gebruikelijke plaats voor "print files". Denk maar aan Prfile.pdf. Hiermee kan je dus nog niets, behoudens opvragen maar wat niet standaard zal gebeuren. In SYPRS1 (printer icoontje links) kan wat mij betreft wel een optie daarvoor worden opgenomen.

De PDF file staat nu klaar voor allerlei verdere verwerking, waar voor wat betreft dit ontwerpje *niets* van aan de orde is. Enkele ideeën :

• Emailen van de klaarstaande Prfile.pdf als attachment vanuit CRM.
• Emailen van de PDF versie voor die funkties die automatisch emailen ondersteunen (zoals nu Orderbevestiging, Inkooporder).
• Opslagstruktuur + naamgeving voor archivering (automatisch).
• Een additionele button EmPDF naast PrScr e PrPDF die middels een popup om Relatie-Id en Kontaktpersoon-Id vraagt, de betreffende print print en daarna de email client opstart met daarin de geadresseerde ingevuld en de PDF als attachment al in zich heeft.

Dit soort zaken betreft maatwerk (allemaal in de kategorie "valt best mee"), en zal vervolgens onderdeel van Profit-Print-3 zijn.

en


Ehh, ik zeg het maar even, nu het nog kan, maar het lijkt me niet dat het laatste feasable zou zijn. Misschien is het niet goed duidelijk te maken, maar die funktionaliteiten zijn er al, en werken tot aan een bepaald punt (emailen). Dat ga je natuurlijk niet op gestruktureerde (en gemoduleerde) wijze onderbreken met iets dat dat eind helemaal niet haalt. Ik denk eigenlijk dat wij domweg Nee zouden zeggen als dat wordt gevraagd.

Net zo moeilijk zal het zijn om duidelijk te maken dat wat je bij het Faktureren wenst domme onzin is, omdat het gewoon geen oplossing is die het eind kan halen (ditto dus) maar wat we toevallig wel zouden toestaan omdat er nog niets anders is ? hmm ...

Het moet ook van mijn hart dat je (Marco) het nu anders hebt uitgelegd als via email. Daar was het gewoon printen - klaar. Niets emailen. Ik heb je er al voor gewaarschuwd dat je die verbinding zou gaan maken, en dat niet te doen. Vanuit een topic van Paul Woelders wijs je dan ook nog hier naartoe, wat zeer onterecht is.

Wat was je eigenlijk van plan ? Faktuurrun opstarten en bij iedereen waar is ingesteld dat 'ie de faktuur ge-emailed krijgt even snel het email adres opzoeken invullen ? kom op zeg ...

Het spijt me zeer, maar ik denk niet dat we dit gaan maken.

Maar ik vrees dat niemand weet wat 'ie moet oplossen als de termen (onterecht dus, door ons) door eklkaar worden gebruikt. Yvonne heeft wellicht precies de verkeerde aangepast, en wiet weet mag de andere niet eens.

We zoeken het wel even uit.

Ik ga eens 0,75 uur zeggen. Gebeurt niet vaak, maar een half uur is te weinig en een uur te veel.

en


Hetgeen je wilt zal wel niet kunnen, of is fout of ...
Maar in elk geval komt het nogal abacadabra over wat je schrijft. Nadat ik mijn hersens binnenstebuiten heb gekeerd lijk je tot twee keer toe te vragen om het weergeven van de voorloop tekst, ook al is de variabele leeg. Is dit juist ?

Johan,

Ik weet niet precies wat je wilt ("claimen"). Maar ik zou zeggen, zie mijn post achter de eerste link die je in de eerste post alhier hebt gegeven.

Ik durf intussen niets meer echt te voorspellen, maar met een 6 weken moet ik er niet meer dan een jaar naast kunnen zitten.

Als het goed is merk je er weinig van, behalve dan dat je met een SQL DBMS te maken hebt (en de rapportage mogelijkheden van dien) en dat dus niemand erbij kan, behalve via de officiële weg (lees : programmatuur die dat toestaat, en anders userid+wachtwoord).

En dat je geen limiet op 2GB meer hebt natuurlijk.
En on-line backup.

Paul, als ik de PDF even erbuiten mag laten (daarover lopen andere uit te werken topics), dan moet dat kunnen voor een 6 uur.

Bij de Kontaktpersonen kan je dan aangeven welke persoon (mogen er meer zijn) de Faktuur moet ontvangen, en bij de Debiteur kan je dan aangeven dat de Faktuur via email wordt verzonden.

Als je bij de Wijzigen Kontaktpersonen kijkt, zie je de twee al werkende voorbeelden onderin. Daar kan je mee testen als je het leuk vindt.

De PDF is op dit moment nog een moeilijker verhaal, waarmee ik je adviseer het eerst eens zonder te doen.

Zohoo ... en de accountant vond dat een prima antwoord ? Maar ja, het is ook geen EDP Auditor natuurlijk.

Het wordt steeds gewaagder om het te noemen (omdat het ietwat complex is allemaal), maar binnenkort kan dat hoor. Een ander DBMS ...

Even onder het voorbehoud dat er een reden voor is (kan ik zo niet bedenken) ... gaan we proberen !

Kijk eens of je bij 3-1-8-8 iets ziet wat de basis zou kunnen zijn ?

Zo niet dan mag je op op 6 uur houden. Mag je zelf nog bedenken wat je erop wilt hebben ook.

Bijna klaar.

Zei ik dat een jaar geleden ook niet ? (en daar zit toch echt een persoon kontinu aan te werken ! )

Hier zijn we ons niet eens van bewust. Maar natuurlijk moet alles wat je ooit kan tegenkomen hier in passen.
Maar vooralsnog lijkt 80 me dan wel voldoende.

Heart Intern : Houd even rekening met de Raadpleegfunktie van de Gedisablede Rubrieken, alwaar 80 zonder afkappen wellicht het grid onleesbaar maakt (wordt misschien te breed).