Skip to main content
Skip table of contents

Effective work with search containers and templates

Basics

The control of Word from CURSOR-CRM is resolved comfortably. It offers great flexibility in the design of queries and document templates. With CURSOR-CRM you can use these templates very effectively and thus create documents faster and more secure. At the same time, flexibility means that the administration of templates and searches has to meet increased requirements. Basically, experience shows that good preparation and good organization of activities is the key to success. The term success here means the achievement of the following goals:

  • quick editing for changes and new templates,

  • this work should be as error free as possible and creates

  • good-to-maintain templates as a result.

Based on the lessons learned over time, this chapter provides a number of recommendations on how to manage complex searches and templates. As a scenario, it always makes sense to assume a large number of templates to be edited. This makes problems clearer: even very simple adjustments get a different weight for 200 affected templates.

Under this condition, the 3 goals are:

  • Faster editing

  • better overview and thus fewer errors

  • better maintainability

to discuss the existing solution and ways to reach it.

Faster editing

The question here is: how much time does it take to get templates into the system or customize existing templates? This section describes the most important findings.

Reduction of the number of templates

A simple calculation: the fewer templates you have to edit, the faster you reach your goal. Thus, there should be good organization at the beginning of the work: the existing and the required templates are to be considered in terms of their similarity. Which “families” exist, which horizontal and vertical similarities can be identified? Is it even possible to reach the extreme case: a single template that replaces all similar templates?

Such solutions exist: Offer and contract templates with energy suppliers are often very similar, they differ, for example, in terms of the offered type of energy (gas, electricity) and the product offered (tariff), many elements of the letter (such as the terms and conditions) are identical. In the meantime, we are pursuing the goal of creating as few templates as possible for such letters. This results in so-called “all-in-one” templates for offers and contracts.

Maintain blocks centrally

In many templates, the same information is always displayed in the same way: the address header, the salutation, the sender information. Since it is logical to keep these elements centrally. There is a simple way to do this, even for non-developers: the use of INCLUDETEXT field functions. Redundant information is stored as blocks in a centrally stored file. For changes then, only one place has to be adjusted. This not only applies to individual components, but also to entire documents, such as the GTC. They can also be stored in one place so that they can appear in INCLUDETEXT fields in any letter.

Use of the text replacement file

The text replacement file is a powerful tool for adding or changing settings for multiple templates in one step. Therefore, it is especially suitable for adapting drive paths or file names of files to be inserted via INCLUDETEXT. So you can insert a different sender block into a part of the templates in one step, without having to open them individually. Another simple example is the setting of a fixed zoom factor, which automatically adjusts to the desired value when the letters are opened.

Improvement of the overview

There are mistakes that occur again and again and should therefore be prevented by precautionary measures. They often come about because the administrator finds it difficult to keep track of the many fields, searches, bookmarks, and other elements. The following measures have emerged as a consequence of this situation. They also help to locate and eliminate possible errors faster.

Structure and designation of the complex search

The complex search has fundamental importance for the creation of the letter. It should be set up in such a way that it is easy to understand and in case of emergency it has to be adapted safely. The following advice serves this purpose:

  • The number of complex searches and the sub-searches should be kept as small as possible. A copy of a complex search is quickly created, but at the same time copies of the partial searches are created at the same time, so that one can create 10 or more new searches with just one touch of a button. To compare these later on whether they differ from the original or not, is time consuming and therefore must be prevented as early as possible. Therefore, it is best not to work with copies, but manually create variants of existing searches. Although this costs more time initially, it pays off in the long term.

  • The names of the complex searches and the partial searches should also be chosen wisely. The following nomenclature has proven itself:

    • You always start with the word “WORD_”, because that immediately signals the purpose of the search.

    • This is followed by the complex searches for a narrow term for the purpose: EB (single letter), VTR (contract), ANG (quote), SB (serial letter) and so on.

    • For the partial searches, this second part is about the entities used. Examples would be GP_, AP_ADR, ANLKTO_ANL_AO. From this one can derive on which entity the search is based and also on which it ends. In the main search, you then add the abbreviation “HS”, in table searches you can add the term “Tab”. Finally, numerical values follow. This makes it easier to identify variants or extended children of searches.

  • The aliases of the partial queries should always be written in uppercase letters, as EVI makes the case tables in the mapping tables case-sensitive.

Several small instead of one big complex search

At first, one is often tempted to work with a few, but extensive complexes of searches. However, this complicates the long-term overview, so that the benefits initially worked out can turn into the opposite. It also makes work unnecessarily difficult for colleagues who are familiarising themselves with this area.
Experience has shown that the following procedure is therefore appropriate:

