MailOpdracht.cls.xml

Twee belangrijke opmerkingen (dit is de vhisie van WV en JCL):

• input params zijn enerzijds te beperkt en anderzijds te specifiek : "MailOpdracht" -> beter een algemene "Opdracht" met ook "Render-opties" object [ Te bespreken met WV/JCL]
• OrderData is OK, maar de structuur moet een "propere" dto zijn die AX moet invullen, en wij zullen er in caché dan wel de bizarre "pxMemo"-structuur (e.d.) van maken
  Let wel: VH legt de propere structuur vast (eventueel met overleg met ADU)

Zelfde opmerking geldt uiteraard voor Offerte- en LeveringService.

Het "Resultaat" vind ik nogal kort door de bocht :

Technisch beschouwd :
Het resultaat van "Render" is een pdf-stream
Het resultaat van RenderAndFile is een bestand (of een error) --> ObjResultaat.BestandVolledigeNaam en ObjResultaat.ErrorMessage
Het resultaat van RenderAndMail is een OK of een error --> ObjResultaat.ErrorMessage
Het resultaat van RenderAndPrint is een OK of een error --> ObjResultaat.ErrorMessage

Conclusie:
ook al is "RenderAndFile" voorlopig de enige die resultaat MET inhoud teruggeeft, toch zou ik het result-object dus specifiek benoemen, iets zoals hierboven,
eerder dan RenderResultaat.DocNaam

Ook een property MailReplyTo bijvoegen (omdat de meeste mails vanuit de server verstuurd worden)
Dit principe moeten we meer en meer gaan gebruiken, om te vermijden dat de replies naar "CacheAdmin@..." worden gestuurd.