packing list not showing total weight and carrier.

I am glad that I contributed to openerp. I can find a few hours to spare and look into openerp code. Is there any documentation to set up openerp code in eclipse on windows? I have eclipse and pydev both installed on my system.

This has been fixed with 2578 <email address hidden> revision of stable addons.
You can set carrier from following two places which is further applied to stock picking carrier field.
1.Field name Delivery method which is many2one in Partner form =>Sales & Purchases Tab=>Deliveries Properties.
2.Field name Delivery method which is many2one in Sale order form=>Other Data tab.

Thanks.

is the weight problem, where packing list shows weight=0 despite of corresponding sale order line showing some value for weight, also resolved?

Yes, You may check and let us know.

how can openerp be upgraded? do i need to download individual modules and then check? If so then which module do i need to upgrade and check and from where should i download it? when i started using openerp then at that time I just downloaded the exe files of openerp from its home page; so please guide me on how to upgrade from repository.

Hello Akshay,

Install bzr on your system.
Get the delivery module from https://code.launchpad.net/~openerp/openobject-addons/5.0.

Thanks.

So i need to replace the old delivery module in my addons directory with the new delivery module and restart the server..am i correct?

Alright got it working. Weight is shown correctly but problem 2 still persists that is "for the same packing list the view stock.picking.out.form showing carrier correctly but delivery.picking.out.form showing carrier field blank"...If this has been corrected then tell me which module to update other than delivery

Hey Jay,
I think there is some trouble in code of weight calculation. It does not take into account the uos coeff because the weight is ofcourse for default UOM and not UOS and therefore UOS coefficient should be used (it is used in weight calculation in sale module). I forgot to remind you about this but now since we r discussing the coefficients (in another thread) so please rectify the code for delivery module as well. Also it is much better to have each stock.move has a weight field that represents weight of the individual move in a picking and then the picking can just sum up the weights of the move. Also Stock picking view can be modified accordingly to show the weight of each move individually.

This is the code that i did in stock.py file of delivery module:

class stock_move(osv.osv):
    _name = "stock.move"
    _description = "Stock Move"
    _inherit = 'stock.move'

    def _cal_weight(self, cr, uid, ids, name, args, context=None):
 res = {}
 for move in self.browse(cr, uid, ids, context):
     weight = 0.00
     if move.product_id and move.product_uos_qty > 0.00 and move.product_id.weight > 0.00:
         weight += (move.product_id.weight * move.product_uos_qty / move.product_id.uos_coeff)
     res[move.id] = weight
 return res

    _columns = {
 'weight': fields.function(_cal_weight, method=True, type='float', string='Weight',digits=(16, int(tools.config['price_accuracy'])),
           store={
    'stock.move': (lambda self, cr, uid, ids, c={}: ids, ['product_id','product_uos_qty'], 10),
    }),
    }
stock_move()

# Overloaded stock_picking to manage carriers :
class stock_picking(osv.osv):
    _name = "stock.picking"
    _description = "Picking list"
    _inherit = 'stock.picking'

    def _cal_weight(self, cr, uid, ids, name, args, context=None):
        res = {}
        data_picking = self.browse(cr, uid, ids, context)
        for picking in data_picking:
            total_weight = 0.00
            if picking.move_lines:
                for move in picking.move_lines:
             if move.weight > 0.00:
                        total_weight += move.weight
            res[picking.id] = total_weight
        return res

    def _get_picking_line(self, cr, uid, ids, context=None):
        result = {}
        for line in self.pool.get('stock.move').browse(cr, uid, ids, context=context):
            result[line.picking_id.id] = True
        return result.keys()

    _columns = {
        'carrier_id':fields.many2one("delivery.carrier","Carrier"),
        'volume': fields.float('Volume'),
        'weight': fields.function(_cal_weight, method=True, type='float', string='Weight',digits=(16, int(tools.config['price_accuracy'])),
                  store={
                 'stock.picking': (lambda self, cr, uid, ids, c={}: ids, ['move_lines'], 20),
                 'stock.move': (_get_picking_line, ['weight'], 20),
                 }),
        }
.
.
.
<more code here>
stock_picking()

I hope this code also makes it to stable version :)

Hello Akshay,

Would you please attach a patch and open another bug with description?

It would be best if users get threads for specific problems/bugs.

Thank you for your efforts.

We appreciate this.

It has been Fixed by revision 2644 <email address hidden> on 5.0.7.
For Weight field on moves, it will be committed to trunk soon.
Thanks.

