Kingmotor POS

Kingmotor is a car repair shop. A repair job is not a retail sale: there is a vehicle, a mechanic, the parts used, and an invoice at the end that has to agree with all three.

Off-the-shelf point of sale assumes a counter and a product. It has nowhere to put the car.

I built custom modules on Odoo, the open-source ERP, so the system matched how the shop actually works rather than the other way round.

The problem

• Generic retail software does not fit a workshop. There is no field for the vehicle, and no way to attach the mechanic who did the work.
• The counter, the invoice and the parts were tracked separately. Which means reconciling them afterwards, every time.
• Nothing linked a job to its invoice. Working out what a particular repair had been billed for meant matching records by hand.
• Stock was a guess. Parts left the shelf during a job without anything counting them out.

What I built

One form for the whole job

The customer, the vehicle, the mechanic assigned and the parts used all sit on a single transaction, which moves from draft through to invoiced. The job is entered once and carries its own history.

Invoicing that follows the job

Every job's invoice, with due dates, follow-up activities and whether it has been paid. Because the invoice comes from the transaction rather than being written separately, the two cannot disagree.

Parts counted as they are used

Inventory with part codes, categories, prices and stock on hand. Parts come off the shelf as part of the job that used them, so the count reflects what is actually there.

The result

• A job is recorded once and carries through to the invoice, so the counter and the billing cannot drift apart.
• A repair can be looked up by vehicle, by mechanic or by invoice, because all three are on the same record.
• Parts stock reflects the work that consumed it rather than being counted separately.

Built as custom Odoo modules in Python and XML.