Currently, Country/Region context works only by fixing a comma separated list of countries in which a feature is enabled. In code, the same is true for the container of strings when checking if a legal entitiy is in a country/region.
I propose an extension of the simple list of countries to a "legislation". A "legislation" is a platform managed list of countries which can be added to a country/region property as. It could be managed as a metadata artifact and deployed, with an extension capability to add more countries in the future, or as a pure runtime feature. "Legislation" should have a unique string, longer than 2 characters not to collide with ISO country/region codes, or be prefixed with a non-alpha character, e.g. "+".
For example, features common to the European Union, such as VAT features, Intrastat reporting and so on, could be marked in metadata with a "legislation" +EU. Similarly, in code, checks could be rewritten from isLegalEntityInCountryRegion with a long list of countries to a short container of only "+EU".
Given that functions that are enabled for more than one country generally fall into a couple of broad categories:
- are actually there because of some super-national legislation (EU, EEU, SEPA, NAFTA, Mercosur/Mercosul...)
- are not really localization features, just features developed by a localization team (used to be payment calendars, also configurable text descriptions, withholding tax per invoice line...)
- features that exists because several countries used to be one or had some other common historical influence
it would be beneficial to be able to add new countries to at least two of the above groups of features.
D365 should support all danish regulation, we are however missing a reporting feature: the danish version of PRODCOM or "Industriens salg af varer"
The regulatory reporting requirement is mandatory for all manufacturing with more than 10 employees.
It is reported to the danish statistics authority, "Danmarks Statistik". The following must be reported:
Value (sales price ex. tax, total amount in DKK)
Quantity (the qty. stated with the commodity code)
As addition to the items total revenue and additional revenue split on installation work, repair work, contract work, revenue on basic trading and other revenue. (I guess this part is hard to automate).
In the GER, please implement embedded functions
DIV(real _operand, int _divisor) for integer division with truncation and
MOD(real _operand, int _moduloBy) for the modulo division.
In addition, please implement a scope attribute in the Counter element to have multiple counters running in parallel and for example be able to assign the same counter in the same record at 2 places.
My blog http://erconsult.eu/blog/electronic-reporting-er-cookbook/ documents my struggles with this regards.
With the July 2017 update, CSV was added for import compatibility in GER. However, there are scenarios where CSV is required for export as well. As an example we can consider some of the payment files that are exported to certain countries require CSV formats.
Due to legal requirements or customer requriements, some customers must have their data located in a datacenter in a specific geographic region. For example, German companies usually want data privacy according to Germam standards which requires either a data center in Germany or a data center outside of Germany but compliant with the regulations. Chinese law requires the data to reside on Chinese servers.
So how about enabling geolocation of the data, maybe based on the legal entity id? So for example the records in the Contoso example with data area id "DEMF" should physically be on a server in Germany, and those with CNMF should reside on a different server. This would allow global single instance with compliance to local laws, and might also even improve performance if Dynamics servers are also distributed. They would be mostly communicating with their local datacenter SQL server instance.
This should be possible to implement using the partitioned tables and indexes feature of SQL server:
It should be possible to set up at customer level which taxes will be included in XML generation for electronic invoice.
When you use CFDI 3.3 for the following project journals (Fee, Subscription and Expense) you will note in XML file attribute 'Unit' is a fixed value.
It would be desired to have a new brand field for this purpose for each of these journals.
When you use CFDI 3.3 for the following project journals (Hour, Fee, Item, Subscription and Expense) you will note in XML file attribute 'Description' copies its value from attribute 'Unit'.
It would be expected to retrieve this value from field 'Descrption' in Invoice journal.
When using CFDI 3.3, customer shoul be able to receive PDF file by e-mail. Only XML file is sent.
For reference TFS 3936076 in Dynamics database.
Today is out of scope the record E531 for the generation of the SPED fiscal in AX2021R3
REGISTRO E531: INFORMAÇÕES ADICIONAIS DOS AJUSTES DA APURAÇÃO DO IPI – IDENTIFICAÇÃO DOS DOCUMENTOS FISCAIS (01 e 55)