select your pdf document template from organizational party

[Nicolas Malin-2]

Hi all,

Currently, I work on a pdf invoice creation for a personal project and I
wish go for this time to improve the printable document configuration
(like order pdf, invoice pdf, shipment pdf, and soon) related to the
organizational party that at its origin.

To realize it I started a POC where a add a new entity
PartyAcctgPrefTplDoc (maybe you have a better name) that associate an
organizational party (PartyAcctgPreference), a documentType
(invoiceType, orderType...) and a content.
The content return the screen to use (as blog concept) and the standard
document screen return the given screen or call the default screen is empty.

With this improvement, you can create your own pdf template document in
your custom plugin with associate data and use it without any framework
modification.

More, if you have a specific case to rendering different document
following functional case, you can implement it on your screen.

Also, we can have a standard choice to rendering your document from a
content, manageable from PartyContent association.

The life isn't pretty ? (french expression, if you not understant, just
ignore it :)

Feel free if you have some remarks, I will create an issue for each
document type manageable by this concept to detail more this idea.

For example :
    Content data
  ---------------------

     <DataResource dataResourceId="MY_TPL_SALES_INV" dataResourceTypeId="URL_RESOURCE" dataResourceName="My templage sales invoice" mimeTypeId="application/pdf" objectInfo="component://myplugin/widget/AccountingPrintScreens.xml#MyBeautyfullInvoicePDF"/>

     <Content contentId="MY_TPL_SALES_INV" contentTypeId="DOCUMENT" dataResourceId="MY_TPL_SALES_INV" contentName="My Beautyfull template sales invoice with flowers"/>

     <ContentPurposeType contentPusposeTypeId="INVOICE_TEMPLATE" description="Content dedicate to rendering invoices"/>

     <PartyAcctgPrefTplDoc partyId="Company" invoiceTypeId="SALES_INVOICE" contentId="MY_TPL_SALES_INV" fromDate="2000-01-01 00:00:00" />

  ----------------------

   Standard screen (application/accounting/widget/AccountinPrintScreens.xml)
  -------------------------
    <screen name="InvoicePDF">...
      <actions><script
location="component://accounting/groovyScripts/invoice/GetInvoiceTemplateScreen.groovy"/></actions>
      <widgets>
           <include-screen name="${screenName}"
location="${screenLocation}"/>
      </widgets>
     </screen>

     <screen name="DefaultInvoicePDF">
         <section>.....
  ------------------------

GetInvoiceTemplateScreen.groovy return DefaultInvoicePDF screen if
didn't found any configuration for the invoice.partyIdFrom (for sales)
or invoice.partyId (for purchase)

Cheers,

Nicolas

--
logoNrd <https://nereide.fr/>
        Nicolas Malin
The apache way <http://theapacheway.com/> : *Charity* Apache’s mission
is providing software for the public good.
[hidden email]
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
<http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>

[taher]

Hi Nicolas,

The concept sounds interesting, but I'm having a bit of difficulty
understanding the design from your explanation. Perhaps a JIRA with a
PoC patch might help put it in perspective. But overall I like the
general idea of allowing overridden PDF templates.

On Tue, Jan 23, 2018 at 11:10 PM, Nicolas Malin
<[hidden email]> wrote:

