Service Contract Item Change Tracking

This documentation was authored in part by secure AI tools.  Please review this content carefully before integrating it with other processes.

This article explains how Service Contract Item changes are tracked, what information is recorded, and how end users can view and manage these changes.

---

Overview

The Service Contract Item Change Tracking (Report Q0399) feature records all changes made to service contract items that impact recurring monthly revenue (RMR).

A change record is automatically created whenever:

• A new service contract item is added
• An existing item is updated in a way that affects billing (price, quantity, start date, or end date)

This ensures a complete audit trail for reporting, billing validation, and revenue analysis.

---

How to View Item Changes

1. Navigate to the Service Contract
2. Locate the desired Service Contract Item
3. Open the Extended Menu in the item grid
4. Select View Item Changes

This will display a history of all recorded changes for that item.

---

What Information Is Tracked

Each change record includes key details about what changed, when it changed, and how it impacts billing.

Key Fields

• Billing Effective Date
  The date the change takes effect for billing (typically the next invoice date)
• Change Reason Code
  A user-selected reason for the change (may be required depending on configuration)
• Change Type
  A system-generated category describing the type of change (see below)
• Previous vs. New Values
  • Quantity
  • Price
  • Monthly Amount
• Monthly Delta
  The difference between the old and new monthly amount
• Billed Date & Invoice Number
  When the change was invoiced and on which invoice
• Start/End Dates
  Tracks how contract dates changed over time
• Source
  Indicates how the change was made (User, System, API, Import)
• Notes
  Optional comments explaining the change (not shown on the item itself)

---

Understanding Change Types

Each change is categorized automatically to support standardized reporting.

Common Change Types

• Start – A new item is created
• Reactivation – An inactive item becomes active again
• Expansion – Increase in monthly revenue
• Contraction – Decrease in monthly revenue
• Terminate – Item is ended (churn)
• Usage – Metered or consumption-based adjustment

How Change Type Is Determined

The system determines the change type based on:

• The selected Change Reason Code, and/or
• The Monthly Delta (increase or decrease in value)

Examples:

• Price increase → Expansion
• Discount applied → Contraction
• New item → Start

If no reason code is provided, the system uses the Monthly Delta:

• Positive change → Expansion
• Negative change → Contraction

Note: Users with appropriate permissions can override the system-derived Change Type.

---

Change Reason Codes

Change Reason Codes help explain why a change occurred.

• Managed in the system under the SRVCHGREAS code type
• Each reason code is mapped to a Change Type
• Users can select from predefined options when making changes

Optional Requirement

A system config setting controls whether a reason is required:

• Config Setting: RMRREQUIREREASON
  • OFF (default): Reason code is optional
  • ON: Reason code and change date are required for all changes

---

Editing Change Records

Users with the appropriate permission (SERVCONT_EXEC) can edit change records.

When a change record is edited:

• The system does not overwrite the original record
• Instead, it creates:
  1. A reversing entry for the original change
  2. A new corrected change record

This preserves a complete audit history.

---

Bulk Changes

Changes made through bulk operations (such as global price updates or imports) are tracked with:

• Bulk Change Flag (Y/N)
• Batch Number (groups related changes together)

This makes it easier to identify and report on large-scale updates.

---

Important Rules & Validations

To ensure accurate data and reporting, the system enforces the following:

• Monthly Delta must be accurate
  Must equal: New Monthly Amount – Previous Monthly Amount
• No duplicate changes
  Prevents multiple changes for the same item on the same effective date
• Valid reason codes only
  Must exist in the configured reason code list
• Billing Effective Date restrictions
  Cannot be set in the past (unless special handling is enabled)
• Zero-value changes restricted
  Changes with no financial impact may be limited unless explicitly allowed
• Data integrity enforced
  All changes must reference valid service contracts and items

---

Notes

• Change log notes are stored with the change record only and do not appear on the service contract item
• Some planned fields (such as proration details) are not currently used