Printing in ClassiX^®

This documentation shows the ClassiX^® user, how Word and ClassiX^® – Printing work together. At first it is explained, which Word documents participate in the printing in which way, before describing a print form. Finally it is explained with selected examples, how Word accesses database information.
This documentation explains which Word document modifications cause what changes in a form printout.

1. Working with Word         1.1 OleBox         1.2 Formatvorlage 2. Word Document Groups         2.1 Master Data Documents         2.2 Anschreiben- und Fußdokumente         2.3 Text Modules         2.4 Document Modules 3. Überblick Formulare         3.1 Dokumente                 3.1.1 Baumdarstellung                 3.1.2 Ex- und Importieren von Dokumenten         3.2 Dokumentbausteine                 3.2.1 Bedingte Dokumentbausteine                 3.2.2 Ex- und Importieren von Dokumentbausteinen 4. Dynamische Datenfelder 5. Häufige Probleme und Fragen

Forms

PDF Source File

1. Working with Word

1.1 OleBox

The OleBox generates the interface between ClassiX^® and the Word- and Excel documents. Double-clicking a displayed OLE object [1] starts the equivalent application and the OLE object can be processed.
Similar to a MLString widget [2], the MLOleBox is capable of multilinguality. The language can be changed via keys PgUp/PgDown. For better orientation, the current language gets indicated in the top right corner of the widget by a specific amount of triangles.

After editing a Word document, there are different ways of saving it and returning to ClassiX^®. The more correct ways are the ones via menu (file -> close) or via close button. Closing the document via "Close and return to..." is not wrong but it takes longer.

The Word documents behind an OleBox can also contain document variables which will be described at a later time. When updating information from behind these fields, it is also possible to update the OleBox. This happens via Refresh button.

1.2 Style Sheet

To realise a harmonic appearance for the Word documents, ClassiX^® makes use of the style sheets.

A style sheet is a group of formatting characteristics, which can be applied to the document text to quickly change the outer appearance. If you apply the style sheet, you adopt such a formatting group at once.

Starting Microsoft Word, the new, empty document will be based on the template normal and the entered text will use the style sheet default. When entering the text, Word uses font, font size, line spacing, text alignment and other formats that have been defined for the current default style sheet. 

Since the style sheet is saved locally, Word documents which have been created on different computers will have a different formatting. Besides the effect that there will be a large formatting variety, there will also the the following problem:

When printing, Word texts will also be inserted into other documents. This happens via Word copy function. Since the copy function only adopts content and significant format changes, the text appearance can change in the printout. 

Example:

When copying a Word text, only content and additional formats will be adopted. That way, font size and additional specification "bold" will be adopted into document2. The new font though will be "Times New Roman".

To prevent this problem, every new Word document in ClassiX^® will have the same style sheet. This model ("classix.dot") is saved in the /ClassiX/system directory. To generate all new Word documents with the font size 12, this simply needs to be defined in classix.dot.

2. Word Document Groups

2.1 Master Data Documents

Master data documents are used in ClassiX^®, to describe the object which hold these documents. This type of Word documents for example describe for example sales items and conditions. Master data documents will appear without any changes on the printout, since they usually contain pure text.

2.2 Anschreiben- und Fußdokumente

These Word documents are used for quotations and orders. Other than pure text, they contain fields [3], which ClassiX^® fills with information. That way, it is not necessary for the person who processes a quotation, to put their name under each quotation. Instead, they can define a field, which reads out this information for them from the database and prints it out in the form.

2.3 Text Modules

Text modules are mainly used when generating a proceedings transaction, such as a letter. They are different to documents which are used to print complicated forms. While a form consists of multiple modules, a proceedings transaction generally consists of only one Word document.  Text modules are the model for a proceedings transaction. When generating a transaction, only one text module copy gets generated and which will then be used. With this, text modules contain almost only fields, since the text will be individually entered via user into the copy.

2.4 Document Modules

Document modules are used to create a complex form. They only consists of fields or text, which is the same for every printout. In contradiction to the text module copies, the user has no influence on the Word documents. While in text modules, only text information is inserted into the documents, completely different Word documents are imported in document modules. These are mainly master data documents. 

3. Form Overview

3.1 Documents

A document usually describes a form printout. This can be done for example via document modules which are supposed to be used in the form, as well as via Randeinstellung and document type etc.. That way, documents can be assigned via type to the following business fields:

