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.
On French localisation, there is not possibility to do international payment.
All payment formats stand for EUR currency (Europe SEPA or domestic CFONB 160)
Making international payment is a common requirement for all countries.
=> Create international payment format for France.
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).
When importing 0.02 the customer cannot see the rejections comments from the bank in AX. When there are multiple rejections the partner should search for the comments in the XML file. For hundreds records this is a huge effort on daily/monthly base.
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.
For customer payments only camt.054 format is available. The request is to have pain.002 available for customer payments same as it is available for vendor payments.
The bank provides the pain.002.001.03 (payment status report) which includes the reason codes for rejections. These rejections needs to be followed every month and so pain002 needs to be available.
They require to import a number of file format exported from Westpac banking system to create Accounts receivable receipts in D365 .
I note in Electronic reporting a WBC Direct Entry System (au) configuration is available. This produces an .aba file
Other formats they require to import from Westpac products are:
1. CAF (cash Apply file )
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.
The system does not seem to post correct reversal amount GL entries when a supplier invoice is registered with TDS and cancelled later using an invoice approval journal leaving a balance in the invoice registration offset account and TDS ledger account.
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: