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.