Step 1

You first build a search with a maximum of 5 to 6 partial searches. These provide reliably, in a certain context (for example, quote letters from the activity or letter of a department that always works with given links) the basic data to the address, your own employees and so on. This search is called “WORD_EB_BASIS_01”.
The aliases of the advanced search should be designed so that their first letter is “counted” in ascending alphabetical order. Behind these letters, the sequential number of the complex search reliably, for the basic search thus "01". This results in alias names such as "A01_SEL", "B01_AP" or "C01_GP".
In the course of this complex search, duplicates are created that are not created by copying: instead, you must create a new complex search, to which partial searches are added, so that first real copies arise.

Step 2

Now you put together groups of documents that need the same fields from other entities (for example, attachment, contract or connection). Each of the groups thus created is assigned a copy of the basic search. The sequence number in the name of this complex search is incremented by one, in this case “WORD_EB_BASIS_02”.

Step 3

This complex search will now be extended by further partial searches according to the requirements of the documents. For the aliases of these added searches, the alphabetical nomenclature is continued, with the letter again being appended to the sequential number of the complex search currently being processed, in this example “G02_ANL”.
The advantage of setting such fixed aliases is related to the mappings tables of the template: If you want to compare the mapping tables of 2 document templates, you can sort them easily by the content of the column “Search field”. This sorts the fields in order according to the order of the complex search (s). Now you can export the two mapping tables to Excel and then compare them with a IF-function: { WENN A1 = B1; "Gleich"; "Ungleich" }. In this way, you can quickly get an overview of it with little effort,

  • which fields are present in which templates or not,

  • what complexes of searches they come from and

  • whether they are each assigned to the same bookmark.

Name assignment of the bookmarks

The names of the bookmarks can be chosen arbitrarily. It makes sense to follow an order here as well, in order to be able to more easily recognize later what lies behind the respective bookmark. The following rules for name allocation have proven to be useful.

  • The name of the bookmark has as the first part, the second part of the aliases of the partial search, from which the transferred field comes, for example “GP_” or “ADR_” at partial searches with the alias “G00_GP” or “G00_ADR” ,

  • This alias is followed by a name that references the field. Of course you can use the name displayed on the mask. However, should this change over time, the name of the bookmark is no longer understandable and may even be misleading. Therefore, one should switch to the name of the field in the database or a translation of that name. In our example, "GP_Name1", "GP_Name2" and "GP_Name3" are used instead of the (historically grown) names "GP_Company", "GP_Addition1" and "GP_Addition2".
    Basically it is possible to consider whether German or English expressions should be used for the descriptions. English terms should only be used if it is really likely that the templates should also be edited by employees who cannot work with the German terms.

  • For key fields you should extend the name with an additional element: If you pass the key value, you add a suffix "_K" (for "Key"), for the description field a "_D" (For "Description"). The letters “K” and “D” are automatically provided for serial letter fields for the same function, so you should use them here for consistency.

Include the SET fields in a table

Many templates pass a large number of fields. Since a “SET” field must be present in the template for each field, the result is an unmanageable list. Accordingly, the susceptibility to errors increases. The solution has proven to be to store the SET fields in a table. In this case, each SET field is written in a single field in the first column. This table can be made invisible in letter templates by adding it as a “table in table” in the table that contains the address header. Other solutions would be to format them as "hidden" or to delete them via a vba command after the end of the document creation.

What advantage do such tables have?

  • You can sort your entries, and so compare very quickly in Excel, for example, whether the list of SET fields matches the entries in the mapping table.

  • You can store information about the fields and other useful data in other columns. Here is a suggestion for 3 more columns, as it is already used in many templates:

    • Column 2: It contains a REF field, which represents the transferred value. As a result, it can be determined in the created letter whether the addressed data really gets into the document.

    • Column 3: Here you set the name of the SET field as a fixed text. This makes the test easier, because the name of the bookmark stands next to the given value.

    • Column 4: this provides space for more information. Longer texts can also be stored here so that they are easy to find.
      This solution has one disadvantage: The conversion of the SET fields is no longer possible. CURSOR-CRM expects all SET fields as plain text at the very beginning of the document, but not distributed to one table cell at a time. Therefore, you have to do the comparison between the mapping table and the SET field table manually. For some practice, this is a simple task, which moreover rarely needs to be done.

Measures for better maintainability of the templates

