Dynamics 365 Finance

Colombia Invoice format (Beyond the XML-Electronic Invoice), requires certain criteria to be fiscal-legally accepted.

• Invoice should include Invoice resolution legend tied to an editable field that allows to update each time a new resolution is issues by the fiscal authorities, this can be done company bases or POS based or fiscal point based.

• Invoice must add a legend what is the system that is printing the legend + the license that the company has paid.

Here is a quick blog that helps to understand the scope of the requirement

https://www.holded.com/es/guias/facturacion/requisitos-datos-facturas

The suggestion is MS to develop all this field in the standard customer invoice report.

When generating electronic yearly fiscal reports for Colombia the District Magnetic Media is a must for the majority of companies. As of now Only National magnetic media has been partially released but is important to have available as well the electronic reports that build the XML for the "Scretaría de Hacienda Bogota".

The formats to be developed should be 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 1010, 1011, 1012 updates to 2024 according to the resolution 1255 from 2022 of the "Secretaría de Hacienda Bogota".

The suggestion is MS to develop all these formats based on the Vendor/customer address criteria to include all transactions performed in Bogota or companies based in Bogotá district.

from the netting agreements, the user can create a new netting and to finalise it he needs to post it.

The journal created for this netting posting, is now blocking the approval.

The client I'm currently working for requests to have an approval before the netting is being finalized.

This to avoid executing a payment to a client, where soon after there is a sale to that client and resulting in a receivable.

We suggest to have some processes or operations that can be launch automatically everytime we upgrade Sandbox1 environment, as a “warm-up”, to avoid the frustration of the user’s customer on performance response for their firsts actions.

Currently, the Ledger parameters do not include 100% of the fields needed to copy general ledger parameters between legal entities. To address this issue, we propose creating a new data entity that includes all general ledger parameters. This would make it easier for customers with multiple legal entities to copy general ledger parameters between them, reducing the risk of errors and saving time. By creating an inclusive general ledger data entity, customers will be able to manage their financial data across multiple entities more efficiently

We would like to add a new feature or function on Personalize for All vendor form, On the Credit limit table, when select and then deselect Show in header, the Credit limit amount is hidden from header. After saving on Save view and reopen All vendors and select New view, Credit limit reappears in Fasttab header.

Since this issue is code limited, we would like to request back-end team for adding new function for customer to able to hide the information on the Fasttab header.

There is a problem with changing a Project ID on the Purchases Order and Agreements.

When we create a PO or agreement select a project ID, the next we add a new line and then change the project ID – this operation does not change project ID on the line details.

We have been utilising this Microsoft data migration approach document for opening lease balance migration

https://community.dynamics.com/blogs/post/?postid=df76953f-bb2c-405a-ad21-cabcf82d742d

It is not possible to use the historical lease transactions to arrive at the lease balance, so we are utilising "option 2" from one of the Microsoft approach documents to bring the lease in at a "point in time".

We utilise a 4-4-5 financial calendar and are linking finance leases to fixed assets. This means that the fixed assets can depreciate on a weekly financial calendar to calculate 4-4-5 correctly and the monthly lease postings can occur in the lease module.

Because of 4-4-5, the cutover date at go-live will not always be a month end, it will be a period end.

Example:

Period end date of 27/10/2023.

Using this as an example, we are populating on the lease the lease commencement date of 27/10/2023 and according to the article.

In line with the article, we need to create a payment schedule line with zero amount to cover the period between the cutover date, and the date or next payment.

However, in doing so, we are encountering errors. Some leases have a quarterly compounding interval and quarterly payments. 

When setting up the payment schedule, we are getting error messages relating to the payment frequency of the payment schedule line must be quarterly if the compounding interval is quarterly.

Example:

Lease commencement date 27/10/2023

Next actual payment date 29/12/2023

So we are entering the below in the payment schedule:

Lease commencement date 27/10/2023

Payment schedule line 1 = 27/10/2023 for 2 months at zero amount with Quarterly payment frequency

Payment schedule line 2 = 27/12/2023 for 2 days at zero amount with quarterly payment frequency. 

Payment schedule line 3 = 29/12/2023 for 16 months at the payment amount with quarterly payment frequency.

This then gives an error saying: For period interval Days, payment frequency must be Monthly

When we then set the payment frequency to be monthly, we encounter another error message when trying to create the payment schedule.

Payment frequency should not be more frequent than the compounding interval. 

It does not seem possible to setup the lease to accommodate for quarters where there is a timing difference between the cutover date and the next payment date.

The date of VAT register is always blank for purchase ledger invoices created automatically by intercompany trade operations.

The system ignores the date of VAT register filing field on the sales tax group.

Given that all the information is within the one single system when performing intercompany trade, the system should follow the same logic for intercompany purchase invoices as it does with non intercompany purchase invoices, and apply the same logic to automatically assign the date of VAT register value.

Regarding Issue 646819 that is By design, and your (Microsoft) remarks are the following:

There is a difference in process of fetching exchange rate for calculating accounting currency amount and reporting currency amount, so the system posts voucher transaction with penny difference.

If you have chosen to have the same currency as accounting and reporting currency, then the calculation should be the same and no penny difference should exist. This should be regarded as an error!