Friday, October 28, 2011
Wednesday, October 19, 2011
US Taxes
• A general summary of withholding taxes, including basis of tax, valid calculation methods of each pay type, reciprocity agreements between different taxing jurisdictions, and valid filing statuses.
• Compensation Taxability Reference Charts.
• Taxability status of employee contributions to retirement plans, cafeteria plans (IRS Section 125), dependent care, and flexible spending plans.
• Withholding tax calculation examples. These examples are based on a married employee with two children whose spouse is also employed, unless noted otherwise.
• Tax rate tables.
• General summaries of Social Security and Medicare (FICA) Federal Unemployment Insurance (FUTA), State Unemployment Insurance (SUI), and State Disability Insurance (SDI), including taxable wage base, employer and employee tax rates, and valid calculation methods for each pay type.
• General summaries of Railroad Retirement Taxes, including taxable wage base, employer and employee tax rates, and valid calculations for each pay type.
• Where applicable, general summaries of miscellaneous taxes levied by the taxing jurisdictions.
The following table lists the U.S. taxes detailed:
• Compensation Taxability Reference Charts.
• Taxability status of employee contributions to retirement plans, cafeteria plans (IRS Section 125), dependent care, and flexible spending plans.
• Withholding tax calculation examples. These examples are based on a married employee with two children whose spouse is also employed, unless noted otherwise.
• Tax rate tables.
• General summaries of Social Security and Medicare (FICA) Federal Unemployment Insurance (FUTA), State Unemployment Insurance (SUI), and State Disability Insurance (SDI), including taxable wage base, employer and employee tax rates, and valid calculation methods for each pay type.
• General summaries of Railroad Retirement Taxes, including taxable wage base, employer and employee tax rates, and valid calculations for each pay type.
• Where applicable, general summaries of miscellaneous taxes levied by the taxing jurisdictions.
The following table lists the U.S. taxes detailed:
Monday, October 10, 2011
Peoplecode Facts - Peoplecode information
Order of Execution of PeopleCode Programs
1. PeopleCode event.
2. Within an event, by level order-as determined by the buffer allocation order.
3. For a given field, first record PeopleCode, then component PeopleCode.
WinMessage
WinMessage should not be used in production. It works for browsers running in a Windows
environment, but it is Windows specific. Use it only during development, then remove or comment out the code before putting it into production. WinMessage is supported for compatibility with prior releases of PeopleTools. New application development should use the MessageBox function instead and is supported for
both Unix and Windows operating environments.
Trace Peoplecode
Here are five ways to start a trace:
• The Trace PeopleCode page - PeopleTools, Utilities, Debug, Trace PeopleCode
• Click the link to set a startup trace on your PeopleSoft sign on page.
• Use the Trace utility on Configuration Manager.
• Include the SetTracePC PeopleCode built-in function in a program.
• Append the trace flags in the process definition parameters to trace process running on the process scheduler.
Only two-tier or three-tier development environment applications (such as an Application Engine program being tested from Windows) can be traced using the Configuration Manager trace panel.
Commenting Peoplecode
Both the REM comments and the /* */ style of comments can span multiple lines. However, the
recommended method is to use the latter (/* ... */), since it can span multiple PeopleCode statements and is
therefore more flexible.
Commented text cannot exceed a maximum of 16383 characters.
As of PeopleSoft 8.4 you can use <* and *> to comment out a block of code that includes nested comments.
Use RowSelect to:
• Prevent a row from loading by using the DiscardRow function.
• Stop loading rows into the buffer by using the StopFetching function.
RowSelect PeopleCode is placed on a record field or component record.
Warnings and errors can be placed in RowSelect but will not be displayed to the user and are not used for that purpose in this event.
1. PeopleCode event.
2. Within an event, by level order-as determined by the buffer allocation order.
3. For a given field, first record PeopleCode, then component PeopleCode.
WinMessage
WinMessage should not be used in production. It works for browsers running in a Windows
environment, but it is Windows specific. Use it only during development, then remove or comment out the code before putting it into production. WinMessage is supported for compatibility with prior releases of PeopleTools. New application development should use the MessageBox function instead and is supported for
both Unix and Windows operating environments.
Trace Peoplecode
Here are five ways to start a trace:
• The Trace PeopleCode page - PeopleTools, Utilities, Debug, Trace PeopleCode
• Click the link to set a startup trace on your PeopleSoft sign on page.
• Use the Trace utility on Configuration Manager.
• Include the SetTracePC PeopleCode built-in function in a program.
• Append the trace flags in the process definition parameters to trace process running on the process scheduler.
Only two-tier or three-tier development environment applications (such as an Application Engine program being tested from Windows) can be traced using the Configuration Manager trace panel.
Commenting Peoplecode
Both the REM comments and the /* */ style of comments can span multiple lines. However, the
recommended method is to use the latter (/* ... */), since it can span multiple PeopleCode statements and is
therefore more flexible.
Commented text cannot exceed a maximum of 16383 characters.
As of PeopleSoft 8.4 you can use <* and *> to comment out a block of code that includes nested comments.
Use RowSelect to:
• Prevent a row from loading by using the DiscardRow function.
• Stop loading rows into the buffer by using the StopFetching function.
RowSelect PeopleCode is placed on a record field or component record.
Warnings and errors can be placed in RowSelect but will not be displayed to the user and are not used for that purpose in this event.
Security Sets and Security Access Types
What is Security Set and Security Type ? How they are different ??
Security Set - a grouping of data that is being secured.
The sets differ by the origin of the transaction security data. For example, people of interest without jobs is a separate security set from people with jobs because the transaction data used to secure the access does not come from the JOB record, but from the PER_POI_SCRTY record.
Following the delivered security set
1) DEPT - Department - SJT_DEPT
2) PPLJOB - People with Jobs - SJT_PERSON
3) PPLPOI - People without Jobs - SJT_PERSON
4) PPLUSF - US Federal People with Jobs - SJT_PERSON_USF
5) RSOPN - Recruiting Job Openings. - HRS_SJT_JO
Security Types - SCRTY_TYPE_TBL
Security access types are different ways of securing the data within a security set. Each security set has a number of security access types that you can choose to enable. Among other things, security access types determine:
Security access types are different ways of securing the data within a security set. Each security set has a number of security access types that you can choose to enable. Among other things, security access types determine:
1) The security transaction data.
2) there is data security for future-dated rows.
3) If the access type uses a department security tree.
Few of the Delivered security types
Security set Type Descr Trans. Record TreeDEPT 021 Departments by Tree DEPT_TBL DEPT_SECURITY
DEPT 022 Departments - non Tree DEPT_TBL
Few of the Delivered security types
Security set Type Descr Trans. Record TreeDEPT 021 Departments by Tree DEPT_TBL DEPT_SECURITY
DEPT 022 Departments - non Tree DEPT_TBL
DEPT 023 Departments by Setid DEPT_TBL
PPLJOB 001 Job Department Tree JOB DEPT_SECURITY
PPLJOB 002 Job Location JOB
PPLJOB 003 Job Business Unit JOB
PPLJOB 004 Job Company JOB
How the Security views work
The security views work by joining together the security join tables along with the OPRID of the user accessing the view. All security views share some characteristics both in their structure and their view text.
Each view must include the OPRID as a key field, the keys for the transaction data, and any additional fields that are used as search or list box fields. Most core views also include other fields from the security join record that other views can enter where criteria against.
We are not including ROWSECCLASS as a key in the security views. This is because if we do, then we would have to require a ROWSECCLASS be entered for every OPRID. The reason for this is that when the join to PSOPRDEFN is done behind the scenes, it will put the value of PSOPRCLS into the field returned from PSOPRDEFN.ROWSECCLASS if the ROWSECCLASS is blank. If the PSOPRCLS is also blank, then the OPRID is returned. This makes it impossible to join to the SJT_CLASS_ALL table. Including the ROWSECCLASS as a non-key field in the security view is okay, but does not provide any benefit. You will still find it in some views because it was less risky to leave it there for now.
The core views need to join in PSOPRDEFN, SJT_CLASS_ALL, and the appropriate transaction SJT. For example, for People with Jobs and/or People without Jobs the SJT record is SJT_PERSON.
Each view must include the OPRID as a key field, the keys for the transaction data, and any additional fields that are used as search or list box fields. Most core views also include other fields from the security join record that other views can enter where criteria against.
We are not including ROWSECCLASS as a key in the security views. This is because if we do, then we would have to require a ROWSECCLASS be entered for every OPRID. The reason for this is that when the join to PSOPRDEFN is done behind the scenes, it will put the value of PSOPRCLS into the field returned from PSOPRDEFN.ROWSECCLASS if the ROWSECCLASS is blank. If the PSOPRCLS is also blank, then the OPRID is returned. This makes it impossible to join to the SJT_CLASS_ALL table. Including the ROWSECCLASS as a non-key field in the security view is okay, but does not provide any benefit. You will still find it in some views because it was less risky to leave it there for now.
The core views need to join in PSOPRDEFN, SJT_CLASS_ALL, and the appropriate transaction SJT. For example, for People with Jobs and/or People without Jobs the SJT record is SJT_PERSON.
When Security process should be executed
Refresh SJT_OPR_CLS and Refresh SJT_CLASS_ALL are Security process.
When to execute Refresh SJT_OPR_CLS process
On the Roles - Permission Lists page
• Add a permission list with data permission to a role that is already assigned to one or more users.
• Remove a permission list with data permission from a role that is already assigned to one or more users.
On the User Profile component
Add a row security permission list.
• Delete a row security permission list.
• Add a role with data permission.
• Delete a role with data permission.
• Clone an existing profile that has data permission through roles or a row security permission list.
• Deactivate a user.
You can refresh SJT_OPR_CLS in real-time by using the subscriptions on the USER_PROFILE and ROLE_MAINT messages or on demand using the SCRTY_OPRCLS app
engine process.
Run the Refresh SJT_CLASS_ALL process when
• Add a new department to a department security tree.
• Delete a department from a department security tree.
• Move a department to another parent node in a department security tree.
• Modify a department security tree.
When to execute Refresh SJT_OPR_CLS process
On the Roles - Permission Lists page
• Add a permission list with data permission to a role that is already assigned to one or more users.
• Remove a permission list with data permission from a role that is already assigned to one or more users.
On the User Profile component
Add a row security permission list.
• Delete a row security permission list.
• Add a role with data permission.
• Delete a role with data permission.
• Clone an existing profile that has data permission through roles or a row security permission list.
• Deactivate a user.
You can refresh SJT_OPR_CLS in real-time by using the subscriptions on the USER_PROFILE and ROLE_MAINT messages or on demand using the SCRTY_OPRCLS app
engine process.
Run the Refresh SJT_CLASS_ALL process when
• Add a new department to a department security tree.
• Delete a department from a department security tree.
• Move a department to another parent node in a department security tree.
• Modify a department security tree.
Security Join Tables - SJT Tables in Peoplesoft
There are 2 type of Security Join tables
1)Transaction - Security Join Tables
2)User Side - Security Join Tables
Transaction security definitions are stored in one of the following four SJTs, depending on the kind of transaction data:
• SJT_PERSON (stores person-related transaction data)
• SJT_PERSON_USF (stores person-related transaction data for USF installations)
• SJT_DEPT (stores department-related transaction data)
• HRS_SJT_JO (stores job opening-related transaction data)
User security definitions are stored in the following two SJTs:
• SJT_CLASS_ALL The row security access assigned to a permission list (role-based or row security).
Contains the data permission information for all the permission lists that are given data access on the Security by Dept Tree page or Security by Permission List page.
Stores Data From 1)SCRTY_TBL_DEPT 2)SJT_CLASS
Following are keys
CLASSID , SCRTY_SET_CD , SCRTY_TYPE_CD , SCRTY_KEY1 , SCRTY_KEY2 , SCRTY_KEY3
• SJT_OPR_CLS Which user profiles are assigned which permission lists
Contains the user IDs of people with data permission and the permission lists with data permission that are assigned to them.
Stores Data From
1)PSOPRDEFN
2)PSROLEUSER
3)PSROLECLASS
1)Transaction - Security Join Tables
2)User Side - Security Join Tables
Transaction security definitions are stored in one of the following four SJTs, depending on the kind of transaction data:
• SJT_PERSON (stores person-related transaction data)
• SJT_PERSON_USF (stores person-related transaction data for USF installations)
• SJT_DEPT (stores department-related transaction data)
• HRS_SJT_JO (stores job opening-related transaction data)
User security definitions are stored in the following two SJTs:
• SJT_CLASS_ALL The row security access assigned to a permission list (role-based or row security).
Contains the data permission information for all the permission lists that are given data access on the Security by Dept Tree page or Security by Permission List page.
Stores Data From 1)SCRTY_TBL_DEPT 2)SJT_CLASS
Following are keys
CLASSID , SCRTY_SET_CD , SCRTY_TYPE_CD , SCRTY_KEY1 , SCRTY_KEY2 , SCRTY_KEY3
• SJT_OPR_CLS Which user profiles are assigned which permission lists
Contains the user IDs of people with data permission and the permission lists with data permission that are assigned to them.
Stores Data From
1)PSOPRDEFN
2)PSROLEUSER
3)PSROLECLASS
Subscribe to:
Posts (Atom)