Improved by revision 3170 <email address hidden>.
Thank you for the patience.

I just upgraded my production system to 5.0.7 and now I discover that the field "weight", which was formally a float, has now become a function field!
Come on, there are people using this field, you can't just make it a function! What if we want to write something else in the field like we used to in 5.0.6?
Do as you want on the trunk but the sake of all you care for, this is supposed to be STABLE.
Lionel

For your information, there was a module "delivery_weight" in the community branch to estimate the weight of a packing and let you adjust it. It's very basic but it used to suit our needs - now it won't work anymore of course.

Well , Lionel.

For the sake of old record(s),I agree with you.
We can revert those changes and can put a button on view to evaluate weight.

But, it would be a great pleasure for users if they get immediate(auto-calculated) weight on Picking without pressing a button each time.

Let me know your views.

The openobject developer guide states that the functional fields can be made editable by using "fnct_inv" paramtere. This is what it says:
"fnct_inv is the function or method that will allow writing values in that field." on page number 76

I tried to use it and was able to make the weight field as editable in UI but it did not save the value that i typed in and threw some python error. I am exploring it more.

Hey Jay, What do you think...why not use fnct_inv and make weight field as editable so user can enter any data from UI and still have it as function field. That way we would not need any stupid calculate button. For god's sake dont make users click the calculate button.

Numérigraphe, Your concern is absolutely valid BUT in production environments one should NOT use community modules. And these openerp guys are doing a magnificent job and I am more than 100% sure that they will come up with something good to address your concern very soon.

Jay,
I agree that automatic computation is better than button-pushing. I don't mind that being changed on the trunk.
5.0 is changed already, so if we're the only ones impacted then keep the changes - we'll patch our server.

Now for the trunk: from our experience, we know that a computed weight can be an estimate at best, but there are lots of reasons for overriding it: some products have variable weight (tulip bulbs for example), or sometimes 1Kg more or less can change the carrier's shipping rate and we have a tolerance.

I think we could introduce a new field "weight_override": when it's null, weight = current function ; when it's not null, weight=weight_override.
You could either show both fields side-by-side, or show only weight_override and add a button "Change weight" with a wizard to change weight_override.

If you're willing to do this in the delivery module, that's fine and I'll gladly test and validate, and probably backport/patch to our 5.0 server.
Otherwise I'll do the necessary changes in delivery_weight.

Can you please tell me what you think about this?
And would you like me to file another bug report about this improvement?
Lionel

Akshay Jain a écrit :
> why not use fnct_inv and make weight field
> as editable so user can enter any data from UI and still have it as
> function field. That way we would not need any stupid calculate button.
> For god's sake dont make users click the calculate button.
>
I agree of course, with a reserve however: a value manually entered must
not be overwritten without a warning, even if other parameters change.
But that means we may need a way of showing that it's not automatic
anymore...
> Numérigraphe, Your concern is absolutely valid BUT in production
> environments one should NOT use community modules.
Oh well, I wrote this module myself so I trust it just enough for
production on our own server :)
It's just a quick workaround and I humbly agree a better solution should
be found.

Lionel

Lionel,
I agree that a value manually entered must not be overwritten without user's consent. How about having a configuration setting that allows users to set whether weight should be set automatic or manual and then accordingly show the corresponding field (weight_auto or weight_manual) on packing form.

Akshay,

just a remark:
are you aware that lot's of such "community" module have better code quality
score than the "official" modules form Tiny using their own "quality'"
criteria?
So I mean don't let the marketing fool you this is all relative, it pretty
much depends on who made what module and how it's being sold.
Official addons have an highly specific mrp_repair module, while community
module have a generic stock_rma module, you could also check the reporting
engine...
Now, in general I ask for more feature planning and shorter development
cycles to avoid such wildcat changes in the """stable""" release.
I'm not sure yet, but we might have a customer impacted here with that
change (and by the way they are also a customer of OpenERP S.A. via a
maintenance contract).

Regards

2010/3/18 Numérigraphe <email address hidden>

