Archiving outgoing documents

This process takes printed outgoing documents – invoices, delivery notes, order confirmations – into the archive automatically and links them to the SAP document. It runs unattended in the background and consists of two steps: first the documents of the period are produced again, then the resulting files are archived.

The most frequent question about this process is why a document is in the archive twice – or the other way round, why one was skipped. That is decided by the duplicate check further down.

When it runs

The process is driven by a timer of type C (also written REPRINT), set up under timers. It handles the period since its own last run up to now.

Two things must be true for the timer to do any work:

• The timer is due and active.
• The user running it holds the ECM-Connect permission.

Without the permission it stays silent

Without the ECM-Connect permission the timer is booked as executed while doing nothing: the next run is scheduled, nothing is archived. From the outside that is indistinguishable from a run that found nothing to do. When a timer appears to run but never archives anything, check the permission of the user running it first.

What happens

Step 1 – produce the documents again

The print output is produced again for every outgoing document of the period. The files land in the print folder and carry a name the next step uses to recognise the SAP document they belong to.

A problem here does not stop the archiving

If this step reports an error, step 2 still runs and archives whatever is in the print folder. The log carries a warning with the reason. That is deliberate: files already produced should not be left behind because a single document caused trouble.

Step 2 – archive the files

1. Connection and database are checked. Without the archive connection, or when the link table deviates from the expected structure, nothing is archived – every file stays where it is. That is on purpose: a document that reaches the archive but cannot be linked to SAP would be uploaded again on every further run.
2. The print folders are read, filtered by the permitted file extensions.
3. Locked files are skipped. A file still being written is not touched – it is picked up on the next run.
4. The file name is split. Separated by underscores it carries the SAP object, the document number, the document category and optionally the draft flag. With fewer than four such parts the file is not processed and stays where it is.
5. For the category "print" the duplicate check applies – see below. For "scan" it does not.
6. The file is archived, indexed, and the link entry to the SAP document is written. From then on the document is reachable from the document itself.

The timer counts as run even after a failure

If a step fails, the timer is still booked as executed and starts again at its next due time. Otherwise the same job would return every few minutes with the same error and block every other timer. So do not read the success of a run off the timer, but off the log and the ECM monitor.

Duplicate check

The question is: may a document that is already in the archive be archived again?

Two statements decide it:

Statement	Where	Applies to
Parameter NODUPLICATES	on this timer	this one timer only
Setting ECMALLOWPRINTDUPLICATES	in the settings	every archiving run

The timer parameter is the more specific statement and wins where it is set. It can only ever forbid duplicates – there is no parameter that allows them against the setting.

NODUPLICATES on the timer	ECMALLOWPRINTDUPLICATES	Result
not set	yes	duplicates allowed – every run archives the document again
not set	no	documents already archived are skipped
set	yes	skipped – the parameter wins
set	no	skipped

The spelling of the parameter does not matter; NODUPLICATES, noduplicates and NoDuplicates all work.

What counts as a duplicate: an existing archive entry is looked up for the combination of SAP object, document number, archive object and draft flag. If one exists, the file is not archived again.

The shipped default allows duplicates

ECMALLOWPRINTDUPLICATES ships as Y – "duplicates allowed". Whether it still says so in your system is shown in the settings reference, looked up at your own value. When documents appear twice in the archive, that is almost always the cause, not a fault of the archiving.

What steers it

This process reads its instructions from the existing settings, and that is where they are described:

What	Where
Timer, schedule and parameter	timers
Print folders, file extensions, duplicates	settings reference
The categories "print" and "scan"	document categories
Target archive and indexing	repository · document types
Watching a run	ECM monitor

What can go wrong

A document is in the archive several times

The duplicate check did not apply. Check in this order:

1. Is NODUPLICATES set on this timer – not on another one?
2. What is the value of ECMALLOWPRINTDUPLICATES in your system? It ships as "yes".
3. Is it the category "print"? For "scan" no duplicate check takes place.

Nothing is archived at all, the files stay put

The log then reads nothing was archived with the reason:

Reason in the log	Meaning	Remedy
no DocuWare connection	there is no archive connection	check the connection data and whether the archive server is reachable
no DocuWare REST client / no DocuWare request	the connection was not built completely	restart the service; if it persists, check the connection settings
no path was handed in	no print folder is configured	set the print folder in the settings
no file extension was handed in	no file extension is configured	set the permitted extensions in the settings

Message "table @… does not match the expected structure"

Table @… does not match the expected structure, missing fields: … – archiving skipped, please update the database structure

The link table is missing fields. The run stops before the first upload so no documents end up in the archive without a SAP link. The message names the missing fields; the database structure is updated through the installation. After that the timer carries on by itself.

A single file stays behind while the others are processed

Two possible causes:

• The file is locked because it is still being written. It is processed on the next run – nothing to do here.
• The file name does not fit. It needs at least four parts separated by underscores. Without them the document cannot be matched.

Documents are archived but not indexed

The log reads the files were archived, but the indexing did not succeed. The documents are in the archive and linked to SAP but keep their old index values. The run can be repeated; the indexing is then caught up.

The document cannot be opened in the web client

The archive … has no result list, so the document cannot be opened in the web client. Please assign a result list to the archive.

The archive has no result list. This only affects opening in the web client, not the archiving itself – the document is there.