When creating a transaction from the Transaction Entry page, users must choose between "Voucher Other" for Labor, Material and Equipment type transactions; and "Voucher Expense" for expense type transactions. Resources of those types will be available for choosing based on the voucher type chosen. This ensures users cannot create a Labor type transaction on an Expense type resource. If an incorrect Transaction Classification type is selected and does not match the same type as the Resource selected, the application will generate an error message. ( REVMGR-20952: Invalid transaction class )
XML Open Gateway (XOG) write action of a transaction does not provide the same safeguarding of type mismatch. This action allows users to XOG write a Labor type transaction (using a Labor Transaction Class) against an Expense type resource (or mismatch combination). XOG should prevent the creation of such transaction with a failure error, however it successfully creates such transaction into the IMP_TRANSACTIONIMPORT table waiting for further processing into the Financial Module. The successful creation of this transaction can cause issues in other areas of the application.
Steps to Reproduce:
Example: (snippet of XOG input file)----- snippet -----
<Transaction actualCostRate="120" actualCostRateCurrency="USD" billRate="120" billRateCurrency="USD" chargeable="1" chargeCode="cc2" externalID="E37289-8" importStatus="N" projectID="MYTESTPROJ" resourceID="EXPENSE101" transactionDate="2015-04-11" transactionType="L" units="1" taskID="5000009" inputTypeCode="chargeitc" groupId="123" voucherNumber="ABCVDD" transactionClass="TCLabor"/> ----- snippet -----
Expected Result: XOG results in an error indicating a labor type transaction must be created on a labor type resource, or it must not be created on an expense resource
Actual Result: XOG is successful, a transaction is created in Clarity and can be posted to WIP when it should not
Applies to all supported PAS environments for specified releases.
Caused by CLRT-71718
Workaround: Although the XOG allowed the transaction to be created with the mismatch, there will be issues with this transaction for WIP Adjustments and for posting the data back to the Project.
To REMOVE this transaction with mismatch types:
To CORRECT this transaction with mismatch types:
Reference CA PPM 13.3 Resolved Defects documentation