From an insurance perspective, it is critical to have the terms on the commercial documentation (commercial invoice) because this defines 'who' is responsible should the shipment get lost or damaged (found that out the hard way!).
Incoterms are pretty much set, so Microsoft could either add the standard set, or make all tenants add these manually themselves (don't care... so long as it can be done)
There needs to be a field in the SHIPPING section of a contact card, that allows you to select the 'terms' (which are different to your payment terms), and this field needs to be available for printing on all documentation (quotations, sales orders, purchase orders, invoices etc.).
A second table relationship needs to establish the NAMED POINT for the terms (this is described by the ICC... it's not just a good idea, it's a requirement). For example, FOB(New York) or CIF(Shanghai). You cannot have one without the other and the Named Point may be very different to the company location (it could be in a different state or country entirely).
This is a fundamental part of international trade, and broadly domestic trade (sometimes domestic operators don't use specific incoterm names but fundamentally they use the process). Without having the ability to capture these agreed terms between parties, D365 is missing a significant financial and legal component of trade between sellers and buyers.
Comments
From my short and intensive 25-years-of-NAV-BC-experience this requirement can be identifiet as legal requirement in many Countries. I'm wondering why this still has to be discussed as all of my extensions do have this as a "legal must have".
Category: Sales
Thanks a lot, Chris.You are so right. This is common ground for daily trade business.Definitely a must have requirement BC.By the way, ... ICC published the first Incoterms® rules in 1936.
Category: Sales
I agree too!
Special when you have the incoterm EXW, and you don´t know the end-customer. BC will know a delivery address from you and that makes not sense.
Category: Sales
We have the same issue.
Especially for incoterm DAP - delivery at place, we need a full address to be printed on the sales document. only the place won't do.
Category: Sales
FULLY AGREED.
For cross border or transactions in or out of Free Trade Zones, the International transaction is governed by Incoterms. Dynamics is currently structured for DOMESTIC ONLY.
Incoterms are NOT THE SAME as the transport terms (i.e. prepaid freight, etc.) or payment terms. Incoterms are a 2 or 3 part term. The first part is the 3 letter designation from the International Chamber of Commerce. The second is the location reference. The third, as optional best practice, is a reference to the revision of incoterms (i.e. Incoterms 2020). The first two must be on purchase or sales documentation.
Category: Sales
This is highly required since Brexit in the UK.
Please consider to develop this idea in the near future.
Thanks
Category: Sales
As far as I know there is no separate field available for the named point, we've already added this for some customers but I'd appreciate to have on in BC standard application as this is a main element for the use of incoterms
Category: Sales
We've had the same trouble regarding the "named point".
Somebody suggested to use the field "port" in the forum (https://community.dynamics.com/ax/f/microsoft-dynamics-ax-forum/105185/incoterms-location-spesification), is it the correct field?
I also saw that there is a "destination code", but it's not on the documents, only on vendor / customer code, so I'm unsure how it should be used.
I vote for that topic anyways and stay tuned for answers.
Category: Sales
Business Central Team (administrator)
Thank you for this suggestion! Currently this is not on our roadmap. We are tracking this idea and if it gathers more votes and comments we will consider it in the future.
Best regards,
Business Central Team