Currently, when the field ‘Confirmations, delivery and invoicing on hold’ = ‘Tax Invoice’ is set on the Customer Master, sales order invoices are blocked from processing, while other transaction types such as Customer Free Text Invoices and Customer Payment Journals are allowed to process under certain conditions.

For example:

• A credit Free Text Invoice processes successfully, but a debit Free Text Invoice fails.
• A credit Customer Payment Journal processes successfully, but a debit Payment Journal fails.

This behavior makes sense as it prevents increasing the customer’s balance while allowing reductions.

However, credit Sales Order Invoices, which also reduce the customer’s balance, are currently blocked from processing. 

Suggestion: Sales Order Invoices—especially credit transactions—should be allowed to process when they reduce the customer’s balance, just like the other transaction types. This would ensure consistency across invoice and payment processing logic and reduce manual workarounds.

When a field on a customer's address is changed, the system expires the old address and creates a new, active one. Both the new and old addresses are linked to the same location ID, and the old address is moved to the history tab. The problem is that addresses that are truly expired and no longer in use are also stored in the same history tab. As a result, there is no way to differentiate between a genuinely inactive address and an active address that has simply been modified. This makes it impossible to determine which addresses are truly inactive in our records.

A main account filter would be helpful in the JPK_KR_PD report and would support users in data verification. The main account filter is available in the standard functions as follows: Turnover and balances statement and Journalizing. Note that Turnover and balances statement and Journal there are a part of JPK_KR_PD.

The form at path Accounts payable> invoices> Open vendor invoices has a filter on transaction type that is setted by default to show only records with transaction type Lease expenses, Purchase order or Vendor. These filters have been applied starting from version 10.0.44.

If we post an invoice using the general ledger journal, the invoice will have transaction type General Journal. So starting from version 10.0.44 these invoices are not shown automatically in this form anymore.

We tried to modify the filter and save the view as personalised and pinned by default, but when we refresh the page the personalised view is overridden by the standard one.

Since this is a behaviour by design, we're raising this idea in order to ask to allow the personalised view to be saved withouth being overridden by the standard one.

Issued Reminder: There is no option to select 'Show Not Due Amounts'.

When you want to send an e-mail (button: Send by Email), see also e-mail attachment

Best regards,

Daniël van den Hoek

4PS by Hilti

Currently, it is necessary to input additional budget in the new fiscal year before running POYE to cover encumbrance increases caused by exchange rate fluctuations, as concluded under KB 1047194.

We would like to make this process effortless and fully integrated. Also, there should be a report that shows the fluctuation for budget forecast,

Currently, when attempting to insert records into the Business document customer invoice lines entity via staging, the following message is returned:

'1' 'Business document customer invoice lines' record(s) inserted in staging. Results. insert/update/delete not allowed for entity with ReadOnly = Yes.

This indicates that the entity is marked as ReadOnly, preventing any insert, update, or delete operations.

Business Impact:

The inability to import customer invoice lines programmatically limits automation and scalability for organizations managing large volumes of customer invoices. Manual entry is time-consuming and error-prone.

Current functionality confirms that the entity is read-only and not intended for import operations.

Related entities such as SalesInvoiceHeaderV2Entity and SalesInvoiceLineV3Entity also exhibit similar restrictions in recent versions (10.0.43 and 10.0.44).

Proposal:

We propose enabling insert/update/delete operations for the Business document customer invoice lines entity in Data Management. This would allow users to import customer invoice lines efficiently and align with other supported document entities.

Suggested Benefits:

• Improved automation and data integration
• Reduced manual effort and error rates
• Enhanced support for bulk invoice processing scenarios

In Advanced Bank Reconciliation, users can generate customer and vendor payments that post using the journal defined on the related bank account. Currently, if a workflow or approval process is configured on the assigned payment journal, the system does not trigger the workflow and instead produces an error. To work around this, an additional payment journal must be created and configured specifically for Advanced Bank Reconciliation postings. A more effective solution would allow the same journal to be used, with the option to bypass workflow logic. This could be achieved by introducing a configurable setting - either on the journal, the bank account, or within the Cash and Bank Management parameters - that enables users to determine whether workflows should be enforced for these postings.

When processing cost invoices through the invoice journal, the supporting invoice document is only available as an attachment. If a user wants to review the invoice prior to posting, they must first open the attachment before continuing with the journal. A more efficient approach would be to extend the functionality currently available in the Pending vendor invoices form - where the invoice file is displayed directly alongside the invoice record - so that the invoice document is visible within the invoice journal for cost invoices as well.

We have observed that same main account has been mapped for accounts payable and prepayment. This created a lot of issue in vendor reconciliations, especially with prepayment invoice option for vendor advances. As industry best practice and operation efficiency in reconciliation- standard system must not allow same main account mapped to accounts payable (vendor main account) and prepayment main account.

This will save the issues in reconciliation of vendor ledgers, vendor aging and other vendor balance reports. this will enhance the clarity and reconciliation time.

Renu Jajoo

RJ-14081220-0