We have a special helper extension which can be found under the Tools menu called OOMerge Fields. This extension will list all available fields for each module and their internal name so we can easily copy and paste the field names into out OpenOffice template documents.

• {entity.field}
  • will be substituted by the named field of the named entity, these fields can be consulted in the OOMerge Fields extension if the field cannot be found it will be left unmodified, for example, {nonexistent_entity.fieldname}, {entity.nonexistent_field}, {sihubiera} or {sinexiste}
  • examples: {account.accountname}, {contact.bill_address}, {product.productcode}
• {siexiste entity}…{/siexiste}
  • all text contained inside the {siexiste} and {/siexiste} will be added to the final document if there exists at least one entity related to the main entity of the merge if none exist or entity is not defined the whole block will be eliminated inside the block fields of the first entity found may be used
  • examples: {siexiste asset}, {siexiste contact}, {siexiste campaign}, {siexiste product}, {siexiste invoice}
• {siexiste entity.field=value}…{/siexiste}
  • all text contained inside the {siexiste} and {/siexiste} will be added to the final document if there exists at least one entity related to the main entity of the merge whose indicated field has the indicated value. For fields with multiple values (multiple select picklist), the string |##| must be used to separate the values and ALL values in the field must be the same as the value for the entity to qualify as equal.
  • if the entity or field do not exist the whole block will be ignored.
  • inside the block fields of the first entity found may be used
  • examples: {siexiste asset.type=Fichero}, {siexiste contact.type=Responsable Seguridad}, {siexiste campaign=GAdwords Noviembre08}
• {siexiste entity.field en (value1,value2,value3)}…{/siexiste}
  • all text contained inside the {siexiste} and {/siexiste} will be added to the final document if there exists at least one entity related to the main entity of the merge whose indicated field has at least one of the indicated values. Fields with multiple values (multiple select picklist) are directly supported, no special syntax is needed.
  • if the entity or field do not exist the whole block will be ignored.
  • inside the block fields of the first entity found may be used
  • examples: {siexiste asset.type en (Fichero,Contacto,Aplicación)}, {siexiste contacto.tipo en (Responsable Seguridad,Responsable Ficheros)}
• {sinoexiste entity}…{/sinoexiste}
  • negative case of {siexiste…}
• {sinoexiste entity.field=value}…{/sinoexiste}
  • negative case of {siexiste…}
• {sinoexiste entity.field en (value1,value2,value2)}…{/sinoexiste}
  • negative case of {siexiste…}
• {paracada entity}…{/paracada}
  • for each related entity of the main merge entity we will merge the whole text contained between the two commands and add the result to the final document
  • if no related entity is found the whole block will be ignored
• {paracada entity.field=value}…{/paracada}
  • for each related entity of the main merge entity whose indicated field has the indicated value we will merge the whole text contained between the two commands and add the result to the final document. For fields with multiple values (multiple select picklist), the string |##| must be used to separate the values and ALL values in the field must be the same as the value for the entity to qualify as equal.
  • if no related entity is found the whole block will be ignored
• {paracada entity.field en (value1,value2,value3)}…{/paracada}
  • for each related entity of the main merge entity whose indicated field has at least one of the indicated value we will merge the whole text contained between the two commands and add the result to the final document. Fields with multiple values (multiple select picklist) are directly supported, no special syntax is needed.
  • if no related entity is found the whole block will be ignored
• {paracada entity.field!=value}…{/paracada}
  • negative case of {paracada…}
• {paracada entity.field !en (value1,value2,value3)}…{/paracada}
  • negative case of {paracada…}
