Incoterms are an international contract terms defined by the International Chamber of Commerce. This is used to determine some contract conditions when purchasing/selling goods to other countries.
But i think this will be usefull for all Tryton users so I’m wondering if this will be a good adition to the set of module of the Tryton foundation but I have some doubts about it:
It is worth to gave 3 diferent modules or with 1 is enought?
Do we need to store the incoterms on a table or with a selection field on sales/purchase is enought?
It is possible to assing multiple incoterms codes to the same sale/purchase?
I do not see any advantage to have multiple modules.
For me, the integration should be deeper than just adding a field. The incoterm should be in compatible with the configuration of the order. For example, it should not be possible to use “FCA - Free Carrier” if a carrier cost is define on the order. Also I think the goal should be to have the incoterms completely deduced from the Tryton data, of course for now we are missing some information but at least we should be able to limit the choice.
I do not know but it would seem strange as the terms define costs for operation on the order and not only on goods like carriage.
I do not see why versioning them. For me, only one version is active at a time so remove older (with inactive) should be enough.
Would be interesting to define default party incoterm rules at shipment address level.
In our implementation it was at party level, but in a last deployment we found this new requirement.
No, the incoterm depends on the data on the order like payment term, carrier cost etc.
The point is not to set an incoterm but to deduce the incoterm from the setup.
The rule system should not be for the incoterm but for all other parameters.
From my experience in the industrial business as Purchasing and Operations Director, I would say that can be much easier than that. 90% of the time a third party (say supplier or customer) will have the very same Incoterm. In my company now we only will use EXW and DAP for example.
Only when the company works for projects shall be usefull to be able to change the incoterm. Depending on the project it could be posible to have a third party using different incoterms.
This said, I am used to having the incoterm as a default value of the third party. This default value could be added to the purchasing order or sales order automatically with an open option to modify it.
I believe this is a very simple solution that will work for most Tryton users. I personally don’t see the option of making it deduced. It’s not worth it’s while
I must be deduced otherwise there will be incompatible setup. For example, it would make no sense to have DAP set and no delivery address.
Incoterms are just a summary of the configuration.
OK, that can be. But I see it more like a check than a deduction. Let’s say: every incoterm where delivery is involved should be checked against the existence of a delivery address.
EXW should’t make this check.
But what I see important and simple is to have the incoterm condition as a part of the third party values. When talking about customers this should check the existence of the address, for suppliers is not neccesary.
I think it is better the other way around. The document should limit the available incoterms for its configuration. And we could have on the party a list of valid/accepted incoterms (ordered by preferences). So to validate the document, it should have a valid incoterms for its configuration and a valid incoterms for its party. The document may select automatically the preferred available incoterms.
Then we should propose the first one and automatically pick the next if an invalid configuration is set. This way the system will be smart enought to pick the right Incoterm depending on the sale parameters and the party configuration.
It’s much better than what I’m proposing but sincerelly I don’t see it worth it’s while. I don’t have a clear idea of what that suposes on programming time so I must admit I don’t have enough criteria.
As a user I don’t see I would need something so precise. For me, it’s enough to have the Incoterm set in the third party and to be able to change it on the sale if necesary.
With your proposal you go a step ahead so if it’s easy to programm would be great!!
I’ve been thinking on how to properly define the limits. As Tryton is modular we should be able to define for each incoterm a list of exclusion clause. The exclusion clause should be only created by modules and we will use a Many2Many to refer them.
A similar field should be added at document level (sale/purchaes) but in this case it will be a functional field. This wil allow the developer to compute for each document it’s exclusion clauses.
With this information we can add a domain that test that both clauses matches. This will prevent the user to select wrong incoterms.
With this desing the incoterm module should loads by default all the know codes (Here is a list) so other modules will be able to include the exlusion clauses of each one.
On the other hand, we should be able to name the place where the goods should made available (i.e: Seller Warehouse, Buyer Warehouse, A named Port). I think that for each party we should add a list of Named Places.
With this setup, it should be possible to exclude some clauses depending on the ownership (if it’s from seller or buyer) of the delivery place.
The sale_shipment_cost module should also include a condition to restrict the Incoterms that do not include transportation costs (CPT, CIP, etc). So this incoterms should not be selected if a carrier is selected.
To resume, the incoterm module should define the folliwing models:
Incoterm
Code: The 3 digits code used to represent it
Name: The translatable name of the incoterm
Clauses: A Many2Many to the exclusion clauses of this incoterm
Clause
Name: A translatable name to represent the clause
Place
Name: A Char field to the name
Company: The company to which the place is associated
Party: An optional party from which party the place is associated
Address: An address to represent the place.
The Party model should be extended with the follwoing fields:
Accepted incoterms: A sequence ordered list of the incoterms accepted by the party.
Places: A list of incoterms places that related are to the party
And for each document (purchase/sale) we will add the following fields:
Incoterm: A Many2One to the incoterm. If only one is applicable it will be automatically set via on_change
Place: The place where to deliver the goods. It will also be automatically set if only one is applicable.
Sometimes place should be more precise than an address… Could be a Gate number, loading dock, … and sometimes, just a name is enough “Singapour”, “Port of Antwerp”, …
And also some incoterms doesn’t require a place and for the others, place is required. So maybe Incoterm class could have a boolean field “Place Required”.
The name should be used to represent the exclusion on the user interface.
The idea is that each module creates the exclusion it’s manages so they then it can be referenced with the xml_id.
Because it talks about a named place, which can be for example “The Barcelona Port” or “The Seller warehouse”. So for me the adress is not enought as we also require to have the name of the Agreed Places.
Yes, this should be one condition to enforce that the placce have and adddress set. So the delivery address is set.
No when the goods are picked by the buyer on the company warehouse. Currently we enforce that the shipment address is related to the party (or shipment party) so when the goods are picked up on the warehouse this address should be empty.
I’m wondering if it will not be simpler to have check boxes for each exclusion on the terms. For example with the shipment cost, we could have a shipment cost check box. So only terms with it checked can be used on sale with shipment cost. It will be easy to write such dynamic domain.
I still do not see why those places could not be an address.
Or if it is just a name why should it need to be linked to an address.
There is no need to include the address of delivery nor the destination altought it is a good practice. See: Delivery - Incoterms Explained
As the agreeded places should be normally reused for multiple operations, I think it makes sense to have it listed in the party form, but if you prefer to keep it simple we can include only a name without address.
I still believe the place should be the address.
In worst case, the address will have only the name filled but it is where the company must deliver the goods.
