Problem Statement:

1.1 Ambiguity between Dual Status Fields

Within Oracle RMCS, there are two distinct status indicators that govern the revenue lifecycle: Satisfaction Status and Satisfaction Status of Additional Event (ASE). There is currently limited documentation to clarifying how these two fields interact.

1.2 Dynamic Nature of Status Derivation

Technical analysis suggests that the Performance Obligation Satisfaction Status is not static value stored in a single database column (such as LINE_SATISFACTION_STATUS in the VRM_PERF_OBLIGATION_LINES table). Instead, Oracle RMCS dynamically derives this status at runtime based on the Satisfaction Measurement Model:

• Quantity-Based: Derived from comparing the sum of Satisfaction Events against Net Quantity (Ordered Qty).
• Period-Based: Derived from comparing the Report Date against Plan Start and End Dates.
• Percentage-Based: Derived from the cumulative sum of milestone percentage events.

Because this status is dynamic on RMCS UI side, custom reports must reflect the “True Status” of a contract by following similar dynamic status derivation to avoid discrepancies in revenue forecasting.

1.3 Lack of Unified Revenue Satisfaction Framework

Standard Oracle RMCS logic separates Satisfaction Status (physical/time performance) from Additional Satisfaction Event (ASE) Status (administrative/compliance holds). This separation often creates “Release Exceptions,” where revenue appears earned but remains legally trapped. Without a unified view, the Revenue Team faces:

• Manual Reconciliation: High effort required to cross-reference multiple fields during month-end close.
• Forecasting Inaccuracy: Difficulty in automating hardware revenue projections based on fragmented fulfillment data.
• Audit Risks: Lack of a documented “Source of Truth” for why specific revenue is deferred or blocked.

Solution Objectives:

• Ensure UI Alignment: Align all custom reports with RMCS UI logic to maintain data consistency and eliminate ambiguity between report outputs and the system of record.
• Implement Dual-Status Reporting: Reflect the RMCS design by including two distinct fields—Satisfaction Status and Satisfaction Status of Additional Event—ensuring that values and meanings remain identical to the RMCS UI for easier validation and comparison.
• Standardize Derivation Logic: Formally document the derivation logic for both status fields to serve as a technical blueprint for developers and a training resource for business users.
• Improve Fulfillment Visibility: Enable clearer revenue analysis by distinguishing between physical/time-based fulfillment (Satisfaction Status) and administrative/manual releases (ASE Status).
• Unified Revenue Satisfaction Framework: The goal of this initiative is to eliminate reporting ambiguity within the Forescout Revenue Management (RMCS) ecosystem by establishing a Unified Net Revenue Status. This framework aligns custom report logic with the Oracle RMCS UI while providing a single, actionable status that bridges the gap between physical fulfillment and accounting compliance.
  • The “Net Revenue Status” This design introduces a calculated Net Revenue Status field. By evaluating the ASE Requirement Flag and aggregating both the POB and ASE statuses, the system provides one of four clear business verdicts:
    • DEFERRED: Fulfillment has not yet commenced.
    • RECOGNIZING: The “gate” is open, and revenue is flowing incrementally.
    • RECOGNIZED: Performance and compliance are 100% complete.
    • PENDING: Physical fulfillment is complete, but a “Compliance Hold” is preventing recognition.
    • PENDING (Partial): Delivery is done, but ASE only allows partial recognition.

Why we should have both Satisfaction Status and Satisfaction Status of Additional Event in the custom report.

• Satisfaction Status: Answers “The Performance Aspect” of a given performance obligation such as “Has the physical work been delivered or has the service time elapsed?” Meaning it helps track the physical fulfillment of the contract.
• Satisfaction Status of Additional Event: Answers the “Permission/Compliance Aspect” for a given performance obligation such as “Is the revenue legally or administratively allowed to be released?” It acts as a gatekeeper or a “hold” that ensures compliance.

How to derive Satisfaction Status for a given performance obligation.

Quantity Measurement Model Satisfaction Status Derivation (Point-in-Time).:

1. Requirement Overview

The report must dynamically calculate the satisfaction status for Performance Obligations (POBs) that are fulfilled based on physical quantities (Point-in-Time). This status is derived by comparing transactional satisfaction events against the original net ordered quantity.

2. Business Rules

• Line Identification: Apply this logic only where “Satisfaction Measurement Model” = ORA_MEASURE_QUANTITY_SATISFIED AND “Satisfaction Plan” is NULL.
• Data Aggregation: The system must aggregate (SUM) all records from the Satisfaction Events table for each unique POB_ID.

