Product stock quantity management
Collapse
X
-
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. -
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 -
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 helpLeave a comment:
-
What I would offer to consider to add:
1. "lot" control. A “lot” is a specific batch of an item that was received, is currently stored, or was shipped from your warehouse. The criteria that constitute a lot can be determined at an organizational level by anything from the materials that went into a product to its expiration dates. (https://www.irms360.com/blog/lot-control)
2. Costs calculation by "lot" as well as you can purchase same goods by different prices, so your sale price might be different also based on "product" pricing model.
3. I have heard that there are some issues to organise calculations of outgoing (-) goods by different methodology like FIFO (“First-In, First-Out”) or if we selling goods by serial numbers like TV the sale by exact "lot" (serial) number.Last edited by partomas; 07-14-2021, 07:11 PM. -
IncomeOutcome entity (any suggestions how to name?)
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.Leave a comment:
-
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.Last edited by yuri; 07-13-2021, 02:07 PM.Leave a comment:
-
"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.Leave a comment:
-
One entity with a signed value (+ or -) vs two entities. Which one is better? I considered the former is a better option.Leave a comment:
-
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.Leave a comment:
Leave a comment: