Skip to content

Configuring accounting

The accounting form in invoiceR can be configured in great detail. This page describes how the forms are structured and the settings that control the behaviour of the accounting step. How users do the accounting is described under Accounting.

Further pages on this topic:

  • Accounting fields: showing and hiding fields, dependencies between fields, width of selection lists.
  • Accounting buttons: additional buttons above the accounting table, for example for an Excel import.

The forms are defined in the database:

TableContent
conf.AccountingFormsthe forms (accounting variants), optionally per organization unit and process type
conf.AccountingFieldsthe individual fields: data field, label, editor type, width, visibility
conf.AccountingFormFieldswhich fields appear in which form and in which order
conf.AccountingFormMapperswhich form applies by default, optionally per role, organization unit and process type

A field is therefore described once in conf.AccountingFields and included in one or more forms through conf.AccountingFormFields. The data editor uses the same tables.

If there are accounting variants that are completely independent of each other, the simplest approach is to create several forms. Users can switch between forms while editing an accounting line.

If the variants only differ in that individual fields are hidden or locked, one form is enough. Control the status of the fields concerned instead, see Accounting fields. This avoids an unmanageable number of forms.

If a document is already fully accounted for, invoiceR skips accounting and sends the document straight to approval. Fully accounted for means: the document amount is not zero, and the total of the accounting lines equals the document amount. This is the case, for example, when default accounting from the assignment rules distributes the full amount.

If someone requests new accounting from approval, for example, the document would already be accounted for and would skip accounting again. To prevent this, store this configuration on the route that leads to the automatic assignment step (ConditionalAssignmentNode) (column Configuration in conf.Routes):

{ "SkipAutomaticProceed": true }

Documents arriving via this route then always go to accounting. If the same entry is in the configuration of the step itself (conf.Nodes), it applies to all documents.

Change detection recognizes when a user changes specific values in the document header or in an accounting line and then triggers an action. Possible actions:

  • log the change with the old and new value in the history,
  • delete approvals already given on the accounting line concerned.

Change detection is stored as a list per process step in the step’s configuration (column Configuration in conf.Nodes). If the list is missing or empty, invoiceR checks nothing, which saves processing time.

{
"ChangeDetection": [
{ "Place": 0, "LogLevel": 0, "VisaResetLevel": 0, "PropertyName": "SupplierId" },
{ "Place": 1, "LogLevel": 0, "VisaResetLevel": 2, "PropertyName": "AccountId" }
],
"SkipValidationForProceedSaving": false
}
EntryMeaning
Placewhere the property is: 0 document header, 1 accounting line
LogLevelhow the change is logged: 0 debug, 1 info, 2 warning, 3 error
VisaResetLevel0 approvals are kept, 2 approvals on the line are deleted (1 warning is not implemented)
PropertyNametechnical name of the property, for example AccountId, CostcenterId, SupplierId

In the example, a change of supplier is logged. If someone changes the account of a line, the approvals on that line are deleted.

Change detection runs within validation. If a change would delete approvals, the user first gets a warning. Only once they confirm it are the approvals deleted.

For the warning to appear when the user clicks the green button to forward the document as well, validation must also run on forwarding. To do this, set "SkipValidationForProceedSaving": false in the step configuration (the default is true).