• 1.  Change resource Dept on a Transaction

    Posted Aug 28, 2012 03:07 PM
    Have some transaction errors created, where a user (admin) changed a resource's department prematurely in Clarity before it was updated in a our PeopleSoft master data set. This master data set overwrote the admin's change, but not before transactions were recorded against the wrong department.

    Also, we've had issues with resources converting to timesheet based transactions from imported transactions (they've moved from a different part of the company), where inflight transactions from their old system are imported into Clarity after they've already been assigned to their new department in Clarity.

    Now, we need to correct these transactions, assigning them to the correct (previous) resource department.

    Have not found a means to do this, not even in Clarity 13. When creating a WIP Adjustment, many attributes can be changed on a transaction, but not the resource's department. Looking at the nikuxog_transaction.xsd file, appears that even by xog, there is no means to assign a department to a transactions other than to the department that the resource is currently assigned to - meaning that there is no way to process inflight transactions correctly or to correct transactions that have department errors.

    Is this correct? If not, how can one fix such errors? Does one have to reverse such transactions, change the resource's department back to its previous value, process the transaction and then reset the resource back to their current department?

    If so, "Ugh!" Or, can we just do an SQL Update on the transactions, directly?


  • 2.  RE: Change resource Dept on a Transaction

    Posted Aug 29, 2012 01:06 AM
    As far as I know the "ugh" way (Does one have to reverse such transactions, change the resource's department back to its previous value, process the transaction and then reset the resource back to their current department?
    ) is the only "Supported" way to do this. The "Unsupported" alternative for a "Posted" and "UnInvoiced" transaction would be to update the dept in the PPA_WIP table (NOT RECOMMENDED), you would be updating a financial table :O which may be considered a heinous crime by the company's compliance groups

  • 3.  RE: Change resource Dept on a Transaction

    Posted Sep 09, 2012 09:47 AM
    Hi Dale,
    i think customization of the trans xml through xog should work, will try and will let you know


  • 4.  RE: Change resource Dept on a Transaction
    Best Answer

    Posted Sep 11, 2012 12:52 PM

    As of this time a WIP adjustment wouldn't change the transaction employee department to the current value set on the resource financial properties page, we do have an enhancement open requesting a few changes including this. Our Product and Marketing teams are transitioning to using the Ideas page in this community to track ERQ, it would be best to place a new request (if one does not exist) there and you will get mine plus a few other votes.

    You can extend the request to having the choice on whether to adjust existing transactions to reflect also current project department/location as well


  • 5.  RE: Change resource Dept on a Transaction

    Posted Nov 13, 2012 05:17 PM
    Connie - I found one Idea related to transactions, describing how to convert the current architecture to an ODF based architecture. Although good (I voted for it), it did not contain two ideas that I have. So, I've created these:

    - Batch WIP Adjustments
    - Allow adjustment of all transaction metadata

    Regarding reversing the transaction, changing the resource's department and then processing the transaction again, I have a few problems:
    1 - the quantity of transactions that need to be updated makes this process prohibitive
    2 - where does one go to initiate the reprocessing of reversed transactions?

    I have reversed transactions on our TRN system - but then I've not been able to see them again in the UI. They'e still in Clarity with -2 status, but I don't see them listed or counted on the pages that I see - not on:
    - Transaction Entry
    - Post to WIP
    - Create WIP Adjustment
    - Approve WIP Adjustment
    - Transactions

    If one can see reversed transactions in the UI, where is one supposed to see them? Searching Clarity docs, I've not found anything on what happens to transactions once reversed, or where to see them.

    Its almost as if once reversed, its gone from the UI for good. Perhaps this is intentional and the user would need to resubmit their timesheet, and imported transactions would need to be reloaded?


  • 6.  RE: Change resource Dept on a Transaction

    Posted Nov 13, 2012 06:22 PM
    WIP reversals are for transactions that you want to get rid of, and reversals are final. Therefore these transactions would not show up anywhere in the UI - they are 'gone' for good and can't be modified further.

    If the transaction origin is vouchers/XOG, you can reverse the existing WIP transactions, then create new vouchers/XOG transactions again;
    If the origin is timesheets, don't reverse the transactions (should avoid any type of WIP adjustment all together on timesheet transactions). You can adjust the timesheet to have 0 hours, process them financially to WIP to back out the WIP actuals; then adjust the timesheet again and this time put the hours back, process them financially to WIP and these transactions should pick up the current employee department/location. This would be quite an effort if the timesheets in question are of a large number


  • 7.  RE: Change resource Dept on a Transaction

    Posted Nov 16, 2012 01:07 PM

    Thanks for confirming my fears about reversed transactions being 'gone for good.' I have expect that the same thing occurs with invalid transactions that are deleted. However, I haven't checked to see of deleted, invalid transactions still exist in Clarity with a status of -2, like reversed transactions.

    The transactions that need 'department' correcting are from a mixture of timesheets and imported transactions. Understand your suggestions.

    The process for fixing timesheet transactions will only be feesible on a small scale. I don't see us doing anything on a large scale with this method. Stressing "Do it right the first time!" I think is the only thing we can do. We just don't have the backing to tell a large number of users and their Clarity admins, that they've screwed up and have to redo many of their timesheets. The admins know what needs fixing - preference is to let the admins make the corrections (through some batch capability, not by having them resubmit timesheets for users!) and let the users work on getting our new products designed/tested and into production.

    Ok - I think this tread is done. Here's to hope that the ideas I created will get approved/implemented....soon!

  • 8.  Re: Change resource Dept on a Transaction

    Posted Jul 28, 2014 04:38 PM

    Hi Connie,


    This subject has come up again for us.  We are on 13.1 and haven't seen, yet, the enhancement you described.  Expect to be on 14.1 before end of year.


    I have found that by changing a resource's department and then creating a WIP Adjustment, we can partially make the changes we want to make:

    - change resource to department that transaction should have been against

    - create WIP adjustment for the transaction

    - delete cost/rate values for the transaction

    - mark "Calculate New Rates" checkbox

    - Save and Return


    The adjusted transaction will utilize the rate from the 'new' department assigned to the resource.  Great - this is what we want.  However, the resource department identified in the transaction will not be changed - so, we have the old department, the new rate from the new department, but the old department referenced in the transaction.  So, when auditing transactions, it looks like an error "Here's the department, but that's not the rate for the department for that time period.  Where did that rate come from?"


    So, maybe the enhancement was partially implemented?  The rate does update (Yes!), but the department value does not (dang!).


    Thanks for any updates on this,