<span class="bold">Create and Update Supplier Warranty</span>

The Supplier Warranty Solution includes these REST APIs:

Warranty Coverages
Warranty Contracts

Warranty Coverages

Supplier warranty begins by defining Warranty Coverages. They are reusable templates used to translate and model the warranty terms extended by a Warranty Provider from the purchase of an asset or the continued support of an existing asset through an extended warranty period. The provider is the main supplier reference on the coverage and its related Warranty Contracts. The provider is also the supplier to whom you typically submit a Warranty Claim for the reimbursement of in-house repair or component replacement expenses. A coverage includes information about what is extended under the warranty terms, who is responsible for the repair or replacement of an asset or its associated components, and how long the warranty period will last. After a coverage is defined and set to status Ready, it's used to instantiate a unique Warranty Contract for an asset. The contracts can then be viewed and considered during Maintenance Work Order execution. Over time, the contracts expire for an asset using a scheduled process to update their status.

The warranty period of a coverage could be defined by a time duration, utilization meter interval (such as an odometer or hour meter) or by using both methods with a whichever-expires-first rule. When the coverage is used to instantiate a contract for an asset, the contract is first assigned a Start Date. If the asset and contract are created by the receipt of an item using a purchase order, then the start date is set to the asset's created date. If the contract is created manually using the UI or the REST API, then either a user-defined or the present date is set as the start date.

After the start date is assigned to a contract, the application determines if an End Date, Calculated Expiration Date, or both will be assigned to the contract. If a time duration is defined in the coverage, then the resulting contract has an end date calculated as the start date + duration value. If one or more meter intervals are defined in the coverage, then the resulting contract calculates which meter interval expires first and sets it as the Calculated Expiration Date. If both methods are defined in the coverage, then both dates are displayed in the contract and the application utilizes a whichever-date-comes-first rule to determine when to expire a contract. This provides for both a static End Date, as well as a dynamically Calculated Expiration Date that are updated over time as meter readings are recorded for the asset.

The Warranty Coverages REST API supports these methods:

POST: Used to create a new coverage or child resources in an existing coverage.
- It is recommended that when you define a new coverage you pass a complete definition that includes both the parent resource (header) and child resource details (if required).
- Optionally, you can create just a coverage header and then incrementally define the applicable items, meters, and transaction codes as required.
PATCH: Used to update attributes in the header and child resources until the coverage is used to create its first warranty contract. After the first contract is created, you can only perform these updates:
- End-date the coverage header.
- Disable the child resources.
- Define new child resources using POST.
DELETE: Used to remove a coverage or individual child resources. You can use DELETE until the coverage is used to create its first warranty contract.
- After the first contract is created, you can only use PATCH to end-date the coverage or disable individual child resources. This maintains coverage definition history.

This use case discusses the following scenarios for a warranty coverage:

Create a warranty coverage header with duration only.
Create a warranty coverage header with meters only.
Create a warranty coverage header with duration, items, meters, and transactions codes.

Things to Consider before Creating the First Coverage

Before you create the first coverage, there are dependencies across other objects and setups that you should consider:

Items that are used to create enterprise assets must be set up in the Oracle Product Information Management offering by its inventory master and child organizations. Assets that are based on these types of items are eligible for supplier warranty. The assets can be created from a purchase order receipt or manually.
- The items must be set up as full lifecycle, maintainable, serial controlled, and purchasable from suppliers.
- Items can be optionally referenced in a coverage, allowing for the automatic instantiation of warranty during the purchase of an item from a supplier in an organization.
Users who define coverages must have Inventory Organization and Item Class access granted to define Items and Suppliers in a coverage. Details are covered in the Maintenance chapter in the Oracle Fusion Cloud Implementing Manufacturing and Supply Chain Materials Management guide.
Suppliers must be set up in Oracle Supplier Management. These will be the suppliers from whom an item is purchased from, and who will extend warranty terms as the Warranty Provider.
Manufacturer is an optional attribute in the coverage header that can be used to track an original equipment manufacturer reference for a supplier warranty, typically if the Warranty Provider is not the original equipment manufacturer. If used, the original equipment manufacturer must be set up as a Party that has usage as a Manufacturer.
Coverage Type is an optional attribute in the coverage header that can be used to further describe or group similar coverages. The Type is helpful to manage coverages across users and to further refine your search results. Examples include types such as New Purchase, Extended Warranty, and Original Equipment Manufacturer Warranty. An administrator can define the Type codes by using the user-defined lookup ORA_CSE_WTY_COVERAGES_TYPE.
Utilization Meters may be optionally used to define and track the coverage terms using a Warranty Contract. Examples may include an odometer or hour meter. Meter Templates must be first defined and then instantiated against each applicable asset that uses the meter before creating a warranty contract using the coverage.
Repair Transaction Codes may be optionally used to define the unique references for an asset's system, component, and item that are covered by warranty. These codes can then be referenced during work order execution for resource and material transactions. These codes are set up using the task flow Manage Condition Event Codes. When you define new codes, you must select the type as Transaction code only.

