Neil Catubig SUPPORT ESCAL ENG

Checked on the existing "Purchase spend analysis Power BI content" but it is only providing high-level PO information, and not showing the information required by the client,

It would be good to have a Power BI report that includes a list of Purchase orders and the related PO Invoices that have been issued against specific POs in addition to what are existing (which are very limited as of now).

Recognition processing preview total incorrect:

> the recognition preview total sums up the individual lines as absolute values.

> it does not take into account the credit or debit of the Recognition type.

This gives a misleading total value for the proposed recognition.

Currently, when setting up Database logging on Table LedgerFiscalCalendarPeriod (Ledger fiscal calendar period) – on ‘Update’, on fields Reference, Ledger, Period Status, you'd see the following scenario/results:

=====

Action taken:

Change the Fiscal period Status on a specific Period, from ‘Open’ to ‘On hold’

Result:

Only the Status field is logging the ‘Value’ and ‘Previous value’ entries

FiscalCalendarPeriod, Ledger fields are not getting recorded in the log

That is happening as there are no ‘Updates’ done on the FiscalCalendarPeriod and Ledger fields (only the 'Period Status' value was updated). The History tab will show cumulative changes, and just shows the recent change that had happened and on which particular field (i.e. Period Status).

=====

Due to that current design behavior in database logging, that means the user would not know which Period was updated and from which Ledger it is from.

Thus, it would be good to have a way to track data changes on Table LedgerFiscalCalendarPeriod, and also show the current values on fields: FiscalCalendarPeriod, Ledger, to help users understand which Period was updated and from which Ledger it is from.

Currently, there is no out-of-the-box standard support for Electronic signatures on Table LedgerJournalTrans / Field PaymentStatus.

This can often required by businesses if they need changes on vendor payment status - i.e. from 'None' to 'Sent' upon generating the generated ER XML file - to be tracked and electronically signed/approved.

In the currently releases of D365FO - when you try to set it up for Table LedgerJournalTrans / Field PaymentStatus, it will throw the error 'Transaction does not contain a required signature' but there's no way to manage the signature and the updates are not saved.

Support splitting of Sales tax amounts into the split Customer payment fee amounts

-

Currently, when users split the Payment Fee amounts into multiple lines (to match the specific no. of Item/Product lines [as well as their specific GST/Sales tax requirements] from the Sales order/SO invoice that the payment is settled against), the payment fee (with Sales tax) posting in customer payment voucher is wrong.

In other words, when posting a Customer payment journal with multiple Payment fee lines (having GST/Sales tax calculated on each Payment fee line), it adds up all the GST/Sales tax amounts into only one of the Payment fee amounts.

Example scenario:

====================

ACTUAL RESULTS:

Fee #1 = 11.70

Sales tax on Fee #1 = 1.17

Fee #2 = 8.00

Sales tax on Fee #2 = 0.80

Customer payment account (Main) = 975.70

Customer payment account (Fee #2) = -8.00

Customer payment account (Fee #1) =-13.67 (from 11.70 + 1.17 + 0.80)

AR account = -975.70

EXPECTED RESULTS:

Fee #1 = 11.70

Sales tax on Fee #1 = 1.17

Fee #2 = 8.00

Sales tax on Fee #2 = 0.80

Customer payment account (Main) = 975.70

Customer payment account (Fee #2) = -8.80 (from 8.00 + 0.80)

Customer payment account (Fee #1) =-12.87 (from 11.70 + 1.17)

AR account = -975.70

Local business terms, like GST for Sales tax, need to be incorporated/localized into the new Expense Management (PowerApps) app.

Currently, in the new Expense Management PowerApps app, the Sales Tax-related field labels do not reflect/honor user language settings in D365FO.

For example, in the Australia local business context:

> The business users are using language: EN-AU in D365FO:

> When the EN-AU users log in into D365FO, as expected, they’d see that ‘Sales tax’ will display as ‘GST’, as ‘GST’ is the Australia (EN-AU)-specific term for 'Sales tax' for Australian businesses.

> But, when the same users log in into the new Expense management app, the ‘Sales tax’ terms are still not reflecting the EN-AU equivalent terms (from D3656FO) of ‘GST’. It is keeping the 'Sales tax' labels.

This is related to the new Feature 'Automatic split of large financial journals'.

After enabling that Feature, it hides the Line Limit parameter from individual journals. Instead, Line Limit becomes a global parameter that's effective for all journals. The default value for the Auto-split parameter is 1000.

That global 'Line limit' parameter should be exposed to the users and allow the users to change it to more than 1,000.

Thank you!

SCENARIO/ISSUE:

Let's say, User #1 created a new vendor bank account and set to expired the existing ones.

User #2 then generates a payment proposal and tries to settle an invoice that is previously tagged with the old, expired vendor bank account.

At this point, there is no warning if the vendor bank account on the transaction is already expired. User #2 then went ahead and generate the payment, not knowing that it had the incorrect vendor bank account details.

RESOLUTION:

With the current design, users need to set the new/valid vendor bank account into the 'Alternate account' field in the payment proposal lines.

FEATURE REQUEST:

To make User #2 aware that expired vendor bank accounts are being used in the vendor payment proposal lines (before they generate and send out the payment file), it would be best to add into the Payment proposal lines form the same vendor bank account validation that now exists on the vendor transactions, where it is currently throwing the following message where applicable: 'The bank account is inactive. Select an active bank account’

The desired warning/error message is similar to it with a slight variation: 'The bank account on the line is inactive. Select an active bank account as an Alternate account’

Currently, the Posted Sales tax/GST inquiry (Tax - Inquiries and reports - GST Inquiries - Posted GST) is not indicating the GST/Tax amounts with the correct signs (i.e. Tax/GST Payable amounts are shown as Positive amounts instead of being Negative amounts).

In contrast, Sales tax/GST amounts are displayed with (correct) signs: GST Payable = negative, GST Receivable = positive in the following Reports:

Tax> Inquiries and reports>GST Reports>GST Transactions

Tax> Inquiries and reports>GST reports>GST/Ledger reconciliation

Thus, there is a need for Sales tax/GST amounts need to be consistently indicated with signs (Positive/Negative) across all Standard GST Inquiries and Reports.

Thank you for reviewing this request.

Currently, you can only set a 'Number sequence' for Purchase orders from the Procurement and sourcing module.

There is no option to set a 'Number sequence' for Purchase orders that are specifically created from Projects. Thus, for example, there is no way to set a prefix on Project Purchase order numbers that is different to non-Project POs.

Please consider adding that option as some businesses require different numbering on POs if they are raised from Projects.

Thank you!