Quote Item
  -> Product Order Item
  -> Service Order Item
  -> Provisioning / Resource Order / Network Action
  -> Service Inventory
  -> Product Inventory update
  -> Billing activation

Apa pekerjaan teknis yang harus dilakukan agar product order dapat direalisasikan sebagai service?

1. Product order item mana yang menyebabkan service order ini?
2. Service apa yang dibuat, diubah, disuspend, diresume, atau dihentikan?
3. Service specification apa yang menjadi target?
4. Characteristic teknis apa yang diminta?
5. Dependency antar service order item apa?
6. Downstream system mana yang bertanggung jawab melakukan fulfillment?
7. Milestone mana yang sudah selesai?
8. Jika gagal, fallout reason dan recovery action apa?
9. Kapan service dianggap completed?
10. Bagaimana service order mengupdate service inventory/product inventory/billing readiness?

Add Enterprise Internet 1Gbps for Customer A at Site X.

Create CFS Internet Access with bandwidth=1Gbps, site=X,
then create access circuit,
then assign router configuration,
then activate monitoring.

service_order_id
service_order_number
source_product_order_id
source_product_order_item_id
customer_id / account_id
requested_start_date
requested_completion_date
expected_completion_date
state
priority
external_system_reference
orchestration_reference
created_at
updated_at

Mengapa service order ini ada?
Dari product order mana ia berasal?
Apa status teknis keseluruhan?
Siapa downstream owner/system-nya?
Kapan pekerjaan ini harus selesai?

service_order_item_id
service_order_id
parent_service_order_item_id
source_product_order_item_id
action
state
service_specification_id
service_instance_id
requested_service_payload
sequence_number
dependency_group
assigned_system
created_at
updated_at

Cannot resume service that is not suspended.
Cannot terminate service that does not exist.
Cannot add service instance with duplicate external service id.
Cannot modify service if parent product order was cancelled.
Cannot activate service before prerequisite resource is assigned.

Service Specification:
  Internet Access CFS
  Required characteristics: bandwidth, access_type, site_id

Service Order Item:
  action = add
  serviceSpecification = Internet Access CFS
  characteristic bandwidth = 1Gbps

Service Instance after completion:
  service_id = SVC-123
  status = active
  bandwidth = 1Gbps
  linked product_instance_id = PI-789

bandwidth
access_type
vlan_id
circuit_type
site_code
router_model
ip_assignment_type
service_class
redundancy_mode
sla_profile

service_order_item_characteristic
- id
- service_order_item_id
- characteristic_code
- value_text
- value_number
- value_boolean
- value_json
- unit_of_measure
- source
- created_at

Create Internet Access CFS
  dependsOn Create Access Circuit RFS
  dependsOn Assign Router Resource
  dependsOn Configure Monitoring Service

acknowledged
rejected
pending
inProgress
held
failed
partial
completed
cancelled

pending
ready
inProgress
waitingDependency
waitingExternal
completed
failed
fallout
cancelled
skipped

Header completed hanya jika semua required item completed/skipped valid.
Header failed jika terminal failure tidak dapat di-recover.
Header partial jika sebagian service completed dan sebagian gagal/held.
Header cancelled tidak boleh menghapus history item yang sudah berjalan.

serviceability checked
resource reserved
technical design completed
provisioning submitted
provisioning completed
activation confirmed
service test passed
customer handover completed
billing ready

service_order_milestone
- id
- service_order_id
- service_order_item_id
- milestone_code
- status
- planned_at
- achieved_at
- source_system
- external_reference
- correlation_id

ServiceOrder
ServiceOrderItem
FulfillmentTask
ProvisioningRequest
ProvisioningResponse
ServiceOrderMilestone
Fallout
RetryAttempt
ManualIntervention

Product order item
Product offering/specification
Configuration
Site/location
Customer/account
Existing inventory
Catalog/service rules

Service order
Service order items
Service characteristics
Dependencies
Assigned downstream systems
Initial milestones

decomposition_rule_version
decomposition_input_snapshot
decomposition_output_reference
decomposition_decision_trace

service_order_fallout
- id
- service_order_id
- service_order_item_id
- fallout_code
- fallout_category
- severity
- source_system
- error_code
- error_message
- retryable
- manual_intervention_required
- assigned_team
- resolution_status
- resolution_note
- created_at
- resolved_at

request_id
idempotency_key
service_order_item_id
attempt_number
external_correlation_id
request_payload_hash
status
last_attempt_at

Retry must not create duplicate service.
Retry must not advance service order twice.
Retry must preserve original causation/correlation.
Retry must distinguish unknown outcome from known failure.

Request timed out.
Downstream may have completed it.
Do not blindly send another create without checking external state or idempotency support.

Release reserved resource.
Cancel provisioning request.
Deactivate partially created service.
Reverse service inventory update.
Notify product order orchestration.
Prevent billing activation.

cancellation_request_id
reason
requested_by
requested_at
accepted_at
compensation_status
compensation_task_reference
final_state

ServiceOrder
ServiceOrderItem
ServiceOrderItemCharacteristic
ServiceOrderItemRelationship
ServiceOrderMilestone
ServiceOrderStateHistory
ServiceOrderItemStateHistory
FulfillmentTask
ProvisioningAttempt
ServiceOrderFallout
ServiceOrderCancellation
ServiceOrderExternalReference

