Suggest a new Idea

  • 13

    Extension of Country/Region context to "Legislation"

    Suggested by Boštjan GolobNew 1
    Category: Globalization - Regulatory features

    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. 

  • 2

    France - CFONB 320 for international payment

    Suggested by Annaick BoudinNew 0
    Category: Globalization - Regulatory 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.

  • 2

    Electronic Reporting: implement functions DIV and MOD

    Suggested by Eugen GlasowNew 2
    Category: Globalization - Regulatory features

    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.













     






     

  • 2

    GER format should have ability to save file as CSV for export

    Suggested by Vamsi Pranith DonepudiNew 1
    Category: Globalization - Regulatory features

    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.

  • 2

    Geographically / geo-location distributed database

    Suggested by Falk StarkeNew 0
    Category: Globalization - Regulatory features

    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:


    https://docs.microsoft.com/en-us/sql/relational-databases/partitions/create-partitioned-tables-and-indexes


     

  • 1

    MEXICO PDF file is missing when email CFDI in Dynamics 365

    Suggested by Felix Vazquez CarrilloNew 0
    Category: Globalization - Regulatory features

    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.


     


    Felix

  • 1

    BRASIL: SPED FISCAL - BLOCK E531

    Suggested by Elisabete PadulaNew 2
    Category: Globalization - Regulatory features

    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)


    Page: 165


    http://sped.rfb.gov.br/estatico/0D/2DC4C346EDFCDFAFA26C391C7398D060594B50/GUIA%20PRÁTICO%20DA%20EFD%20-%20Versão%202.0.22.pdf

  • 1

    MEXICO - CFDI 3.3 Printed invoice (Representación impresa)

    Suggested by Felix Vazquez CarrilloNew 0
    Category: Globalization - Regulatory features

    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:


    http://www.sat.gob.mx/informacion_fiscal/factura_electronica/Documents/Jornada_Material/MERIDA_SALA_1/1_ABC_Factura_Elect.pdf


     


    Thanks


    Felix

  • 1

    BRAZIL: Field translation in Fiscal books

    Suggested by Elisabete PadulaNew 0
    Category: Globalization - Regulatory features

    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

  • 1

    BRAZIL - SPED CONTRIBUIÇÕES - BLOCK C175

    Suggested by Elisabete PadulaNew 0
    Category: Globalization - Regulatory features

    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)


    Page 111


    http://sped.rfb.gov.br/estatico/FA/C35C6D3D1DB03BD46C938D40C1A1FFF38F5AE0/Guia%20Pratico%20EFD_Contribuicoes%20Versao%201_25.pdf