Product stock quantity management

[eymen.elkum]

Hi yuri ,

I wonder if you already planned for this feature or will consider to plan for it,

I have a project where I need to have quantity management for products in addition to transactions and so,

If this is planned feature then I go with the minimal code for my project, but if will not planned then I may go ahead to make an extension for this.

Thanks in advance

[yuri]

Hi,
Not planned.

[item]

Hi Eymen,
my 2 cents idea :
if you make this kind of extension .. i think you must think this :

- product quantity by "factory" (i think it's another word )

=> factory -> is place .. like : you have 2 in NewYork, 5 in Istanbul, .. so if NewYork = 0 .. you can send product from Istanbul

Regards

[eymen.elkum]

"factory" (i think it's another word )

I think you are talking about "warehouse"

thanks for your suggestion,

[item]

I think you are talking about "warehouse"

thanks for your suggestion,

Yes, this is the word
with odoo
and each warehouse have a custom integration (bad word too)
sample :
amazon
ebay
..

[partomas]

Might be there are some updates regarding simple "warehouse" functionality? Also I'm interesting simple manufacturing module to produce product by combining another two products. So there are "warehouse" module come in to count what we have left in stock.

[yuri]

Please describe how you see this functionality working. We may add it in our our list to consider.

[emillod]

yuri our idea is to create two entities with itemlist. One for adding new products to stock, second to substract. Thanks to that in product entity user would see current stock
Also it would be great to create some limits in invoices/quotes, to make sure that worker can only sell products which are in stock.
Of course after quote would change status to completed, hook should generate new document with products which are in quote to substract amount.

[yuri]

One entity with a signed value (+ or -) vs two entities. Which one is better? I considered the former is a better option.

[emillod]

yuri one entity with +/- probably will be also okay i think.

[partomas]

Please describe how you see this functionality working. We may add it in our our list to consider.

So, I'll try to make it as simple as possible:

"Warehouse" if we have a "sales" module and can sell product (-) quantity we could have "purchase" module which will work opposite like sales just (+) quantity of product to stock. So at the end we'll have some amount in stock after reach operation. Additional to that it would be good to have some clasificator of Warehouse locations like "Segment A, Rack 305, shelf 10B". Just for fast finding of stock.

"Assembly Management" (https://docs.microsoft.com/en-au/dyn...assemble-items) is very simple procedure that enable to create one sellable good from another goods in a stock. Just combining them together by different proportions. Income (-) product quantity by "assemble recipe" outcome (+) another Product quantity.

Then CRM could be very useful not only for sales of services, but for goods too.

[yuri]

The model I came up with:

Product entity (already exists)

IncomeOutcome entity (any suggestions how to name?)

fields:
- value (integer, +/-, plus for income)
- productId
- parent (Sales Order, Purchase Order)
- status (to be able to cancel an operation, or to reserve items in a draft Sales Order/Quote)

Sum of values gives the current number of product items of a specific product

Sales Order entity (already exists)

Purchase Order entity

The con is that we don't have a single entry in database for a single inventory (product) item.

The pro is it can be build upon the existing model of Sales Pack.

Please give any suggestions if anyone have.

[telecastg]

lot number, serial number, and unit cost could be opitional fields of the ProductTransaction entity, and cost method (FIFO, LIFO) could also be an enum field.

Based on the cost method field, different cost computations could be implemented.

For assembly management, I would propose a BillOfMaterials entity as "recipie" which would include the ProductId, UsageQty and even ManHours to incorporate labor costs.

As an observation, including these capabilities would bring Espo closer to a full ERP system

[partomas]

I’m not sure, but lot tracking must be a bit different entity, not only field if we do +/- per product quoantity, but I might be wrong.

[partomas]

By the way I would like to add on top:
4. warehouse report not only by quantity of product, but by lot's as well for inventorisation.

5. there are might be need for some measurement units conversion as we can purchase products e.g. tons, pallets and sold in units. But it can be realised by module mentioned before - "Assembly Management".

6. "Assembly Management" is need to have some traceability functions to recall some products by lot if one ingredient was defective. So for that purpose lot in warehouse might be very functional. And it's not only good for tracking sales, when maintenance or warranty services come in case's.

[telecastg]

IncomeOutcome entity (any suggestions how to name?)

I would suggest ProductTransactions, that entity could have additional fields like WarehouseId so you could track movements between Warehouses as well and track shipments from different locations..

Product.stockBalance could be a calculated field based on the ProductTransactions history

I am working in a possible Financial module and use FinancialTransactions to record FinancialAccount movements in a similar scheme as above.

[item]

+1 for warehouse

[emillod]

telecastg yeah. Maybe it could be also possible to cover movement between werehouses functionality.
I prepared few months ago extension for private finances inside EspoCRM :d So if you have any questions, let me know, maybe i could help

[telecastg]

telecastg yeah. Maybe it could be also possible to cover movement between werehouses functionality.
I prepared few months ago extension for private finances inside EspoCRM :d So if you have any questions, let me know, maybe i could help

Thanks so much, I will take you up on your offer