Comments
I agree.Let's say, you have a N:N relationship between Tutors and Minors, and when creating the Relationship, select Use Custom Labels option with Tutors and Minors as the labels (so that you can identify them).When you open the Minor Form in contact, you'd expect to be able list the Tutors of this Minor in a subgrid, and vice versa, if you open the Tutor Form, you'd expect to be able to see the Minors for this Tutor in a subgrid.If you add a Minor in the Tutor Form, when you go to the Minor record (using Minor Form) you don't see the Tutor record in the subgrid. Instead you must click the Related tab, and from there, select Tutors.Subgrids should allow both sides of the relationship (just like Related).
When consolidating, we have clients that would like to consolidate on a transaction/detailed level to see which documents it is consolidating. It will also help the user identify which transactions have been eliminated and which entries require an additional entry to eliminate within the consolidated company.
We added a new field to the Case entity called 'Resolve By' which is set from the SLA Instance to make it easy to see and use in the Case Views etc.We also added a 'Follow up by' in the Case entity which allows a user to put a date when they next want to look at a Case without creating a separate task or other activity. Then can then be used in Views as well. The field is on the form for users to easily update.
I can confirm that BC (v23.2) still does not behave properly. Interestingly though, while debugging the code, I see that it firstly does populate the UoM with the UoM from the Production BOM! Also the calculation for Routings and Components is good. However, after all of this is done, it does one final thing: Forcefully places the Base UoM of the item on the PO-line, undoing everything it has already done right.Scenario:Version: NL Business Central 23.2 (Platform 23.0.15284.0 + Application 23.2.14098.14274)An Item to be produced via a Production Order, with a BOM:No. 1000012 Base Unit of Measure: PCS Item Unit of Measure: BAG (100000x the Base UoM) Production BOM No.: PRB210008A Production BOM:No.: PRB210008 Unit of Measure Code: BAGA Released Production Order for item 1000012:No.: PRO00000018 Source type: Item Source No.: 1000012Pressing the Button “Refresh Production Order” creates a Production Order Line for Item 1000012, but with Unit of Measure Code ‘PCS’, which is the base UoM of the Item, even though the Production BOM that is used has the Unit of Measure Code ‘BAG’. Manually changing the Unit of Measure Code in the line yields the expected result, also in the Components. Debugging the process shows that the PO Line firstly gets filled with the expected UoM ‘BAG’, but later it get filled with the Item’s Base UoM. This seems, at it’s minimum a waste of efficiency, but I think it’s a bug.I've had contact with MS support, but I only get referred to this Idea. I don't thing we should be needing to vote to fix bugs?
I do not think the linked Idea is the same idea.We miss the Active Duration calculation for when the SLA has failed. Currently the timer stops when the SLA expires but does not record the working duration from SLA start to SLA completion even if the time is greater than the failure duration.This needs to be calculated though the SLA instance as only this has the work calendar on it, we cannot calculate it from only the Case as it has no calendar, and we cannot access the work calendar data to make any calculations.