ECA Capped Case

Overview
ECA currently offers Adjustment due to Cap (100% discounts) to customers when all the invoices against a contract
up to that point hit a certain $$ value (Cap) (Ex $40,000). Cap limits vary from contract to contract.

Historical Invoice value for a contract is calculated manually. The decision that if the cap discount is to be applied is
based on if the cap limit is hit referring to the historical invoice values. If the discount is to be applied during the
‘current’ billing cycle, a new Billing Code is added at the end of the sales order, with a negative pricing on the Sales
order equal to the net value on the sales order. Two billing codes DEFERRED REV and CONTRA AR are used with a
negative pricing that works as the discount.

The entire process of ECA Capped Case discounting, is very time consuming and requires expertise and resources.

As-Is Process
 Currently the cap adjustment calculations manually done outside SAP, in a spread sheet. Invoice amounts are collected from SAP.

 From the spreadsheet, over (under) values are compared with the Net Value and there are two scenarios –
o If the sales order net value is greater, then the discount amount in the spreadsheet “over (under)” column is subtracted from
the net value. This new total will be the amount of cap adjustment. Some of these will need a full cap adjustment, some will
need only a partial adjustment.
o If the sales order net value is less than the amount in the “over (under)” column there will be no adjustment in the billing Cycle.

 Manually, in VA02, a new line (Cap line) with Billing Codes DEFERRED REV or CONTRA AR. The Billing Code selected is based on the
Customer Account Assignment Group on the Sales Order Header – Accounting tab. Typically the line item is added (at the end of all line
items) and manually numbered (950) if available.
o The Net Price of the new Cap-line item is the net value on the sales order until that point and is entered in the Amount column.
o Qty for the Cap-line is $1
o Pricing Date of the Cap-line will be matched with other line items.

 Capped cases are tracked separately in another spreadsheet.

Key points
 ECA capped case applies to 1 contract, however, we will need to limit existing contracts
 Caps are total dollar value, not quantity.
 Invoices to be adjusted to $ 0.00 value once Cap is passed with 1 fractional value to equal Cap.
 Cap Discounts may require dedicated GL
 New Pricing Condition required with a value formula to determine line-item credit value
 Caps generally apply to entire contract, however, there are some exceptions for certain materials
 Capped case discount must be displayed in 1 line item for invoice output
 Taxes are applicable to Capped case line items at the original Price levels and billed to clients
 Cap-Discounts to be posted to separate Ledger Account, they are not posted to Revenue.
 Taxes are not included for the cap value limit consideration

High level Requirements for automating ECA Capped case discounts.

 Replace the capped case discounts with an automatic calculation of ‘Sum’ and apply the adjustment automatically on every
sales order, within SAP.
For certain contracts, NOT all invoices are included in the calculation of ‘Sum’. A start date is determined after
which the calculation will be made.
This Cap discount functionality should apply only to ECA. (Sales Orgs 1300, 1310, 1325 )
 Apply Cap-Adjustment on each line item with a new item price condition based on the cap limit. Creating a new line item on
the sales order is NOT required.
 Apply cap adjustment based on the historical billing of the associated contract. For each sales order line, calculate if the cap
is hit, from the historical invoice amounts plus prior sales order lines. Cap adjustment should NOT apply until the Cap-limit is
not hit.
 Create a new Price (discount) condition for Cap-Adjustment at item level.
Maintain the cap limit as a scale value in the condition maintenance.
 Capped case in a Partial Order - Capped case scenarios can emerge midway thru a sales order when historical invoice
amounts plus prior sales order lines hit the cap-limit. In such a scenario, cap adjustment should apply ONLY to the
subsequent sales order lines.
 Every time an invoice is saved (both create and change), save the sum of all the Historical Invoice values on the contract.
Allow for the changes in the historical Invoice values (Should we ??)
 New data fields - Create new field on the Contract Header-Additional data B to display the sum of the historical invoice Net
values against the contract.
 Allow the Historical Invoice Value to be changed manually in VA42 (should we ??)
 Include Invoice Cancellations, Credits and Debits to update the Historical Invoice Value every time created or changed.
 Certain materials are exempted in the capped case discount calculations.

Approach / Proposed Solution

1. The manual calculation of, if a contract hit the cap limit will be replaced by an automatic determination when a sales order
line the sales order line-item is created and saved. This same calculation will also apply for change orders (VA02).
2. A new condition ZECP-ECA CAP Discount (with a value formula to determine if the line-item is eligible for adjustment) will
be created to apply to all eligible billing codes instead of creating new line item.
3. The current practice of changing the Customer Account Assignment Group on the contract header will NOT be required, as
the Cap-Adjustment discount condition will be posted to a specific G/L account.
4. Taxes will be charged as applicable on all sales order lines before the cap adjustment will be applied. This will be achieved
by placing the new condition after the tax base sub-total.
5. Cap adjustment will not apply to excluded materials and will not be part of the calculation of historical Invoice amount on
the contract header.
6. Cap-Adjustment (discount) on the invoice form will be included in the total discount.

