Process Data and Where Do You Set It / Journal Edit Fails for Some Ledger Groups

Set up Financials/ Supply Chain> Business Unit relate>General Ledger, Open Periods> Open Period Update.

Set up Financials/Supply Chain>Business Unit Related> General Ledger> General Ledger Definition Second page…is process date filled in?
change it to a valid date per the detail calendar being used.

When the process tried to used that date as the posting date, it failed edit agains the open periods/calendar set up. The errors received includedNo fiscal year and accounting period is defined in the calendar for the journal date, The journal date is not in an open period of this ledger, Adjustment period is not open.

To explain where Process date gets set refer to chapter 3 of the GL peoplebooks.
On the journal processing options of the General ledger definition page.
Setting up Financials/Supply Chain, Business Unit Related, General Ledger, General Ledger Definition, Second page- Journal processing options. You can define the process date or define it to come from the open period from /and or open period to dates.

Journal Process Date
Specify how processes determine the process date for journals. The Journal Post (GLPPPOST) and Journal Generator (FSPGJGEN) processes and many other general ledger processes support the use of the Process Date option. Valid values are:

Current Date: For general ledger processes that use Process Date in their run controls, select this option to use the date at the time that the batch process runs.

Process Date: Use a date that you specify in the next field for all journals in the batch. The system only permits you to enter a working calendar day. Before you run any processes that use a process date, you can use the Maintain GL BU Process Date (maintain general ledger business process date) process to perform a mass update of the journal process date. You can run this process for an individual business unit, a range of business units, or all business units.

Process Date
Specify a process date.

Journal Date Open To Date
When the journal date is greater than the open to date, choose to either recycle the journal or to change the journal date to the open to date.

Allow Different Unpost Date
Select to enable users to specify an unpost date for a posted journal. This date becomes the journal date for the unpost journal when the original journal is unposted. The unposting journal carries its original journal date in the UNPOST_JRNL_DATE field. The default is not to allow unpost dates. Related journals:

For interunit journals, users cannot change an unpost date if any of the business units are not enabled for this. Otherwise, all journals in the set use the user-specified date.

For suspense correction journals, the system uses the same date as the base journal.

For reversals, the system uses the original journal date unless the period is closed. There is a runtime option for reversal journal date in the event that the origina

Process Server Definition

Sleep Time : The Process Server Agent is a demon program that runs in the background on the server. We do not want it to work continuously hence specify the sleep time. When it wakes up, it checks to see if any processes have been queued in the Process Request table.
e.g. : If you set Sleep Time to 15 seconds and no process is queued, it will wake up every 15 seconds to look for work. If it finds some work it will process all that’s possible in 15 seconds and go back to sleep. If the work isn’t completed it will continue from the point which it left and work on it for the next 15 seconds and go back to sleep. This process continues till the Process Server Agent is shut down. Typically you wouldn’t set Sleep Time any lower than 10 seconds which is almost like real-time. We generally recommend 30-60 seconds for most PeopleSoft applications. The maximum sleep time is 9,999 seconds, about two hours and twenty-six minutes.

Heartbeat : The Process Server Agent needs to track server status-running, down, or suspended. Every time it checks the server status it updates the LAST_UPD_DTTM field in the PS_SERVERDEFN table with the current date and time of the database engine. This prevents the database from accepting more than one Process Server Agent with the same name on one or multiple servers.

Each process defined is either API aware or API unaware. An API aware process is able to update its process status. An API unaware process does not have any defined program interface to Process Scheduler. e.g. WINWORD.EXE.
To make COBOL and SQR processes API aware, use the standard API code provided by PeopleSoft. Crystal processes have API built into PSCRRUN.EXE. The API code updates the Process Scheduler the process’ runstatus, completion code, message set, and message number. The API call is given just before it COMMITs processing.
If an error is encountered in the process, the code performs the rollback and updates the runstatus to “unsuccessful,” COMMITs this update and then terminates.

Note: As the processes within a job have to notify the server of the runstatus when complete, the processes in the Job Definitions have to be API aware processes are allowed in Job Definitions. This is how the decision is made to continue with the next job process.

Max API Aware : Maximum number of Application Program Interface (API) aware tasks running concurrently.

Max API Unaware : Maximum number of non Application Program Interface aware tasks running concurrently

Days Before Purge : Every time to start the Process Server Agent it checks the Process Request table for processes (this server or client-based) with the status of Cancelled, Delete, or Success.

If the Days Before Purge > Today’s Date = Completed date the entry is physically deleted from the request table.

Operating System : Name of the appropriate operating system for this server (UNIX, VMS, DB2 etc.)

Process Class : Specify all the different Process Classes that you can run on this server. A process class is assigned to a process in Process Definition. If the Process Class for the process being run does not exists here it will result in processes remaining queued on the server.