3. Detailed Logic & Calculations

For every eligible POB line, the report must execute the following steps:

Step 1: Calculate Total Satisfied Quantity

• Define Total_Satisfied_Qty as the sum of all satisfaction events recorded for a specific POB.

Total_Satisfied_Qty = Sum of (satisfaction_quantity).

• Null Handling: If no records exist in the satisfaction events table for a POB ID, the report must treat the Sum as 0 and set the status to “Not Started”.
• Reversals: Satisfaction events with negative quantities must be included in the Sum to ensure the net satisfaction position is accurate.

Step 2: Compare to Net Quantity (Ordered_Qty)

Assign the status based on the following three logic gates:

1. Not Started
   • Condition: If Total_Satisfied_Qty = 0
   • Description: No shipments or fulfillment events have occurred.
2. Extent Satisfied
   • Condition: If Total_Satisfied_Qty is greater than 0 AND Total_Satisfied_Qty is less than Ordered_Qty.
   • Description: Some fulfillment has occurred, but the total quantity is less than the amount promised.
3. Fully Satisfied
   • Condition: If Total_Satisfied_Qty is greater than or equal to Ordered_Qty.
   • Description: The customer has received the full quantity (or more) promised.

Period Measurement Model Satisfaction Status Derivation (Period-Based / Over-Time):

Satisfaction Plan: “Daily Rate Partial Periods” or “Daily Rate All Periods”

1. Requirement Overview

For service-based or subscription-based Performance Obligations (POBs), satisfaction is not triggered by a single event but is earned through the passage of time. This logic determines if a subscription is “pending,” “active,” or “expired” based on the relationship between the reporting period and the contract dates.

2. Business Rules

• Line Identification: Apply this logic only when:
  • “Satisfaction Measurement Model” = ORA_MEASURE_PERIOD_SATISFIED
  • “Performance Satisfaction Plan” = Daily Rate Partial Periods or Daily Rate All Periods
• Reference Date: The logic should compare the Report Period End Date (or Current Date) against the contract duration.

3. Detailed Logic & Calculations

The report must derive the Satisfaction Status based on the following timeline logic:

Rule 1: Not Started

• Condition: If Report Period End Date is less than (<) Plan Start Date.
• Description: The service period has not yet started as of the reporting date. 0% of the revenue should be recognized.

Rule 2: Extent Satisfied

• Condition: If Report Period End Date is greater than or equal to (>=) Plan Start Date AND Report Period End Date is less than (<) Plan End Date.
• Description: The obligation is currently in progress. Revenue is being recognized daily, but the full service term has not been completed.

Rule 3: Fully Satisfied

• Condition: If Report Period End Date is greater than or equal to (>=) Plan End Date.
• Description: The service period is complete. The total allocated amount for this obligation is now fully earned.

Satisfaction Plan: Immediate (point-in-time)

1. Requirement Overview

The Immediate satisfaction plan is a point-in-time recognition model where 100% of the allocated revenue is recognized on the Plan Start Date. Unlike other period-based models, there is no “in-progress” state; the obligation is either not yet started or completely finished.

2. Business Rules

• Line Identification: Apply this logic only when:
  • Satisfaction Measurement Model = ORA_MEASURE_PERIOD_SATISFIED
  • Performance Satisfaction Plan = Immediate
• Reference Date: The logic compares the Report Period End Date (or “As-Of” date) against the Plan Start Date.

3. Detailed Logic & Calculations (Plain Text)

The report must assign the Satisfaction Status based on the relationship between the Reporting Period and the Plan Start Date:

Rule 1: Not Started

• Condition: If Report Period End Date < Plan Start Date.
• Description: The revenue recognition trigger date has not yet been reached. The total amount remains as Contract Liability.

Rule 2: Fully Satisfied

• Condition: If Report Period End Date >= Plan Start Date.
• Description: 100% of the revenue is recognized on the Start Date. The obligation is considered fully satisfied immediately.

Percent Measurement Model Satisfaction Status Derivation (Percentage-Based):

1. Requirement Overview

For service or project-based Performance Obligations, satisfaction is not driven by time or quantity, but by the completion of specific milestones (e.g., 25% project completion, 50% design sign-off). The system determines the status by aggregating (summing) all reported satisfaction percentage events through the reporting period.

2. Business Rules

