Managing incoterms on tryton

This post was flagged by the community and is temporarily hidden.

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
    – Building Name: DUS Airport
    – City: Düsseldorf

1 Like

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.

I have simply done the encoding of the cited examples in the demo database and this is it looks like after:

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.

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:

    def order_name(cls, tables):                                                    
        table, _ = tables[None]                                                
        return [Case((CharLength( == 0, 1), else_=0),]  

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”.

The more we discuss it the more I agree with Udo

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.

We already discussed:

I think a good midpoint could be to allow defining addressess with no party as suggested @dave.

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.

Good luck in keeping the overview.