Microsoft Dynamics 365
REMARK: Including finance contact prospects (e.g. merging and acquisitions, trade agreement negotiations, human resources applicants, etc...)
REMARK: Or for purpose distance.
REMARK: Example public institutions, or forbes 500.
Yes, this would be extremely useful to help us accurately keep track of monthly sales and pull true reports.
Please, why is prohibited "single key can't include fields from both the base table object and table extension object"?
Typically what developer need is extended some Base App key for my new field in Extension. I can not imagine any issue why could not be SEAMLESSLY copied to companion table.
I think that let devopers to ensure field mirroring is wrong idea. Developer then must solve issues with initializing data when install Extension, issues with Insert/Modify/Rename...
Only what Developer needs is to use required key. Platform may do that. If Extension needs to key from field from another table, just maintain copy of it and create requested key...
also related somewhat is this idea: https://experience.dynamics.com/ideas/idea/?ideaid=f29e4bcc-de0e-ec11-b76a-0003ff459a6f
If you voted for this, you may be interested in the next one too: https://experience.dynamics.com/ideas/idea/?ideaid=96162047-dd19-ec11-b76a-0003ff457cd8
I see similar problems with QM in D365 an WHS.
Point 1: I am also totally missing this possibility
Point 2: is basically implemented. The main problem here is, that the incomming quantity is not totally blocked for the time of the suspection. e.g. you get 100 pcs in and the sample size is 10%. In this case 90% is dircetly available. This causes bis processual problems if the QM-inspection fails.
Point 3: Is basically working. What I am missing is the case of a partial good and partial failed quantity. There is no kind of "split functionality" for the quality order. This would allow to transfer the good quantity into the warehouse and to rework, return or scap the faild quantity. A manual split causes lot of errors.
It's not acceptable that the vendor ledger entries and customer ledger entries are excluded from the API.
Especially given how easy it would be to add them.
These are essential for almost every implementation.
2 years later + 180 votes later and our modern BC webclient still missing this essential feature that was present in NAV windows client since 2009 RTC :(