Introduction
Meet the shop we'll follow through this guide: an OEM that builds humanoid robots. One customer just placed an order for 90 units. By the end, you'll have followed that order all the way from the sales desk to a finished robot on the shipping dock — and seen most of Carbon along the way.
Carbon spans the office and the floor: ERP for orders, purchasing, and planning; MES for the people actually building. The thread that ties them together is a single order, so that's where we start.
The sales order
Open the sales order dashboard. There's already an order on the books: 90 robots. But the customer doesn't want all 90 at once — they want 30 this week, 30 next week, and 30 the week after. That delivery schedule is going to shape everything downstream.
An order line doesn't close the moment you ship part of it. Carbon holds the line open — its status reads "To Ship and Invoice" — until every unit has both shipped and been invoiced. That single fact is what lets one order be fulfilled in batches without losing track of what's left.
The order often starts as a quote.
Carbon has a full Quote module with quantity-break pricing, so the 90-unit price could have been negotiated in quote to cash first. We'll pick the story up at the confirmed sales order, where the build truly begins.
Batch it into jobs
You don't build 90 robots as one monolithic job. With a batch size of 30, Carbon splits the order into three jobs — one per delivery. Each can be scheduled, released, and shipped on its own timeline.
Batching matches your build to the delivery promise.
Three jobs of 30 let you release week one now, keep weeks two and three in planning, and ship each batch the moment it's done — instead of waiting on all 90.
Create the job
From the order, create the job. Carbon carries the part, quantity, and due date across automatically — the job inherits exactly what was sold, so the floor never works from a stale spec.
It carries one more thing across, and it's the most important: the robot's manufacturing method — its full recipe of materials and operations. The job doesn't point at the part's master recipe, though. It gets its own copy.
Get the method
Pulling that recipe into the job is an explicit action in Carbon called Get Method. It clones the part's method — every material, every operation — into a job-specific method that belongs to this job alone.
That copy is the whole point. Need a one-off substitution for this batch — a different fastener, an extra inspection step — you edit the job's method and the part master stays untouched. And when a change proves itself, you can push it back up to the part so every future job inherits it.
The part holds the master recipe; the job holds a working copy.
Editing a job never silently rewrites your part library, and updating a part never disturbs a job already in flight. The link between them is a deliberate copy-up, copy-down — not a live wire.
Release or plan
Now the key decision. You'll release one job — week one — and leave the other two in planning. The difference is exactly what each action sets in motion:
- Release — generates inventory alerts for any required material that isn't in stock, and adds the job's tasks to the shop-floor schedule. This is work the floor can start.
- Plan — generates the same inventory alerts, but does not schedule anything. It's how you see what a future job will need without committing the floor.
Plan to see demand early; release to put work in motion.
Planning weeks two and three now means you can order long-lead material today — without cluttering this week's schedule with jobs the floor can't touch yet.