Changelogg

It is now possible to directly invoice orders and receive the invoice immediately.
This is managed through a new object (config) associated with the order.

The option to send invoices via FTP has been removed, as this is no longer a preferred delivery method.

NLIKE allows you to filter data in the same way as NOT LIKE in SQL.
Example: &filter[property][NLIKE]=Arn% filters out all values that do not start with "Arn".

• For customers, customerNumber is now required. Customer number can still be changed by PUT and PATCH.
• For suppliers, supplier number is now required. Supplier number can still be changed by PUT and PATCH
• For artice, articleNumber are now required.
• For artice, articleNumber are now required.
• For employee, employeeNr are now required.
• For project, carrier.key are now required.

Crossing claims with payments in accounting means matching an incoming payment to outstanding invoices or receivables, marking them as settled. When a customer makes a payment, or we pay a suppliers claim, it is linked to the corresponding invoice in the accounting system. If the payment does not cover the full invoice amount, it is partially crossed, leaving the remaining balance outstanding. A single payment can also be applied to multiple invoices, distributing the amount according to a predefined priority. This process ensures accurate financial records and provides a clear overview of outstanding receivables and payments.

There are several ways to cross claims with payments:

• The payment can be included in the same voucher as the incoming payment.
• A single incoming payment can cross multiple claims.
• The crossing follows the order in which the claims are listed.

• The claim and payment can be in separate vouchers but submitted at the same time.
• Multiple claims can be crossed with a single payment.
• The crossing follows the order of the claims.

• The claim's ID can be submitted in IdsToCross within VoucherCreateConfig for the payment.
• Multiple claims can be crossed or partially crossed with a single/multiple payments.
• The order of IDs in IdsToCross determines the priority of the crossing.

The crossing process is optimistic and not guaranteed unless all prerequisites are met. Here are some possible reasons why crossing might fail:

• The accounting year covering the selected voucher dates is closed, and the system could not find a suitable accounting year.
• A selected ledger entry is already crossed or has the LedgerState "Locked".
• Voucher lines contain missing or invalid ledger references.
• Not all voucher lines have a reference to a ledger.
• At least two vouchers must have the LedgerState "blank" or "partCrossed".
• Among the voucher lines available for crossing ("blank" or "partCrossed"), at least one must have a remaining balance above 0, and at least one must have a remaining balance below 0.
• Database storage failed, most likely due to an invalid voucher line reference.

To confirm that a crossing was successful, a lookup must be made of the requirements and the LedgerState and RestAmount must be looked at.