• Line Identification: Apply this logic only when:
  • Satisfaction Measurement Model = ORA_MEASURE_PERCENT_SATISFIED
  • Performance Satisfaction Plan = NULL
• Data Aggregation: The system must sum the SATISFACTION_PERCENT from all related events in the satisfaction events table for each unique POB_ID.

3. Detailed Logic & Calculations (Plain Text)

For every eligible POB line, the report must execute the following steps:

Step 1: Calculate Total Satisfied Percentage

• Definition: Total_Satisfied_Percent = Sum of all “satisfaction_percent” values found in the events table for that POB.

Step 2: Assign Status based on Cumulative Percentage Assign the status using these three rules:

1. Not Started
   • Rule: If Total_Satisfied_Percent = 0
   • Meaning: No milestones have been achieved or reported yet.
2. Extent Satisfied
   • Rule: If Total_Satisfied_Percent > 0 AND Total_Satisfied_Percent < 100
   • Meaning: One or more milestones have been reached, but the total project/obligation is not yet 100% complete.
3. Fully Satisfied
   • Rule: If Total_Satisfied_Percent >= 100
   • Meaning: The cumulative milestones meet or exceed 100%.

How to derive Net Revenue Status for a given performance obligation.

1 The Requirement for a “Net Revenue Status” Field

1.1 The Ambiguity of Disconnected Statuses

In the standard Oracle RMCS architecture, Satisfaction Status and Satisfaction Status of Additional Event (ASE) exist as independent data points. While technically accurate, these fields often provide a fragmented view of the contract’s financial health. For the Revenue Team, seeing a status of “Fully Satisfied” on a POB is misleading if an unreleased ASE hold is simultaneously preventing all revenue recognition. This disconnect forces users to manually cross-reference multiple columns to understand the true accounting position.

1.2 Inefficiency in Period-End Reconciliation

During month-end close, the Revenue Team must identify “Release Exceptions”—contracts where physical fulfillment is complete but revenue remains trapped in a liability account. Relying on two separate status fields requires complex filtering and manual work. Without a single, unified status that aggregates these conditions, the time required to diagnose recognition delays increases, extending the close cycle and increasing the risk of reporting errors.

1.3 Lack of Clear “Actionable” Data for Forecasting

For Hardware (Quantity-based) items, the decision to “Forecast” revenue into a future period is dependent on the net result of both fulfillment and compliance.

• A POB that is “Partially Satisfied” but “ASE Blocked” requires a different business action than a POB that is “Partially Satisfied” and “ASE Released.”
• Standard system statuses do not provide a “Net” value that a reporting engine can use to automatically trigger forecasting logic (e.g., projecting revenue to Book Date + 30 days).

1.4 Complexity of the “Not Required” Logic

Oracle RMCS does not require an ASE for every Performance Obligation. When a POB does not require an ASE, the ASE status field is essentially irrelevant. However, in a standard report, this creates “noise.” A business user must first check the Requirement_Flag, then check the Satisfaction_Status, and then ignore the ASE_Status. This multi-step mental process is prone to human error.

Master Logic: Net Revenue Status Determination

This master table combines the ASE Required Flag, the POB Satisfaction Status, and the ASE Status into a single, unified Net Revenue Status.

ASE Required?	POB Satisfaction Status	ASE Status	Net Revenue Status	Business Meaning / Action
N	Not Started	Not required	DEFERRED	Fulfillment hasn’t started. No ASE required.
N	Extent Satisfied	Not required	RECOGNIZING	Incremental fulfillment is occurring.
N	Fully Satisfied	Not required	RECOGNIZED	Performance is 100% complete.
Y	Not Started	Not satisfied	DEFERRED	Waiting for both delivery and the ASE trigger.
Y	Extent Satisfied	Not satisfied	PENDING	Performance has started, but ASE is a total “Gatekeeper.”
Y	Extent Satisfied	Partially satisfied	RECOGNIZING	Both delivery and the ASE are moving incrementally.
Y	Extent Satisfied	Fully satisfied	RECOGNIZING	ASE gate is 100% open; status follows physical progress.
Y	Fully Satisfied	Not satisfied	PENDING	Release Exception: Delivery is done, but ASE is holding revenue.
Y	Fully Satisfied	Partially satisfied	PENDING (Partial)	Delivery is done, but ASE only allows partial recognition.
Y	Fully Satisfied	Fully satisfied	RECOGNIZED	Both Performance and Compliance are 100% complete.