Abakion Legal 28.0.202641.6849

In the Adjust Client/Job Liability report and in Invoicing Setup under the Liability group, you could previously only control the text on the adjustment lines with Adjustment Text and Main Adj. Text, and only with the merge field %1. The text on the balancing account could not be controlled independently.

Two new optional fields have now been added: Bal. Adjustment Text and Bal. Main Adj. Text. They are used as the description on the balancing account in the journal lines. The fields are available both on the report's request page under Options and in Invoicing Setup under Liability, and they work like the existing text fields. If they are empty, the result is unchanged. The texts used are also saved per run in the archive.

More merge fields have also been added, and they can be used in all four text fields: %2 (bank account number), %3 (registration number), %4 (Belongs to Job No.), %5 (Belongs to Customer No.), and %6 (bank account code). %1 is unchanged. The merge fields are always retrieved from the bank account in the journal line's Account, also in the Bal. texts. If the account is not a bank account, or the bank account lacks the information, the merge field is empty without an error. %4 only makes sense when the bank account is linked to exactly one matter.

After merging, the text is cleaned up: double spaces are collapsed, and spaces and trailing characters such as hyphen, comma, colon, and semicolon at the end of the text are removed. Punctuation in the middle of the text is left untouched. The text is truncated to 100 characters after the cleanup. Existing texts containing only %1 give an unchanged result.

In the Adjust Client/Job Liability report, you can now specify a Summary Code, which is set on all the journal lines the report creates. This makes it possible to post adjustments to client collection accounts without a customer dimension.

The Summary Code field is available in Invoicing Setup under the Liability group and on the report's request page under Options. The value from Invoicing Setup is the default value on the request page and can be changed before the report is run. Only valid summary codes can be selected. The Summary Code used is also saved per run in the archive. If the field is empty, the journal lines are created without a summary code, as before.

If you previously specified a summary code for adjustments in General Ledger Setup, the value was moved automatically to Invoicing Setup during the upgrade. The field in General Ledger Setup is no longer visible.

When you closed the Time and Charges page with OK, all fees with a zero amount were previously removed automatically without asking you. This made it impossible to create a journal line for a fee with a zero amount, even when it was allowed in the Summary Code setup.

The Summary Code is now checked for each fee with a zero amount. If the Summary Code allows posting with a zero amount, you are asked whether you want to create a journal line with a zero amount. If you answer Yes, the fee is included as usual. If you answer No, the fee is removed as before.

Fees with a zero amount whose Summary Code does not allow zero amounts are still removed automatically, so existing setups work unchanged.

In User Setup, two fields had identical Danish translations, making it impossible to tell the difference between what they controlled. These were the field for Allow matter creation of all matter sub types and the field for Allow use of all No. Series for contacts.

Each of the two fields now has its own Danish translation, so it is clear what each of them does. The fix also applies to the places where the field names are shown in the group template.

When you created or edited a line in Time Entries, the page could hang without the line being saved. Users experienced that the system kept working without finishing, and they had to close the page or end the session. The problem only occurred for a specific resource on a specific date, while other resources and dates worked normally.

The cause was that after each change, the system checks the other time registrations for the same resource and date. If one of them changed from incomplete to complete during the check, the change was not registered as a change. This triggered a new check of the same registrations over and over again.

This has now been fixed so that changes between incomplete and complete are handled correctly, and the check finishes as expected.

When matter entries were moved to another matter with the Move Job Ledger Entries function, the entries were moved, but the Job No. dimension, currency, and prices were not updated to the new matter. The associated time entries did not follow either.

The move now follows the same rules as Move/Modify Job Ledger Entry. Dimension, currency, and prices are updated based on the new matter, and the time entry follows along. If the entries' task is missing on the target matter, it is created automatically as a copy of the task on the original matter with the same number. Moving to an archived matter is rejected.

If a single entry cannot be moved, none of the entries are moved. The error message now states which matter entry is concerned, with posting date and resource, as well as the reason. Only the first error is shown.

Note that open entries that are on an invoice proposal can no longer be moved. Entries with a posting date outside your allowed period are also rejected.

When a disbursement was posted to the matter, the VAT Product Posting Group on the Customer Ledger Entry was retrieved from the setup of the Summary Code selected on the purchase document. It did not necessarily match the VAT product posting group actually used on the line in the purchase document. If the two were different, the posting of the purchase document and the reposting to the matter could get different VAT information.

The error applied to both purchase invoices and purchase credit memos.

The VAT product posting group is now retrieved from the current line in the purchase document, so both the purchase document and the reposting to the matter get the same VAT information.

Previously, it was possible to post a sales document where one or more lines had a Matter belonging to a different client than the one the document was issued to. The check only existed when entering the allocation and therefore did not cover lines created manually, copied from another document, or where Bill-to Customer No. on the document was changed after the allocation.

Each line with a Matter is now checked when you post or run Posting Preview. If the matter's client differs from the client on the document, posting is stopped with an error stating Job No., Line No., and the two client numbers. The check applies to both sales invoices and sales credit memos.

Split invoices to an invoice recipient or co-client are not affected, as the document's Bill-to Customer No. is still the matter's client.

In the Word Reminder report, the merge field FirstContactName was blank if the Contact field was empty on the issued reminder. This happened even though the customer had a name, so the greeting in the reminder letter had no name.

FirstContactName now shows the first word in Contact. If Contact is empty, the customer's Name from the issued reminder is used instead. If Contact is filled in, the behavior is unchanged.

Note that Contact on the issued reminder itself is still empty in these cases. Only the greeting in the letter has been fixed. When the customer name is used, the full name is shown, so the greeting may, for example, become "Dear Firma A/S" instead of a first name. There are no changes to the Word layout.

When the Save Inv. and CM Mails in DMS function was enabled in Document Setup, invoice emails, credit memo emails, and reminder emails were not always saved on the matter in SharePoint. The problem occurred when the email was sent from a shared mailbox or on behalf of another mailbox. The email was sent correctly and could be seen in Sent Items, but was not archived.

The cause was that, by default, Exchange places the sent copy in the sending user's own Sent Items, while the program only looked for the email in the shared mailbox. The email was therefore either not found, or its content could not be retrieved.

The program now first searches for the sent email in the user's own mailbox and then in the shared mailbox. Since Exchange can be slightly delayed in placing the copy in Sent Items, the program tries several times before giving up. The sender on the archived email is now the account the email was actually sent from, even when Current User is selected in the email dialog. The fix applies to invoices, credit memos, and reminders and requires no new setup.

The protection against duplicates is unchanged. If the same document is sent with the same subject several times within 2 minutes, the email is not saved, so the wrong email is not archived.