Logistics mailing list archives

logistics@odoo-community.org

Avatar

Re: negative quants and returns

by
WilldooIT, Jonathan Wilson
- 15/12/2015 14:34:14

@Joël: yes that would be a work around but the customer who uses this feature would not do it. They only need to record serial numbers on the way out. Telling them to record them on the way in would be too much unesssrsary work. The user case is valid but the implementation is sloppy.

On 15 Dec 2015 11:23 pm, "Joël Grand-Guillaume" <joel.grandguillaume@camptocamp.com> wrote:
IMO if you allow to enter non-serialized goods in stock and you force a serial on delivered goods, no negative quants should be generated, but you should reconcile  them. Workaround is to force lot tracking at every steps to avoid that.

On Tue, Dec 15, 2015 at 12:38 PM, Jonathan Wilson <jon@willowit.com.au> wrote:

@Joël: in v8 it is possible to receive stock without serialisation and then assign a serial/lot number when the stock is delivered. Odoo leaves the original quant untouched and generates a new negative quant with the assigned serial/lot number. Really messy and smells like a kludge I agree.

On 15 Dec 2015 7:23 pm, "Joël Grand-Guillaume" <joel.grandguillaume@camptocamp.com> wrote:
@Jonathan : Right ! I'm wondering if that should happen... Why do you ship something with a serial that don't have any in stock ? I mean, normaly if you ship a serialized item, you should have it with a serial in your stock and if so, no negatif quant is created right ? What am I missing here ?

On Mon, Dec 14, 2015 at 6:38 PM, Jonathan Wilson <jon@willowit.com.au> wrote:

@Joel
Just remember that Odoo creates negative quants itself when delivering serialised on output items.

On 15 Dec 2015 2:38 am, "Joël Grand-Guillaume" <joel.grandguillaume@camptocamp.com> wrote:
Thanks for update. We're going in the direction to provide a module that forbid the user to create negative quants. Only a specific group of user would have the right to do so. This way, it'll enforce people to correct the proper way before delivreing something.

The proper way would be:

 * Unreserve something to deliver another customer
 * Don't force picking but make inventory if stocjk quantity are wrong





On Mon, Dec 14, 2015 at 12:37 PM, <Pedro@pad.odoo-community.org> wrote:
Joel, current module will finish with a quant of quantity 0, but that can be modelled other way.

2015-12-10 12:08 GMT+01:00 Jonathan Wilson <jon@willowit.com.au>:
@Joel: re following the quant trail - great idea but could get complicated I guess, eg if the quant that contained the non-serialsed item had several items included in it (which is very likely since it was non-serialsed when receipting) then it would have to be split and the split quant would have to have a retro-created history based on its parent. Maybe that why Odoo never attempted it? But  the current situation is very messy with negative quants being created endlessly. 

Maybe an automated move to the Inventory Loss location from the existing non-serialsed quant and and move of the serialised quant back to the stock location (or wherever it came from)? Maybe not the inventory loss location as that could potentially cause an financial journal to be created, but some other virtual location? After this the new serialised quant and the negative serialised quant could be merged? (possibly too complicated and obscure?)

Jonathan Wilson
mob: +61 4 000 17 444
2013 & 2015 Odoo Best Partner Asia/Pacific
Creators of  Odoo-Pentaho integration project





On 10 December 2015 at 18:23, Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com> wrote:
@Jonathan: I think Quants with different serial (event if on has and the other not) should not be merge in a "generic" case. May be for yours it make sense.

Another way here is may be to follow the move_history_ids link to define wether we can merge a quant with and without serial. In that case, it makes sens for me that the resulting quants have a serial.



On Thu, Dec 10, 2015 at 1:37 AM, Jonathan Wilson <jon@willowit.com.au> wrote:
We have a similar issue for "serialise on delivery" items - the system leaves the original quant (un-serialised) in place and generates a new negative quant for the moved serialised item. There was a bug that was causing the QoH to just take into account the +ve quants which was causing mayhem resulting in rubbish QoH figures. We fixed that but now need a way to get then system "clean" again and have been wondering about the best way to do that. The "stock_quant_merge" nearly does it, however in our case, the original quant has no serial number. Maybe the module could be extended so that if the one of the merged quants was without a serial it could pick up the serial number from the other serialised quant. Not quite sure if this would break something though - thoughts? 


Jonathan Wilson
mob: +61 4 000 17 444
2013 & 2015 Odoo Best Partner Asia/Pacific
Creators of  Odoo-Pentaho integration project





On 10 December 2015 at 08:22, Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com> wrote:
Hi there,


I thought about this one. What about building an OCA addon to reconcile stock.quants in a same location ?

I mean, it makes sense, like dedupplicating partners or bank reconciliation. Those are similar uses cases made manually, with some automation magic.

We can imagine a simple tools suggesting quants reconciliation that someone approves on a periodical basis. What do you think ?



My2cents,

Joël



On Wed, Dec 9, 2015 at 2:08 PM, Alexandre Fayolle <alexandre.fayolle@camptocamp.com> wrote:
Hello all,

I'm facing an issue on a customer's database. For various reasons
(including, but exclusively, errors in custom addons), some
availabilities of outgoing moves have been forced, resulting in negative
quants. I need to repair the situation for my customer.

My first attempt was to return the pickings, to have the quant
reconciliation code do the work, but in case the quant that originally
created the negative quant is being returned, the stock module
explicitly refuses to reconcile them (see
https://github.com/odoo/odoo/pull/9907). The official answer is that it
breaks the traceability of quants, and that stock inventories should be
used for this. I'm not fond of inventories there, because I don't think
that the resulting traceability is clearer (quite the contrary in fact),
but I'm concerned pushing 9907 could break other parts of Odoo (Joss
mentionned mrp).

Before moving further, I'd like to gather opinions from people here.
Here are the options I could think of, feel free to add your suggestions:

* stick to inventories to fix this
* create an addon module to allow returns to reconcile the broken quants
(possibly asking the user to explicitly say he wants to do so)
* merge #9907 in OCB
* ???

Thanks for your feedback.

-- 
Alexandre Fayolle
Chef de Projet
Tel : +33 4 58 48 20 30

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac Cedex
http://www.camptocamp.com

_______________________________________________
Mailing-List: http://odoo-community.org/groups/logistics-21
Post to: mailto:logistics@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe




--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager


_______________________________________________
Mailing-List: http://odoo-community.org/groups/logistics-21
Post to: mailto:logistics@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


_______________________________________________
Mailing-List: http://odoo-community.org/groups/logistics-21
Post to: mailto:logistics@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe




--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager


_______________________________________________
Mailing-List: http://odoo-community.org/groups/logistics-21
Post to: mailto:logistics@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


_______________________________________________
Mailing-List: http://odoo-community.org/groups/logistics-21
Post to: mailto:logistics@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


_______________________________________________
Mailing-List: http://odoo-community.org/groups/logistics-21
Post to: mailto:logistics@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe




--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager


_______________________________________________
Mailing-List: http://odoo-community.org/groups/logistics-21
Post to: mailto:logistics@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/logistics-21
Post to: mailto:logistics@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe




--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager


_______________________________________________
Mailing-List: http://odoo-community.org/groups/logistics-21
Post to: mailto:logistics@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/logistics-21
Post to: mailto:logistics@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe




--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager


_______________________________________________
Mailing-List: http://odoo-community.org/groups/logistics-21
Post to: mailto:logistics@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

Reference