CA PPM: Can negative transactions be entered?

Document ID : KB000018475
Last Modified Date : 25/05/2018
Show Technical Document Details
Question:

Question:

There are two sides of a transaction. The project side and the financial side.

When transactions are entered as vouchers or XOG'ed in, it is processed by the Post-to-WIP job, which is on the financial side.

The project side will not have this updated information until the Import Financial Actuals job is run.
The financial-side table (PPA_WIP) is synchronized to the project-side table PRASSIGNMENT.

When a negative-quantity transaction is entered, (quantity less than 0,)  an out-of-sync situation may occur if there are not enough actual hours available to handle the corresponding credit.

Answer:

CA PPM does support negative transactions in WIP on the financial side, but there are situations when a negative quantity transaction does not update on the project/assignment correctly, causing quantity between WIP and assignments to become out of sync.
 

PPM assignments cannot show negative work, therefore if the net quantity between two transactions results in a negative, PPM will show 0.
 

The following scenarios are how CA PPM treats negative transactions.

Scenario 1: Different quantity, same date
1. Enter 5 actuals for SAME transaction date
2. Enter -8 actuals for SAME transaction date

PPM interprets this as:
a. There are 5 hours originally.
b. Then there are -8 hours.
c. 5 - 8 = -3

RESULT is 0, since negative hours (-3) are discarded.
WIP would show -3 quantity

Scenario 2: Different quantity, same date
1. Enter -5 actuals for SAME transaction date
2. Enter 8 actuals for SAME transaction date

PPM interprets this as:
a. There are -5 hours originally, which is discarded. 0 is the result.
b. Then there are 8 hours.
c. 0 + 8  = 8  WIP would show 3 

RESULT is 8
since it is a positive result.
WIP would show 3 

Scenario 3: Different quantity, same date
1. Enter 8 actuals for transaction date
2. Enter -5 actuals for SAME transaction date
    
PPM interprets this as:
a. There are 8 hours originally.
b. Then there are -5 hours.
c. 8 - 5 = 3  

RESULT is 3,
since it is a positive result.
WIP would show  3 (match)

Scenario 4: Different dates
1. Enter 8 hours of actuals for transaction date1
2. Enter -3 hours of actuals for DIFFERENT transaction date2

PPM interprets this as:
a. There are 8 hours on original transaction date1.
b. There are -5 hours on original transaction date2.
c. These are separate transaction dates.

RESULT is 8,
because
+8 is posted on transaction date1
-3 is backposted on transaction date2, which is discarded because it is negative.
WIP would show 8 for date1, -3 for date2 (net of 5 for both dates)

There will be an issue when a reversal occurs on a negative transaction because if an original negative showed as 0 in PPM (as described above), then the reversal adds a positive quantity, which in essence, doubles the amount.

Scenario 5: Reversal
1. Enter -8  actuals for transaction date

Result in PPM is 0 because the actuals cannot be below 0

2.  Reverse the transaction which creates a debit amount of +8.
    Import the transaction back to the project

Result:  PPM shows +8

SUMMARY:
Negative actuals posted on a specific date does not cancel out actuals from a different date.

In summary, when using negative transactions, you should have a pre-posting
(include Post to WIP and run Import Financial Actuals job) validation done on the existing actuals total
on the exact transaction dates that will be used in the transactions,
making sure that enough positive units of actuals exist on the project for the dates that negative quantities
are going to be posted to.

We do not recommend Reversing or Transferring any negative transactions as it will inflate PPM actual hours.
   
Timesheets transactions are not subject to this type of out-of-sync situation, because the you cannot enter negative hours on a timesheet.

If using XOG to import transactions ensure that if you use GroupID field, that the debit amounts have a lower value than the credit amounts.  If you use the same GroupID for each transaction make sure the debit amounts are first in the xog file.

An extra step in doing XOG is to process the debits first and then the credit separately as this will insure the debits get imported back to the project first.

Answer:
.
Additional Information:
https://comm.support.ca.com/kb/explain-wip-reversal-and-wip-transfer-actions/kb000021749