Store service report as document
In some cases, it may be useful to store the created report for future reference in the database. The report is then stored as an attachment on the OMD database, attached to the related task.
External systems can retrieve the stored servicesheet to transfer it into their local database for documentation purposes.
Note that, apart from properly closed tasks, the report for cancelled visits is also stored in the OMD database, if this preference is set to true
.
In case the email on the task is empty and no forwardEmail
or forwardEmailBCC
address is defined, this preference will not cause the report to be stored.
This preference will produce more content on the database and more traffic during exchange with external systems. The servicesheet will be purged like any other attachment, according to the purgeAttachments
preference.
serviceReportStoreAsDocument | ||
---|---|---|
Type | Default Value | Example |
Boolean | false | true |
In case multiple tasks on a tour are related to the same debtor and service sheets are sent to the same list of email addresses, OMD can collect the service sheets and send them in one mail. To enable this behaviour, set the preference serviceReportCollectMultiple
.
serviceReportCollectMultiple | ||
---|---|---|
Type | Default Value | Example |
Boolean | false | true |
If multiple service sheets are collected, OMD offers an indicator attribute collectiveMail
within the XML Task element, which is processed by a subject line template, referenced by serviceReportSubjectTemplate. By this, the subject of the collective mail can alter from the standard subject line.
If the preference serviceReportCollectMultiple
is enabled, mails with single service sheets, related to the same debtor are collected in the mail queue, with status in preparation
. Since another related task could remain unclosed for some reason, OMD will consolidate the group of pending mails after some time and yet send them without waiting for the unclosed task. The number of hours to wait can be set by the preference serviceReportMailAgeLimit
. This wait timeout can be disabled by setting the value of 0 hours.
serviceReportMailAgeLimit | ||
---|---|---|
Type | Default Value | Example |
Integer | 10 | 0 |
In case an image was attached to a task, the system sends an email to the address given with the related territory. When the image was attached to a note, an email is created in relation to the note instead. The preference sendNoteImageEmail
enables the system to always send the image email to the territory's address. This preference is related to images directly captured with the camera, it is not related to images attached to a mobile note.
sendNoteImageEmail | ||
---|---|---|
Type | Default Value | Example |
Boolean | false | true |
See the process flow preference allowNotePictures
for more details.
The preference serviceReportRequiresSignature
adds an additional check for given signatures, before sending service sheets to customers. Setting this preference to the value signature
disallows any sending of service sheets for tasks without a customer signature present. The value resourceSignature
enables sending, even if a signature was alternatively given by the resource. However, this check does not affect sending the service sheet to other addresses, like those defined in forwardEmail
, forwardEmailCC
or forwardEmailBCC
.
serviceReportRequiresSignature | ||
---|---|---|
Type | Default Value | Example |
String | empty |
resourceSignature |
The preference directEmail
steers the behavior of sending the report by email. If set to true
, an attempt to send the email is made immediately after the report has been generated. If set to false
, the generated email will be stored in the mail queue for later processing.
directEmail | ||
---|---|---|
Type | Default Value | Example |
Boolean | true | false |