Business process models
Builds a coherent model of commercial documents and responsibilities so each business step retains its meaning and historical terms.
business-process-domain-modeling
See how it helpsWhen is it useful?
Use it when CRM or ERP work spans customer records, quotations, orders and later delivery or billing documents.
What does it help you do?
- Separates customer, opportunity, quote and order concepts.
- Preserves agreed prices and terms so later catalog changes cannot rewrite historical documents.
- Traces quotations through shipments, returns and invoices.
Try asking this
Design a quote-to-order flow that preserves agreed prices even when the product catalog is updated later. Accept a quote, change the catalog price and create the order. The order should retain the accepted price and a traceable link to that quote revision.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Business Process & Domain Modeling
When to Use
Use when designing, extending, or reviewing CRM and ERP modules, business entities, document lifecycles, or operational workflows.
Core Discipline: Ubiquitous Language & Bounded Contexts (Eric Evans)
Never treat an ERP or CRM system as a collection of flat CRUD tables where any column can be overwritten at any time. Model the actual business process, actors, invariants, and document lineage:
1. Keep Distinct Domain Concepts Separate
Even when two entities share similar attributes (customer name, line items, total amount), they represent different legal and operational commitments with distinct lifecycles:
- CRM Entities:
- Lead / Prospect: Unqualified or inbound inquiry before qualification.
- Account (Company / Organization) vs. Contact (Person): An Account is a legal/business entity; Contacts are people associated with one or more Accounts (with roles like Decision Maker, Billing Contact, Technical Buyer).
- Opportunity (Deal): A qualified potential sale tracked through pipeline stages with expected value and close date.
- Commercial & ERP Document Chain (Quote-to-Cash):
- Quote / Proposal: A time-bounded commercial offer to a customer.
- Sales Order: A confirmed commitment to deliver goods/services at agreed prices and terms.
- Fulfillment / Shipment / Service Delivery: Physical or operational execution (often partial or split across multiple deliveries).
- Invoice / Credit Note: The legally binding accounting/billing document (coordinated with the billing/invoicing subsystem).
- Payment / Settlement: Actual cash movement and reconciliation.
Never collapse Quote, SalesOrder, Fulfillment, Invoice, and Payment into a single table or a single status column!
2. Document Lineage & Historical Price/Term Immutability
- Snapshotting Commercial Terms: When a
QuoteorSalesOrderis created from the Product/Price Catalog, copy the agreedunit_price,currency,tax_rate,unit_of_measure,sku_code, andproduct_name_snapshotonto the document line item (order_lines). - Never Retroactively Recalculate Finalized Documents: Updating a product's catalog price today must never alter the price or total of already-issued quotes, confirmed orders, or historical invoices!
- Explicit Document References: Maintain foreign-key lineage (
quote_id$\rightarrow$sales_order_id$\rightarrow$shipment_ids[]/return_ids[]$\rightarrow$invoice_ids[]) so every business transaction can be traced end-to-end from initial quote to final delivery and settlement.
3. Build for the Actual Bottleneck (Goldratt's Theory of Constraints)
- Scope CRM/ERP features to the concrete workflow problem at hand—never build a speculative "universal workflow engine" or full enterprise ERP suite when the business needs a clean quote-to-order flow.
Included files 1
SKILL.md
