Product stock quantity management

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • yuri
    replied
    We released a big update of our Sales Pack extension. With the new version, an EspoCRM instance can be transformed to a fully-fledged inventory management tool.

    Leave a comment:


  • item
    replied
    Hello all,
    Any Update, new extension (pay)..
    Any Conector for Amazon or .. (pay)

    I try to migrate a "odoo" to espoCrm but need theses Conector/Warehouse else :s

    Last edited by item; 01-11-2022, 07:44 PM.

    Leave a comment:


  • partomas
    commented on 's reply
    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.

  • partomas
    commented on 's reply
    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.

  • telecastg
    commented on 's reply
    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
    replied
    Originally posted by 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
    Thanks so much, I will take you up on your offer

    Leave a comment:


  • partomas
    commented on 's reply
    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.

  • item
    commented on 's reply
    +1 for warehouse

  • emillod
    replied
    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

    Leave a comment:


  • telecastg
    replied
    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.

    Leave a comment:


  • yuri
    replied
    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:


  • partomas
    replied
    Originally posted by yuri
    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.

    Leave a comment:


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

    Leave a comment:


  • yuri
    replied
    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:


  • emillod
    replied
    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:

Working...