> Hi all,
>
> Currently, I work on a pdf invoice creation for a personal project and I
> wish go for this time to improve the printable document configuration (like
> order pdf, invoice pdf, shipment pdf, and soon) related to the
> organizational party that at its origin.
>
> To realize it I started a POC where a add a new entity PartyAcctgPrefTplDoc
> (maybe you have a better name) that associate an organizational party
> (PartyAcctgPreference), a documentType (invoiceType, orderType...) and a
> content.
> The content return the screen to use (as blog concept) and the standard
> document screen return the given screen or call the default screen is empty.
>
> With this improvement, you can create your own pdf template document in your
> custom plugin with associate data and use it without any framework
> modification.
>
> More, if you have a specific case to rendering different document following
> functional case, you can implement it on your screen.
>
> Also, we can have a standard choice to rendering your document from a
> content, manageable from PartyContent association.
>
> The life isn't pretty ? (french expression, if you not understant, just
> ignore it :)
>
> Feel free if you have some remarks, I will create an issue for each document
> type manageable by this concept to detail more this idea.
>
> For example :
>    Content data
>  ---------------------
>
>     <DataResource dataResourceId="MY_TPL_SALES_INV"
> dataResourceTypeId="URL_RESOURCE" dataResourceName="My templage sales
> invoice" mimeTypeId="application/pdf"
> objectInfo="component://myplugin/widget/AccountingPrintScreens.xml#MyBeautyfullInvoicePDF"/>
>
>     <Content contentId="MY_TPL_SALES_INV" contentTypeId="DOCUMENT"
> dataResourceId="MY_TPL_SALES_INV" contentName="My Beautyfull template sales
> invoice with flowers"/>
>
>     <ContentPurposeType contentPusposeTypeId="INVOICE_TEMPLATE"
> description="Content dedicate to rendering invoices"/>
>
>     <PartyAcctgPrefTplDoc partyId="Company" invoiceTypeId="SALES_INVOICE"
> contentId="MY_TPL_SALES_INV" fromDate="2000-01-01 00:00:00" />
>
>  ----------------------
>
>   Standard screen (application/accounting/widget/AccountinPrintScreens.xml)
>  -------------------------
>    <screen name="InvoicePDF">...
>      <actions><script
> location="component://accounting/groovyScripts/invoice/GetInvoiceTemplateScreen.groovy"/></actions>
>      <widgets>
>           <include-screen name="${screenName}"
> location="${screenLocation}"/>
>      </widgets>
>     </screen>
>
>     <screen name="DefaultInvoicePDF">
>         <section>.....
>  ------------------------
>
> GetInvoiceTemplateScreen.groovy return DefaultInvoicePDF screen if didn't
> found any configuration for the invoice.partyIdFrom (for sales) or
> invoice.partyId (for purchase)
>
> Cheers,
>
> Nicolas
>
> --
> logoNrd <https://nereide.fr/>
>         Nicolas Malin
> The apache way <http://theapacheway.com/> : *Charity* Apache’s mission is
> providing software for the public good.
> [hidden email]
> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>
> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
> <http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>

[Michael Brohl-3]

+1 for the idea and a patch to better understand the solution.Thanks,

Michael

Am 25.01.18 um 12:13 schrieb Taher Alkhateeb:

> Hi Nicolas,
>
> The concept sounds interesting, but I'm having a bit of difficulty
> understanding the design from your explanation. Perhaps a JIRA with a
> PoC patch might help put it in perspective. But overall I like the
> general idea of allowing overridden PDF templates.
>
> On Tue, Jan 23, 2018 at 11:10 PM, Nicolas Malin
> <[hidden email]> wrote:
>> Hi all,
>>
>> Currently, I work on a pdf invoice creation for a personal project and I
>> wish go for this time to improve the printable document configuration (like
>> order pdf, invoice pdf, shipment pdf, and soon) related to the
>> organizational party that at its origin.
>>
>> To realize it I started a POC where a add a new entity PartyAcctgPrefTplDoc
>> (maybe you have a better name) that associate an organizational party
>> (PartyAcctgPreference), a documentType (invoiceType, orderType...) and a
>> content.
>> The content return the screen to use (as blog concept) and the standard
>> document screen return the given screen or call the default screen is empty.
>>
>> With this improvement, you can create your own pdf template document in your
>> custom plugin with associate data and use it without any framework
>> modification.
>>
>> More, if you have a specific case to rendering different document following
>> functional case, you can implement it on your screen.
>>
>> Also, we can have a standard choice to rendering your document from a
>> content, manageable from PartyContent association.
>>
>> The life isn't pretty ? (french expression, if you not understant, just
>> ignore it :)
>>
>> Feel free if you have some remarks, I will create an issue for each document
>> type manageable by this concept to detail more this idea.
>>
>> For example :
>>     Content data
>>   ---------------------
>>
>>      <DataResource dataResourceId="MY_TPL_SALES_INV"
>> dataResourceTypeId="URL_RESOURCE" dataResourceName="My templage sales
>> invoice" mimeTypeId="application/pdf"
>> objectInfo="component://myplugin/widget/AccountingPrintScreens.xml#MyBeautyfullInvoicePDF"/>
>>
>>      <Content contentId="MY_TPL_SALES_INV" contentTypeId="DOCUMENT"
>> dataResourceId="MY_TPL_SALES_INV" contentName="My Beautyfull template sales
>> invoice with flowers"/>
>>
>>      <ContentPurposeType contentPusposeTypeId="INVOICE_TEMPLATE"
>> description="Content dedicate to rendering invoices"/>
>>
>>      <PartyAcctgPrefTplDoc partyId="Company" invoiceTypeId="SALES_INVOICE"
>> contentId="MY_TPL_SALES_INV" fromDate="2000-01-01 00:00:00" />
>>
>>   ----------------------
>>
>>    Standard screen (application/accounting/widget/AccountinPrintScreens.xml)
>>   -------------------------
>>     <screen name="InvoicePDF">...
>>       <actions><script
>> location="component://accounting/groovyScripts/invoice/GetInvoiceTemplateScreen.groovy"/></actions>
>>       <widgets>
>>            <include-screen name="${screenName}"
>> location="${screenLocation}"/>
>>       </widgets>
>>      </screen>
>>
>>      <screen name="DefaultInvoicePDF">
>>          <section>.....
>>   ------------------------
>>
>> GetInvoiceTemplateScreen.groovy return DefaultInvoicePDF screen if didn't
>> found any configuration for the invoice.partyIdFrom (for sales) or
>> invoice.partyId (for purchase)
>>
>> Cheers,
>>
>> Nicolas
>>
>> --
>> logoNrd <https://nereide.fr/>
>>          Nicolas Malin
>> The apache way <http://theapacheway.com/> : *Charity* Apache’s mission is
>> providing software for the public good.
>> [hidden email]
>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>
>> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
>> <http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>