purchase sales production warehouse financial accounting controlling others

As mentioned before, document modules which build the form are indicated in the documents. Usually in the document, the indicated module order also defines the order in which the modules will be combined in the form. But there are also exceptions. In the order for example, there is a fixed, predefined order which cannot be changed by the module order. Header and footer as well as balances are also repeated on each side, independent from their position in the module list.

3.1.1 Tree Display

The tree display mainly helps analyse the document build-up. The major advantage is, that also sub-modules of document modules are displayed, while only the first level will be displayed in the module group. The document module types can be read off the symbols used in the tree. Other than that, ID, name and type in brackets will be displayed.

3.1.2 Document Export and Import

Exporting and importing documents has the following advantages. That way, it is for example possible to save/archive documents outside the database or to modify them in a test system and to adopt them into the running system via import/export.

Documents can simply be exported via selection window. For this, please select the particular documents and click on the floppy disk symbol in the toolbar. Then select the FileDialog window in the folder, in which the form(s) are supposed to be saved. Result will be a 'document.dat' and 'component.dat' as well as numerous Word documents in the folder.

Document indications can be found in 'document.dat' - the document name and modules.
    DOCUMENT      1e   T("purchase at call order", "") 1     25,00 mm  0,00 mm  10,00 mm  5,00 mm
    COMPONENT     1e   KOPFZEILE
    COMPONENT     1e   1e
    COMPONENT     1e   9
    COMPONENT     1e   3
    COMPONENT     1e   4e

Specifications about the document modules are indicated in the 'component.dat'.
    COMPONENT     4ae  T("Bestellung (Unterposition)", "")  5    16
    COMPONENT     6    T("Bestellung", "Purchase Order")    7    8
    COMPONENT     4e   T("Bestellung", "Purchase Order")    5    1
    SUBCOMPONENT  4e                                        4ae
    COMPONENT     3    T("Bestellung", "Purchase Order")    3    8

The remaining files are Word documents which belong to the modules. If a file name consists of two numeric values, it is a simple module. In this case, the first value describes the ID and the second value describes the the language. Otherwise, it is a conditioned module. While the first value still describes the ID, the second value stands for the condition and only the third one for language.

The following will describe the difference between simple and conditioned document modules.

The import happens via monitor window  [4], which executes the command  "ZERO SendMsg(LOAD_DOCUMENT)". IN the FileDialog, please select the 'document.dat' and the 'component.dat' which have been exported or installed before. When loading documents, it is important, that the ID has not been assigned yet, since this would cancel the process. In the window on the right, it is possible to select, what process will be applied to the modules.

3.2 Document Modules

Document modules are wrapping objects for Word documents, which are being used for printing a form. Other than Word documents, they also hold information such as ID, name, type and module type. In addition, it is possible to insert sub-modules, which are -when printing the module- considered in the specific order in which it is also listed in the sub-module list.

The type has large influence on the module print. It is only possible to place list balance at the equivalent location at the top and bottom via header and footer. It is important, that the document header displays the headline on each page, starting with the second page. The article about conditioned modules will provide more information about this.  Moreover, the check boxes 'New page in front of the module' and 'New page behind this module' help control document module output.

Document modules are specified by their type. Other than the type 'no content', which is only used as a container for further sub-modules, there is 'simple' and conditioned document'. While a 'simple document' only contains a Word document with the different languages, it is worth taking a closer look at the 'conditioned modules'.

3.2.1 Conditioned Document Elements

A 'conditioned document module' can be generated by selecting the document type in the DropDown menu. Here it is possible to use the option of adopting the content of a simple document into the condition. Either way, the following picture will appear.

Selecting an item in the new table leads to the opening of a new window, which in turn navigates to the Word object. Moreover, it is possible to indicate the position name and condition. New items can be created and deleted via right-click in the condition window. Creating new items there is even the possibility of selecting a predefined condition. All regular expressions which return TRUE or FLASE, are allowed as conditions and with this, it is possible access all used variables and objects.

The following example might give more details. Document heads in ClassiX^® generally consist of conditioned modules. That way, there is a Word document, which is used for the first page and one each for the following pages, depending on the logged clients.