Priority : (High, Medium, or Low) Used to prioritize all processes queued to run on a given server.

Max Concurrent : It is very similar to Max API Aware except that it controls how many processes of a particular process class may run concurrently on the server.

Master Scheduler, Recurrence Scheduled JobSets Showing Duplicate Entries

In PeopleTools 8.4x Process Scheduler shows duplicate entries when scheduled JobSets are launched with recurrence without the use of a Master Scheduler.

For problem cause read details below from :
PeopleBooks Library > PeopleSoft Process Scheduler > Managing PeopleSoft Process Scheduler

Master Scheduler is an optional server that enables you to distribute workload across multiple Process Schedulers. However, in the following conditions, a Master Scheduler is required

Condition : Primary Operating System is UNIX or OS390.
Reason : When a PSJob is scheduled through the Process Request page and no specific server is specified, the system assigns the PSJob to the primary operating system. When a PSJob item must run exclusively from Windows NT/2000 (for example, Crystal, PS/nVision, or Cube Builder), Master Scheduler Server is required to redirect the PSJob item to PeopleSoft Process Scheduler on Windows NT/2000.

Condition : You schedule job for which job items must run in different operating system.
Reason : It is possible to have one job item run in PeopleSoft Process Scheduler on UNIX, and have the remaining items run in Process Scheduler on Windows NT/2000.

Condition : You schedule a job that is set up in the Schedule JobSet definition with items set to run on different servers.
Reason : In the Schedule JobSet definition, there are options where you can specify to have items run either on a specific PeopleSoft Process Scheduler Server or on a specific operating system. For example, UNIX or OS390.

Condition : You enable the load balancing option.
Reason : When a machine goes down, Master Scheduler can transfer queued requests assigned to the PeopleSoft Process Scheduler Server on a downed machine to a PeopleSoft Process Scheduler Server started on another machine.

When multiple PeopleSoft Process Scheduler servers are brought up for the same database, each server is responsible for creating its own workload by querying the Process Request table. The servers attempt to schedule requests that are specified to run either on that specific server or on any server. If a request is set to run on any server, it’s possible for more than one server to attempt to schedule the same request. To work around this, specify a specific server through the Process Request page. However, this becomes disadvantageous if the specified server goes down. This request remains queued until the PeopleSoft Process Scheduler Server is brought up again.
The Master Scheduler resolves this by becoming the central point for querying the Process Request table. When a Master Scheduler is available, all active PeopleSoft Process Scheduler Servers switch into a remote server mode. Master Scheduler registers and monitors any active remote servers.

Create a Master Scheduler: A Master Scheduler is an optional server process. To implement select one of your process schedulers and have it boot the master scheduler. There can be only one master scheduler per database.
Take the following steps.
1. In PSADMIN choose to configure a process scheduler server.
2. Answer YES to the shutdown question.
The following prompts appear :
3. Do you want to change any config values (y/n)? [n]:n
4. Do you want the Application Engines configured (y/n)? [y]: n
5. Do you want the Master Scheduler configured (y/n)? [n]: y
6. Do you want the Optimization Engines configured (y/n)? [n]: n
Configuration file successfully created.
8 Now boot the server. You should see 1 new process extra started, (probably named PSMSTPRC).

Those are the necessary steps to implement a Master Scheduler.
Remember that there can be only one Master Scheduler per database.

Limiting Access to Process Monitor to Individual Users

First there are a few key things to keep in mind.

1) The Process Profile permission list is assigned directly to the user profile on the user Profile General tab, and ONLY the profile is controlled by this permission list. Process groups are controlled through the permission lists assigned to the user through their roles.

2) Remember, the process profile permissions are based on the profile permission list of the user who is submitting the process, not the user viewing the process monitor. Therefore, if a user has a profile that allows “View by ALL” and “Update by ALL”, then all users will be able to see the processes submitted by this user in the process monitor.

3) If you want to find out what Process Profile Permission lists you currently have assigned to user profiles you can run the following SQL:

SELECT OPRID, PRCSPRFLCLS FROM PSOPRDEFN

This will give you a list of all users with their Process profile Permission List. Or you can run the following SQL to get a list of all the permission lists you are using as Process profile permission lists.

SELECT DISTINCT PRCSPRFLCLS FROM PSOPRDEFN

This is documented in PeopleBooks how the Process Profile Permission List works. However prior to PeopleBooks 8.45 it is documented incorrectly. Below is how it should be stated:

Home > PeopleBooks Library > PeopleTools Security > Working With Permission Lists > Setting Process Permissions

Process Profile Permissions

Allow Process Request

