UNIT I PROJECT: MAP A COMPLETE MINI ENTERPRISE

Design a fictional company that uses Odoo across product sales, procurement, services, manufacturing, and online channels.

This is business modeling, not Odoo configuration. Do not build records in Odoo until you can explain the flows on paper.

TABLE OF CONTENTS

• Project Goal
• Part 1: Design the Company
• Part 2: Flow A - Lead-to-Cash
• Part 3: Flow B - Procure-to-Pay
• Part 4: Flow C - Service Delivery
• Part 5: Flow D - Manufacturing
• Complete Solution

PROJECT GOAL

Complete the five existing parts and include the eCommerce channel in Part 1 and the relevant sales flow. For each flow provide the seven requested elements, one numerical check, one exception with an owner, and completion evidence. Score each flow 0 for missing/incorrect, 1 for a correct sequence with missing reasoning, or 2 for a traceable explanation with quantities and exception handling. Revise each flow to 2 before moving on. The goal is a coherent business model; no paid environment, code, or deployment is required.

Design a fictional company with:

• Sales,
• Purchasing,
• Warehouse,
• Finance,
• HR,
• one service offering,
• one manufactured product,
• one eCommerce channel.

Then create four business flows:

Flow A - Lead-to-Cash

Flow B - Procure-to-Pay

Flow C - Service Delivery

Flow D - Manufacturing

For every flow identify:

• trigger,
• master data,
• transactions,
• responsible departments,
• application responsible for each stage,
• output,
• next process.

If you can do that correctly, Unit I has done its job.

PART 1: DESIGN THE COMPANY

Define at least one customer, vendor, resale item, service, manufactured product and its component recipe, plus the requested departments and employee roles. Choose a release baseline, edition, hosting assumption, and company boundary; explain how these support your flows. Assign a stable reference and unit to each product. Use the same identities when they recur across flows.

Create your fictional company profile including departments, products, services, customers, vendors, and employees.

PART 2: FLOW A - LEAD-TO-CASH

Supply opening stock, ordered quantity, price, billing policy, and payment terms. Trace demand → shortage decision → receipt if required → delivery → billing → settlement. Include sufficient-stock and supplier-delay outcomes. Explain what proof closes fulfillment and what separate proof closes the customer balance.

Map a product sale from prospect interest through payment.

PART 3: FLOW B - PROCURE-TO-PAY

Supply opening quantity, replenishment quantity, vendor price, and bill-control assumption. Identify who orders, who receives, and who verifies the bill. Test a partial receipt and a mismatched supplier bill. State whether buying is manual or triggered by configured replenishment rules.

Map a procurement cycle from need through vendor payment.

PART 4: FLOW C - SERVICE DELIVERY

Define hourly or fixed-price terms, the service product, project/tasks, responsible employee, and eligibility of recorded time. Use a complete set of hours and a rate to calculate a bill. Test non-billable work or an overrun, and identify who agrees a change with the customer.

Map a consulting or implementation sale from opportunity through billed hours.

PART 5: FLOW D - MANUFACTURING

Specify finished demand, opening finished stock, the per-unit BoM, and usable component stock. Calculate gross components, shortages, consumption, finished output, and delivery balance. Test a component shortage or rejected finished unit. Explain which actions are planned manually and which would need configured automation in Odoo.

Map a made-to-order manufacturing scenario from sales demand through delivery and invoicing.

UNIT I PROJECT: COMPLETE SOLUTION

The solution below uses a fictional company called Gulf Smart Solutions (GSS). It sells IT products, manufactures custom office desks, offers Odoo implementation services, and sells selected products through eCommerce.

PART 1: DESIGN THE COMPANY

COMPANY PROFILE

GSS is one operating company using an Odoo 19.0 conceptual design. For illustration it evaluates Enterprise with Odoo.sh if maintained Python extensions are needed; this is a stated option, not a requirement to purchase hosting. Each quantity example below is independent unless a handoff is explicitly stated. All prices omit tax, discounts, and freight, and opening physical stock is usable and unreserved.

Gulf Smart Solutions (GSS) is a Qatar-based company that:

• resells IT hardware,
• manufactures custom office desks,
• provides Odoo implementation consulting,
• sells selected products online through its website.

DEPARTMENTS

MASTER DATA