The current page number is generally accessed via access path print.counter. That way, the condition print.counter=1 returns a TRUE when the first page is currently getting printed. The next paragraph will explain the structure of the next conditions. It is obvious though, that two conditions can be connected logically. The next condition only returns TRUE, if var(cyberEnterprise).uniqueID=“001“ as well as print.counter>1 are fulfilled.

It needs to be mentioned, that it is possible to return one Word document only. Whenever there are two fulfilled conditions, only the Word document in the top item gets returned. That way it can be an advantage to be able to move the items with the arrows on the right.
 

3.2.2 Exporting and importing document modules 

Exporting document modules is similar to exporting documents. For the export, please select the modules in the according selection window and click in the floppy disk symbol. Since this does not require a document, only the component.dat will be generated.
The import gets executed via message LOAD_DOCUMENT_COMPONENTS.

4. Dynamic Data Fields

The connection between the module and the ClassiX® system gets created by inserting document variables. This happens via menu Insert/Field. A window gets opened, which provides the required field selection. The document variable can be found under the category document automation as a field name DocVariable. Button 'OK' generates a new document variable. The entry {DOCVARIABLE \*MERGEFORMAT} will be inserted into the document. The checkmark in the checkbox can generally be taken away. Keeping the checkmark where it is makes the DocVariable content get exported uniformly. There are two modes for displaying  DocVariablen. Via key combination Alt+F9 it is possible to switch from the detailed {DOCVARIABLE ID \*MERGEFORMAT} to the shortened mode << ID >> and back.

From now on, there are different ways of accessing information in the ClassiX^® database. When printing, at least one object will be passed to Word.  That way, it is possible to access all information about this object and about objects that are connected to the original object via access path.

This method does not only make it possible to export a simple text or numbers, but also Word text such as condition- and sales item descriptions. Word objects are always accessed via access path, which ends with mlWordDoc. Just like multilingual text can be accessed via mlDescription, the equivalent language will be returned for the document and inserted where the field is.

The second is to access used variables in ClassiX^®. There are for example variables, which always describe the same. CyberEnterprise always holds the object of the current client, user always represents the current user and printObject is always the object, which is currently getting printed. Variables that are used only sometimes are being added. When printing, it is for example possible to access the variable tmpCondition  to export information about the condition, which is currently getting printed.

These two methods are not optimal though, when exporting collection [5] values or for complex access paths, which cannot be displayed in Word. For this, ClassiX^® provides the option of directly accessing macros which are defined in the modules. The print object will be passed to the macro via field name call (macro name) and the code behind it will be executed.

It is important to define the macro in one of the print modules, too. One value needs to be returned - generally this should be a string. 

In connection with accessing information with the so far introduced methods, there is also the option of using the ClassiX^® base methods from the print object.

In connection with the document variable, it is possible to use further Word field functions. Some of the most important ones is the IF condition. This branching option is always structured as follows: 

 { IF condition "statement true" "statement false"}

In this fields, it is also possible to access information via DocVariables. It is important to use double apostrophes. This is not necessary, but it can lead to evaluation errors. But not only IF conditions, but also formula expressions, etc. can be used.

Another option to use IF conditions is, that the redundant blank line can be avoided. The following example makes this clear:

5. Common Problems and FAQs

IF Conditions are not interpreted correctly in Word
ð	Here it can help to put condition blocks, which are compared to each other into quotation marks. Sometimes, this is actually necessary. If a condition expression is supposed to be compared to NOTHING, a space character needs to be inserted in between the quotation marks. { IF "Expression" = " " ..... }
Word gets cancelled with a problem report
ð	in the old print method, it is not possible to join table cells vertically.
		no modifications possible
ð	There might be a syntax error in the document variable. It is possible to use the print window title to find faulty documents.
ð	There are too many Word documents in the according TEMP folder, which have been generated by Word itself. These should simply be deleted.
Text blocks look different in the printout than in ClassiX®
ð	It should be checked, whether document modules and the eventually involved Word documents have the same style sheet (see chapter 1.2)

ñ

[1] OLE ("Object Linking and Embedding", is commonly known as a Microsoft framework for a compound document technology, which is based on the COM-specification. COM is short for "Component Object Model".

[2] Fields inside a window

[3] Fields are used as place holders for changing data in a document or to create serial letters in serial documents.

[4] Windows for direct entry, which can be accessed via [ALT] + [right-click]

[5] Object collection in ClassiX^®, which is connected to an access path