Here is an implementation: Issue 9961: Manage incoterms - Tryton issue tracker
I feel having the location as address field is not a good idea. It adds unnecessary overhead.
Just a free text entry serves the needs, keeps the database clean and does not upset the sales clerk
I was not able to find any reference to the incoterm location. Per your comment I understand that the patch considers that using “shipment_address” is enough but I don’t think that is the case.
I’m not an expert but as AFAIU there needs to be a destination address, which I understand should be the existing “shipment_address” and also an Incoterm Place which is where the responsability of the goods changes from the sender to the receiver. As you said that would not require a complete address, and could simply state “Barcelona Port”,
Or am I wrong?
Correct, it could just be a location or port of entry or airport. So ‘Barcelona Port’ or ‘Liege’ or ‘DUS Airport’ could be ‘valid’ entries
Why? Could you provide an example?
I think you could have an incoterm with a place which is not the final destination. For example, incoterm could be taken in charge until an airport, harbor, … then the customer should take in charge the delivery to the shipment address.
In such case why would you encode the final address instead of the airport?
Up to the contractual situation, reflected in the Incoterms.
I scanned some 500k sales order in a customer system: It is just city or harbour, maybe ‘Norfolk warehouse’, but never a full address
Because you must specify the appropriate delivery address for the carrier. The place determines the allocation of costs (or responsability) during the trip. That is at what point of the trip from your warehouse to the customer warehouse the reponsability of the goods moves from one to the other.
For example, if the seller is delivering a container using FOB and that container is broken (falls from the crane into the floor) in the port, then it’s the seller’s insurance that must take care of the costs. But if the container is broken in the ship, then it’s buyer’s insurance that takes care of the costs.
The wikipedia page is quite useful, in particular this table:
See also that most “modes of transport” need the “named place of delivery”. Ie:
Could you please give an concrete example where the seller is responsible of shipping the goods after the place.
In your FOB example, the seller must ship the goods only to the place are loaded on board. So the carrier used requires only to have this place/address. The ship on the board is “organized” by the buyer.
Yes it is where the seller must deliver aka the delivery address.
DDP Liege would be a valid incoterm. It is not necessary nor common practice that the Incoterm location contains a full address
I’m not sure I can answer those questions with enough confidence, as I said I’m not an expert. It’s been always my understanding that the seller needs to create a shipment document (and invoice) that indicates the final delivery address, no matter what mode of transport is used in incoterms.
I would say that it’s possible for the supplier to prepare all the documentation (including transport) until the final destination, even if EXW or FCA is used.
I looked at other sources and although a bit hard to find explicit references to the distinction, I found this one which explicitly states that there’s a difference between the delivery address and the place where the costs are exchanged:
I could also find some information in SAP documentation where it states that for some modes of transport the user is required to inform the named place:
Once the seller is no more responsible, he can not know for sure what is the destination and he does not need to know.
OK there is this case but there is a default value if not specified and more over it can just be specified as comment on the sale order.
No they said that there is an option to force use to fill a location. I do not see the real point to have such enforcement in standard.
AFAIK @coogor and @albert are right. Customer destination address can be different to Incoterm place, and both must be specified.
That is the reason why he needs to state for some incoterms a location.
The delivery address needs to be stated on the shiment documents - this is obvious because the customers wants the goods delivered to the right location. This is fully independent from the point where the risks moves from the seller to the customer (as specified in the incoterm)
If you see ‘comment on sale order’ a free text field ned to the incoterm you are right
Because some incoterms require the entry of a location. SAP has managed it in that way that they have a customizing table where one can specify which incoterms require a location. The system then checks if there is an entry in the location field and throws an error if this is not filled.
I guess a similar setup in Tryton should work as well.
In international trade the invoice is used to carry out customs clearance operations and other legal procedures.
The Incoterm code is recommended on the invoice which will be the legal document of exchange with customs in most countries.
In some cases we can use the pro-forma invoice (order confirmation) as a document for customs, but in the case of invoicing after shipment there may be a difference between the amounts of the order confirmation and the invoice. It is also possible to modify financial information on the invoice (product price, costs, …).
For insurance and customs clearance reasons, it is not recommended to mix different Incoterm codes on the same invoice but rather to group the invoices by Incoterm.
By analyzing the following 2 modules, I can see that the Incoterm has indeed been included on the invoice and that it is used as a consolidation key.
I also find different document which confirms that it is recommended to have the Incoterm code on commercial invoices.
example:
We also need to specify the primary mode of transport that will be used for shipping. This mode of transport can also depend on the Incoterm because for the specific incidents of sea transport it is necessarily a sea transport;)
We can define a transport list:
- Sea Transport
- Air Transport
- Multi Modal Transport
- Road Transport.
Do you have any information regarding this invoice information in other countries?
Why would the customs care about the Incoterm?
For me it should not be a problem as long as it is clear on which lines each incoterm applies.
But they both support multiple incoterms per invoice.
Also I do not see how it is managed as a discriminate key for the sale_invoice_grouping.
Indeed I think it will be wrong to store on the invoice the incoterms because:
- it could be changed on the shipment (or sale) by an amendment for example and no more correspond to the value on the invoice
- it is the shipment value that are the trust source
- it does not make sense to set an incoterm on an invoice which is not linked to a shipment
So for me Incoterm should be a computed field based on the value retrieved from the lines (like for origins). But it should take the value from the shipment (and nor the sale) through the linked moves.
Also we should ensure to link to an invoice line only moves with the same incoterm to allow clear identification of the product to which it applies (like a separation/grouping on the invoice).
The carrier on the sale and shipment is considered (by design) as the primary mode.
This is already managed by the module. The carrier has a field “mode” which filter the available incoterms.
But we are missing a way to define multiple carriers.
One idea is to create a meta carrier which contains a list of carriers. The drawback is that the user may need to create a lot of combination. And we must ensure that the meta-carrier has the correct properties aggregated from the list.
Another idea is to add on the order an ordered list of carriers with location. If this list is filled then only one of the carrier can be used as “primary” carrier (but carrier can be left empty). The shipping cost is computed for all the carriers and the list is copied to the shipment.
I think the second option is the most flexible and simple for the user.
I just had a look at https://codereview.tryton.org/326951002/
The proposal is also missing the version of Incoterms used which seems to be imperatively required on documents. All documents we know from customers include the version of the incoterms.
According to the link already posted which gives valuable information about the named place of delivery
it also states:
Many companies have complex agreements with their counterparties and service providers, which will be time-consuming to redraft.
Therefore parties are free to continue to refer to Incoterms 2010, Incoterms 2000 (or any other revision!) – provided that this is specified unambiguously in their agreements.
Therefore we should have versioning on incoterms and best will be to include the version in the rec_name.
I guess because shipping costs are part of the customs duty.
We should try to not overcomplicate things.
It makes sense to put the incoterm on the order header and push this thru to delivery and invoice.
On a delivery or shipment the Incoterm will never be changed, as the legal contract is the sales order, not the delivery or shipment (and a delivery does not necessarily need a shipment).
Sure, one can group multiple deliveries in one shipment, but that does not affect the incoterm at all.
I dont see the need at all to juggle with carriers.
For cross-border transport a pro-forma invoice for customs clearance is usually issued. That - as well as the final invoice - need to contain the incoterm. It may be one grouping criteria for a collective invoice.
I am convinced, that it is a good idea to use Tryton addresses, because…
a Tryton address is designed as a general location which is related to one and only one party. Addresses have a minimal overhead, as you could even create an empty address for a party. (Of course there is room for improvements: Addresses and locations could be separated, because there is no need for a location to have a party… but this is for another topic.)
No, not in my experience. A free text field never keeps a database clean and is always a workaround for unsolved data complexity. In the long run it will produce a mess, because it is unstructured data. It is costly to index and search in databases.
On the other hand Tryton addresses keep the database clean, as they are re-usable. I very much appreciate that we avoid text fields as much as possible in the design. IMHO best is to leave this kind of text-field-optimisation into the hand of the integrator.
I thing the clerk immediately likes Trytons address conception. Because she will recognize addresses as a kind of structured Textfield which can be reused the next time, searched and sorted in list views. The entered data can be selected and sorted for the arrangement of tours and planning the route of a carrier for a tour.
All the named examples in the discussion can be included as valid re-usable address locations in Tryton:
-
“Barcelona Port” can become the address:
– name=Port
– city=Barcelona
or the lazy one puts it in the street field (the name ‘street’ has also room for improvement), which is the requested text field: Barcelona Port -
“Liege” can become the address::
– city=Liege -
“‘DUS Airport” can become the address::
– street (is a text field!): DUS Airport
or
– Building Name: DUS Airport
and
– City: Düsseldorf
1 Like