Commercial services: design direction

Status: exploratory CRM design. The working scope is Sharps and Success Works MSP records and migration preparation. The MSP records and migration plan is the working specification; the CRM inventory describes existing structures to inspect.

Commercial foundation

A Commercial Service identifies a customer commitment independently of an invoice number, payment status or a particular month's seat quantities. It retains the relevant Plan, Deal and accepted agreement relationships.

Commercial Service is the shared commercial record for MSP, Tech Projects and Hardware. An operational module can support that record without becoming a separate commercial model for its category. A renewal belongs to the same service identity when the underlying service continues; the original Deal and current agreement need not be the same.

For an MSP with an existing Managed Services Plan, use that Plan and its linked records as the main basis for configuring the Commercial Service. Reuse the customer, original Deal, operational status, charge configuration, seat rules and delivery references before seeking supplementary evidence. Keep the Plan linked and active for operational continuity. Its billing inputs remain maintained there; the commercial model does not require a duplicate billing configuration or a Plan for Tech Projects and Hardware.

New shared commercial information belongs on the Commercial Service or its linked commercial records. Accepted agreements supplement the Plan baseline and expose discrepancies for review. A Plan billing date is not automatically an agreement date, a fallback revenue value is not an agreed fee, and a current seat count does not establish historical monthly quantities. Initial migration does not establish ongoing synchronisation or authorise commercial edits to change operational billing.

Configured charges and dated seat eligibility explain what billing should generate. Track existing invoices and their actual lines, and reconcile each line back to its configured charge where the evidence supports a match. For MSP, that charge is an existing MSP Invoice Line on the operational Plan. Each actual line links to its parent Invoice, CRM Product, service and coverage dates and retains its billed quantities, prices, discounts and financial values. Later Product or charge changes do not rewrite issued lines. Capturing invoice history does not require generating new invoices.

Reuse CRM Invoice records for document history and reporting by invoice date, customer, currency and source status. Use their line amounts for service and Product breakdowns, and reconcile those amounts to each invoice's totals. The invoice-to-line relationship and configured-charge mapping make successive months traceable through records.

Service month is a grouping of invoice and credit lines by service and coverage period, within a currency. The design does not require a Service Month module or a parallel set of monthly charge snapshots. Multiple documents can contribute to a month, and an invoice can contain several service periods. Source invoice date and service coverage remain distinguishable.

The accepted agreement, configured billing instructions and issued invoices can disagree. Their relationships make a difference explainable; copying one over the other does not resolve it. Draft refresh follows operational billing rules, and actual financial evidence remains traceable to the source document.

Delivery budgets and recorded work meet invoice lines through service ownership, scope and dates. Shared support effort is counted once. Customer entitlement, billed quantity and internal effort remain separate. Missing Product matches, costs or historical evidence stay visible as gaps.

How the structure develops

Design populated records for Success Works, test them against Sharps, and revise the structure where those cases expose a need. Existing modules are candidates for reuse, not a mandate to retain every field or add every proposed module. A new record type needs a concrete business purpose demonstrated by a candidate.

The designated later examples are Cercle recurring Tech Project, Gidget Phase 5 one-time Tech Project and ARACY Hardware. They are outside the MSP migration preparation. Dashboards, rendering, forecasting and broad historical imports are outside this design stage.

The output is a field/relationship proposal, concrete before/after records, source mappings, migration actions and unresolved decisions. This document does not establish a billing cutover or change an operational workflow. Current MSP invoicing, Deal processing and invoice reconciliation remain the references for implemented behaviour.