This goal is actually a combination of the two aspects already addressed. A better overview and the use of tools that convert multiple templates in one step are also good prerequisites for effective maintenance of the templates over time. Therefore, only aspects that specifically concern the area of​maintenance are addressed here.

Store master mapping templates

It does not make sense to pass an oversized quantity of fields to the templates for reasons of simplification, because each field costs time. Therefore, you must endeavor to supply the templates at this point only with the necessary fields. Here you can use the existing optimization routine, which reduces the mapping table to the really required bookmarks in the template. However, you probably get a different quantity of list entries for each template. If you now have to add another field to one of the templates, you must also check whether and, if so, under what name the field already exists in other templates.

From these contexts, the following solution has proved to be practical: you divide the templates into groups to which you assign the same mapping table. The loss of time in some of the templates due to superfluous bookmarks is bearable. For these groups you then create a template by copying, which is set to inactive and whose sole purpose is to “keep” the mapping table. It can also serve as the source for the SET fields table, which is the counterpart of the mapping table.

If you make changes, you must extend this master mapping table and then apply it to the individual templates via the corresponding button. Of course you must also adjust the SET fields table in the template. The easiest way to name a mapping template is to use the following structure:

CODE
"_Mapping_Master_[Name der komplexen Suche]"

With the underscore, these searches are always at the top of the lookup lists, making them easier to find.

Create a central working directories

You should create a directory outside the application where you save backups of the templates, the file for the text blocks, the text replacement file and other materials.

The following terms have proven to be directory names:

  • 01_Dokumentation

  • 02_Templates backup

  • 03_Fuse of the vba modules

  • 04_Textersetzungsdatei

  • 05_Textbausteine

So you have the same environment in the long term and can facilitate familiarization with a foreign environment for colleagues.

Macro security

Word and Excel macros must be able to run on the client machine.

The following options are available for this:

Microsoft Word

  • Reduce security settings for macros in Word to “Enable all macros”
    OR

  • Include the local document directory from the Windows Client and the Web Client in the list of trusted locations.
    The distribution can be done by group policy:

    • Windows Client key


      • Key path = HKEY_CURRENT_USER\Software\Policies\Microsoft\office\16.0\word\security\trusted locations\location4

        • The version must be adapted accordingly, e.g. 14.0 = Office 2010

        • The number of the trusted location (location[n]) is to be assigned individually. In our example, this is the fourth trusted location (location4).

      • path = %USERPROFILE%\<productName>, type = REG_EXPAND_SZ instead of REG_SZ (otherwise the environment variable will not be resolved)
        e.g. %USERPROFILE%\EVI

      • allowsubfolders = 1, type = REG_DWORD, meaning: Subfolder allowed

    • Web Client key

      • Key path = HKEY_CURRENT_USER\Software\Policies\Microsoft\office\16.0\word\security\trusted locations\location1

        • The version must be adapted accordingly, e.g. 16.0 = Office 2016

        • The number of the trusted location (location[n]) is to be assigned individually. In our example, this is the first trusted location (location1).

      • path = %USERPROFILE%\CURSOR\WebClient, type = REG_EXPAND_SZ instead of REG_SZ (otherwise the environment variable will not be resolved)

      • allowsubfolders = 1, type = REG_DWORD, meaning: Subfolder allowed

  • Extended substructure (from version 23.1)
    The structure of the storage locations has been extended. A distinction is now made between generated and imported documents.
    The generated documents are trusted and are stored in the "internal" sub directory.
    Imported documents, such as those added by a user using drag and drop, can potentially be security critical and are therefore "stored in the "external sub directory.

    If you want to take advantage of this new distinction and classify imported (external) documents as an untrusted source, the trusted storage location must be restricted to the internal sub directory.
    Without changing the trusted storage location, the behavior is identical to before. Both generated and imported documents will continue to be trusted.

    Examples of internal sub directory:

    • Rich Client:
      path = %USERPROFILE%\<productName>\<server_port>\tmp\document\internal
      allowsubfolders = 1 (because of existing sub directories)

    • Web Client
      path = %USERPROFILE%\CURSOR\WebClient\<server_port>\internal
      allowsubfolders = 1 (because of existing sub directories)

Microsoft Excel

  • Reduce security settings for macros in Word to “Enable all macros”
    OR

  • Include the local document directory from the Windows Client and the Web Client in the list of trusted locations.
    The distribution can be done analogous to Word by group policy. The key path here is to replace word with excel, e.g. HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\16.0\excel\security\trusted locations\location1

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.