Clarity

Hi All,

I'm again opening this "sensitive" topic. I'm not 100% sure what should be the best way to do it because it still only remains SQL insert as a "solution" for that.

I know many "issues" within my experience and also others on this community but in fact, there is no exact solution for that (Posted TS not in ppa_wip table) not either the root-cause of this problem .

There are only queries and portlets that can identify those cases but not which they can solve it. So my question is how to best handle it?

So, our issue is as usual, Posted TS which are not in PPA_WIP table.

I've checked all common things I know, all is fine (imp_transactionimport table is blank, ppa_transcontrol contains some data (for adjusted TS by other teams) but not for our resource, timeperiod were opened when posted, resource is financially active, resource is opened for time entry, track mode is clarity, investment is active, investment financial status is open , investment is opened for time entry).

However Prtimeentry.prrmexported = 0

This only the one case in our system.

Q1: Could it be that the name for resource contains a letter "í" for her name Rodríguez. Not the standard “i“?

Q2: So, we have 5 Posted TS with Prtimeentry.prrmexported flag set to 0. How can I process it to ppa_wip table?

Thanks

Matej

Answer to Q1 is NO.

Q2 - check that the reporting time period is still open and that the project is financially open and run Post Timesheets job again and it should export to the financial module.

Check this KB

How to identify the 'MISSING' hours in the posted timesheets which are stuck with PRRMEXPORTED = 0

Hi Kathryn,

Post Timesheets I cannot run because there are already new TS in Approved status which they will be affected also...

Is it somehow possible to Post only those TS within older time periods? I know this is possible only in Post Transactions to Financials...

Or only way is close all time periods except those I'd like to post Posted TS against....

@Urmas: OK, thanks

Re:

Post Timesheets I cannot run because there are already new TS in Approved status which they will be affected also...

Is it somehow possible to Post only those TS within older time periods?

The way I have done that is to make a record of the approved timesheets and return them, post and re-approve the returned timesheets.

Hi Urmas,

Hmm, sounds fine, but we have currently over 400 Approved TS in our system and users may wonder why their TS are "strangely processed"...

We are posting TS only once per month so I'll only see then if it work (ending of May), means if it will be processed. But still there is an option

what should I do when it will not processed correctly? Means if Prtimeentry.prrmexported will be still 0. How then I should handle it?

Originally, I thought this as my question... How to handle it if "standard" jobs not process those Timesheets Thanks

As per my understanding, the whole Transaction Posting process works as follows (if you do it through the UI):

1. Go to Transactions. Create a new Transaction by selecting the Transaction Class/Charge Code/Input Type Code and assign it to a Task as well as to a financially active Resource.

2. Allocate Actuals to it. And submit.

3. Post Transactions to Financials.

4. View the Posted Transactions in the list view on the UI.

5. Post to WIP.

6. Post Timesheets.

I've explained this as a summary. And, you can check the values of the Transaction Class, etc. in the DB Table: ppa_wip and the Actuals in the DB Table: ppa_wip_values.

Once these steps are followed, you should be able to view the Posted Transactions within the DB Tables as well as on the UI. Please correct me if I've missed anything.

Suhail.

From the tech ref

PRRMEXPORTED

A flag that indicates whether the time entry row has been processed and data sent to the project accounting component.

I read that to mean when the flag is set to 0 as in your case the time entry rows have not been processed and data sent to the project accounting component

I have to ask: Did you actually check what Kathryn_Ellis suggested or did you just check the standard thing in the GUI?

Hi Urmas,

About PRRMEXPORTED flag, yes I know that...

About Kathryn's questions:

Time periods: OK

Project: OK

Mentioned KB article: I've used exactly that query now and also in the past to identify those stuck TS....

Just wanted to know if PRRMEXPORTED flag will be still 0 after Post Timesheets job will run on the next time. What to do next

Matej

If the time period is still open and the settings are correct for financial enablement on the investment, the next time the Post Timesheets job runs it should pick it up automatically

Hi Kathryn,

Unfortunately it happened the same thing as I feared. After next Posting TS action, this resource has not been processed again, means Prtimeentry.prrmexported is still 0...

