This chapter describes the process of extending and renewing contracts.
This chapter covers the following topics:
This group of topics explains how you can extend and renew contracts.
Oracle Service Contracts allows you to extend the duration of a contract or a contract line without having to submit the contract to the approval workflow.
A contract must be in a status of Active, Signed, or Expired to be extended. Contracts in a status of Entered, Canceled, or Terminated are examples of contracts that cannot be extended.
When you extend the duration of a contract, the contract lines are automatically extended, as long as the end date of the line is the same as the end date of the contract. If the end date for the line is different from the end date for the contract, the line will not change if the contract is extended. This functionality ensures that a service with a duration that, is deliberately different from the contract duration, retains its intended duration.
Either you can extend the contract without repricing it, or you can choose to reprice it. For example, you may:
You can also extend the duration of a contract line manually. See Extending a Contract Line.
After you have extended a contract, you should review any changes to the billing schedules. See How Billing Schedules Are Updated for Extended Contracts
Note: You cannot extend the original contract if it has already been renewed. However, you can extend the renewed contract, as long as another contract does not follow it.
The process of renewing a contract involves making a copy of an existing, active contract at a point in time. The dates are changed to reflect a period similar to that of the existing contract, beginning on the first day after the existing contract expires. Other attributes of the new contract may also be changed, such as pricing.
Contracts can be renewed either manually or automatically. You can manually renew a contract from the Contract Navigator, or your administrator can set up the application to automatically submit a contract for renewal. Regardless of whether you plan to renew contracts manually or automatically, you can:
After a contract has been renewed, changes to the existing contract will not update the renewal contract. For example, if a contract is renewed 90 days before expiration and the customer requests changes to their existing contract 15 days after the renewal process has begun, the changes made to the existing contract will not be reflected on the renewed agreement. If changes have not been made on the renewal contracts and it is still in an Entered state, you can:
Note: When renewing a Subscription contract:
To upsell a contract by adding additional services or covered goods, you may do so at renewal. To upsell a contract, you must work with a sales representative when an opportunity to open and update the contract occurs.
You can cancel service lines or covered products during a renewal if you no longer want to renew them. See Understanding Line Level Cancellation and Termination Reasons.
For information about creating and enabling templates for e-mails to customers, see About Templates for E-Mails to Customers.
Note: For the procedure about extending a contract line, see Extending a Contract Line.
For the procedure about extending a contract subline, see Extending a Contract Subline.
You can extend the duration of a contract subline. If a warranty or service contains multiple lines, then you can select the sublines to extend their duration. When you extend the duration of sublines, the application does the following:
After the contract is extended, an additional billing stream sequence appears in the billing schedule. This sequence covers the extended duration. Depending on the billing schedule, the total amounts for any unbilled periods are updated to reflect the remaining duration of the contract.
If you do not reprice the contract, the total amount of the contract remains unchanged. However, for each line, a new billing stream sequence is added with the same billing period as the preceding stream sequence. The number of periods for the new billing stream sequence reflects the duration of the extension.
Although the total amount of the contract has not changed, the billing stream sequences for any unbilled total amounts are also updated to reflect the remaining duration of the contract. The billing schedule is also updated.
For example, if you have a one-year contract with a service line that is priced at 100 USD and is scheduled to be billed one time during the one-year duration, and you extend that contract without repricing it; a second billing stream sequence is added with the same billing period as the previous billing stream sequence. Because the contract has not been billed, the amount for each billing stream sequence is now 50 USD. However, the total amount of the service line remains 100 USD.
Billing Stream Before Contract Extension
Seq | Number of Periods | Start Date | End Date | Duration | Period | Amount | Total Amount |
---|---|---|---|---|---|---|---|
1 | 1 | 01-MAR-2005 | 28-FEB-2006 | 1 | Year | 100 |
Billing Stream After Contract Extension
Seq | Number of Periods | Start Date | End Date | Duration | Period | Amount | Total Amount |
---|---|---|---|---|---|---|---|
1 | 1 | 01-MAR-2005 | 28-FEB-2006 | 1 | Year | 50 | |
2 | 1 | 01-MAR-2006 | 28-FEB-2007 | 1 | Year | 50 |
If you reprice the contract, the total amount of the contract is updated to reflect the new pricing. For each line, a new billing stream sequence is added with the same billing period as the previous stream. The number of periods for the new billing stream reflects the duration of the extension. Because the total amount of the contract has changed, the billing streams for any unbilled amounts are updated to reflect the new amount and the new billing stream. The billing schedule is also updated.
For example, you have a one-year contract with a service line that is priced at 100 USD, and is scheduled to be billed one time during the one-year duration, and you then extend the contract and reprice the service line to 200 USD, a second billing stream sequence is added with the same billing period as the previous billing stream sequence. Because the contract has not been billed, the amount for each billing stream is now 100 USD and the total amount of the service line is 200 USD.
Billing Stream Before Contract Extension
Seq | Number of Periods | Start Date | End Date | Duration | Period | Amount | Total Amount |
---|---|---|---|---|---|---|---|
1 | 1 | 01-MAR-2005 | 28-FEB-2006 | 1 | Year | 100 |
Billing Stream After Contract Extension
Seq | Number of Periods | Start Date | End Date | Duration | Period | Amount | Total Amount |
---|---|---|---|---|---|---|---|
1 | 1 | 01-MAR-2005 | 28-FEB-2006 | 1 | Year | 100 | |
2 | 1 | 01-MAR-2006 | 28-FEB-2007 | 1 | Year | 100 |
Contracts can be renewed manually or through an event-driven process.
The life cycle of a renewal contract is similar to a newly authored contract. See Overview of Managing Contract Negotiation.
The key difference between a new contract and a renewal contract is the process following contract creation. A new contract remains in a sales representative's queue pending his action; whereas the application routes a renewal contract to the sales representative, the customer, or bypasses both and activates the contract. Two parameters determine the branching: the renewal rule and the threshold amounts derived from the Global Contracts Defaults. See Entering Contract Defaults.
You can set up renewal rules that apply to both the manual renewals and the event-driven renewals. See Specifying How a Contract Will Be Renewed,Renewing Contracts Manually, and Managing the Event-Driven Renewal Process.
To derive the renewal process, the application evaluates renewal rules using the contract, party, organization, and global level hierarchy for the authored contract. At each level, starting with the contract authoring level, the application evaluates renewal rules according to a logic that first evaluates threshold conditions and determines the validity of a threshold-driven process. If a threshold condition is not satisfied, the application uses the renewal process entered on the contract. If no renewal process is entered on the contract, the logic is repeated at the next level of the hierarchy, such as the organization level. The renewal process follows the following logic to determine the renewal process for a contract:
Level | Renewal Process | Evergreen Threshold | Online Threshold |
Contract | Null | NA | NA |
Party | Evergreen | Null | 20,000 |
Organization | Null | 10,000 | 15,000 |
Global | Online | -- | -- |
Effective Renewal Rule Values | Evergreen | 10,000 | 20,000 |
In the previous example, if the contract amount is equal to 15,000, the application uses the default renewal process at the party level, which is Evergreen. This level is used irrespective of the contract amount.
Level | Renewal Process | Evergreen Threshold | Online Threshold |
Contract | Online | NA | NA |
Party | Manual | Null | 20,000 |
Organization | Null | 10,000 | 15,000 |
Global | Online | -- | -- |
Effective Renewal Rule Values | Online | 10,000 | 20,000 |
In the previous example, if the amount is 5,000, the Evergreen process holds. If the contract amount is 15,000, the Online process holds. If the amount is 25,000, the Online process holds. After the application derives the renewal process, workflow logic determines contract routing and the process flow.
Renewal types include the following:
The Manual, Online, and Evergreen renewal types have subprocesses that you define by selecting an Internal Approval method either within the contract itself or within the Global Contracts Defaults. Internal approval method is a required field that needs to be defined when a renewal process is defined at the contract, party, organization, or global level. When the renewal process determines the renewal process type for a contract, the corresponding approval flag determines the internal approval method for that contract. See Entering Contract Defaults.
The following table provides an overview of the combinations of renewals types and internal approval methods. You can start renewals through an event-driven process or manually:
Renewal Process | Internal Approval Method | Description |
Manual | Required | This renewal type sends a notification to the inbox of the sales representative associated with your contract. See Understanding Manual Renewals with the Internal Approval Set to Required. |
Manual | Not Required | The Submit for Internal Approval action associated with this renewal type results in an automatic QA check and contract activation. A QA check failure results in a Failure notification, and routes the contract back to the negotiation stage of the process, where you can update it. Activation takes place with the Signature notification directed to the sales representative. See Understanding Manual Renewals with the Internal Approval Set to Not Required. |
Online | Manual | This renewal type sends an e-mail notification to the customer to renew the contract over the Web. See Understanding Online Renewals with the Internal Approval Set to Manual. |
Online | Automatic | This renewal type enables a contract that has been accepted online by the customer to be automatically submitted for internal approval without a sales representative's intervention. See Understanding Online Renewals with the Internal Approval Set to Automatic. |
Online | Not Required | This renewal type skips the internal approval allowing a contract to be directly submitted for activation as a result of online customer acceptance. See Understanding Online Renewals with the Internal Approval Set to Not Required. |
Evergreen | Required | This renewal type enables you to have the application create a renewed contract and submit it for approval to the sales representative specified on the contract or the help desk contact specified in the Global Contracts Defaults. See Understanding Evergreen Renewals with Internal Approval Set to Required. |
Evergreen | Not Required | This renewal type enables the application to renew the contract in Active status. No approval or human intervention is required. See Understanding Evergreen Renewals with the Internal Approval Set to Not Required. |
Do Not Renew | NA | This renewal type enables you to prevent a contract from being renewed. See Understanding How Do Not Renew Works. |
By setting the renewal type of a contract to a Manual renewal with the Internal Approval set to Required, the application sends a notification to the Inbox of the sales representative associated with your contract.
The process works as follows:
By setting the renewal type of a contract to Manual with the Internal Approval set to Not Required, you can author a contract and have it activate after customer acceptance.
The following describes how the process works:
By setting the renewal type of a contract to Online with the Internal Approval Set to Manual, the application sends an e-mail notification to the customer to renew the contract over the Web.
The following describes how the process works:
By setting the renewal type of a contract to Online with the Internal Approval Set to Automatic, the application submits contracts accepted Online by the customer for internal approval without sales representative intervention.
By setting the renewal type of a contract to Online with the Internal Approval Set to Not Required, you are allowing the internal approval to be skipped during the Online process. This allows the application to directly submit a contract for activation after online customer acceptance.
The following describes how the process works:
By setting the renewal type of a contract to Evergreen with Internal Approval set to Required, the application creates a renewed contract and submits it for approval.
The following describes how the process works:
Note: If you do not see the Submit button, your administrator may not have set the status and operations to allow online updates.
By setting the renewal type of a contract to Evergreen Renewals with the Internal Approval set to Not Required, the application renews the contract in a status of Active.
Following is a description of how the process works:
By setting the renewal type of a contract to Do Not Renew, you can prevent a contract from being renewed.
During the renewal process you can create multiple quotes for a single contract and publish them for customer acceptance. Each renewal quote should be unique and specify different pricing, quantities and party information. The customer can accept one of these multiple quotes, which matches with their requirement. If a quote is accepted by the customer, or the quote Negotiation Status has changed to Pending Internal Approval or Pending Activation, the quote will be set as Master and the other quotes will be withdrawn.
When you create multiple quotes during renewal, the first quote is set by default as the master quote.
Multiple Quotes and Evergreen renewal are mutually exclusive. For a contract if the Renewal Process is set as Evergreen, then you cannot select the Allow Multiple Quotes check box for the contract and vice versa.
In the Service Contract Authoring window, Summary, Renewals tab you can select the Allow Multiple Quotes check box to let the contract contain multiple quotes. In the Service Contract Search page, you can view the contract that has multiple quotes through an icon representing this and also search for multiple quotes for a contract. In the Service Contract, Renewals tab page, you can view the Allow Multiple Quotes and Master Quote check boxes. In the Service Contract, Administration tab page, you can view the Master Quote check box.
You can perform the following steps to specify multiple quotes for a contract:
Additional Information: Setting the renewal type within does not necessarily mean the contract will be renewed accordingly. The application may override this option based on the Evergreen and Online renewal types as well as thresholds specified in the Global Contracts Defaults.
You can specify whether a contract should renewal manually on the contract. Upon renewal, whether it is an event-driven or manual renewal, the application sends a notification to the sales representative associated with the renewal. See Understanding Sales Credits During Renewals.
Prerequisites
Confirm the setup of sales territories, or set OKS: Use Territories to Default Sales Person to No and specify the sales representative who handles renewal requests in the profile option OKS: Default Sales Person for Renewal.
You can allow a contract to automatically activate after customer acceptance.
Prerequisite
Confirm the setup of online renewal.
Online renewal is available for Warranty and Extended Warranty, Service Agreement, and Subscription categories of contracts.
The e-mail the application sends includes a hyperlink the customer can use to access your organization's web site and renew the contract. See Overview of the Customer Acceptance Portal.
You can allow a contract to be automatically submitted for internal approval without intervention by the sales representative after it is accepted online by a customer.
You can have online customer acceptance result in an automated QA check and submission for contract activation.
You can have the application create a renewed contract and submit it for approval to the sales representative specified on the contract or the help desk contact specified in the Global Contracts Defaults.
You can have the application renew a contract upon expiration.
The following provides an overview of how Oracle Service Contracts determines which sales representative receives sales credit for the renewal. The application uses OKS: Enable Sales Credit profile to make this determination. This profile option has four values:
OKS: Enable Sales Credit Profile Option Setup | Business Rule |
Derive for Revenue Type | Drops both types of sales credits and derives only the sales credit specified under the OKS:Revenue Type profile option. |
Derive for Revenue Type and Retain Other | Drops and derives only the sales credit specified under the OKS:Revenue Type profile option; Retains the other sales credit. |
Drop All | Drops both sales credits; no derivation of either. |
Retain All | Retains both sales credits; no derivation of either. |
Rules to Derive Sales Representative When the Profile Option OKS: Enable Sales Credits is set to Derive:
The application uses the following profile options to derive a sales representative for the renewal agreement:
Other Profile Options Used for Sales Credits:
You can set up renewal rules that apply to both manual renewals and automatic renewals. Pricing methods specify how the contract will be priced at renewal. There are three pricing methods:
For more information on defining pricing methods for renewals, see:
The following is intended to help you understand how the Price List pricing method works.
A contract using the Price List pricing method has the Corporate price list assigned. For the original contract the list price of item X is $150. Before the contract is renewed, item X on the corporate price list is changed to $200. Item X on the renewed contract will be $200.
The following is intended to help you understand how the Manual pricing method works.
A contract using the Manual pricing method contains item X. For the original contract the list price of item X is $150. Before the contract is renewed, item X on the price list is changed to $200. When the contract is renewed, item X will be $150, not the increased price of $200.
The following is intended to provide some scenarios to help you understand how renewal markup pricing works.
In calculating the amount of a contract for a renewal agreement using Renewal Markup Pricing, begin with the original year contract Con03. This agreement has a final price that is comprised of the year 2003 price list plus any discounts or surcharges that are applied (modifiers).
The contract contains a renewal markup that indicates that the final price of the contract should be increased or decreased by a certain percentage when that contract is renewed. Also identified is a renewal price list Cap04. This price list is generally used to assure that renewal customers are not being asked to pay more for their renewal agreements after markups than new customers are paying for their original service contracts.
When renewing the contract, any modifiers carried over from Con03 to the renewal agreement are applied to the Cap04 list price to calculate the final price. Service Contracts compares this amount to value of Con03 plus the renewal markup percentage. The renewal markup value is used unless it exceeds the cap pricing value. The application, effectively, selects the lower of the two values and that amount becomes the new contract final price for the renewal agreement.
Example 1: Markup pricing does not exceed cap (using surcharges)
List price of item X $1,000
Modifier: 10% surcharge
Contract Final price: $1,100
Renewal markup: 5%
Cap List price of item X $1,500
Modifier: 10% surcharge
Example 2: Markup up pricing exceeds cap (using surcharges)
List price of item X $1,000
Modifier: 10% surcharge
Contract Final price: $1,100
Renewal markup: 5%
Cap List price of item X $1,000
Modifier: 10% surcharge
New Contract Final Price $1,100
Example 3: Markup pricing does not exceed cap (using discounts)
List price of item X $1,000
Modifier: 10% discount
Contract Final price: $900
Renewal markup: 5%
Cap List price of item X $1,200
Modifier: 10% discount
There are a number of implementation setups that are required to define and trigger the renewal process. For more information, see the Oracle Service Contracts Implementation Guide.
By entering a grace period, you can extend the service a customer receives while a renewed contract is in the process of being negotiated and approved. This group of topics explains how grace periods work and how to set them up:
By specifying a grace period you grant the customer the services of a contract beyond the expiration date at no extra charge. Grace periods ensure the customer does not experience an interruption of service while a contract is being renegotiated, for example.
The actual start and end dates of the contract and the billing schedule are unaffected by the grace period.
If the renewal happens within the grace period, the new contract takes effect the day after the original contract expired and the customer is billed accordingly.
Suppose, for example, that a customer calls on January 15 to renew a service contract that expired on December 31. Because the contract had a one month grace period, the customer did not experience any interruption of service, but the new contract goes into effect and is billed from January 1 rather than from the date of the call or the end date of the grace period.
You can specify a grace period both for the current contract and for the renewed contract.
You can use the Global Contracts Defaults form to set up a standard grace period for the contracts that are renewed.
The grace period affects only lines and sublines that expire on the same day as the contract.
If you add a 30 day grace period to this contract, services 2 and 3 are eligible for entitlement until 30-JAN-2004. Service 1 is not.
The same logic applies to sublines and coverage terms. Only those items that end on the same day as the contract end date are considered for coverage during the grace period. As long as the business processes are eligible for entitlement, the original terms associated with the business process (preferred engineer, coverage times, reaction times, resolution times, and billing types) will continue through the extended period.
You can delete the grace period from the contract at any time, either before the contract expires, when the grace period goes into effect, or when the renewed contract becomes active.
You can grant, modify, or deny a grace period for the current contract. During a grace period, the customer continues the same level of service as under the old contract, at no extra charge, if the contract expires.
Prerequisite
Set the profile option OKS: Enable Grace Period to Yes at the Site Level.
A grace period becomes effective upon the expiration of the renewed contract.
Prerequisite
Set the profile option OKS: Enable Grace Period to Yes at the Site Level.
If the renewed contract has the same duration as the original contract, a copy is made of the original contract, which also includes a copy of the billing schedule.
If the renewed contract has a duration that is different than the original contract, then the billing schedule does not appear on the renewed contract. The renewed contract fails the QA check because the billing schedule does not adjust itself to the new duration. This also happens when you renew a one year contract for six months. Even if the renewal type is Evergreen (Internal Approval is Not Required), the renewed contract stays in Entered status because it fails the QA check.
Warning: Irrespective of the renewal duration the billing schedules are not copied during renewal consolidation of lines or sublines.
If you are considering using the Evergreen (Internal Approval is Not Required) renewal type, you should also consider using billing profiles. When a billing profile is defined in the global defaults, the billing schedule for the renewed contract is created according to that billing profile.
Renewing service contracts can be complicated because some organizations will always sell a full duration service contract the first time, resulting in a single customer having numerous contracts expiring at different times over the course of a year. This requires the customer be contacted multiple times per year for renewal confirmation and perhaps renegotiation, which increases the workload for renewal.
Renewal Consolidation addresses the problem of multiple contracts expiring during a year (or other given period) causing multiple renewals. With Renewal Consolidation, all the contracts to be renewed over a given period are consolidated into a single renewal contract.
Renewal Consolidation has several benefits:
The renewal consolidation process is initiated after a contract has been renewed, which may have been the result of the renewal event where contracts are renewed in mass or manually renewed from the Contract Navigator using the right mouse click. In both cases the contract is in the Entered status and is considered the Target contract.
If a contract is not valid for consolidation, you will see the error message Target contract is invalid. If the target contract is eligible for renewal consolidation, the Renewal Consolidation window is displayed and is used to facilitate the selection of all the source contracts for consolidation. The upper half of the window displays all the details of the target contract. The lower half displays all the eligible source contracts in a tree structure.
The following lines are displayed:
A contract is eligible as a source contract if the following are true:
When submitting the renewal consolidation, a concurrent request consolidates all of the selected source lines into the target contract. If the services are the same on the source and target contracts, the covered levels of those services can be merged into one contract line on the target contract.
Merging occurs if the following conditions are met:
In addition, setting the profile option OKS: Check Coverage Match to Yes, forces the renewal consolidation process to preserve differences in coverage.
The Check Coverage API compares each attribute of the coverage and stops as soon as one difference is found. It returns the result to the renewal consolidation process. If the coverage is the same, the sublines of the source contract are merged under the service of the same name on the target contract. If the coverages are different, a new contract line is created on the target contract for the service on the source contract.
The Check Coverage API checks the following attributes:
The start dates of the consolidated lines begin one day after the expiration of the original source line and all the end dates coterminate with the target contract. When the operation instance is reviewed at a later date, that is, after the concurrent request has processed normally, all the consolidated source lines are identified with ##.
When the renewal consolidation or operation instance is created, a source line is eligible for consolidation at that point in time. However, between the time it is created and the time it is submitted, a given source line may have been renewed, whether it be by consolidation in another operation instance or renewed manually. Therefore, at the time of submission, the application verifies that the source is still eligible for consolidation. If not eligible, Oracle Service Contracts excludes the source line from the consolidation.
After consolidation has taken place, the target may be opened to verify that all the source contracts have been consolidated successfully. The new terms and conditions may then be reviewed with the customer. Once the customer agrees with its terms and conditions, the contract may be submitted for approval and billed at the intervals designated in the contract.
Note: An Extended Warranty line can be consolidated into a Service line. However, a Service line cannot be consolidated into an Extended Warranty line. This is because an Extended Warranty line supports only a product while a Service line supports party, customer, site, product, item, and system.
During renewal consolidation only the lines or sublines that are moved from the source to the target contract are repriced as per the target contract's price list. All the lines on the target contract prior to renewal consolidation process are not repriced automatically.
You can generate quote letters and e-mail them to a customer as part of the renewal process. The person who receives this e-mail quote is specifically identified on the Summary Renewals tab.
Prerequisites
The following profile options must be set up in order to use the e-mail Quote functionality:
You can perform the following steps to send quote letters by e-mail:
You may elect not to maintain one or more services on the contract at the time of renewal. Alternately, you may choose to discontinue service only for specific service lines or covered products on a service contract at time of renewal.
Note: Your administrator can define status and operations to prevent canceled status lines from being deleted from contracts. Entered lines can similarly be controlled.
You can terminate lines and sublines in contracts due to service transfer, product return, product replacement, updates to instance quantity in install base, instance expiration/termination in install base and manual service termination. When you terminate lines and sublines, the termination reason and source appears in the authoring form along with termination date and status.
Note: When services are transferred from Entered contracts, the transferred service lines and sublines are automatically placed in Canceled status with a cancellation reason of Service Transferred. Lines canceled due to service transfer are not eligible for status change back to Entered.
You cancel both lines and sublines for contracts with the Entered status; whether these contracts were created as new contracts through authoring, or as renewal contracts through the renewal event or the manual renewal process. You can also cancel both lines and sublines for Manual and Online renewal contracts, provided they pass QA successfully at time of renewal, Evergreen contracts go straight to Active status and are not typically eligible for line level cancellations.
If you cancel a line or subline, the cancellation date stamp is today's date. You must also enter a cancellation reason.
If you attempt to delete an Entered contract with lines that are canceled due to Transfer, all canceled status lines are deleted on the contract except for the lines that are canceled with a cancellation source of Service Transfer.
You cannot delete service lines or covered levels that were canceled as a result of a service transfer:
Canceled lines are excluded from quotes, QA checks, and are not eligible for billing or termination. Amounts for canceled lines are not rolled up to contract line/header. Canceled lines are included in reports.
After you activate a contract, the canceled lines and sublines remain on the active contract as Canceled. In subsequent renewals, the canceled lines drop from the renewed contract. If all lines in Signed, Active, Expired status are terminated during the life of the contract and the only remaining lines on the contract are in Terminated or Canceled status, the contract should not be selected for renewal by an automated renewal event.
Canceled lines or sublines cannot be made active on Active contracts.
You cannot perform the following actions on a canceled service line:
You cannot perform the following on a canceled service subline:
When you cancel or terminate services and sublines, the reasons and source appears in the authoring form along with a date and status.
The following cancellation sources appear in the authoring form:
Cancellation Source | Cancellation Reason |
Manual | you determine |
Service Transfer | Service Transferred |
The following termination sources appear in the authoring form:
Termination Source | Termination Reason |
Manual | you determine |
Service Transfer | you determine |
Item Instance Return | Covered Product Returned |
Item Instance Replacement | Covered Product Replaced |
Item Instance Expiration | Covered Product Expired |
Item Instance Quantity Update | Covered Product Quantity Updated |
Prerequisite: Open a contract with contract lines in Entered status.
To cancel a contract line
Prerequisite: Open a contract with contract lines in Entered status.
To cancel a contract subline