question regarding moving financial period

I have a question regarding moving financial period backward. We have a requirement where we need to move the financial period backward during the day. As you would know, moving period backward causes problem, where the webserver caches this table and does require us to bounce E1 web services. This is not a practical solution.





Does any one ave a better solution to handle this.

One solution, I have heard is that we create a special user who have a special OCM mapping to a different copy of F0010 table. This way, when he/she changes, it makes the chane to secondary table without impacting rest of the users. Then this user can do what ever he/she needs to do.

I have also heard about removing F0010 table from teh cache list, however it has a performance hit.

What release and tools release are you on? We have done this before and clearing the service cache from SAW and clearing the database cache from WSJ has worked just fine for us. We are on 8.12, 8.96.2.2.

Hi We are on E810 Wintel/SQL platform with Tools release 8.96.2.3. Clearing cache does not always works perfectly.

Hi Nick,
If i correctly understand, you want to put some transactions in an already closed period. For doing this you want to open the previously closed period, post transactions and then put back the current period.

ideally for back dating transactions, what we do is open the period, and Log out of JDE completely (User only). No need to Bounce or stuff like that. When you re-login, the changed period is effective. So, now you will be able to post transaction and if required back revert to original period.

This all depends on how the technical setup is of the installation.

Regards

[ QUOTE ]
Hi Nick,
If i correctly understand, you want to put some transactions in an already closed period. For doing this you want to open the previously closed period, post transactions and then put back the current period.

ideally for back dating transactions, what we do is open the period, and Log out of JDE completely (User only). No need to Bounce or stuff like that. When you re-login, the changed period is effective. So, now you will be able to post transaction and if required back revert to original period.

This all depends on how the technical setup is of the installation.

Regards

[/ QUOTE ]

When looking into the "technical setup of the installation", any words of wisdom or areas of caution?

We have several AP postings that are getting the PBCO error and are trying to find the best solution.

~Kelli

I have moved the period back using my Fat client and the change was available immediately. We ended up making the F0010 a non-caching table with no effect on performance. YMMV depending on how many companies you have

Late post to this thread.

The log-off/log-in method mentioned in this thread does not work if the user is re-connected to a call object kernel that already has a user(s) in it with already cached F0010. It'll work in a small test environment - but not a real environment with 100 users.

We just went all-web (9.0) and this is a big issue for our accountants - particularly during the months when they are doing prior year closes.

Questions for Stats:
1. What release are you on?
2. Did you try to remove F0010 from your Web Servers cache also?

I have seen a client do something similar to what you mentioned (special user) , but rather we had a special environment , which was identical to the main PD env , except the OCM for these 3 tables - F0010 , F0009 and F0013 were to a different datasource (Control Tables , in this case). We then had special roles that had access to this environment and these roles were assigned to specific finance users who needed to be able to work/transact in previous periods etc.

[ QUOTE ]
Late post to this thread.


Questions for Stats:
1. What release are you on?
2. Did you try to remove F0010 from your Web Servers cache also?

[/ QUOTE ]

1) 8.11 SP1, think we were on 8.97 Tools the time

2) Per ID 664721.1, I used P98613 and deleted the entry to cache the F0010. My recollection is that this stops a one-time write to cache and forces a table I/O when called. But I just a BSA, so I am not 100% sure.

I did the change first in PY. I timed a series of transaction beore and after the change. I did not notice any effect on performance. Oracle does say it may affect performance, but I did not see any. I made the change for the very same reason, the accountants. As a recovering accountant, I understood their pain.