Service order must reference source product order/order item unless externally initiated.
Service order item action must be valid for target service instance state.
Service order item cannot start until required dependencies are complete.
Completed service order item must have completion evidence.
Failed/fallout item must have fallout reason.
Retry attempt must be idempotent.
Cancellation after execution must have compensation trace.
Service inventory update must be traceable to completed service order item.

create table service_order (
    id uuid primary key,
    tenant_id uuid not null,
    service_order_number text not null,
    source_product_order_id uuid,
    source_product_order_item_id uuid,
    customer_id uuid,
    account_id uuid,
    state text not null,
    priority text,
    requested_start_date timestamptz,
    requested_completion_date timestamptz,
    expected_completion_date timestamptz,
    orchestration_reference text,
    version bigint not null default 0,
    created_at timestamptz not null,
    updated_at timestamptz not null,
    unique (tenant_id, service_order_number)
);

create table service_order_item (
    id uuid primary key,
    tenant_id uuid not null,
    service_order_id uuid not null,
    parent_service_order_item_id uuid,
    source_product_order_item_id uuid,
    action text not null,
    state text not null,
    service_specification_id uuid,
    service_instance_id uuid,
    assigned_system text,
    sequence_number integer,
    version bigint not null default 0,
    created_at timestamptz not null,
    updated_at timestamptz not null
);

create index idx_service_order_source_product_order
on service_order (tenant_id, source_product_order_id);

create index idx_service_order_state_date
on service_order (tenant_id, state, created_at);

create index idx_service_order_item_order_state
on service_order_item (tenant_id, service_order_id, state);

create index idx_service_order_item_assigned_system_state
on service_order_item (tenant_id, assigned_system, state);

{
  "id": "SO-10001",
  "state": "inProgress",
  "relatedParty": [],
  "serviceOrderItem": [
    {
      "id": "SOI-1",
      "action": "add",
      "state": "inProgress",
      "service": {
        "serviceSpecification": {
          "id": "SPEC-INTERNET-CFS"
        },
        "serviceCharacteristic": []
      }
    }
  ]
}

Internal IDs should map to stable public IDs/hrefs.
State names must preserve external contract semantics.
Characteristic values should be typed consistently.
Fallout/internal error detail may need separate operational endpoint.
Process/task internals should not leak unless API is operational/internal.

ServiceOrderCreated
ServiceOrderAccepted
ServiceOrderRejected
ServiceOrderStarted
ServiceOrderItemStarted
ServiceOrderItemCompleted
ServiceOrderItemFailed
ServiceOrderHeld
ServiceOrderFalloutRaised
ServiceOrderFalloutResolved
ServiceOrderCompleted
ServiceOrderCancelled

event_id
event_type
event_version
service_order_id
service_order_item_id
source_product_order_id
source_product_order_item_id
state
action
assigned_system
correlation_id
causation_id
occurred_at

ServiceOrderResource
  -> ServiceOrderApplicationService
  -> DecompositionService
  -> FulfillmentOrchestrationService
  -> ServiceOrderRepository
  -> OutboxPublisher
  -> DownstreamProvisioningAdapter

POST /serviceOrder
  -> directly call downstream OSS
  -> update DB later

1. Persist service order and item.
2. Persist outbox/work command.
3. Commit transaction.
4. Async worker sends provisioning command.
5. Persist attempt/result.
6. Transition state.
7. Publish event.

service_order_id       -> preserve order-level sequence
service_order_item_id  -> preserve item-level sequence
source_product_order_id -> group by product order flow

ProvisionServiceCommand
ReserveResourceCommand
ActivateServiceCommand

Lost Redis key must not lose service order state.
Stale lock must not block fulfillment forever.
Cached status must not override DB state.

process_instance_id
business_key
service_order_id
service_order_item_id
task_id
incident_id

fact_service_order
fact_service_order_item
fact_service_order_milestone
fact_fallout
fact_provisioning_attempt

dim_customer
dim_product
dim_service_specification
dim_downstream_system
dim_site
dim_team

Who/what created this service order?
Which product order item caused it?
Which decomposition rule created each item?
Which downstream system received the request?
What request payload was sent?
What response was received?
Why did state transition happen?
What fallout happened?
Who resolved it?
Was completion evidence received?

SERVICE_ORDER_CREATED
SERVICE_ORDER_ITEM_STARTED
PROVISIONING_REQUEST_SENT
PROVISIONING_RESPONSE_RECEIVED
FALLOUT_RAISED
MANUAL_INTERVENTION_ASSIGNED
FALLOUT_RESOLVED
SERVICE_ORDER_COMPLETED

1. Start from product_order_id/product_order_item_id.
2. Find related service_order/service_order_item.
3. Check decomposition trace/rule version.
4. Check service order/item current state.
5. Check state transition history.
6. Check dependencies between service order items.
7. Check fulfillment tasks and provisioning attempts.
8. Check downstream request/response/correlation ID.
9. Check fallout records and retry attempts.
10. Check service inventory update.
11. Check product inventory update.
12. Check billing readiness trigger.
13. Check event outbox/inbox and projection freshness.

Was service order created correctly?
Was it accepted by downstream?
Is it stuck because of dependency, external wait, manual hold, or data error?
Was completion acknowledged but not consumed?
Did retry create duplicate external work?
Did cancellation require compensation?

Can we explain, from data alone, what technical work was required, what happened, what failed, what was retried, what completed, and how it changed service/product/billing state?