Question: In Consignment, when put contraints on consignment-level and when on goods-level?

[BobZuidhoek]

Hi everyone,

In the model of Consignment, you can put constraints on the Consignment-level itself, but also on the Goods-level within the Consignment.

I can easily understand how Constraints live on Consignment-level. Constraints such as delivery windows, size-constraints, route-constraints, etc naturally live on Consignment-level (meaning these constraints overspan all goods within the Consignment). I can also understand how these same constraints of example end up on the CMR's handling instructions section.

Then there is the possibility to put constraints on Goods level. I'm wondering which constraints you would put on Goods level that needs to live on goods level instead of just placing this on Consignment level.

I'm not in the business of TMS-software so I'm on thin ice on this one: how do carriers look at this in their TMS's? I presume they rather want to have just 1 set of Constraints that apply to the whole consignment instead of having to deal with different contraints being placed within Goods?

So the questions in order:

1. In which use cases is it better to put Constraints on goods level in favor of putting these on Consignment-level?

2. Let's say a shipper is shipping goods with conceptually different sets of constraints on goods level (e.g. 1 goods-line with frozen fish that has a temperatureConstraint of maximum -5 degrees and 1 goods-line with fruit that has a temperatureConstraint between 5 to 10 degrees). Would it be best that in such a case you create 2 consignments (so each consignment only has one constraint)? Would that achieve better clarity and/or better legal representation?

3. How do carriers deal with this in their TMS's? Do they rather want to have Consignments with 1 set of constraints on Consignment-level and nothing on goods-level?

Hope someone can help clarify this a little.

PS: this subject also came up in Github #37, but there the question was specifically about if a temperatureConstraint should be able to live on goods level or just on consignment level. I'm asking the question more generically here.

[thomaskolmans]

This is sometimes necessary with consolidated consignments - in that case different goods can have different constraints and are relevant within one consignment if you will. It's in that case important to know what constraints are there specifically to the product.

Also, goods are also TransportEquipment so a SpeedConstraint or WeightConstraint is very very relevant.

[bmeesters]

I think putting constraints on both goods and consignments is relevant, like @thomaskolmans showed. I can see how it can also lead to confusion. Since repeating the shared constraints on each good is incredibly repetitive, I am inclined to leave it as is. This is not great from a standards point of view (since some parties will use the fine-grained goods constraints, and others the more coarse consignment constraints). However removing one is too limiting.

We could maybe make guidelines or rules of what types of constraints go where in the documentation. For example:

• timewindow constraints for consignments
• speed, weight, size constraint for equipment
• temperature, size constraints for items

Would something like that help?

[bmeesters]

Though there has been little activity here I think it would make sense to add guide lines to all constraints to make it clear which ones make sense where.

[bmeesters]

I added extra comments on both the goods constraint and the consignment constraint in the OpenAPI spec. Hopefully this helps. If anything is missing feel free to make a new ticket.