Arts and crafts retail runs on details that generic Odoo never anticipates. You sell yarn by the skein but buy it by the case, run make-and-take classes that consume inventory, take goods on consignment from local makers, and carry thousands of SKUs that differ only by color, weight, or fiber. Out of the box Odoo's product.template/product.product variant matrix, standard stock.picking flows, and generic POS handle a plain shop well — but they have no concept of a class that reserves seats and draws down bead and paint stock, no consignment settlement that pays a maker only on sale, and no craft kit that bundles a project's components while still tracking each part. Teams paper over this with spreadsheets, manual stock adjustments, and POS notes that never reconcile.

We build the Arts & Crafts Store as a proper Odoo module — its own __manifest__.py declaring dependencies on stock, sale, point_of_sale, and mrp — rather than a pile of Studio tweaks. New models extend the ORM: a craft.class.session model (models.Model) with @api.depends computes for remaining seats and material consumption, a consignment layer linking res.partner makers to products with computed amounts owed, and craft-kit assembly built on mrp.bom phantom BOMs so a "beginner knit kit" explodes into its component stock moves at sale time. Everything is secured with ir.model.access.csv plus record rules so instructors see only their class sessions and consignors see only their own settlement lines. Views ship as XML/OWL for the back office and inherited POS screens for the counter, with QWeb reports for consignment statements and class rosters.

Technically, the template wires into the flows you already run. Class bookings post through the existing sale/POS pipeline so revenue lands in the correct accounts; material draw-down uses standard stock moves so on-hand counts stay honest; and consignment settlement generates vendor bills only against sold units. Automated actions (server actions on ir.cron) can flag low-stock consumables, remind instructors of tomorrow's roster, and roll unsold consignment inventory into return pickings. Because it is a real module, the same logic is reachable over the XML-RPC/JSON-RPC API for any storefront, marketplace, or booking widget you connect. We target Odoo 17.0, 18.0, and 19.0 and note Community vs Enterprise differences up front — for example, features that lean on Enterprise-only apps are called out during scoping so nothing is assumed.

Build-to-order means we do not hand you a pre-existing download. After a short scoping call we confirm the exact models, POS behavior, reports, and edition (Community or Enterprise) your shop needs, then build, install on your staging database, run UAT with you, and deploy to production — typically one working week from confirmed scope. You receive the installable source, documentation, training, and a post-go-live support window. Pricing starts from $999 (indicative, single-company base scope); multi-company or multi-store rollouts, deep POS and payment-hardware integration, class-booking website widgets, and consignment/maker-payout automation depth increase the quoted scope. You get a fixed quote after the scoping call, never a surprise invoice.