[Nicolas Malin-2]

Thanks for the return guys,

Sure I will open an issue with the patch but I need to found how do it
to help the review.

Nicolas


On 26/01/2018 09:56, Michael Brohl wrote:

> +1 for the idea and a patch to better understand the solution.Thanks,
>
> Michael
>
> Am 25.01.18 um 12:13 schrieb Taher Alkhateeb:
>> Hi Nicolas,
>>
>> The concept sounds interesting, but I'm having a bit of difficulty
>> understanding the design from your explanation. Perhaps a JIRA with a
>> PoC patch might help put it in perspective. But overall I like the
>> general idea of allowing overridden PDF templates.
>>
>> On Tue, Jan 23, 2018 at 11:10 PM, Nicolas Malin
>> <[hidden email]> wrote:
>>> Hi all,
>>>
>>> Currently, I work on a pdf invoice creation for a personal project
>>> and I
>>> wish go for this time to improve the printable document
>>> configuration (like
>>> order pdf, invoice pdf, shipment pdf, and soon) related to the
>>> organizational party that at its origin.
>>>
>>> To realize it I started a POC where a add a new entity
>>> PartyAcctgPrefTplDoc
>>> (maybe you have a better name) that associate an organizational party
>>> (PartyAcctgPreference), a documentType (invoiceType, orderType...)
>>> and a
>>> content.
>>> The content return the screen to use (as blog concept) and the standard
>>> document screen return the given screen or call the default screen
>>> is empty.
>>>
>>> With this improvement, you can create your own pdf template document
>>> in your
>>> custom plugin with associate data and use it without any framework
>>> modification.
>>>
>>> More, if you have a specific case to rendering different document
>>> following
>>> functional case, you can implement it on your screen.
>>>
>>> Also, we can have a standard choice to rendering your document from a
>>> content, manageable from PartyContent association.
>>>
>>> The life isn't pretty ? (french expression, if you not understant, just
>>> ignore it :)
>>>
>>> Feel free if you have some remarks, I will create an issue for each
>>> document
>>> type manageable by this concept to detail more this idea.
>>>
>>> For example :
>>>     Content data
>>>   ---------------------
>>>
>>>      <DataResource dataResourceId="MY_TPL_SALES_INV"
>>> dataResourceTypeId="URL_RESOURCE" dataResourceName="My templage sales
>>> invoice" mimeTypeId="application/pdf"
>>> objectInfo="component://myplugin/widget/AccountingPrintScreens.xml#MyBeautyfullInvoicePDF"/>
>>>
>>>
>>>      <Content contentId="MY_TPL_SALES_INV" contentTypeId="DOCUMENT"
>>> dataResourceId="MY_TPL_SALES_INV" contentName="My Beautyfull
>>> template sales
>>> invoice with flowers"/>
>>>
>>>      <ContentPurposeType contentPusposeTypeId="INVOICE_TEMPLATE"
>>> description="Content dedicate to rendering invoices"/>
>>>
>>>      <PartyAcctgPrefTplDoc partyId="Company"
>>> invoiceTypeId="SALES_INVOICE"
>>> contentId="MY_TPL_SALES_INV" fromDate="2000-01-01 00:00:00" />
>>>
>>>   ----------------------
>>>
>>>    Standard screen
>>> (application/accounting/widget/AccountinPrintScreens.xml)
>>>   -------------------------
>>>     <screen name="InvoicePDF">...
>>>       <actions><script
>>> location="component://accounting/groovyScripts/invoice/GetInvoiceTemplateScreen.groovy"/></actions>
>>>
>>>       <widgets>
>>>            <include-screen name="${screenName}"
>>> location="${screenLocation}"/>
>>>       </widgets>
>>>      </screen>
>>>
>>>      <screen name="DefaultInvoicePDF">
>>>          <section>.....
>>>   ------------------------
>>>
>>> GetInvoiceTemplateScreen.groovy return DefaultInvoicePDF screen if
>>> didn't
>>> found any configuration for the invoice.partyIdFrom (for sales) or
>>> invoice.partyId (for purchase)
>>>
>>> Cheers,
>>>
>>> Nicolas
>>>
>>> --
>>> logoNrd <https://nereide.fr/>
>>>          Nicolas Malin
>>> The apache way <http://theapacheway.com/> : *Charity* Apache’s
>>> mission is
>>> providing software for the public good.
>>> [hidden email]
>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>
>>> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
>>> <http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>
>
>

