|
Hi,
There would be many ways of doing this, however I would put the
column in the product_template table and another to indicate
location.
Or maybe create another table: product_id, location_id, soh, ...
When stock_move is created update table.
Grahame
On 25/08/14 16:09, lin.yu wrote:
·@Marcelo, Thanks
for info. I am quite intrested for both the thread and
intergration with lokad.com.
But I could find the thread you metioned.
@Grahame, Thanks. Where to add the column if I want the stock
level of multiple products in multiple locations.
LIN Yu
Project Manager
--
Elico Corporation, Shenzhen branch
Odoo Silver Partner
Cell: + 86 186 1691 1351
Skype: llccluf
http://www.elico-corp.com
Elico Corp is best Partner Odoo 2014 for
Asia-Pacific
Remember:
with version 8, OpenERP becomes Odoo!
![Elico Corp]() ![Odoo Silver Partner]()
Original Message
Date: Monday, Aug 25,
2014 12:48
Subject: Re:
[Openerp-community] Fw: Re: odoo with a daily 50000
ordersvolume
Hi,
The problem with calculating stock levels can be
overcome by adding a column that stores the current
level.
Evey stock move then can modify the stock level column.
I would consider using SQL directly to do this task to
avoid ORM slowness
Much less work, maybe up to 80x faster, at least in 6.1.
Grahame
On 25/08/14 13:42, lin.yu wrote:
Original Message
Date: Monday, Aug
25, 2014 11:22
Subject: Re:
[Openerp-community] odoo with a daily 50000 orders
volume
Hello
Raphael,
Thanks
for your fast response. They are really helpful.
We
have worked a daily 5000 order lines, 30000
moves project before with another company in V7.
After several months, we had terrible
performance issues as well. Especially in stock
moves and procurements.
As
you mentioned on V8 stock scalability issue is
gone. I doubt that still. The new stock level is
calculated based on the stock quant history,
which will be millions of lines in our case. And
what’s more, each stock operation needs to
operate on stock quant objects (aplication level
+ database level), besides the old objects in
V7.
Personally
I think we need an archive function to save old
stock data in another table, redefine the stock
level function based on the archive result
(inventory line or another seperate table).
For
the workflow, I do not know how to deal with it
yet. Maybe we should get rid of workflow on each
stock operations.
With the volume
increases, it requires the system to lighten
the resource of every operations .
It would be great to
have a proof that odoo / openerp can work on
that level volume.
Look
forward to receiving more feedbacks from the
community.
BR,
Original Message
Date: Monday,
Aug 25, 2014 10:43
Subject: Re:
[Openerp-community] odoo with a daily 50000
orders volume
Hello Lin,
we worked indirectly on a case in the USA
with 1/10 of the numbers you mentioned. And
we had terrible issues. Just to be clear we
were called as firemen and didn't had a
chance to study things upfront on that
project. Well basically, 2 things became
extremely slow: workflows because tables
were huge and stock moves (that was on 6.1)
because millions of move to crawl to compute
any stock level.
On v8, there is good hope that the stock
scalability issue is gone. As for the
workflows I'm afraid I'll probably still
have issues: all workflows use the same
tables and open workflow instances of sale,
stock, account accumulate. My advice is: if
it's on a version prior to v8, forget it
because of the way the stock moves work. If
it's on v8, well in any case plan some very
serious optimizations and testing to see
feasibility.
Number of concurrent users isn't too hard
to tackle by adding more cores now that we
have process based parallelism, but as for
very large tables, well you'll have to clean
them up often, you'll have tweak indexes,
probably to bypass some computations and use
some custom SQL, add caching...
I never heard about sharding in
OpenERP/Odoo so I guess nobody ever did
sharding, so don't assume it would be easy
like in frameworks where it's being done...
As for the company we worked for, well,
after 18 months they ended up dropping
OpenERP for SAP. Probably putting way more
money on it than trying again on v8 and
paying a lot of engineering to get the
things optimized, but still it's the
decision they took and scalability was one
of the main reasons and that was 1/10th of
the figures you mentioned. So don't take
that challenge lightly and good luck!
Regards.
--
Raphaël Valyi
Founder and consultant
+55
21 3942-2434
![]()
_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to : openerp-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to : openerp-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
|