Create a Warranty Coverage Header with Duration Only

This scenario creates a coverage in Ready status, which means it can be used to create a contract that will have an End Date calculated only using the Warranty Duration value. The unit of measure code can be defined as a DAY, MONTH, or YEAR. The Start Date and End Date can be optionally defined, or you can leave both values as null and not pass the attributes, which will set the present date as the Start Date.

Example payload

Here's an example of the payload in JSON format:

{
"CoverageName": "ALM Coverage Dur Only",
"CoverageCode": "ALM_COVERAGE_D1",
"CoverageDescription": "Coverage by Duration only",
"CoverageStartDate": "2022-01-01",
"CoverageEndDate": "2022-12-31", 
"CoverageStatusCode": "ORA_READY",
"CoverageTypeCode": null,
"ManufacturerNumber": "123456",
"SupplierNumber": "654321",
"WarrantyProviderNumber": "12345678",
"WarrantyDuration": 30,
"UOMCode": "ORA_DAY",
"TermsAndConditions": "Defined terms and conditions",
"ReactionsAndResolutions": "Defined reactions and resolutions",
"ServiceLevelAgreements": "Defined service level agreements",
"InternalRepairAllowedFlag": true,
"AuthorizationRequiredFlag": true,
"PartsReimbursementFlag": true,
"PartsReturnRequiredFlag": true,
"LaborReimbursementFlag": true,
"FilterByTxnCodeFlag": true
}

Create a Warranty Coverage Header with Meters Only

This scenario creates a coverage in Ready status, which means it can be used to create a contract that will have only a Calculated End Date based on the Asset Meter's current Reading and Daily Utilization Rate. There won't be a Contract End Date based on the Duration, as it is not defined. During warranty contract creation, the asset will be validated for matching meters by the Meter Code. If there's a match, then the warranty contract will reference the Asset Meters for its expiration. Any mismatches will result in the contract being created in a Draft status, requiring review.

Example Payload

Here's an example of the payload in JSON format:

{
"CoverageName": "ALM Coverage Meter”,
"CoverageCode": "ALM_COVERAGE_METER1",
"CoverageDescription": "Coverage by Meter only",
"CoverageStartDate": "2022-07-01",
"CoverageEndDate": null,
"CoverageStatusCode": "ORA_READY",
"CoverageTypeCode": null,
"ManufacturerNumber": "123456",
"SupplierNumber": "654321",
"WarrantyProviderNumber": "123456789",
"WarrantyDuration": null,
"UOMCode": null,
"TermsAndConditions": "Defined terms and conditions",
"ReactionsAndResolutions": "Defined reactions and resolutions",
"ServiceLevelAgreements": "Defined service level agreements",
"InternalRepairAllowedFlag": true,
"AuthorizationRequiredFlag": false,
"PartsReimbursementFlag": true,
"PartsReturnRequiredFlag": false,
"LaborReimbursementFlag": true,
"FilterByTxnCodeFlag": true,
"coverageMeters":[
{
"MeterCode": "METER_TEMP_CODE_ABS_ASC_1",
"MeterStartValue": 0,
"MeterIntervalValue": 500
},
{
"MeterCode": "METER_TEMP_CODE_ABS_ASC_2",
"MeterStartValue": 100,
"MeterIntervalValue": 1000
}
]
}