[Pierre Smits-3]

Hey Nicolas,

Is this a follow-up of the 'template-able' solution you proposed back in
2014/2015? If I remember correctly, your solution envisioned having
FTL-templates for invoice, order, shipment and other documents which could
be retrieved through the content component based on passed parameters.


Best regards,

Pierre Smits

V.P. Apache Trafodion

On Tue, Jan 23, 2018 at 9:10 PM, Nicolas Malin <[hidden email]>
wrote:

> Hi all,
>
> Currently, I work on a pdf invoice creation for a personal project and I
> wish go for this time to improve the printable document configuration (like
> order pdf, invoice pdf, shipment pdf, and soon) related to the
> organizational party that at its origin.
>
> To realize it I started a POC where a add a new entity
> PartyAcctgPrefTplDoc (maybe you have a better name) that associate an
> organizational party (PartyAcctgPreference), a documentType (invoiceType,
> orderType...) and a content.
> The content return the screen to use (as blog concept) and the standard
> document screen return the given screen or call the default screen is empty.
>
> With this improvement, you can create your own pdf template document in
> your custom plugin with associate data and use it without any framework
> modification.
>
> More, if you have a specific case to rendering different document
> following functional case, you can implement it on your screen.
>
> Also, we can have a standard choice to rendering your document from a
> content, manageable from PartyContent association.
>
> The life isn't pretty ? (french expression, if you not understant, just
> ignore it :)
>
> Feel free if you have some remarks, I will create an issue for each
> document type manageable by this concept to detail more this idea.
>
> For example :
>    Content data
>  ---------------------
>
>     <DataResource dataResourceId="MY_TPL_SALES_INV"
> dataResourceTypeId="URL_RESOURCE" dataResourceName="My templage sales
> invoice" mimeTypeId="application/pdf" objectInfo="component://myplug
> in/widget/AccountingPrintScreens.xml#MyBeautyfullInvoicePDF"/>
>
>     <Content contentId="MY_TPL_SALES_INV" contentTypeId="DOCUMENT"
> dataResourceId="MY_TPL_SALES_INV" contentName="My Beautyfull template
> sales invoice with flowers"/>
>
>     <ContentPurposeType contentPusposeTypeId="INVOICE_TEMPLATE"
> description="Content dedicate to rendering invoices"/>
>
>     <PartyAcctgPrefTplDoc partyId="Company" invoiceTypeId="SALES_INVOICE"
> contentId="MY_TPL_SALES_INV" fromDate="2000-01-01 00:00:00" />
>
>  ----------------------
>
>   Standard screen (application/accounting/widget
> /AccountinPrintScreens.xml)
>  -------------------------
>    <screen name="InvoicePDF">...
>      <actions><script location="component://accounti
> ng/groovyScripts/invoice/GetInvoiceTemplateScreen.groovy"/></actions>
>      <widgets>
>           <include-screen name="${screenName}"
> location="${screenLocation}"/>
>      </widgets>
>     </screen>
>
>     <screen name="DefaultInvoicePDF">
>         <section>.....
>  ------------------------
>
> GetInvoiceTemplateScreen.groovy return DefaultInvoicePDF screen if didn't
> found any configuration for the invoice.partyIdFrom (for sales) or
> invoice.partyId (for purchase)
>
> Cheers,
>
> Nicolas
>
> --
> logoNrd <https://nereide.fr/>
>         Nicolas Malin
> The apache way <http://theapacheway.com/> : *Charity* Apache’s mission is
> providing software for the public good.
> [hidden email]
> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>
> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
> http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>
>