These options apply to using PeopleSoft Process Monitor. You can restrict which users are permitted to view or update a given process, based on the user who launched (and owns) the process. You can specify restrictions as follows:

View by.

Specify who can view processes that are launched by users who have this permission list assigned as their process profile permission list on the User Profile – General page. Select from the following options:

Owner: For a process that’s launched by a user who has this process profile permission list assigned, only the user who launched the process can view it.

All: All users can view processes that are launched by a user who has this process profile permission list assigned.

None: No one can view processes that are launched by a user who has this process profile permission list assigned.

Update By.

Specify who can update the status of processes that are launched by users who have this permission list assigned as their process profile permission list on the User Profile – General page. For example, you decide whether users can restart or cancel a request.

Note. Updates are made using the PeopleSoft Process Monitor Process Detail page in the Update Process component.

Select from the following options:

Owner: For a process that’s launched by a user who has this process profile permission list assigned, only the user who launched the process can update it.

For example, nobody else can restart a request that this user submitted. However, this user might still be able to update another user’s processes.

All: All users can update processes that are launched by a user who has this process profile permission list assigned.

None: No one can update processes that are launched by a user who has this process profile permission list assigned.

Note. Be careful as you grant update authority to submitted processes. An inexperienced user can easily disrupt batch processing by deleting or holding processes. This is especially true with restarting processes. If a program is not coded for a restart, then users should not be able to restart it. Restarting a program that is not properly coded to acknowledge the previous program run can threaten data integrity. Remember, the process profile permissions are based on the profile of the user who is submitting the process, not the user viewing the process monitor.

Launch Application Engine from Command LIne or Shortcut

Create Shortcut to Run Application Engine

Create Process Type Definition, Override the %%PRCSNAME%% with %%RUNCNTLID%%, so you can ad-hockly run programs you are developing without each having to have its own Process Definition – which you’d want once this goes into production. So, you need a New Process Type Definition, lets say you create one called AppEngineGenericTestType.

The Parameter List string should read;
-CT %%DBTYPE%% -CD %%DBNAME%% -CO %%OPRID%% -CP %%OPRPSWD%% -R %%RUNCNTLID%% -I %%INSTANCE%% -AI %%RUNCNTLID%%

Then create a Process Definition called FASTTEST that is associated with this Process Type, can have one for the client and another for a Server. Be sure to associate it with the AE_REQUEST component & TLSALL Process Group, on the Process Defintion options tab, so it can be launched from Go, PeopleTools , Application Engine, Process, Request, Request.

If setting up for a Server, be sure to modify that Server, ie PSUNX and add a row for this new Process Type, AppEngineGenericTestType, and let it run 1 or 3 or however many of concurrent you want.

Then you navigate to Go, PT, AE, Process, Request, Request, Add;

User ID PS
Run Control MYAEPROG
Program name MYAEPROG
Add

Then when the request page opens, select Process Frequency of Always ( so you can repeatedly run this process over and over as you go thru development with it), and then hit the RUN button. Select the Server Name, and FASTTEST, and it will queue up, and because you told the Server about it, it will run, and it will really run an AE program called MYAEPROG using the Process Definition called FASTTEST.

NOTE: This is an unofficial approach to testing that allows a developer, to defer defining a Process Scheduler Process Definition for each Application Engine program while in the Development phase of testing and running an AE. Once testing has been done, Process Definitions, and Run Control Pages should be created specifically for the Developed Application Engine Program.

When using Developer’s Shortcut and the FASTTEST method of testing, you will not get the Redirected Terminal Output (the standard output for the Application Engine program 2-tier). If run via Process Scheduler, there will be no log file generated, because a specific Process Definition for the Application Engine program was not used.

Process Profile, Process Permissions and Process Groups

Permissions Lists for Multiple Process Profiles and Process Groups
Here is some information that will explain how all this works. The Process Profile: (Found on the General Tab of the User Profile)

The Process Profile contains the permissions a user requires for running batch processes through Process Scheduler. For instance, the process profile is where users are authorized to view output, update run locations, restart processes, and so on.

Only the Process Profile comes from this permission lists, not the list process groups.

Process Profile Permissions: (Found on any Permission List under the Process tab)

Process Scheduler security involves more than simply adding a few Process Groups to a Permission List. You also need to specify to what capacity a Role (or set of users) can modify certain Process Scheduler settings. The Process Profile definition determines the default Process Scheduler settings for a user.

This Permission List with the default Process Profile would be assigned directly to the User Profile on the General tab in the field Process Profile as stated above.

For instance, with the Process Profile, you specify such settings as where the system delivers the output of the process, whether the user can update the Process Request. I.E. Workstation Destinations, Server Destinations, OS/390 Job Controls, and
Allow Process Request. Can the user Override Output Destination, Override Server Parameters, View Server Status, Update Server Status, Enable Recurrence Selection, and Run Client Process. (For Client Processes see EXCEPTION below)

