on
RE:
There's an errore in the correct voucher.It must be like this: AMOUNT FIN TAGF000001 24404000001-CC1 1000 X4000001-CC1 110 X (THIS IS THE NON DEDUCTIBLE TAX LINE)2000001-CC1 110 X (THIS IS THE SALES TAX LINE)4000001-CC2 1000 Y4000001-CC2 110 Y (THIS IS THE NON DEDUCTIBLE TAX LINE)2000002-CC2 110 Y (THIS IS THE NON DEDUCTIBLE TAX LINE)The "TaxTransGeneralJournalEntry" table it is very helpfull to implement the correct solution because it joins taxtrans and generaljournalentry transactions.
RE:
It would be extremely helpful to be able to quickly confirm who a sales invoice was emailed to.
RE:
A strong solution would be to make the bank details table a date effective table, and enable the changes through Self service and Teams
RE:
Definitely need to maintain this feature.
RE:
This issue has a direct impact on the reliability of workflow validation in the purchase order process. Although all lines are properly distributed, the system returns an erroneous validation failure, preventing workflow submission.Our customer confirmed that the proposed workaround (disabling Auto Calculate Totals and Accounting Distribution) is not viable. It introduces a functional gap by bypassing critical distribution validation checks, which are essential to prevent downstream errors during invoice posting — such as missing financial dimensions.This behavior contradicts the intended integrity controls in D365FO and poses a significant risk to data quality and process control. The issue appears to be a regression or unresolved bug rather than a configuration gap and should therefore be prioritized for a permanent resolution in the standard product.We strongly urge Microsoft to reconsider and address this as a product defect, or at minimum provide an alternative workaround that preserves standard validation logic while allowing submission of POs that are in fact correctly distributed.
RE:
This could also allow you to process json payloads that don't fit within the structure of a page, so all for it!This seems to happen more and more often that we come across a json structure we cannot fit in the "rigid" structure of a page
RE:
This change would be especially useful when considering the standard Error Message table, which has a Context Record ID field.Consider the following use-case for a FlowField:CalcFormula = count("Error Message" where(Context = const(true), "Context Record ID" = Rec.RecordId()));Obviously this is pseudo and wouldn't compile, but the Context Record ID is a standard field (ID 10) on the standard table Error Message (ID 700), so improved support for the built in error handling system would be an immediate benefit of introducing Record ID as valid content for FlowFields.
RE:
We are using nested groups to organize simplify our access structure Microsoft made nested groups many years ago, and it has been a huge succes for managing many groups with many users. Microsoft should keep supporting this - or else it will be an administrative hell to have all these flat groups with no dynamic connection between them
RE:
This is needed to use the App
RE:
One of the first things our customers complain about when migrating from Windows client