Seems that something with this resource is wrong...

So the question from the beginning - How to process it correctly- is now in place again.

Can you please advice somehow? Thanks

Matej

Just wanted to double check: "Unfortunately it happened the same thing as I feared. After next Posting TS action, this resource has not been processed again, means Prtimeentry.prrmexported is still 0..."

1. You checked from the database that the "Prtimeentry.prrmexported is still 0..."

2. You ran the Post Timesheets job: The timesheet was posted

3. You ran the Post Transactions to Financials job: The timesheet period falls between the Transaction From Date and the Transaction To Date

4. You checked the Invalid Transactions to make sure that the transaction is not On Hold or in Rejected status

5. You clicked on Apply on the Post to WIP Screen / selected the corresponding project for the timesheet, and clicked on Post button.

The transaction was processed and still the "Prtimeentry.prrmexported is still 0..."

Am I correct in summarizing as to what you did ?

NJ

Hi Navzjoshi,

Yes exactly! The same like the last month... so I've posted my question there how to best handle it, but not exactly got an answer

While these "records" (not yet transactions) have still prrmexported set to 0, they cannot be of course processed....

Thanks

Matej

Hi Matej Petrgal,

Please check this community post - Use the SQL and/or the portlet XML which will help you identify why the transaction is stuck with prrmexported = 0

CA Clarity Tuesday Tip: How to identify "Invalid Timesheets" or Actuals missing in WIP

Thanks,

Jerin     

Hi Jerin,

I read this article in the past and also again last month but there is only info about identification of these cases (which I well know),

but anything about solving these cases....

Matej

Hi Matej Petrgal

Once you identify what the issue is, correct the record and run the Post Timesheet job and the records should show up in invalid transactions.

For eg., if the query says the project is financially closed, then open the project for financials and then run the post timesheet job.

If the trackmode of the resource is not clarity, change it to clarity and then run the Post Timesheet job and the record should show up in the invalid transactions.

Please let me know how it went.

Thanks,

Jerin

And once you run the job, the prrmexported should change to 1 and this would mean that the records are processed to the next table which is imp_transactionimport. Thanks, Jerin

Hi Jerin,

there is nothing from all these "common issues" as a cause. Please read my first (beginning) post.

Matej

Hi, Do you have multi currency in your system? Did you check and made sure there is nothing in the prlock table stopping this from processing? Thanks, Jerin

Hi Jerin,

Yes we have. This user is with a standard "EUR" currency and there is also nothing in prlock table...

Do you have also answer on my question? How to handle these records?

I assume only way is the direct DB update but need to know if only prrmexported flag is needed or it's more complex so not possible....

Matej

Hi, May I know what DB update are you trying ? From your first post, I see that PRRMEXPORTED is 0 which means the job should ideally pick this record and post it. Setting it to 0 is the only way to force the post timesheet job to pick this record so there is no SQL update you can do to push the record to the next table as its already 0.

This would need some in depth look into the data  - can you please open a case with CA Support?

Jerin

Hi All

I've just successfully solved this topic, in spite of not all of you responded on my question how can I process those Timesheets.

I was able to process all TS successfully, after changing the name and ID of resource to Rodriguez (without  "í") (see my first post - Q1)

Hi urmas,

Answer on my Q1 is Yes...

Matej

Well matej256   one should not take anything granted until one sees it himself or herself.

Your Q1  was

So you were only asking about the name, not the ID.

I just posted a couple of timesheets for resources with non ascii characters without problems

as you can see they are in the Invalids and Prtimeentry.prrmexported = 1

If you could not have characters like that you could not use timesheets in Europe, Russia or Japan.

I think the problem is the the ID and when Niku 6 came it was common practice to use only numbers and ascii characters in any of the ID*s

Hi Urmas,

Yes of course, this was an ID issue because only ID is take into account when processed...

I meant my question for resource ID of course, not name, but I didn't express it so clearly (ID vs. name...) so bad question was in place

Matej

There are also issues with names and the extended ascii. eg.  Opening projects in MS Project from 14.3 with the new driver: Any task or resource names with extended ascii are blank.