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.
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
A substantial drawback with all those examples is that party is required on address. If I don’t want to assign such an incoterm location to the receiving party (e.g. I don’t want to assign DUS Airport to a customer that doesn’t have this address) I have to create some random party as a workaround to serve as a container for those addresses. A workaround always smells like unclean design.
Why not use a separate model incoterm_location that could only consist of a text field? I do not really buy the argument that searching on such a field should be less structured, we already search on text fields in addresses.
Indeed the a place (address) is always associated with an owner (party).
I may understand that there may be cases where you do not know the party of the address, so you can create a party without any name (tryton will create a code to identifiy it) and leave as is.
Latter, if you know the details of the party you can just fill it’s name and other related information.
The benefit of having a party is that you can also associate contact mechanisms to them. Following the example of the airport, this may be also usefull to store the phone/email to call when there is some delivery issues.
The database will fill up with empty or just incomplete entries. After encoding some 30 incoterm locations the user will be presented with an empty party list. A user trying to delete such cruft will get a message like "A value is required for field “Incoterm” in “Sale” which is quite enigmatic on its own. It is not what I would call simple or intuitive design. I am not an expert in incoterms thus do not know if in daily practice there is ever a need to store contact mechanisms with an incoterm, according to the messages in this thread it seems unlikely.
Summary:
Re-using addresses as incoterm locations is an overcomplicated an overblown way to encode such locations with grave consequences for the user interface. It doesn’t follow the minimal requirements which is just a text field. Not to forget that addresses vs. text field does have an avoidable cost on database level.
This is not related to incoterms but with the fact that you have incomplete data.
I’m not sure if having an empty list is a big issue because you can always find the right party is desired (when having more than 30 parties there is a change that the one the user is looking for is not on the main screen).
But this can easly be solved by adding the following code on party class:
Not sure if this is something that should be added to Tryton but for sure it is not related to incoterms.
This is error is because you are removing a value which is used on a required relation. This is generic and not related to incoterm. So if you thing there is something to improve please provide a patch for it
I think you are not fully seeing the feature here. The incoterm location can be the customer location or the company location. In both cases those address already exist on the system so having a text field will make the information duplicated and not precise.
Furthermore, if there are severall customers that deliver to the “DUS Airport” you can reuse the same location for all customers, while using a text field may lead to some wrong data: “DUS Airport” vs “Düsseldorft Airport”.
It is related to the fact that a simple text field would obviously be sufficient and doesn’t produce the overhead of incomplete data. Why do you want to force the user to insert basically unneeded data just for the sake of a tolerable interface?
It is not about the nature of such error message but that it could be avoided with a clean design in the first place. Thus this point is relevant for this design of incoterms.
Agreed for the use case of just those two locations: the customer and company location.
Not with my proposal to just link to a model incoterm_location just containing a text field. It would be re-usable like any address field, but save a lot of unneeded empty data.
For me it does not make sense to create a new model for incoterm while we already have the address which is already defined for the customer and the company.
I think we are now at the end of the street:
Using a text field does not work because it does not normalize data
Using a separate model forces to duplicate the data because it’s already on the address
So this leads to think that using the address is the best solution.
I think that some of the problems with using an address are caused by the fact that, at the moment, to have an address you must also have a party.
If addresses could be created that were not linked to any party, then that may help to partially mitigate the issue with:
Then, at a later stage, if a party then needs to be created to go with the address then that could be done.
Also, when a party is set for an address then the party would become fixed, just like it is now. This would mostly preserve the current behaviour, with the exception being addresses that don’t currently have a party.
Why should it be normalized? It is a legal text like the legal notice on taxes and should appear on the documents in the format the user has given to it.
Interesting how the discussion evolves when being afk for some days…
There is no need to normalize data. The location field covers information required for invoices. There is no need to check it against masterdata, nor is it foreign key to anything.
Creating a separate address pollutes the database with incomplete and unnecessary entries.
In Germany we call this ‘Strukturbefriedigung’(*), creating an entry for something just because it is asked to be created, without further need or value. Once you have ‘Airport DUS’ you need to create ‘Airport DUS Terminal B’ the next day and so on. @udono that will clearly not make any sales clerk happy, even if he survived the search issues that @yangoon described.
(*) structural fulfillment may be a translation for it
Good to read that you have a lot of afirmations without any rational.
If you want your opinions to be taken in consideration please provide any rational. Otherwise anyone that does not agree with the will not understand your possition.
Here is (for the third time), the reason why normalization is good:
It seems we all agree on this except you. If you don’t please provide some reasons and not just become the “source of true”
I do not see any problem to have several specific locations for the same Airport. In this case it makes sense to link them to the same party to know they are related.
Which part of ‘for information’ and ‘not used as foreign key’ was unclear?
The million-flies-principle is clearly not applicable for design decisions.
Different to your opinion stated above, the location can be any, not just the customer or company location. PoE re common as well.
You guys are excellent coders, however, business knowledge is not always valued. If in doubt, it can also help to check how the leaders in ERP have designed it.
In the development of the incoterm (https://tryton-rietveld.appspot.com/326951002/) module it is configured at the level of the incoterm FAC and FOB = transport at the buyer’s expense.
Which I think is not totally correct.
For the FOB Incoterm, transport to the boat is the seller’s responsibility and the rest is the buyer’s responsibility. So the pre-routing is the responsibility of the seller and the main carrier is the responsibility of the buyer.
In the case of incoterm EXW, the full transport is the buyer’s responsibility.
But in the case of FAC and FOB incoterms, we have a MIXED mode of transport (part for the seller and part for the buyer).
With the current configuration with FAC and FOB it is not possible to use a transport cost method to have the transport to the place of Incoterm.
I think that we should have at the transport level on Incoterm: Buyer, Seller, Both (or mixed)
I do not think because incoterm is clear and unambiguous about who is responsible of the main carrier.
Indeed if you want to compute non-main carrier cost, you need a new module that allow to define all the carriers involved (and how they are costed) and not only the main one.
I think that we actually need in this case to have a module which allows to define the different carriers.
The current configuration of the incoterm module and the carrier field, allows only the main mode of transport to be defined.
In the default version it is not possible to order transport in the case of incoterm FAC and FOB for pre-routing.
The transport will have to be treated separately.
To manage the transport in tryton in the case of FAC or FOB, it is necessary to extend the transport management with a multi-transporter system which makes it possible to define the complete route and define the transporters payable by the customer or buyer more precisely.