[Nicolas Malin-2]

Hello Pierre,
On 27/01/2018 16:20, Pierre Smits wrote:
> Hey Nicolas,
>
> Is this a follow-up of the 'template-able' solution you proposed back in
> 2014/2015? If I remember correctly, your solution envisioned having
> FTL-templates for invoice, order, shipment and other documents which could
> be retrieved through the content component based on passed parameters.
Yes my solution is more generic that this previous idea, (because I grow
;) )

I  orientated my thinking about to two axes :
* Unique area to configure document template for an existing list easily
* support tenant and plugin system as well

So I oriented my solution on new entity related to PartyAcctgPreference
and an other entity CustomScreen to list all configured screen on the
system. As I work only with the screen, you can custom your template as
you want without limitation that the content system can introduce. But
you can create a content library for your template and like to your
organization the screen rendering a content (we need to define standard
rules for the content resolution)

I put on the issue https://issues.apache.org/jira/browse/OFBIZ-10186 a
patch for analyze my POC, all don't work but the main structure is present.

I imagine tomorrow to introduce new template as plugin like :
* template-invoice-detail-shipping
* template-invoice-europeen-flower
* template-order-consolidate-lines
and this without framework modification :)

Nicolas

>
>
> Best regards,
>
> Pierre Smits
>
> V.P. Apache Trafodion
>
> On Tue, Jan 23, 2018 at 9:10 PM, Nicolas Malin <[hidden email]>
> wrote:
>
>> Hi all,
>>
>> Currently, I work on a pdf invoice creation for a personal project and I
>> wish go for this time to improve the printable document configuration (like
>> order pdf, invoice pdf, shipment pdf, and soon) related to the
>> organizational party that at its origin.
>>
>> To realize it I started a POC where a add a new entity
>> PartyAcctgPrefTplDoc (maybe you have a better name) that associate an
>> organizational party (PartyAcctgPreference), a documentType (invoiceType,
>> orderType...) and a content.
>> The content return the screen to use (as blog concept) and the standard
>> document screen return the given screen or call the default screen is empty.
>>
>> With this improvement, you can create your own pdf template document in
>> your custom plugin with associate data and use it without any framework
>> modification.
>>
>> More, if you have a specific case to rendering different document
>> following functional case, you can implement it on your screen.
>>
>> Also, we can have a standard choice to rendering your document from a
>> content, manageable from PartyContent association.
>>
>> The life isn't pretty ? (french expression, if you not understant, just
>> ignore it :)
>>
>> Feel free if you have some remarks, I will create an issue for each
>> document type manageable by this concept to detail more this idea.
>>
>> For example :
>>     Content data
>>   ---------------------
>>
>>      <DataResource dataResourceId="MY_TPL_SALES_INV"
>> dataResourceTypeId="URL_RESOURCE" dataResourceName="My templage sales
>> invoice" mimeTypeId="application/pdf" objectInfo="component://myplug
>> in/widget/AccountingPrintScreens.xml#MyBeautyfullInvoicePDF"/>
>>
>>      <Content contentId="MY_TPL_SALES_INV" contentTypeId="DOCUMENT"
>> dataResourceId="MY_TPL_SALES_INV" contentName="My Beautyfull template
>> sales invoice with flowers"/>
>>
>>      <ContentPurposeType contentPusposeTypeId="INVOICE_TEMPLATE"
>> description="Content dedicate to rendering invoices"/>
>>
>>      <PartyAcctgPrefTplDoc partyId="Company" invoiceTypeId="SALES_INVOICE"
>> contentId="MY_TPL_SALES_INV" fromDate="2000-01-01 00:00:00" />
>>
>>   ----------------------
>>
>>    Standard screen (application/accounting/widget
>> /AccountinPrintScreens.xml)
>>   -------------------------
>>     <screen name="InvoicePDF">...
>>       <actions><script location="component://accounti
>> ng/groovyScripts/invoice/GetInvoiceTemplateScreen.groovy"/></actions>
>>       <widgets>
>>            <include-screen name="${screenName}"
>> location="${screenLocation}"/>
>>       </widgets>
>>      </screen>
>>
>>      <screen name="DefaultInvoicePDF">
>>          <section>.....
>>   ------------------------
>>
>> GetInvoiceTemplateScreen.groovy return DefaultInvoicePDF screen if didn't
>> found any configuration for the invoice.partyIdFrom (for sales) or
>> invoice.partyId (for purchase)
>>
>> Cheers,
>>
>> Nicolas
>>
>> --
>> logoNrd <https://nereide.fr/>
>>          Nicolas Malin
>> The apache way <http://theapacheway.com/> : *Charity* Apache’s mission is
>> providing software for the public good.
>> [hidden email]
>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>
>> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
>> http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>
>>

