Streamlined Usage Event Creation with Deferred Validation
-
Flexible Usage Event Creation and Business Event Ingestion allows you to capture usage records via REST or file import even when a subscription product PUID or service ID is not yet available. This is controlled by a site-level profile so you can enable it only when needed (for example, migrations, phased rollouts, or upstream delays).
-
When enabled, incoming events without identifiers are accepted in Draft status, appear on the Usage Events Dashboard for monitoring post-rating, and are validated later during the rating phase. This defers strict identifier checks while still enforcing essential create-time validations like UOM, Start Time, and End Time to maintain baseline data quality.
-
Behaviour is controlled by the site profile ORA_OSS_DELAY_USAGE_VALIDATION, which is set to N by default to preserve current controls. Turning it on explicitly allows optional identifier ingest through REST/Import while leaving all other behaviour unchanged.
-
If delayed validation is enabled, the system publishes a business event (only in OIC) after rating for batches containing errored usage events. Subscriber applications can use these events to detect failures, correct data and resubmit records through the existing correction workflow.
-
Behaviour is controlled by a site profile ORA_OSS_RATING_PUB_BUS_EVENT, which is set to N by default to preserve current controls.
-
Error events are intentionally excluded from re-rating to avoid duplicate processing or billing confusion. Instead, they follow a clear correction path: export the errors, fix the data, and re-import for processing.
-
You maintain full operational control over when deferred events proceed. Once you establish a valid association (an Active Subscription Product PUID or a Service ID), move the batch to ORA_IN_PROCESS to trigger standard processing and rating. This lets you time processing to align with catalogue readiness, subscription activation, or provisioning milestones.
-
Identifier integrity is protected through synchronisation rules. If a Service ID cannot be validly derived from the Product PUID for the Event Start Date, the Service ID is automatically cleared to prevent mismatches. While unprocessed and when the profile is enabled, users can also set Subs_Product_PUID to null or change it to another Product_PUID to correct associations before rating.
Business outcomes include faster time-to-ingest by decoupling event capture from identifier readiness, fewer operational bottlenecks during transitions, improved cross-system coordination via business events for errored batches, and strong governance thanks to a default-off, site-controlled configuration that you can enable selectively and roll back easily if needed.
Steps to enable and configure
You don't need to do anything to enable this feature.