I’ll put you in context. I’m migrate from 5.0 to 7.0 and I have got internal shipments in done state with the same planned date and planned start date but they go from one location warehouse to another location with different warehouse than first. This shipments in 5.0 haven’t got transit location because this location was filled in if the dates are different. In 7.0, this functionality was changed and now the transit location is filled in if the shipment was making between locations with different warehouses. The problem is when I enter in those shipments in 7.0, I can not see their moves because now they have got transit location and in 5.0 they not generate moves to transit location.
If you have experience the same problem, ¿How could you resolve it?
If you just look for the moves of a product you will be able to correctly see the move.
One solution may be to perform some SQL queries to duplicate the current moves of such shipments by using the transit location as intermediate moves.
Why do you need to look at the history of intenral shipments?
P.S: Here is the issue which introduced the transit location functionality if you want to dig it depper
Why not? IMHO this change breaks old shipments compatibility.
Because what is really interesting is the detail, and this is shown on stock moves.
The internal shipment does not provide any information but just the grouping of the moves.
Normally when looking at historical data you just search for the moves of a product, which is shown on the stock.move table and this data is already correct.
Well the grouping is a valued information for users.
You can see the grouping from the list of moves as the shipment field will be shown.
AFAIU the problem is just when opening the form view.
AFAIK the shipment is not available in list of moves.
Anyway we can continue arguing all the time but it not make senses that a shipment with moves does not show its moves.
Another option is:
And then we can decide if such queries should can be added as migration query.
Altought this feature was added in 4.2 series, I guess the problem is related to a newer change as you did not notice until now. Probably because you did never define any lead time between warehouses. Could you confirm?
In such case this is related to:
No, the problem is not the transit location but the change on condition to use it or not; and this change was introduced in 6.6.
Before that the transit location was used only when dates were different.
Hi, Im facing the issue mentioned in here that after the migration the internal shipments are now not showing their moves because they don’t have a transit location defined, and the shipment has it because of its on_change_with update.
I also think that it makes no sense having a shipment “without” moves, as you cannot see them, even if its an old record the user may want to see anything.
As I had the on_change_with_transit_location already modified on a custom module, I just solved it by returning None when the locations defined are not the transit location, and now I can see the moves of the shipments created before the migration.
Anyways, I think there should be anything defined on migration section to fix it, probably the SQL queries to duplicate moves and set the correct locations as Sergi says.
Thanks.