Katie Nguyen

Users will get error 'The ledger transaction type Ledger journal for account XXX cannot be reversed.' when trying to reverse posted asset leasing transactions after YEC has been run.

The error message needs to be more specific about why the reversal cannot be done, similar to the log that appears for other types of transaction reversal.

When resetting data mart, users can find that while integration is in Running status from the front end, there can be actual failures when checked from the backend. We need a better log to better monitor it.

This is extremely helpful in Production where access to DB is limited.

According to MS doc,

when invoices are imported, the invoice lines are automatically generated, based on information on the corresponding purchase order, which means that product receipts must be processed before vendor invoice headers are imported into the system so the lines from product receipts can be automatically populated into the vendor invoices.

Since it's by design that there's no batch job running in the background for this process, it's not possible to import the invoice header first then wait for the lines to be created from product receipt which comes later, while this is a typical business scenario where invoices are sent electronically/via email – which will often get long before a delivery is made.

We request to have a process automation/ background batch job for this functionality to make it adapt with real business scenarios.

Context: 

• Some purchases at GC are captured as standing orders (e.g. 10,000 Qty / 1 Unit Price) as the amount invoice is unknown at the time of PO creation.  

• Invoices for these orders come in as normal invoices (e.g. 1 Qty / 950 Unit Price) 

• Since the lines do not match, invoice capture needs to be trained to ignore them and process the invoice as a header only invoice. 

• Header invoices only contain information for the total amount, if there are multiple receipts available, the automation cannot tell which receipt is the right receipt. (Receipts only capture qty information and do not contain price values) 

Requirement: 

• Need to be able to map the product receipt in invoice capture to the product receipt field in D365, so it allows invoices to find the right receipt to match to.  

• Users can capture the product receipt number as the invoice number and in invoice capture. 

• Users can teach the model to capture the invoice number in the new product receipt field. 

• We can potentially utilize existing “Product Receipt” field from Invoice Capture side.

Currently, users need to apply more filters or split the date range to reduce data volume when it comes to exporting a large amount of data.

We need an enhancement on available options such as Export to Excel, Open in Excel add-in, Reporting, Data Management to have a more efficient data export for large amount of data.

There are scenarios where transactions are involved with individuals (local vendors who are not conducting a business) which requires for self-billing as well. It will be NRIC or Passport for such vendors as Business Registration Number. This is a valid scenario which needs to be supported.

We would like to have conditions for Vendor invoice lines.Site and Purchase order lines.Site for Vendor invoice line workflow to check the 'Site' at line level just like the similar ones Vendor invoices. Site and Purchase orders.Site in the parent Vendor invoice workflow.

Actual vs. budget report should show correct amount type regardless of DB/CR default on main account.

Currently, system does not allow to add parameters in Default description for foreign currency revaluation transaction types.

We need this functionality to specify the purpose of the transactions.

• Create a customer payment journal.

• Enter a customer payment for a customer. -back date the payment to yesterday or 3 days ago

• Select Deductions button to create a deduction.

• Select “New” to create one or more deductions (Specify type and amount) and “Save”.

• Return to the customer payment journal, see that the deduction line(s) will be created.  

Actual behavior: The deduction line defaults to the current date

Expected behavior: The deduction line should default to the date of the payment line as most times we are processing a customer payment for at least “Yesterday”.