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:
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)
Regarding CFDI 3.3 Mexico localization, when printing the PDF file invoice (Representación impresa) the following fields should be added to actual format:
1. Forma de pago. Código y descripción. (Type of payment. Code and description)
2. Método de pago. Código y descripción (Method of payment. Code and description)
3. Tipo de comprobante. (Type of invoice: E, I or N).
4. Uso de CFDI. Código (Purpose)
5. El precio unitario debe ser antes de impuestos cuando se desglosa IVA. (Unit price excluding sales tax)
6. Impuesto. (Sales tax)
7. Tipo Factor.
8. Tipo tasa.
See for reference the following link:
In the Fiscal Adjustment Journal, we have the field "Tax Value" that in the Portuguese translation (pt-br) should be "Alíquota de imposto".
Menu: Fiscal Books >> Journals >> General tax adjustment/benefit/incentive >> Lines
Today is out of scope the record C175 for the generation of the SPED Contirbuition.
Registro C175: Registro Analítico do Documento (Código 65)