Overview This presentation will be answering these main

Overview This presentation will be answering these main questions about Auto. Doc: • What does it do? • What is it? • How does it do it? “Starting from the finish” – this is the most effective way to explain Auto. Doc.

What does it do? Consider the familiar scenario… 1. Your financial software creates an invoice. 2. The user (Peter Mc. Kenzie from ‘XYZ Electrical’) elects to print it. 3. Without Auto. Doc, the invoice hits the printer tray like this. . .

Note the highlighted areas we’ve chosen to represent key information for this example.

With Auto. Doc installed, instead of the invoice hitting the printer tray, it’s sent, completely automatically. . . and the invoice is attached like this. . .

Note the letterhead, which is added automatically as part of the print operation.

If the debtor prefers to receive invoices by fax rather than (or in addition to) e-mail, printing the invoice would produce, and send, this. . . where the invoice is the second page of the fax transmission

As well as: • E-mailing, and • Faxing. . . the single print operation can also archive a PDF copy of the invoice. Where? And under what filename?

As in the e-mail and fax functions, you can use the key information from the document. For example: None of these folders existed before the print operation.

In addition to the single print job producing: • E-mails, • Faxes, and • Archive files. . . you can, of course, also print a hard copy.

What is it? • To the end user, Auto. Doc is simply another printer which can be selected to handle a print job. • Auto. Doc printers are virtual copies of existing printers, including those printers’ settings.

Auto. Doc also has a multi-tab configuration console which allows the administrator to define what delivery methods should be applied to a document.

How does it do it? Key concepts/entities: • • • Metadata Font Colour Textual Commands Variables Forms

Metadata: • ‘Data about data’ • Came into prominence with XML • Is the driving force behind XML – allows data to have ‘meaning’ as well as content.

• XML uses ‘tags’ like ‘<doctype>invoice</doctype>’ to encode a text string with meaning • Auto. Doc does not use XML, but is based on the same metadata principle – text is ‘encoded’ so Auto. Doc ‘knows’ when, for example, a document is an invoice • Auto. Doc uses colour to encode metadata

How does it do it? Key concepts/entities: • • • Metadata Font Colour Textual Commands Variables Forms

Font Colour: • Using our earlier example, the invoice text ‘Tax Invoice 1038’ may be produced from a report writer as ‘Tax Invoice 1038’. • Auto. Doc is then configured to recognise red text as representing ‘document type’, and green text as representing ‘document number’.

Why use font colour? • Simplicity • Many applications are capable of producing coloured text • Allows integration of Auto. Doc with existing tools and processes, with minimal change required

How is font colour recognised? • Using the ‘RGB’ (Reg/Green/Blue) settings.

Now consider these RGB settings: • 255, 255 = white = ‘invisible’ • 0, 0, 0 = black (like this) • 10, 10 = ‘not quite black’ (like this!) So, looking at our invoice again. . .

Font Colour Summary: • Built in to many applications • Can be report driven (e. g. automatically ‘coloured’ output from a report writer) • Any pre-existing content can be colour coded, or new content can be added and hidden in white text • You can define the colours for which Auto. Doc looks

How does it do it? Key concepts/entities: • • • Metadata Font Colour Textual Commands Variables Forms

Textual Commands: • Four main command types: 1. 2. 3. 4. • • E-mail address Fax number Form number Language identifier Form number tells Auto. Doc which set of configuration settings to apply Language identifier tells Auto. Doc which of the language tabs to use for e-mail body text and fax cover page text (e. g. ‘EN’ for English ‘FR’ for French)

• The ‘trigger’ for the recognition of textual commands is colour based – you tell Auto. Doc the colour in which the commands are coded. • The default setting is white.

How does it do it? Key concepts/entities: • • • Metadata Font Colour Textual Commands Variables Forms

Variables: • Used to construct dynamic content on the fly. • Allow you to define a template which is populated differently for each circumstance. • In the invoice example, ‘document type’ and ‘user full name’ were two variables used.

• Two main types: 1. Predefined system variables • E. g. date/time stamps, user information such as phone number 2. User-defined variables • • • E. g. ‘document type’, ‘account number’ Always based on document content Identified by RGB settings of document content 20 variables available Names and RGB settings are user-defined.

• Variables can be used in ‘templates’ for document delivery. • In addition to this, variables can also be used as content to use in an optional XML attachment. • Trim function allows portions of variable content to be used.

How does it do it? Key concepts/entities: • • • Metadata Font Colour Textual Commands Variables Forms

Forms (‘templates’): • Contain delivery configuration settings • Auto. Doc knows which form to apply since the form number is specified in the source document as a textual command • 99 different forms available • The 20 user-defined variables are redefinable in each form (=99 x 20 variables)

All of these areas can be configured on a form-by-form basis

Delivery Features • Built in e-mail client • Microsoft® Fax or Symantec® Win. Fax® • Multiple means of storing copies of sent documents/e-mails/faxes • Definable user info can be incorporated into deliveries • Letterheads definable on first page and subsequent page basis

• Letterheads optionally applied to e-mail, fax, archive, and print output, with no pre-printing cost • E-mail can be plain text or HTML-rich content • Definable PDF quality for e-mail attachments • CC and BCC e-mail capability • User profile-overrides for sending e-mail

• Faxes can be scheduled as per fax service options • User profile-overrides for sending faxes • Multiple archive paths available per print job • Existing archive documents can be overwritten or appended to • Two modes of printing: multi-drop and exception-based (if not sent or e-mailed)

Deployment • Personal and Server editions. • Regardless of which edition, Auto. Doc only needs to be installed on one machine. In a network environment, the Auto. Doc printer is simply set up as a shared printer.