• repeticion: inside the {paracada} blocks you can reference a special variable called {repetición} whose value will be that of the current loop iteration. This can be userful to enumerate the elements or to print conditional text based on the iteration. See Examples.
• {incluir Document_Num}
  • With this instruction we can include any document saved in the vtiger CRM document module inside the main document. For example, if we have a document with reference number DOC699, we can put at the beginning of a new paragraph {incluir DOC699} in the position where we wish to insert the document. During the merging process all the contents in DOC699 will be inserted in the position where the {incluir} directive is and the directive will be eliminated.
  • You can use any other directive within the included document, following the same rules as any other document
  • Nesting of {incluir} directives is not supported (truth is that we haven't tried it)
  • At the beginning of the page that includes the document, check the Format» Paragraph» Text Flow» Breaks, that the page number is set to 0 to keep the page counter from starting to count again.
• {incluir entity}
  • With this command we can include, in the template, any document in the vtiger CRM document module that is associated to an entity directly related to the main entity of the merge. For example, if we have an entity Backups related to the main entity on which you compile the document, we can put at the beginning of a new paragraph {incluir Backups} (in this case it would seem logical to be inside a {paracada} loop because an account probably has more than one backup) in the position where we want to insert the document. When compiling all the documents related to the Backups will be inserted in substitution of the {include} directive.
  • You can use any other directive within the included document, following the same rules as any other document
  • Nesting of {incluir} directives is not supported (truth is that we haven't tried it)
  • At the beginning of the page that includes the document, check the Format» Paragraph» Text Flow» Breaks, that the page number is set to 0 to keep the page counter from starting to count again.
• {insertarindice}
  • A table of contents will be created from the outline of the document.
  • It can be used more than once in the same document but the TOC will be the same.
• {imagen entity}
  • This directive must be at the start of a paragraph.
  • The paragraph with the directive will be completely eliminated
  • The next paragraph must contain an image which will be the one substituted by the actual entity image
  • In the case of needing various images, each image to be substituted must be different
  • All the configurations made on the image will be respected, only the image will be substituted
  • We treat the image directives in a special way. The idea is that there are so many possible configuration options for an image (width, height, alignment, …) that it would be complicated to include them in the image directive to indicate how the image should be rendered. So we decided that you include any image, format it as you need using the options that OpenOffice gives you for this and then we will substitute only the image leaving all the formating as you defined it.
• Rules
  • Directives must be on the same paragraph. There can not be a new paragraph in the middle of a directive. For example,

    Dear {Contact.
    firstname},

    is incorrect.

  • The directives {siexiste}, {sinoexiste}, {paracada} and their closings must appear at the very beginning of the line in their own paragraph. The whole line will be eliminated. For example,

    this is the end of the previous paragraph.
    {siexiste activo.tipo=fichero}
    This "si existe" works correctly while this one {siexiste activo.tipo=fichero} is ignored completely
    and will be passed into the final document exactly as it is.
    This is another paragraph that may contain labels like: {Account.accountname}.
    {/siexiste}

  • If directives {siexiste}, {sinoexiste}, {paracada} are used at the start of a paragraph (which is mandatory) but the paragraph is inside a list, then the corresponding closings must also be added as a paragraph inside the list. This can be accomplished with the ALT-INTRO key combination.
  • Additional text after the special directives cannot be used. For example,

    {siexiste activo.tipo=fichero} and more text here on the same paragraph

    is incorrect.

  • {paracada} directives can be nested.
  • {siexiste} directives can be nested with the exception of those in which a value coming from a {paracada} directive is being evaluated. For example:

    {paracada Soportes}
      {siexiste Soportes.soporte_movil=1}
         XXXXXXX
      {/siexiste}
    {/paracada}

    In this case, the {siexiste} will evaluate the same entity as the {paracada}, and will fail. In general we can put {siexiste} inside a {paracada} if we are testing against a diferent entity, for example, this IS CORRECT:

    {paracada Soportes}
      {siexiste Accounts.bill_provincia=Alicante}
           XXXXXXXXX
      {/siexiste}
    {/paracada}

    In this example all related Soportes will be listed and if the account belongs to Alicante it will also incorporate the block XXXXXXXXXXX.

This is to allow formatting of text that is coming from the application. This feature allows you to format the text within a label, inside vtiger CRM. In other words, the format is introduced when creating the text in the appropriate field of the application, then the document generator will convert these formats directly into comprehensible elements in OpenOffice. Only 4 types of formatting items are allowed, with which it is possible to apply any OpenOffice format to the text.

• <b>text</b>, OpenOffice SIGPAC_BOLD style will be applied
• <i>text</i>, OpenOffice SIGPAC_ITALIC style will be applied
• <style estilo=openoffice_style>text</style>, OpenOffice openoffice_style style will be applied
• <br> <br/>, line break (NOT paragraph break)

This formatting will be applied to any text contained inside the directives.

Nesting of <b> and <i> is not supported, use <style> to create this effect.

The character styles SIGPAC_BOLD, SIGAC_ITALIC or any other defined by the user must be created in the template by the user, the document generator only applies the style, it does not create it, if it is not defined the text will appear normal.

There is abundant information of character styles in the online documentation of OpenOffice. Here we can see the styles definition screen:

This is the template used for testing the functionality where the styles definitions can be seen.
This is an example of how the text looks inside the field of vtiger CRM.

<b>EVIDENCIA</b>: El Responsable de seguridad declara que los sistemas de información se han sometido a la precpetiva auditoría bienal en <br/><style estilo=MiEstilo>materia de protección de datos</style>
<i>DEFICIENCIA</i>: No se aprecian.

This is the finished, merged document.
Another example of character formatting.

• In general all merging starts from an account and gives access to all the fields of all the related entities.
• In certain situations other entities may be used as the starting point of a merge.
• SIGPAC has a series of constant fields obtained from the system:
  • {empresa.campo}: information obtained from the organization details in settings
  • {empresa.gerente_campo}: information of the head manager of the company
  • {empresa.responsable_campo}: information of the legal responsible of the company
  • {cuenta.responsable_campo}: information of the LOPD responsible of the company