Process Group Permissions: (Found on any Permission List under the Process tab)

Process groups are collections of Process Definitions that you create using Process Scheduler. Typically, you group Process Definitions according to work groups within your organization, and only users who belong to a particular workgroup can invoke batch processes included in a specific Process Group. For instance, you may have a set of Process Definitions that relate to your Human Resources department and another set for your Manufacturing department.

Regardless of how you organize your Process Definitions, you must assign process groups to a Permission List. Users can run ONLY those processes, through Process Scheduler, that belong to process groups assigned permission lists that are assigned to the user through their Roles. Not through permission lists assigned directly to the user on the General tab of the user profile.

NOTE:
The above statement is true UNLESS you are trying to run the process through a push-button on an application page and you are seeing the following error message “You do not have authority to initiate the XX process”. Process group permissions do not work unless one process group is attached to the user’s primary permission list. A user must have a primary permission lists with at least one process group permission in order for the application to recognize the existence of process group permissions derived from other permission lists via roles. This is an application specific error. See resolutions at the bottom of this resolution for more details.

Here is the SQL for the tables so you can validate that the users and permission lists actually have the process groups you have assigned to them.

You will need to change the OPRID from PS to the OPRID you have a question about in this statement

select DISTINCT A.ACCESS_GROUP, B.OPRCLASS FROM PS_SCRTY_ACC_GRP A, PSOPRCLS B WHERE OPRID = ‘PS’ AND A.CLASSID = B.OPRCLASS

This is for the permission lists

select * from PSAUTHPRCS order by CLASSID

To define the correct processes to their Process Group (or to create a new Process Group) you need to do this through the Process Scheduler manager > Use > Process Definitions, then select a process and on the Process Definitions options tab you will assign or create the Process Group. (See Resolution 700912 – PT 8.1x Process Scheduler: How to create a new Process Group)

PT 8.4 information: In PeopleTools 8.4x, the Process Profile permission list in the User’s Profile General tab is not working as it should. For the Permission List set up in the Process Profile section, permissions are set up such that the user cannot select or access certain data. However, the user is still able to select and change this data while submitting the request. This is a known issue and is addressed and fixed in PeopleTools 8.44.

More information can be found in PeopleBooks under:

Administration Tools: Security > Working with Permission Lists & User Profiles
OTHER RELATED INFORMATION:
712138 – E-SEC: Users need access to view ONLY to their processes in Process Monitor
713525 – E-PRSC/SEC: Cannot run Client processes on Windows 2000 if User is System
711663 – E-SEC: Not authorized to run Process type ‘xxx’ and process ‘xxx’ (65,8)
716760 – E-SEC: You do not have authority to initiate the XX process (5010, 76)

ProcessSchedulerAdmin ROLE note: This role is the administrative role assigned to the OPRID used to boot the Process Scheduler as documented in PeopleBooks. The ProcessSchedulerAdmin role also has administrative rights to any and all process requests viewed from the Process Monitor so is not a role to grant to just any user. Users with this role may be able to submit any process request from a process request page.

SysAudit Resolutions for 01, 02, 03 and 04

Resolution to PRCSSHED Rows Found in Sysaudit Report

PRCSSCHED-01 SQR-Related Process Definitions (PS_PRCSDEFN) that override the PARMLIST field from the Process Type Definition (PS_PRCSTYPEDEFN)

For the listed processes select Process Scheduler, Processes, Override Options Remove the value assigned to the Parameter List field.
(Note: This PRRSCHED-01 is only meant to be a warning. If the override of the Parameter List specified in the Process Type definition was intentional, then the above action can be bypassed).

PRCSSCHED-02 Process Definitions (PS_PRCSDEFN) where the OUTDESTTYPE should be set to ANY

For the listed processes select Process Scheduler, Processes, Destination. In the Output Destination Options group, set the Type option to Any.

PRCSSCHED-03 Process Definitions (PS_PRCSDEFN) where the OUTDESTTYPE should be set to NONE

For the listed processes select Process Scheduler, Processes, Destination. In the Output Destination Options group, set the Type option to (None).

PRCSSCHED-04 Process Definitions (PS_PRCSDEFN) that should be set to API AWARE.

For the listed processes select Process Scheduler, Processes, Process Definition. Select the checkbox that reads API Aware.

(If the API Aware is not marked, this process will get an incorrect RunStatus when viewed from Process Monitor. For additional information, please refer to the Process Scheduler manual under the ‘Process Scheduler Development’ chapter. In this chapter, additional info can be found in the section ‘Understanding Process Request API Support’.