Microsoft Dynamics 365
this comes up with almost every client of ours. Would be nice to have more functionality around this.
Hi Andrei Panko
I see that you change the status at completed.
But let me add this thing:
I understand that on purchase order the job type is important.
Why it is to linked directly into the purchase order when it is created from the planning worksheet? This is the problem. No Job information and also dimension is indicated in the purchase order created the the planning worksheet.
this is why we open a case an Deseree ask to open the idea here.
In Resume, a purchase order created from a planning worksheet related to a job with a Job type Budget per example and an assembly item with BOM, all other items in the BOM that needs to be purchase are detected in the planning worksheet, but the planning worksheet will not indicate the job number, job task, job type and dimension indicated in JOB.
Please consider this demand because it is a real problem. If you need to see a demonstration, I could do it for you to better understand the situation.
Also, let me add an other problem about the creation of a purchase order from the planning worksheet that detect from a job with dimensions, an assembly items linked into a job planning lines that will make possible to create the assembly order and purchase order in the planning worksheet.
If we request the same situation as described by Caroline, we discovered that in the planning worksheet and in the purchase order, no dimension already linked in the Job card follows.
A purchaser can not create the purchase order from a planning worksheet and will need to do it manually because we need to track the dimension in the purchase order as the job and task number already linked behind the scene and are not visible in the purchase order.
Note: Featuring INSTEAD production sales order from supply chain production, might be best option to safeguard uniformity standards and future easy dashboard generations or other power automate or power apps features.
Note: For purpose of operation easy visual identification and easy reporting or un-reporting. with no need to generate a financial reporting or a conventional budget transaction reporting.
We also have several customers with this need, there has to be a way for a BC SaaS to provide an non-changing address of som kind for security protocols.
Also, I think we need the option to add the rest of the conditions as well.
See also my answer on GitHub:
If a group inherited the obsolete state to its children, it would mean that we could never extract an action from a group. We would need to copy the action.
Is this a bug?
This issue is related to the fact that Gen. Journal Posting does not allow Entry Type 'Payment' have a Negative Amount for Vendors.
I have created an Open Source PTE to resolve this: https://github.com/TheDoubleH/BCVoidPayment
From a Technical perspective, here is the issue:
When a User voids a check from the Check Ledger Entries page, A call is made to Codeunit 367 – CheckManagement -> Function FinancialVoidCheck
That function sets the Document Type to “ “ (Blank), which leads to the Vendor Ledger Entry to have a Blank Entry Type.
While the Check Ledger is flagged as Voided and the Balance is correctly adjusted, the Detail Vendor Ledger Entry will not tell a complete story;
If We look at Check 206, the ‘initial’ Detailed Vendor Ledger Entries created end up like this:
The issue is that the Calculation formula for the Payments (LCY) Field on the Vendor Table, filters for Entry Type = Initial Entry, “Initial Document Type” = Payment (And Vendor No and other fields)
And THIS leads the Payment to show an incorrect amount on the Vendor Statistics Factbox
By now, I hope You realize that this is indeed an issue that needs to be resolved.
How do we fix it?
I suspect that the Document Type is left blank, due to the fact that codeunit 11 - Gen. Jnl.-Check Line prevents a Vendor Payment with a Negative Amount (Which makes perfect sense).
Luckily the Check Management Financial Void Check function sets a field: “Financial Void” to true. This means, that we have a possibility to negate the Negative Amount for Vendor Payments in CU11, as well as Positive Amounts for Customer Refunds.