Use CUST-ABC, CUST-DOHA, and CUST-GULF for customers; VEN-DISPLAY, VEN-HARDWARE, and VEN-WOOD for vendors; and PROD-LAP, PROD-MON, PROD-KBD, and PROD-DESK for finished/resale products. Use COMP-TOP, COMP-LEG, and COMP-SCREW for components, each counted by the unit. SERV-ODOO is measured in hours. In Flow A, assume invoicing after full delivery with payment due thirty days after invoice; this is a sample commercial term, not a hosting or software default.

Give the desk and its tabletop, leg, and screw components separate product references. Use Layla’s employee identity for time and a linked authorized user identity when she logs work. Bilal’s HR role should not imply that every employee needs administrative access. The web shop reuses the keyboard/monitor identities; publication and pricing still require deliberate configuration.

Customers

• ABC Trading
• Doha Tech
• Gulf Office Solutions

Vendors

• Global Displays (monitors and screens)
• Qatar Hardware Supply (components and general hardware)
• WoodCraft Materials (desk components)

Products

• Laptop (resale product)
• Monitor (resale product)
• Keyboard (resale product)
• Custom Office Desk (manufactured product)

Service offering

• Odoo Implementation Package (consulting/service offering billed by project and timesheet)

eCommerce channel

• Website store selling keyboards and monitors to online customers

Employees

PART 2: FLOW A - LEAD-TO-CASH

Assume eight monitors on hand and demand for twenty. Buy and receive twelve, then deliver twenty: 8 + 12 − 20 = 0 monitors remaining. The diagram includes receipt after procurement and a sufficient-stock bypass. At 1,000 QAR each the charge is 20,000 QAR; a matched 5,000 QAR settlement leaves 15,000 QAR due. If the supplier delivers only ten, eighteen monitors are available and Sales must agree whether to ship partially or wait for two. Completion requires the actual delivery and settled customer balance, not merely a confirmed order.

Scenario: Doha Tech may need 20 monitors for a new office. Ahmed qualifies the opportunity, quotes, confirms the sale, fulfills from stock with partial procurement, delivers, invoices, and receives payment.

Stage-by-stage mapping

Example numbers: 20 monitors at 1,000 QAR = 20,000 QAR invoice.

PART 3: FLOW B - PROCURE-TO-PAY

Assume ten keyboards initially, a manually approved order for 100, and vendor price 130 QAR per keyboard. Full receipt gives 110 keyboards; the supplier charge is 13,000 QAR. If only eighty arrive, stock is ninety and twenty remain due. Under the assumed received-quantity control, the draft bill for this receipt is eighty × 130 = 10,400 QAR; investigate a supplier invoice for all 100. Finance verifies the difference with Purchasing and Warehouse before treating the cycle as complete. Control policies clarifies the quantity basis.

Scenario: Warehouse stock of keyboards falls below minimum. Sara procures 100 keyboards from Qatar Hardware Supply, Ali records their receipt, and Fatima verifies the vendor bill and processes supplier settlement.

Stage-by-stage mapping

Important distinction: Purchase Order ≠ receipt. Stock should increase when goods are received, not merely when the PO is confirmed.

PART 4: FLOW C - SERVICE DELIVERY

The sample uses time-based billing and a Service product linked to project work. Trace an eligible timesheet to its task and Sales Order Item, then to the invoice. Task completion establishes the work outcome; invoicing and settlement establish separate financial outcomes. If the same work were sold for a fixed 24,000 QAR, eighty-five actual hours would not automatically increase that price. Time-and-material invoicing explains the service configuration.

Scenario: Gulf Office Solutions buys an Odoo Implementation Package for 80 consulting hours. Layla delivers the work through a project with timesheets. Finance invoices based on the commercial agreement.

Stage-by-stage mapping

Layla records requirements 10 hours, configuration 20, migration 15, testing 15, and training 20: 80 hours total. Assume all are eligible customer work at 300 QAR/hour, giving 24,000 QAR. Additional internal training is recorded separately and is not billed under this assumption. An extra five customer hours would be 1,500 QAR only if the commercial terms authorize charging them; the original eighty-hour estimate is not automatic approval to bill any overrun.

Layla links each eligible timesheet to its project task and the SERV-ODOO Sales Order Item so Finance can trace the billed quantity. The project manager reviews eligibility, while Sales or the authorized commercial owner agrees any billable overrun or scope change with Gulf Office Solutions before Finance charges it.

