2014/1/17 Cédric Krier <cedric.kr...@b2ck.com>: > On 17 Jan 12:54, Àngel Àlvarez Serra wrote: >> 2014/1/17 Cédric Krier <cedric.kr...@b2ck.com>: >> > On 17 Jan 10:19, Àngel Àlvarez Serra wrote: >> >> Hi, >> >> >> >> I move here a discussion from codereview >> >> http://codereview.tryton.org/1221003/ >> >> >> >> I've tested the codereview and i find a terrible issue usability >> >> because when you assign moves to packages don't filter assigned moves >> >> if you not save record previously. >> > >> > I want to lower this issue because: >> >> I am not agree to lower this issue because: > > So we agree to disagree. > >> > >> > - there is a workaround by saving after each package creation >> >> It's not a solution for end-user > > It is for you. > By the way, I think it is what most users will do in real condition > because you have to leave the computer to fill each new package.
If you have three people making the package, 1 computer, 2 filling package you have 1 real condition that it is not necessary to leave the computer. Any way, when i stay in a view i expect a correct behavior without thinking if i save the record. > > Also this can be acheived by using a relate instead of editing the > one2many. > >> > - user must encode what he does and so he don't rely on the >> > application to enter the data >> >> But you need to not get lost on data input. > > And so. If you put yourself in real condition you will not be lost. If you have to split the moves you can't make package correctly. 100.000 p1 units - 10.000 p1 units package 1 - 10.000 p1 units package 2 - 10.000 p1 units package 3. ... try this, please. > >> > - if the same move is twice picked, at the end it will be only in >> > one package and the module will warn him about missing packed >> > move. >> >> It's not user friendly, you only need to try, and you get mad after >> third selection. > > Again your are not using it in real condition. Sorry but... there are too much real conditions, my requirements comes from clients that have real conditions. > >> >> I'll encourage you to test the module and try to assign small picking >> >> with 25 lines and split some of them, and try to not get lost after >> >> third move. >> > >> > Such testing is wrong if you don't put yourself in the real condition. >> >> I put on real condition, indeed, 25 lines of picking it's really >> small and split moves it's very >> comon because we use lots. > > I think you don't understand what is real condition. > Take your computer, products and packages and do the operations of > packaging the products. Again, more than one employee do same work, it's easy, faster and common, but i won't to discuss what it's real condition. > >> >> I have a second option, to avoid this crappy code. If you assign >> >> package directly from moves, you can follow your assigment on time >> >> without get lost. >> > >> >> Instead of having a view with one2many moves and one2many packages >> , left only >> one2many for moves, and add package field to stock_move view. >> Then you select move, and search for packages or create a new one. > > That's worst UI because you have to go through all the move to pick the > right package. So if you package thousand of move line in one pack, you > have to do thousand of edition instead of one with the current design. > > By the way, your issue also exist for all the add_remove like in > purchase_invoice_standalone. Then we have to solved this issue in more places :-) , but i think this case is different because you need to create new invoice. May be we can do in generic way. > -- > Cédric Krier - B2CK SPRL > Email/Jabber: cedric.kr...@b2ck.com > Tel: +32 472 54 46 59 > Website: http://www.b2ck.com/ -- Àngel Àlvarez Serra Tel. 93 553 18 03 @aasnan www.NaN-tic.com Avís legal >> _______________________________________________ Nan mailing list n...@lists.nan-tic.com http://lists.nan-tic.com/listinfo/nan
