Custom environment...necessity?

***Stop me if you have heard this one before***

Our company has issues with controlling who posts prior period (prior months, not prior years) journal entries. Our solution? Control the fiscal dates in our primary environment (PD810), but allow a select few to post prior month transactions using...a custom environment (FIN810). FIN810 would be the same as PD810, except that the F0010 would be in a new library (DFINOW). At the end of a month, the dates would be rolled; if the controller wanted to post to a prior month, he would select the FIN810 environment and go to town.

This seems like trying to kill a fly with a low-level nuke...I know this seems to be a backwards method of controlling the dates, but it MUST be done. My question is, is this the best way to go about it?

If yes, then the next question...the F0010 is nested in the Business Data - Prod data source...would I then have to create a new data source (Business Data - Prod2) to path out to? It seems a little inefficient. Please advise.

I won't even comment on the "why" you're doing it, but to answer the technical question, yes, you'd place copies of whatever tables you wanted to keep apart in the new library, create a new datasource, and then for the new environment, still use a default DS for TBLE to Business Data - PROD, but put in individual entries for the 'special' tables that point to the new data source.

Thanks for confirming. We would only need to move the F0010 off into its own library...seems a little much, but the customer's always right...

Can't this sort of authorization be controlled with a Workflow in E810? I have not tried it personally, but it might be worth a shot.

Sometimes the customer will appreciate it when you make an attempt to save them from themselves.

Not this time.

Now y'all understand why I am performing the "high impact forced frontal lobe PC interface" in my avatar...

Urgh!

I would not create another environment (there is no need), but only another role to do it. Create the table on the new/separated library, create the datasource and add the OCM to the Role.

Do not add the role to *all..

My understanding is that OCMs by role do not work properly. I would test that carefully. We have done exactly what you discussed - we set up an separate environment which is a copy of PD and has only one OCM different, which is to another F0010 in a separate datasource which controls the accounting period. We currently have 43 environments (for the 4 standard pathcodes) - this is one of the less complicated environments.

Sue Shaw
Xe SP23i1 Coexistent iSeries V5R3 all client platforms

OK -

This part of my CNC is rusty. Do I need to create another complete copy of PD? From what I gathered, these would be my steps:

*Create new database/library (DFINOW in my case)
*Copy F0010 table from the production business datasource to the new library
*Create new database data source in OneWorld, pointing to the new library
*Create ODBC settings for the new database data source
*Define OCM overrides for the affected users, selecting F0010 from the new database data source
*Activate new override
*Test the new environment

Am I missing anything?

Assuming the new enviroment has been created or exists, yes. You don't need any tables (or physical and logical files for those that wish to remain accurate) for anything other than what you want to be "different" in the new environment. This is simply from a technical standpoint. I'd still be concerned what is happening from a functional standpoint. As the users of the "new" environment will be hitting and updating tables in the "real" production, except the F0010...could this cause users in the "real" production any issues? I don't know, I'm just a dumb CNC person. But again, from a technical standpoint, your list is accurate.

You are close. My comments are preceded by a '-'.

*Create new database/library (DFINOW in my case)
datasources (in our case we have two enterprise servers)
*Copy F0010 table from the production business datasource
to the new library
- correct, don't forget all the indexes
- or you could generate it from OW to the new ds and then copy the data over with SQL. either or.
*Create new database data source in OneWorld, pointing to the new library
- do this through planner which will prompt you to do the odbc part.
- ensure that you do system, and all server maps
- this updates the client\odbcdatasource.inf which gets deployed with packages so that all clients have the new datasource. Tip - don't deploy packages while in the process of setting up a new datasource.
*Create ODBC settings for the new database data source
- should have done this above
*Define OCM overrides for the affected users, selecting F0010 from the new database data source
- you don't have to do this - because you have a new environment, you just have to grant access to the appropriate people to that environment. In your example, the controller - so he/she will have to know that they have to log on to your new environment to post in a prior period.
- add new environment to environment master - you can choose to copy PD which 'should' copy all of the OCMs from PD to your new environment. My preference is to do this with SQL but up to you.
*Activate new override
- if this is add new OCM for your new environment to your new datasource for the F0010, then yes.
(again ensure that you get system and server map ocms - we did this once and forgot the server map ocm so the user could enter journal entries but they wouldn't post - interactive (system ocms) vs batch (server map ocms)
*Test the new environment
- for sure

Good luck.

Sue.

It's rolling along, but when I try to create the ODBC drivers through PLANNER, I am getting an "Add for ODBC source failed". I have sufficient authority. What am I missing?

Never mind. I went "silent" and it went fine...

It's been a while since I worked on the AS/400 but is client access installed on the Deployment server and is it up to date with the same release as your workstations. Also be sure that you PLANNER is fully updated before you make changes to your system. I know at times the planner does not contain all the information the system does because of where certain updates were made, this can mess things up if they don't match because the planner will copy what it has to the system.

Folks correct me if I am way off here!

OCMs per role works fine with 8.10...

Kind of odd...I tried the OCM override by role, and it drove me nuts...when I assigned the override by individual user, it works like a charm.

Thank you everyone for your input.

[ QUOTE ]
Kind of odd...I tried the OCM override by role, and it drove me nuts...when I assigned the override by individual user, it works like a charm.

Thank you everyone for your input.

[/ QUOTE ]

That's interesting - in XE, you could not do security or OCM by role, but you could by Group. In 8.10, groups don't exist and you work with roles and users. Go figure. I guess your "high impact" avitar is appropriate.

Gregg Larkin
JDE System Administrator (CNC) / North America
Praxair, Inc.

We do something similar to this. Instead of a new environment we have put a second copy of F0010 in Control Tables (default is Business Data). We then have OCM mapping for special IDs to F0010 in Control Tables, allowing them to post in the previous period.

It has problems however. We have batch jobs which do the posting, they do not use the previous period F0010 OCM. As a result we have batches going into error trying to post in the wrong period. Our next step is to sit down and re think the requirement.

Gerard,

Why don't they use these OCM? Have you got these mappings defined in both System and Server Map? Or are this jobs run under a different User ID?