For service businesses, Sales → Project → Timesheet → Accounting is as important as Sales → Inventory → Accounting is for product businesses.

PART 5: FLOW D - MANUFACTURING

Assume no finished desks and usable stock of six tops, forty legs, and 120 screws. Ten desks require ten tops, forty legs, and 160 screws; obtain four tops and forty screws. After receipt, completing ten desks with no loss consumes those totals and produces ten desks; delivering ten leaves zero finished desks. If one desk fails inspection, only nine are deliverable until the missing output is resolved. At an assumed 1,500 QAR selling price, all ten delivered desks produce a 15,000 QAR charge under this example’s delivered-quantity policy. Component cost and production cost require additional data; they cannot be inferred from selling price.

Scenario: ABC Trading orders 10 custom office desks. GSS manufactures desks from components. Some components are in stock; WoodCraft Materials supplies missing items. Manufacturing completes the desks, warehouse delivers them, and Finance invoices ABC Trading.

Bill of Materials per desk:

• 1 tabletop
• 4 legs
• 16 screws

For 10 desks: 10 tabletops, 40 legs, 160 screws.

Stage-by-stage mapping

Inventory impact:

• Components decrease during manufacturing.
• Finished desks increase upon production completion.
• Finished desks decrease upon customer delivery.

In this model, the planner manually creates the replenishment and manufacturing actions after reviewing demand and component shortages. Automatic creation would require configured routes, replenishment rules, BoMs, and procurement behavior; the document flow alone does not prove those automations exist.

ECOMMERCE CHANNEL NOTE

Assume the store sells two keyboards at 200 QAR each with online payment before dispatch. The customer charge is 400 QAR; after completed delivery, starting good stock of thirty becomes twenty-eight. Failed or pending payment requires its own follow-up path before treating the order as paid. Map the online order into Flow A’s fulfillment process and identify the website/company, product, customer, payment evidence, and shipment reference. Checkout alone does not prove every downstream step completed.

GSS also sells keyboards and monitors online.

Conceptual flow:

A website checkout creates the same internal document chain as a traditional sale, which demonstrates why eCommerce is a sales channel, not merely website design.

FINAL ENTERPRISE MAP

Trace one product identity from purchase to stock to sale, then explain why the consulting service uses project work instead of stock shipment. Verify each flow’s arithmetic, record references, owner handoffs, assumptions, exception response, and completion evidence. The four flows should agree on shared identities while retaining separate customer and vendor obligations. If you can only recite the app arrows, revise the relevant part with concrete records and an unfinished-case explanation.

PROD-MON provides that trace: Purchasing orders it from VEN-DISPLAY, Warehouse receives it into the same product’s stock balance, and Sales delivers it to CUST-DOHA in Flow A. The receipt proves incoming physical quantity, the delivery proves fulfillment, and the invoice and matched settlement prove the separate customer obligation. SERV-ODOO follows project tasks and eligible timesheets because consulting hours are work evidence rather than physical units held in a warehouse.

Gulf Smart Solutions therefore operates four major connected flows inside one enterprise model:

That diagram demonstrates the core goal of Unit I:

Understand the Business Before the Code

If you can explain these flows, identify master data versus transactions, and name the responsible application at each stage, you are ready for what comes next.

UP NEXT: UNIT II

UNIT I ANSWERED ONE QUESTION

What business is Odoo modeling?

We understand:

• processes,
• departments,
• master data,
• transactions,
• Odoo applications,
• connected document flows.

UNIT II ASKS AN ENTIRELY DIFFERENT QUESTION

How does the software actually make those business processes work?

We now leave the functional view of Odoo and move inside its technical architecture.

When a salesperson opens a Sales Order in their browser:

• How does the browser communicate with Odoo?
• Where does Python run?
• Where is the customer record stored?
• What is the ORM?
• Why PostgreSQL?
• What are addons?
• What is the registry?
• What are workers?
• What happens between Click and Business Record Loaded?

Up next: Unit II: How Odoo Actually Works, starting with Chapter 4: Odoo Architecture, where the roadmap moves into:

along with filestore, addons, registry, sessions, workers, cron workers, and long-polling and WebSocket concepts.