Define password properties in your own JobStep: Password property in JobStep

When grouping article details with custom objects, the custom objects were lost. I.e. they were not transferred to the created message. This error has been fixed.

The CustomObjects from the article details must be saved in the message structures, e.g. in eBiss.Supplier.SupplierArticleDocument, in a different way than in the database. CustomObjects created or regrouped in the mapping will be lost.

If you assign a rule set of the type “non-list element” multiple times in the mapping, a list of objects is saved in the background. This is wrong, only the last data record may remain. It was also not visible in the object instance created in the mapping, only one value was displayed there. If you opened a subsequent mapping with it, only the last data record was visible there. If you then assigned this element, which is only visible once to a rule set of the list type, then just as many list entries were created as were previously 'triggered' in the first mapping.

The error has been fixed:

• If you trigger a rule set that is not a list, then only the last value is saved. This means that each new value overwrites the previous one.
• If a data source is loaded in which several lines are saved for a non-list RuleSet, then only the last one is retained.

• Selectors are not copied: When copying mapping rules, it could happen that selectors were not copied as well. The error has been fixed permanently. Previously, the number of copied lines was sorted out “by hand”. As of this version, copying mapping rules uses exactly the same code as saving the mapping.
• Order not correct: Pasting multiple rules on a rule (not a rule set) would cause the order of the rules then pasted to be reversed. This error has been fixed.

New mapping function SetDocumentSubType.

Adaptation of the help to: Distribute eBiss Client on PC.

When setting filters, e.g. for process instances, an error could occur if the DataReader was already open. This error has been fixed.

The time when a hardware change was detected and the license became invalid could occur with a considerable delay. For example, a change to the hardware could only lead to an invalid license after a few days and the eBiss service abruptly stopped running jobs. This was due to the fact that the check was dependent on several parameters, including actions on the user interface.

Both the fact that the service does not immediately stop processing and the delayed occurrence have been fixed.

The process has been simplified so that if the system is running, a change in hardware is detected after two to six hours and the license becomes invalid after two to six hours. However, the system continues to run for a further 53 - 68 days without the service being affected in the background. Even if the eBiss service is restarted, it will continue to run. Only after the period of 53 - 68 days will no more jobs be executed. This means that there is enough time to detect the problem via the WinClient or the Task Notifier.