Invoice register is posted with wrong purchase order.
During matching process via invoice pool, purchase order cannot be modified.
It is advised to reverse invoice regsiter but this process is time consuming as just new purchase order should selected
Workaround (may not work in all cases)
• Go to the invoice pool
• Delete in incorrect pending vendor invoice
• Click purchase order to find the correct purchase order.
• Submit invoice via workflow.
• Remain in the screen to approve the pending vendor invoice.
It is currently not possible to audit when an employee performs a lookup on a customer object, whether it is using the backoffice (D365) or MPOS customer lookup. This is very important to ensure employees are not misusing their privileges within the system. Think of a healthcare setting or pharmacy where any employee could look up their friends prescriptions without a trace for personal use.
Transaction date column in audit trail
Along with the created date the customer wants to have the transaction date column in the Audit trail in Version 8.0
General ledger>Inquiries and reports>
Now in standard R3 Audit trail report this transaction date was available
And I noted that the audit trail reports is deprecated from 7.0
Can we incorporate the field in Audit trail inquiry
Surcharge on purchase price is not recalculated when posting invoice what impacts when there has been a change in purchase priceThe customer has configured a purchase overhead in the costing sheet. When he receives the purchased goods, the overhead is calculated correctly. However, the overhead is not recalculated if he posts the purchase invoice with a different unit price than that on the purchase order.
He has configured a surcharge of 2%. He creates a purchase order for a quantity of 10 at a unit price of 45.00, confirms the order and receives the goods. The physical cost is 459. He then posts the invoice at a total cost of 600. The financial cost is 609.00, but it is expected to be 612.00.
Have an ability to create a Workflow condition on the PO header for the Dimension values entered in the Accounting Distribution form for the line detailsOur customer would like to create a workflow that checks for specific department values for their Vendor Invoices. They are entering the account distributions by going to Financials | Distribute amounts for each of the lines in the Pending vendor invoice form (Accounts Payable | Invoices | Pending Vendor Invoices)
The customer would like to setup a Vendor Invoice workflow that has a condition for a specific department value that was entered in the Distribute Amounts form.
They do not want to create a Vendor Invoice line workflow and they would like all the verifications done via the Vendor Invoice workflow (header).
We have already tested using the following Department fields:
Purchase order lines.LedgerDimensionDepartment
Accounting Dimension.Ledger dimension.department
All the default Department fields
This functionality is currently not available in D365 and our customers would like to request to have this feature as this is needed for their Business processing
D365 Shall Allow Travel Requisition to be submitted with a Project that has Multiple Funding sources because Travel Requisition is not a Financial Document it is just a support document for the Expense Report. Travel requisition has no financial impact.
Allocation for Funding sources can be controlled through the Project Contract in the Funding Rules section. This should be taken into account where when an expense or travel requisition is posted the correct amount should be allocated and reflected towards the appropriate Funding Source.
Retail Attributes which are used for extentions in CPOS are not save and restored for Quotations. We loose therefore the possibility to transform quotations to sales orders using These Attributes later.
Any document posting (sales, Purchase and Service ) must fill the Invoice Posting Buffer table. But the primary key is fixed and we can't modify this when we develop an extension.
I propose to modify this key in order to calculate the break according to fields that we can add in our developpment.
To do that, you just must create a unique key that defines the combination that references a set of fields.
For this, we can use a primary key based on the calculation of a cheksum of a string type. Since this checksum is unique for a given combination, it will suffice to add, to the string, our fields we want to add to define a new combination to the primary key.
This code can call before inserting data into this table and you can publish an event to allow us to add fields in the combination calculation
The potential risks would be related to the validation order of this table in the document validation codeunit if the execution order is really important.