Create a Warranty Coverage Header with Duration, Items, Meters, and Transactions Codes

This scenario creates a coverage in Ready status, which means it can be used to create a contract that will have an End Date calculated only using the Warranty Duration value and Matching Meter Code. Additionally, Items and Transaction Codes are defined providing a complete coverage definition.

Items can be defined using the master organization, which means any item purchased across its child organizations will be considered, or an item can be defined for a single child organization. Ensure that the same item and organization combination is not defined across active coverages, which will result in the creation of multiple contracts.

Example Payload

Here's an example of the payload in JSON format:

{
"CoverageName": "ALM Coverage All In One",
"CoverageCode": "ALM_COVERAGE_ALLIN1",
"CoverageDescription": "ALM COVERAGE Duration, Meters, Item and Code",
"CoverageStartDate": "2022-07-01",
"CoverageEndDate": "2022-12-01",
"CoverageStatusCode": "ORA_READY",
"CoverageTypeCode": null,
"ManufacturerNumber": "123456",
"SupplierNumber": "654321",
"WarrantyProviderNumber": "123456789",
"WarrantyDuration": 30,
"UOMCode": "ORA_DAY",
"TermsAndConditions": "Defined terms and conditions",
"ReactionsAndResolutions": "Defined reactions and resolutions",
"ServiceLevelAgreements": "Defined service level agreements",
"InternalRepairAllowedFlag": true,
"AuthorizationRequiredFlag": false,
"PartsReimbursementFlag": true,
"PartsReturnRequiredFlag": false,
"LaborReimbursementFlag": true,
"FilterByTxnCodeFlag": true,
"coverageMeters":[
{
"MeterCode": "METER_TEMP_CODE_ABS_ASC_1",
"MeterStartValue": 0,
"MeterIntervalValue": 500
},
{
"MeterCode": "METER_TEMP_CODE_ABS_ASC_2",
"MeterStartValue": 100,
"MeterIntervalValue": 1000
},
{
"MeterCode": "METER_TEMP_CODE_ABS_ASC_3",
"MeterStartValue": 50000,
"MeterIntervalValue": 25000
}
],
"coverageApplicabilities":[
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG1",
"SupplierNumber": null,
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG1",
"SupplierNumber": "7141",
"AutoAssignFlag": false,
"ContractDefaultStatusCode": "ORA_DRAFT"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG1",
"SupplierNumber": "7189",
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG1",
"SupplierNumber": "52070",
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG1",
"SupplierNumber": "46968",
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG1",
"SupplierNumber": "5057",
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG1",
"SupplierNumber": "50310",
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG1",
"SupplierNumber": "41327",
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG1",
"SupplierNumber": "45950",
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG1",
"SupplierNumber": "45913",
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG1",
"SupplierNumber": "44043",
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG1",
"SupplierNumber": "45850",
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG2",
"SupplierNumber": null,
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG2",
"SupplierNumber": "44043",
"AutoAssignFlag": false,
"ContractDefaultStatusCode": "ORA_READY"
},
{
"ItemNumber": "ALM-MX-ITEM-001",
"ItemOrganizationCode": "ORG2",
"SupplierNumber": "45850",
"AutoAssignFlag": true,
"ContractDefaultStatusCode": "ORA_READY"
}
],
"coverageTransactionCodes":[
{
"TransactionCode": "013-000-100"
},
{
"TransactionCode": "013-000-101"
},
{
"TransactionCode": "013-000-102"
},
{
"TransactionCode": "013-000-103"
},
{
"TransactionCode": "013-000-104"
},
{
"TransactionCode": "013-000-105"
},
{
"TransactionCode": "013-000-106"
},
{
"TransactionCode": "013-000-107"
},
{
"TransactionCode": "013-000-108"
},
{
"TransactionCode": "013-000-109"
},
{
"TransactionCode": "013-000-110"
}
]
}