Details
1. Three New Contract Header fields
It is proposed that three New Contract Header fields are added to the Contract Header Additional Data B tab.
(Mocked up screenshot below)
i. Historical Invoice Amount (non editable) – VBAK-xxxxx (similar to VBAK-NETWR)
Every time an Invoice or a Credit or a Debit (corresponding to the contract) is created or changed in the system, Historical
Invoice Amount will be programmatically updated in the backend with the sum of all historical invoices, credits, and debits.
ii. Adjusted Invoice Amount (editable in VA42) – VBAK-yyyyy (similar to VBAK-NETWR)
This can be used in cases where Historical Invoice Amount will need to be adjusted for any reason.
If a $$ value in available this field, the cap case calculations on the new sales orders will be made based of this is field instead of
Historical Invoice Amount.
iii. Adjustment Reason) – VBAK-zzzzz
This is to provide a reason for adjustment.
Selecting a reason will be mandatory, and without a reason, a sales order will error during saving. By default, the reason will be
a blank.
A list of predefined reasons can be made available in a dropdown selection for assigning a reason.
a. Reason1
b. Reason2
c. Reason3
d. Reason4
iv. A change log will be available for any changes made to these Adjusted Invoice Amount and Adjustment Reason.

v. The three new data fields will be appended to VBAK table at the end.

vi. The three new data fields will be available in VA42 and VA43 transactions.
2. Data Flow
It is proposed that three new data fields will be copied to the next sales order being created. However, these fields will NOT
be editable on the sales order.
Copy controls will be maintained/developed for copying the data from contracts to sales orders.

3. Cap Discount Pricing Condition - ZECP

A new % discount condition type ZECP (Cap Discount) will be created and will be added ONLY to ECA pricing procedures.

i. Key combination on the condition type

The only key combination proposed: Sales Org/Assignment.

ii. Start date for the calculation of ‘Sum’

The ‘Valid on’ date will determine the calculation of ‘Sum’ and it is important that the required date is keyed in
here. Else current date is defaulted.

iii. Condition rates with graduated discounts

Graduated scales can be maintained for when the discount should start applying. (mocked up screenshots below)
- Lower tier of the scale (cap limit) - Discount is NOT applied - to be maintained at 0%
- Higher tier of the scale - Discount is applied - to be maintained at 100%
4. ‘Sum’ Calculation and application of discounts
New pricing requirement routines will be created to use with the new condition type ZECP and pricing procedures. The
routines will calculate if the cap is hit and apply the discount condition to the sales order line where applicable.
For each new sales order line entered system will read the Historical Invoice Amount from sales order header, the net
values of all line items on the current sales order up to that point and the net value of current sales order line to calculate
the Sum (as in the spreadsheet).

Sum= Historical Invoice Amount + New value from all sales order lines above the current sales order line + net value for the current
sales order line.

 When the Sum is less than the ZCEP scale value condition, discount will be applied per the graduated scale. (Typically, 0%)
 When the Sum is more than the ZCEP scale value condition, discount will be applied per the graduated scale. (Typically, 100%).
 Therefore, when the cap $$ limit is hit, discount condition will be applied at 100% to all the subsequent lines, thus each line
item will be (zero-net value + taxes).
 Discount will apply only on the line items that are copied from the contracts. When a sales order line is manually added later on
discount will not apply. These will not a reference of the contract and therefore condition wouldn’t apply.

NOTE: In a scenario where the cap is hit only with the partial net value of a sales order line, discount will be applied to the
entire line item.

5. Taxes
Taxes will continue to apply to all sales order lines (when applicable) at the original net values. The ZECP will be positioned
in the ECA pricing procedure after the tax base sub-total, so the taxes still apply while ensuring cap adjustment is applied.

6. Account Posting
Cap-Adjustments (discounts) will be posted to a separate Ledger Account. The G/L account will be finalized discussing with
Joh Mullen.

The same G/L accounts as is now from header- 40040073 will be used for posting the new ZECP discounts.

7. Updates to Historical Invoice Amount

Every time an Invoice against contract is created or changed the new contract header field Historical Invoice Amount will
be updated programmatically with the sum of all historical invoices, credits, and debits. This update will be done on-line
(Instead of an Invoice Output as in the LOP project).

8. Credits/Debits
Every time a Credit or a Debit (corresponding to the contract) is created or changed the new contract header field
Historical Invoice Amount will be updated programmatically with the sum of all historical invoices, credits, and debits.
This update will be done on-line (instead of an Invoice Output as in the LOP project).

9. Excluded Materials (Bill Codes)

 Materials that are excluded from applying cap adjustment (discount) will be maintained as variables in the TVAVRC table.
Discount will NOT be applied to these bill codes. Also, these bill codes will be excluded in calculating the Historical Invoice
Amount on contract Header.
List of excluded materials:
1. DISCOUNT
2. ERROR-OM
3. RE-OTHER
4. RE-BROKER
5. Any other RE* material
6. MEDIA ADS
7. POSTAGE

10. Invoice Form

ZECP – ECA CAP discount will be displayed on all line items. (Mocked up below). The total of all ZECP discounts on the invoice will be
displayed against the Discount amount at the bottom of the invoice.

Assumptions
1. If there are multiple sales orders/Draft Bills for a contract in a billing cycle, review of both the drafts have to be done
together to validate if the cap adjustment is done correctly. This scenario will be validated during testing in QAS.
2. Excluded Materials (Bill Codes) will not have the discount applied and will be excluded from calculating the Historical
Invoice Amount on contract Header.
3.

Open questions
1.
2.
3.

Test and Validations

1. Lines that are added after the
2.