[Nicolas Malin-2]

Hello,

I update the patch on the issue [1] with only the engine to associate
the custom screen to an organizational party.

Don't hesitate to review and comment it ;)

Nicolas

[1] https://issues.apache.org/jira/browse/OFBIZ-10186,


On 23/01/2018 21:10, Nicolas Malin wrote:

> Hi all,
>
> Currently, I work on a pdf invoice creation for a personal project and
> I wish go for this time to improve the printable document
> configuration (like order pdf, invoice pdf, shipment pdf, and soon)
> related to the organizational party that at its origin.
>
> To realize it I started a POC where a add a new entity
> PartyAcctgPrefTplDoc (maybe you have a better name) that associate an
> organizational party (PartyAcctgPreference), a documentType
> (invoiceType, orderType...) and a content.
> The content return the screen to use (as blog concept) and the
> standard document screen return the given screen or call the default
> screen is empty.
>
> With this improvement, you can create your own pdf template document
> in your custom plugin with associate data and use it without any
> framework modification.
>
> More, if you have a specific case to rendering different document
> following functional case, you can implement it on your screen.
>
> Also, we can have a standard choice to rendering your document from a
> content, manageable from PartyContent association.
>
> The life isn't pretty ? (french expression, if you not understant,
> just ignore it :)
>
> Feel free if you have some remarks, I will create an issue for each
> document type manageable by this concept to detail more this idea.
>
> For example :
>    Content data
>  ---------------------
>
>     <DataResource dataResourceId="MY_TPL_SALES_INV"
> dataResourceTypeId="URL_RESOURCE" dataResourceName="My templage sales
> invoice" mimeTypeId="application/pdf"
> objectInfo="component://myplugin/widget/AccountingPrintScreens.xml#MyBeautyfullInvoicePDF"/>
>
>     <Content contentId="MY_TPL_SALES_INV" contentTypeId="DOCUMENT"
> dataResourceId="MY_TPL_SALES_INV" contentName="My Beautyfull template
> sales invoice with flowers"/>
>
>     <ContentPurposeType contentPusposeTypeId="INVOICE_TEMPLATE"
> description="Content dedicate to rendering invoices"/>
>
>     <PartyAcctgPrefTplDoc partyId="Company"
> invoiceTypeId="SALES_INVOICE" contentId="MY_TPL_SALES_INV"
> fromDate="2000-01-01 00:00:00" />
>
>  ----------------------
>
>   Standard screen
> (application/accounting/widget/AccountinPrintScreens.xml)
>  -------------------------
>    <screen name="InvoicePDF">...
>      <actions><script
> location="component://accounting/groovyScripts/invoice/GetInvoiceTemplateScreen.groovy"/></actions>
>      <widgets>
>           <include-screen name="${screenName}"
> location="${screenLocation}"/>
>      </widgets>
>     </screen>
>
>     <screen name="DefaultInvoicePDF">
>         <section>.....
>  ------------------------
>
> GetInvoiceTemplateScreen.groovy return DefaultInvoicePDF screen if
> didn't found any configuration for the invoice.partyIdFrom (for sales)
> or invoice.partyId (for purchase)
>
> Cheers,
>
> Nicolas
>