On 2017-03-09 20:15, Ul wrote: > Am 09.03.2017 um 19:13 schrieb Cédric Krier: > > On 2017-03-09 18:45, Ul wrote: > >> Am 09.03.2017 um 15:29 schrieb Cédric Krier: > >>> On 2017-03-09 14:23, Ul wrote: > >>>> If you just follow the lot relations made by production, you are right. > >>>> But as i explained to Sergi, i added a aditional field 'supplier_lot' to > >>>> move, that is filled by shipment in, as i do not want to use the Lot > >>>> numbers of the supplier internally, but of cause have to track my lots > >>>> back to them. > >>> > >>> But this could be simply managed by adding the field supplier_lot on the > >>> lot instead of adding a new field on the move. > >> this way i have the supplier Lot as a independent Lot that is nicely > >> integrated in my tree. for example: http://pasteboard.co/HpSrF4dk8.png > >> The lots with a party as origin are supplier lots, and with the context > >> menu i can change to the supplier or the shipment.. > > > > I do not understand. > > For me, there is no independent lot possible. Your internal lot should > > always come from the same supplier lot. So the information about > > supplier lot could be stored on the lot. But of course you can add a > > Function field on stock move to show it next to the lot. > Yes, the internal lot always comes from the same supplier lot. But > several supplier shipments can ship the same supplier lot.
That's not a problem if you store them on the lot, you can store many times the same supplier lot. I even think we should have the same design as for party identifier. > I want to > create a new internal lot at each shipment to track the internal lot > back to the shipment. This is the main reason to have an extra internal > lot. I do not follow why this goal requires to add a new field. > The other reason is, that some suppliers have lot numbers with more > than 15 digits and i don't want to type them all the time. > The supplier lot has to have a full line in the lot table to be > searchable as any other lot. I do not understand. > Yes, it would be possible with a many2one field in the internal lot. But > to include the relation in my tree i would need a function field in move > and i would still need a custom query with a union for the tree. So for > me it seems more complicated this way as i want to handle and display > this relation as the other relations. This is a simplification for the developer but for the user it is not as he has to enter both lot on each move. Without talking about integrity error, how will you prevent a user to encode on a move a lot and a wrong supplier lot? -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20170309233451.GD87763%40tetsuo.
