/*
 * Copyright 2026, Jaime Terrats.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
import { workflow } from '../workflow-generator.js';
export function generateCommunicationsWorkflows(version) {
    return {
        'product-catalog-setup.md': workflow(version, 'Product Catalog Setup', `
## 1. Gather Requirements

Ask:
- **Product offerings:** What are the top-level sellable products (e.g., broadband plans, mobile bundles, IPTV packages)?
- **Product specifications:** What are the underlying technical specifications for each offering (speed tiers, data caps, device models)?
- **Attribute schema:** Which configurable attributes does each specification expose (bandwidth, contract term, SIM type)?
- **Pricing model:** Which pricing dimensions apply — one-time (activation fee), recurring (monthly), usage-based (per-GB overage)?
- **Promotions/discounts:** Are there time-bound promotions, loyalty discounts, or bundle incentives?
- **Channel eligibility:** Are certain offerings restricted to specific sales channels (retail, online, partner)?

Check \`force-app/main/default/objects/\` for existing \`vlocity_cmt__ProductOffering__c\` and \`vlocity_cmt__ProductSpecification__c\` customizations before adding new fields.

## 2. Define Product Catalog Structure

### ProductOffering (sellable entity)
- Represents what the customer sees and purchases.
- Links to one or more ProductSpecifications via \`vlocity_cmt__ProductOfferingSpecRelationship__c\`.
- Configure pricing via \`vlocity_cmt__PricingElement__c\` records (one-time, recurring, usage).
- Set eligibility rules and channel restrictions on the offering.

### ProductSpecification (technical blueprint)
- Defines the technical characteristics of a product component.
- Holds configurable attributes (e.g., download speed, data allowance, codec type).
- Linked to ProductOfferings via specification relationships.
- Reusable across multiple offerings — a single "100Mbps Fiber" spec can back multiple retail plans.

### Attribute Schema
- Define attributes on specifications using \`vlocity_cmt__Attribute__c\` and \`vlocity_cmt__AttributeAssignment__c\`.
- Set attribute constraints: picklist values, numeric ranges, dependencies between attributes.
- Ensure attribute values align with TMF620 Product Catalog standards for interoperability.

## 3. Configure Pricing

1. Create \`vlocity_cmt__PricingElement__c\` records for each charge type:
   - **One-Time Charge (OTC):** activation fees, installation charges.
   - **Recurring Charge (RC):** monthly subscription, equipment rental.
   - **Usage Charge:** per-unit overage, pay-per-view events.
2. Associate pricing elements with the ProductOffering.
3. Configure pricing tiers and volume discounts where applicable.
4. Set effective dates for time-bound pricing.

## 4. Configure Promotions and Discounts

1. Define promotion records with eligibility criteria (new customer, upgrade, loyalty tier).
2. Link promotions to specific ProductOfferings or categories.
3. Set discount type: percentage, fixed amount, or free period.
4. Configure promotion duration and auto-expiry rules.
5. Validate that promotions stack correctly (or enforce mutual exclusivity).

## 5. Deploy Product Catalog Metadata

\`\`\`bash
sf project deploy start \\
  --source-dir force-app/main/default/objects/vlocity_cmt__ProductOffering__c \\
  --source-dir force-app/main/default/objects/vlocity_cmt__ProductSpecification__c \\
  --source-dir force-app/main/default/customMetadata \\
  --target-org <alias>
\`\`\`

Verify in the target org:
- Product offerings appear in the Industries CPQ catalog browser
- Pricing elements display correctly on the offering detail page
- Attribute configuration is editable and constraints are enforced
- Promotions apply correctly during a test cart simulation
`),
        'order-orchestration-setup.md': workflow(version, 'Order Orchestration Setup', `
## 1. Gather Requirements

Ask:
- **Order decomposition:** How should a commercial order be decomposed into fulfillment orders? (by service type, by network element, by billing system)
- **Orchestration plan:** What are the sequential and parallel fulfillment steps? (provision network, activate SIM, configure CPE, update billing)
- **Fulfillment systems:** Which downstream systems handle each step? (OSS for network, BSS for billing, inventory for equipment)
- **Fallout handling:** What happens when a fulfillment step fails? (retry, manual intervention, automatic rollback)
- **SLA requirements:** Are there time-based SLAs for order completion or individual steps?

Check \`force-app/main/default/objects/\` for existing order-related customizations on \`OrderItem\` and \`vlocity_cmt__OrchestrationPlan__c\`.

## 2. Configure Order Decomposition

### Commercial Order → Fulfillment Orders
- A single commercial order (customer-facing) decomposes into multiple fulfillment orders (system-facing).
- Decomposition rules are defined in \`vlocity_cmt__DecompositionRelationship__c\`.
- Each decomposed order item maps to a specific fulfillment domain (network, billing, inventory).
- Align decomposition with TMF622 Product Ordering specification for standard lifecycle states.

### Decomposition Rules
1. Define decomposition criteria: by product specification type, by service point, by fulfillment system.
2. Create decomposition relationship records linking commercial line items to fulfillment domains.
3. Configure item-level decomposition for complex bundles (e.g., a triple-play decomposes into 3 fulfillment orders).
4. Test decomposition with representative orders covering all product types.

## 3. Configure Orchestration Plans

### Plan Structure
- An orchestration plan defines the sequence of fulfillment steps for a decomposed order.
- Steps can be sequential (wait for previous) or parallel (execute simultaneously).
- Each step maps to a fulfillment action: API callout, Platform Event, manual task, or sub-orchestration.

### Step Configuration
1. Navigate to Industries Setup → Order Management → Orchestration Plans.
2. Create a plan for each fulfillment domain (e.g., "Network Provisioning Plan", "Billing Activation Plan").
3. Define steps within each plan:
   - **Step name** and **execution order** (sequence number or parallel group).
   - **Step type:** Auto (API callout), Manual (human task), Event (Platform Event).
   - **Completion criteria:** success response code, event receipt, manual confirmation.
   - **Timeout:** maximum wait time before escalating to fallout.
4. Configure dependencies between steps (step B waits for step A completion).

## 4. Configure Fulfillment Integration

### Platform Events for Async Fulfillment
- Publish \`OrderFulfillmentRequest__e\` Platform Events for each orchestration step.
- Subscribe in downstream systems (OSS/BSS) or via Apex triggers for internal processing.
- Include order item ID, action type, and payload in event fields.

### API Callouts for Sync Fulfillment
- Use Named Credentials for external system authentication.
- Implement callout classes per fulfillment system (network provisioning, billing, inventory).
- Handle partial success: update step status individually, do not fail the entire plan on one step failure.

### TMF641 Service Ordering Alignment
- Map orchestration step statuses to TMF641 lifecycle states: acknowledged, inProgress, completed, failed.
- Expose order status via REST API for external system polling (align with TMF622 order state model).

## 5. Configure Fallout Handling

1. Define fallout rules per step type:
   - **Retry policy:** number of retries, backoff interval.
   - **Escalation:** assign to queue or user after max retries.
   - **Rollback:** compensating actions for previously completed steps.
2. Create a fallout queue for manual intervention cases.
3. Configure alerts (email, Chatter, Platform Event) on step failure.
4. Document the fallout resolution process for operations teams.

## 6. Deploy Order Orchestration Metadata

\`\`\`bash
sf project deploy start \\
  --source-dir force-app/main/default/objects/OrderItem \\
  --source-dir force-app/main/default/objects/vlocity_cmt__OrchestrationPlan__c \\
  --source-dir force-app/main/default/objects/vlocity_cmt__OrchestrationItem__c \\
  --target-org <alias>
\`\`\`

Verify in the target org:
- A test order decomposes correctly into expected fulfillment orders
- Orchestration plan steps execute in the correct sequence
- Platform Events fire and are received by subscribers
- Fallout handling triggers on simulated step failure
- Order status reflects TMF-aligned lifecycle states
`),
    };
}
//# sourceMappingURL=communications.js.map