Odoo Manufacturing Consultant, India

Mapping job work onto Odoo subcontracting

Job work is where Indian Odoo projects most often go wrong, because Odoo's subcontracting feature was designed around a vendor producing a finished item from components you supply, while Indian plants use job workers for single steps in the middle of a process. The mapping I usually recommend:

• Each job worker as a subcontractor with its own stock location, so material held at every vendor is visible at any moment.
• The processed item as its own product, for example a heat-treated or plated part, with a subcontracting BoM listing the unprocessed part as its component.
• A subcontracting purchase order for the processing charge, whose receipt records consumption of the material sent and brings the processed item into stock.
• Multi-step chains, such as heat treatment then plating at different vendors, modeled as successive items. Having one vendor ship directly to the next is possible in some setups but needs careful testing on your version.

Partial returns, rejections at the job worker and process scrap need explicit rules. Odoo records what is received and consumed, but the return of rejected or waste material must be designed and tested. I agree these rules with stores and accounts and run the full cycle with one real job worker before others are added. The product-level overview is on my Odoo Manufacturing page.

Challans, e-way bills and job work reporting in Odoo

Material sent to a job worker generally moves on a delivery challan, with an e-way bill where required, and the movements feed periodic GST job work reporting. Your CA confirms the rules; my job is to see that Odoo produces or supports each document from the transfer itself, not from a separate register kept in Excel.

What I verify on your actual edition and version:

• Whether the transfer to the subcontractor location can print a delivery challan in the format your CA accepts, with HSN codes, values and the job worker's GSTIN.
• Whether the e-way bill integration in the Indian localization covers these non-sale movements or only invoices, and how returns from the job worker are handled.
• Whether a report of material sent, received back and pending at each job worker can be produced in the shape your periodic return needs, or has to be built.

Where something is missing, I specify the gap clearly so your implementer quotes for it rather than discovering it at go-live. Many Indian plants end up with a small custom report for job work balances, which is reasonable if it is scoped and maintained. Tax design for invoices and the ledger sits on my Odoo Accounting India page, and the wider compliance setup on Odoo consultant India.

BoMs for castings, forgings, garments and plastics

Indian manufacturing spans BoM shapes that a generic Odoo setup handles poorly. A few I configure often:

• Foundries and forge shops: charge materials by weight, yields that vary by heat, and runners, risers and rejected castings returned to the melt. I model returns as by-products on the manufacturing order so material balance holds, and carry the heat number as the lot so a dispatch can be traced back to its melt.
• Machining for OEMs: stable BoMs, operations at CNC and VMC cells with setup time, and a first-piece inspection on the first operation of each order.
• Garments and textiles: product variants for size and color, BoM lines that apply only to particular variants, and operations for cutting, stitching, finishing and packing. Outside embroidery or printing becomes subcontracting.
• Plastics and packaging: polymer, masterbatch and regrind, with mold changes as setup time and regrind recorded as a by-product.

The rule I hold everywhere: a BoM must be maintainable by your own engineering or production planning person after the implementer leaves. I document structures and naming conventions with worked examples during solution design, so later changes do not depend on a consultant or a developer.

Inspection, imported inputs and the costing method

OEM customers in India expect inward inspection, first-piece approval, in-process checks and final inspection reports, and many products fall under BIS requirements. In Odoo Enterprise, the Quality app lets you place control points at receipt, at specific operations and before dispatch, with measurements recorded and failures raising alerts. A quality location or an extra receipt step keeps uninspected material out of production. In Community, the same discipline needs a manual step and a documented procedure, or third-party modules.

Imported inputs need their own planning settings. Special steels, electronic components and some chemicals come from overseas with lead times far longer than domestic suppliers offer. I set vendor lead times from past receipts, add security days for imported lines, and let buyers confirm suggestions in the replenishment view. Customs duty, clearing and freight can be added as landed costs where the costing method supports them.

On costing, I sit down with your CA and plant head to decide:

• Average, FIFO or standard cost for each product category.
• Which work center rates carry electricity and contractor wages, and how job worker charges reach item cost.
• How rejections and by-products are valued.

A trial month is then reconciled with your CA before go-live. Requirements for these flows follow my requirements gathering method.

Community or Enterprise, and when Odoo MRP is not enough for an Indian plant

Cost pressure pushes many Indian manufacturers toward Community, often with modules from the Odoo app store or a local developer. That can work for a simple plant with an in-house developer. For manufacturing, though, the gaps are real: Quality, the Master Production Schedule, PLM for engineering changes, barcode scanning and tablet shop floor screens are generally Enterprise, as are parts of the Indian compliance integrations. Every replacement module must be maintained through upgrades, so I list each one with its owner before you decide. Check the current edition split on odoo.com.

I advise Indian plants against relying on Odoo MRP alone when:

• Forge shops or press lines need finite scheduling with die changes and sequence optimization.
• Pharmaceutical or API plants need validated batch records under good manufacturing practice.
• Process plants run formulas with potency, solvent recovery or many co-products.
• Job work is spread across many vendors and nobody will own the monthly reconciliation routine.

For cost-sensitive plants I also compare against ERPNext; see ERPNext vs Odoo for manufacturing. Plant-level requirements are on manufacturing ERP India, and my wider work on ERP consultant India and the India hub.