> Akshay Jain a écrit :
> > why not use fnct_inv and make weight field
> > as editable so user can enter any data from UI and still have it as
> > function field. That way we would not need any stupid calculate button.
> > For god's sake dont make users click the calculate button.
> >
> I agree of course, with a reserve however: a value manually entered must
> not be overwritten without a warning, even if other parameters change.
> But that means we may need a way of showing that it's not automatic
> anymore...
> > Numérigraphe, Your concern is absolutely valid BUT in production
> > environments one should NOT use community modules.
> Oh well, I wrote this module myself so I trust it just enough for
> production on our own server :)
> It's just a quick workaround and I humbly agree a better solution should
> be found.
>
> Lionel
>
> --
> packing list not showing total weight and carrier.
> https://bugs.launchpad.net/bugs/519220
> You received this bug notification because you are subscribed to
> OpenObject Addons.
>
> Status in OpenObject Addons Modules: Fix Released
> Status in OpenObject Addons 5.0 series: Fix Released
> Status in OpenObject Addons trunk series: Fix Released
>
> Bug description:
> I am facing 2 problems with packing list.
> Action: Created a sale order with a product. Product's weight was set to
> 2Kg. In sale order line quantity selected was 4 so order line correctly
> showing total 8Kg weight. Set the carrier as well on sale order. Confirmed
> sale order. Now on packing list i am facing following 2 problems:
>
> Problem 1:- Packing list showing weight as 0.0 whereas sale order line for
> the corresponding sale order shows weight correctly as 8Kg. And becoz of
> this problem the carrier charges based on weight dont get added to invoice.
>
> Problem 2:- for the same packing list the view stock.picking.out.form
> showing carrier correctly but delivery.picking.out.form showing carrier
> field blank.
>
> Can you please guide me on this and if its a bug then please tell me a
> quick fix for it.
>
>
>

Well I am new to openerp and not very aware of its community structure. But from my past experience as a Java software developer I know that community editions may be super good but they dont come with a guarantee. Call it a marketing fad or whatever u want but guarantee is a big deal and will always be. Suppose if something goes wrong becoz of a community module and business loses money becoz of it then how can business claim that loss from community?? It cannot.

And yes I know this is a bottleneck in software market where people like Microsoft, Oracle (and many more like them) make huge money by unnecessarily pushing new versions down the throat of their customers and ending support/guarantee on older versions BUT BUT BUT every business needs Guarantee.

But as i said i m new to openerp and not sure of its community structure so please dont take me otherwise.

Hello Guys,

Better we move towards the better solution.

Setting the field as functional field is absolute generic requirement. Isn't it ? Let me know. Why would user push button each time to calculate weight?

And, concerning old values(existing records), this functional field will only be evaluated on changes from product,its uos qty,uom,qty. I have checked already by writing a value of weight X in one Packing. after I applied the change of function field, X value remained same in that packing as there is no client-based change in move. If we change the moves(qty,product,uom), the weight for packing will be re-evaluated. So, previous records are safe.

@ Numérigraphe(Lionel),
I want some guidance here. You said that for packing its not always packing's weight= sum of weight of all moves. you mentioned this by having Variable weight for any product. If this is really the generic case, OpenERP will definitely go for an improvement.

Your votes please.

We can ask Experts for this concept of variable weight.

Thanks.

To sum it up:
- I can confirm that existing data was not lost when we upgraded to 5.0.7
- the function is better than a push button, and "better" should have told you it's a trunk-only thing.
- I do need a way to override the function. Variable weight is typical of food/agriculture I think. Pricing tolerance is common in logistics here, but maybe it's cultural. If that's not generic enough I don't mind developing a module when 5.2 is released.
- right now I have no time or budget for this module, so I have reverted your changes on our server to keep my old stupid workaround working until 5.2 is released.
Lionel

I think all of us have a valid point here. Best solution in my opinion would be as follows:

Have a configuration setting for stock where user gets two option to select from as below:

Option 1: Calculate weight automatically from moves.
If user selects this option then openerp calculates weight automatically and a button on form along side weight field is provided that says "Set weight manually". IF user will click that button then he is allowed to set weight manually and the button changes to "Calculate weight from moves" and that manually set value cannot be calculated automatic until user clicks the button AGAIN.
This option is useful for those situations where the automatic weight calculation is generic and only in 5-10% cases user needs manual weight setting.

Option 2: Manually enter weights
If user selects this option then openerp DOES NOT calculates weight automatically and user is allowed to enter it manually and a button on form along side weight field is provided that says "Calculate Weight from moves". IF user will click that button then openerp calculates weight from moves and the button changes to "Set weight manually" and that automatic value cannot be changed until user clicks the button AGAIN.
This option is useful for those situations where the manual weight setting is generic and only in 5-10% cases user needs automatic weight calculation.

Let me know if this is "better" becoz after all the discussions we had I believe that all of us are RIGHT and openerp needs to evolve. If this solution looks good then of course none of us will expect this before 5.2.