Commercial services: existing CRM inventory
This page records the implementation available for inspection. It is not a target schema or a migration instruction. The MSP records and migration exploration defines the candidate scope and preparation work.
The inventory is based on repository code and private application journals from 7–8 September 2026. Recheck candidate records and live metadata before preparing exact field or record mutations; the counts below are dated readback results.
Operational MSP records
| Existing record | Responsibility |
|---|---|
| Managed Services Plan | Customer/original Deal relationship, current-agreement Deal/dates, billing eligibility, Plan settings and existing support-budget/delivery-scope fields |
| MSP Seats | Contacts and dated seat billing eligibility |
| MSP Invoice Lines | Reusable billing instructions, Product links, quantities/overrides and validity; these are not individual generated invoice rows |
| Products | Catalogue identity, billing defaults and separate Costing_Category classification |
CRM Invoices and Invoiced_Items |
Generated invoice header and Product rows; MSP headers include billing-period dates |
| Xero invoice/credit documents | Financial source documents and line identities |
The MSP invoicing process and invoice integration reference describe generation, draft refresh, seat rules and issued-document locking. During draft refresh, a changed Product sequence can cause CRM subform rows to be replaced. Any additional line attribution must account for that behaviour.
The four optional current-agreement fields are installed on the Plan module. They are populated from the accepted agreements for Sharps and Success Works. This is agreement context only and does not change operational billing inputs. The Plan and its related operational records are the main source for initial MSP Commercial Service configuration. Commercial Service remains the shared commercial record across categories; these Plan fields are not a replacement for that structure. See the Plan agreement migration.
CRM native Invoices and the Zoho Finance integration are distinct representations. Inspect actual API module/field names and document IDs; a related-list label or displayed invoice number alone does not establish identity.
Installed service structures
| Structure | Existing purpose | Question for the MSP walkthrough |
|---|---|---|
Commercial_Services |
Stable customer commitment, category/lifecycle, Plan/Deal/Quote relationships and source/review evidence | Which existing record owns the recurring charges and how does onboarding relate? |
Service_Invoice_Lines |
Captured invoice/credit rows, source keys and financial values, with Product, service and coverage fields | Can these records provide durable attribution, or can native invoice Product rows carry it directly? |
Service_Terms |
Dated agreement/baseline evidence, including reconstructed candidates | Which records are supported by the accepted agreement? |
Service_Labour_Budgets |
Hours, applicable scope/period and planning references | Which budgets are reviewed internal commitments, and which are provisional? |
Service_Source_Links |
Source and delivery-scope relationships | Which links identify the candidate's work without overlap? |
The initial application recorded 84 Commercial Services and 719 captured lines across 138 posted documents. A subsequent application recorded totals of 112 services and 850 lines, with 71 reconstructed term candidates, 79 source labour budgets and 106 source links. These totals describe the applied evidence, not the new migration scope or proof that every candidate is commercially reviewed.
Schema definitions are in commercial_services/schema.py and
commercial_services/position-schema.json. Service_Invoice_Lines already
specifies CRM_Invoice, Product, Commercial_Service,
Service_Period_Start and Service_Period_End, alongside source document IDs,
line IDs and captured financial fields. Field existence does not establish that
each field is populated or maintained automatically for Sharps or Success Works.
There is no installed Service Month header or monthly snapshot-line module in
this inventory. Service_Charge_Lines output from the local planning prototype
was a proposal. Neither is a dependency of the candidate design.
The MSP candidate review adds five optional fields on Commercial Services:
Current_Agreement_Deal, Current_Agreement_Start,
Current_Agreement_Accepted, Current_Agreement_Renewal and
Commercial_Summary. Sharps and Success Works are populated from their Plan
context and reviewed summaries. Their existing service start/end and original
Deal are preserved. The native header and Actual Invoice Lines columns provide
the review surface.
Of their 35 captured lines, 33 have proposed native-invoice billing coverage;
two conflicting Success Works periods remain blank. All are Needs Review,
and their financial values and Product identities are preserved. The additive
field specification and guarded update command are in
commercial_services/msp_review.py; see the
candidate migration reference.
Source authority and migration constraints
MSP Plans, Seats and configured MSP Invoice Lines remain the operational billing inputs. The installed service captures do not replace them. A migration proposal must name which records remain authoritative for each relationship or value and identify any billing change explicitly.
Captured financial rows preserve Xero document and line identities. Native CRM subform IDs and Xero line IDs are different identifiers. If both native rows and captured rows are used, link the representations and count each financial line once. The Product/period attribution model must also cover lines whose source invoice has no native CRM mirror.
The existing capture writer is create-only for matching source-keyed records; conflicting values stop the import. The service-position writer permits a different, guarded subset of updates. Neither should be assumed suitable for arbitrary changes from the new worksheets. Inspect its mutation scope before choosing a writer.
Operational controls and mutation boundaries are documented in Commercial Services historical capture and service performance migration. The Product classification process documents the separate catalogue mutation.
Retained evidence
Private captures, source hashes, schema/record journals and readback are under
.local/commercial-services/implementation-20260907/ and
.local/commercial-services/position-implementation-20260907/. Candidate sources
are listed in the working plan.
Inspect them before fetching additional data. Keep their historical records and
financial evidence intact while preparing the scoped target mappings.