44,39 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
PeopleSoft financial management applications have been recognized as a leading ERP product across a wide range of industries that helps organizations automate their accounting operations, cut costs, and streamline business processes. They offer industry leading solutions for organizations' global needs, however complex they may be.
PeopleSoft Enterprise Financial Management 9.1 Implementation is probably the only learning resource for a novice practitioner, who may otherwise have to rely on thousands of pages of documentation for such a complex ERP system. This book covers all the crucial elements of PeopleSoft Financials—a business processes, configuration, and implementation guide. This is the ideal one-stop resource before entering the world of PeopleSoft implementation.
Beginning with the fundamentals of a generic financial ERP system, this book moves on to basic PeopleSoft concepts and then dives into discussing the individual modules in detail.
You will see how to leverage financial modules such as Billing, Accounts Receivable, Accounts Payable, Asset Management, Expenses, and General Ledger. Dedicated chapters discuss key PeopleSoft features such as application security and commitment control for budgeting. You will learn fundamental ERP concepts such as the chart of accounts, used by organizations for recording and reporting financial transactions, and how to implement them in PeopleSoft through chartfields, business units, and SetIDs.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 482
Veröffentlichungsjahr: 2011
Ähnliche
Table of Contents
Oracle PeopleSoft Enterprise Financial Management 9.1 Implementation
Oracle PeopleSoft Enterprise Financial Management 9.1 Implementation
Copyright © 2011 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: June 2011
Production Reference: 1200611
Published by Packt Publishing Ltd.
32 Lincoln Road
Olton
Birmingham, B27 6PA, UK.
ISBN 978-1-849681-46-9
www.packtpub.com
Cover Image by Dan Anderson (<[email protected]>)
Credits
Author
Ranjeet Yadav
Reviewers
Tim Lin
Jennifer Sharp
Sudharsan Srinivasaraghavan
Acquisition Editor
Dhwani Devater
Development Editor
Neha Mallik
Technical Editors
Aditi Suvarna
Neha Damle
Project Coordinator
Zainab Bagasrawala
Proofreader
Lucy Henson
Indexer
Monica Ajmera Mehta
Graphics
Geetanjali Sawant
Production Coordinator
Melwyn Dsa
Cover Work
Melwyn Dsa
About the Author
Ranjeet Yadav has been working in the IT industry for more than 10 years. He possesses professional experience of more than 8 years as a functional consultant with PeopleSoft finance and supply chain applications. He has worked on PeopleSoft implementations for many world class organizations and performed various roles such as PeopleSoft consultant, Module lead, Finance track lead, and Project manager. Although his entry into the PeopleSoft world was rather accidental, he was quickly impressed by the deep impact such an ERP product can have on an organization's functioning. He finds the challenge of designing solutions for organizations' critical business problems quite exciting.
Ranjeet holds an Electronics Engineering degree and a Post Graduate Diploma in Management with specialization in Information Systems from Indian Institute of Management, Lucknow.
This book would not have been possible without the support of my parents. It was their encouragement and unwavering help through the challenging times that was crucial. It was my wife, Madhavi, who encouraged me to accept the challenge of writing this book. Managing the writing as well as the office job was certainly not easy, but she endured my working late nights and weekends for all these months. I simply wouldn't have been able to proceed without her understanding. I dedicate this book to her.
About the Reviewers
Tim Lin has 14 years' experience of functional and technical ERP systems implementation and support with PeopleSoft, JDE, Taleo, and Saba. He has been involved in all phases of systems delivery including project management, design, development, test, and production rollout and support. He has deep functional HR and Payroll knowledge coupled with strong technical and project management skills.
Tim has implemented complex, high volume HR, and Payroll systems for large Fortune 500 companies including Federal Express, Manpower International, and Fox Entertainment Group. He has been a consultant for 15 years, including six years with Accenture. Currently, he is a Director at Fox Entertainment Group.
Jennifer Sharp has international experience in both the functional and technical sides of I.T. She has worked in the aerospace, government, healthcare, hospitality, pharmaceutical, and retail industries; specifically as a Project Manager, System Administrator, Technical Writer, QA Tester, IS Analyst, and creating web-based training.
She has worked for the State of Indiana, Eli Lilly and Company, Eli Lilly UK, Lockheed Martin, and Orlando Health.
For further information, please visit her website at www.jennifersharponline.com.
I would like to thank Nathan, Logan, and Archer for their support and inspiration.
Retail-PeopleSoft Savoir-Faire, this term perfectly fits Sudharsan Srinivasaraghavan. Sudharsan has spent the last eight years with major retail giants of US, helping them to successfully transform business processes, implement new enterprise systems, and in upgrade of large PeopleSoft programs.
He is a Principal Consultant of Enterprise Solutions Practice at a leading Global Technology Services Company. He has close to two decade experience in managing and implementing various ERP applications. He is specialized in PeopleSoft (PS) Financials and Supply Chain Management applications though. Before entering the IT Consulting, he was leading the Accounts Payable, Asset Management, and Corporate Accounts team in a leading Construction Company of India for 6 years.
Sudharsan also presented a paper on PS Maintenance Management in Retail Industry at Oracle Annual Maintenance Summit 2010.
He has earned a Bachelor's degree in Commerce and Accounting, and he is also a Cost Accountant.
Sudharsan and his wife, Lakshmi, have a girl, Varsha. He loves to spend time with his kid.
www.PacktPub.com
Support files, eBooks, discount offers, and more
You might want to visit www.PacktPub.com for support files and downloads related to your book.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and, as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
http://PacktLib.PacktPub.com
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can access, read, and search across Packt's entire library of books.
Why subscribe?
Free access for Packt account holders
If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view nine entirely free books. Simply use your login credentials for immediate access.
Instant updates on new Packt books
Get notified! Find out when new books are published by following @PacktEnterprise on Twitter, or the Packt Enterprise Facebook page.
Preface
PeopleSoft financial applications have been recognized as a leading ERP product across a wide range of industries that help organizations automate their accounting operations, cut costs, and streamline business processes. They offer industry leading solutions for organizations' global needs, however complex they may be.
PeopleSoft Enterprise Financial Management 9.1 is probably the only learning resource for a novice practitioner, who may otherwise have to rely on thousands of pages of documentation for such a complex ERP system. This book covers all the crucial elements of PeopleSoft Financials - core concepts, business processes, and configuration. This is the ideal one stop resource before embarking into the world of PeopleSoft implementation.
Beginning with the fundamentals of a generic financial ERP system, this book moves on to basic PeopleSoft concepts and then dives into discussing the individual modules in detail.
You will see how to leverage financial modules such as Billing, Accounts Receivable, Accounts Payable, Asset Management, Expenses, and General Ledger. Dedicated chapters discuss key PeopleSoft features such as application security and commitment control for budgeting. You will learn fundamental ERP concepts such as chart of accounts, used by organizations for recording and reporting financial transactions and how to implement them in PeopleSoft through chartfields, business units, and SetIDs.
What this book covers
Chapter 1, PeopleSoft Financials Fundamentals, covers important concepts and configurations such as Chart of Accounts and PeopleSoft Chartfields, Business Units, SetIDs, ledgers, and Journals. It also discusses configuring banks, specifying User Preferences, and using the Setup Manager for PeopleSoft implementation.
Chapter 2, PeopleSoft Security, gives an overview of designing user security for PeopleSoft applications. It discusses important concepts such as Permission Lists, Roles, User Profiles, and related configurations. The chapter also discusses Row Level Security and its configurations.
Chapter 3, PeopleSoft Billing module, discusses important steps in the invoice lifecycle, such as manual and automated invoice entry, billing batch processing, and performing invoice adjustments. It also discusses concepts such as Deferred Revenue Processing and Unbilled Revenue Accrual. The chapter also covers critical billing configurations needed to implement the Billing module.
Chapter 4, PeopleSoft Accounts Receivable module, covers important concepts such as pending item accounting and related configurations such as Entry Types and Entry Reasons. It covers steps in the AR business process such as Pending Item Entry, Receivables Update process, Item Maintenance, Aging, Payment Entry, and Payment Application. The chapter also discusses customer correspondence methods such as Customer Statements and Dunning Letters.
Chapter 5, PeopleSoft Asset Management module, discusses important steps in the fixed assets lifecycle such as Asset entry, Depreciation processing, Asset adjustments, Asset retirements, and creating accounting entries. It also covers critical AM configuration steps.
Chapter 6, PeopleSoft Accounts Payable module, covers the voucher lifecycle steps such as Voucher Entry, Voucher Posting, Matching, Voucher maintenance, Paycycles for processing payments and Withholding. It also discusses critical configurations such as Accounting Templates, Voucher Origins, Miscellaneous Charges, and Payment Terms.
Chapter 7, PeopleSoft General Ledger module, covers various journal entry methods such as Journal Generator, Flat file import, and Manual journal entry. It also gives an overview of journal processing steps such as Journal Edit and Journal Post. The chapter discusses concepts such as Interim and Year-end Closing as well as Allocations and related configurations.
Chapter 8, PeopleSoft Expenses module, covers processing of cash advances and expense reports along with importing Expenses data from various external sources. It covers workflow approvals – an integral part of Expenses module along with other critical configurations such as Employee Profiles, Expense Types, and Location Amounts.
Chapter 9, PeopleSoft Commitment Control, explains the basic concepts behind budget control in PeopleSoft financial applications along with relevant critical configurations. It also discusses the entry and processing of budgets and handling of commitment control exceptions.
What you need for this book
PeopleSoft applications are installed on the server by the System Administrator. The installation is a complex task and requires PeopleSoft technical skills. The intended audience for this book will not be performing this task. It is expected that they will refer to an existing demo environment of PeopleSoft applications. However, following steps can be referred to download the application from Oracle's URL. PeopleSoft applications can be downloaded as follows:
Who this book is for
This book is intended for functional implementation analysts planning to work on implementation teams, business analysts who support in-house PeopleSoft applications, and business users who plan to start using PeopleSoft applications.
Conventions
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text are shown as follows: "For example, in BI_ACCT_ENTRY table, the ACCOUNTING_DT field is used to store the accounting date."
New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "The Billing module creates accounting entries for sales invoices for customers."
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or e-mail <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the erratasubmissionform link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
Chapter 1. PeopleSoft Financials Fundamentals
Before we delve into studying the PeopleSoft Financials applications, we need to understand that it is primarily an ERP application, meant to be used as a transaction processing system. Its core philosophy is driven by the need to record, process, and report accounting transactions of an organization.
In this chapter, we'll establish the understanding of core concepts of PeopleSoft applications—such as Chart of Accounts, Business units, SetIDs, Banks, User preferences, and related configurations. We'll also learn how to use an important tool known as Setup Manager, which is used in implementing PeopleSoft applications.
Note that these concepts are not related to a specific module and serve as the foundation for all subsequent modules in this book. A PeopleSoft Financials practitioner must understand these aspects to be able to successfully maintain and implement the applications.
This book relates to the version 9.1 of PeopleSoft applications. As a result, the concepts and screenshots in this book refer to the version 9.1. Some of the screens and basic concepts may be similar to previous PeopleSoft versions.
Understanding Chart of Accounts and chartfields
Any accounting system (be it manual or automated) is built on a structure that determines how the accounting information is recorded (and ultimately reported). Each organization determines the best possible way to capture and classify the vast number of accounting transactions that take place every day. This decision is a combination of two distinct factors:
Let's take a very simple example to better understand this.
Global Vehicles Inc. is an automobile manufacturer, selling vehicles such as passenger cars, commercial vehicles as well as scooters. Its operations are spread across multiple countries. Let's say that its annual sales from all its vehicles are $100 million. The key challenge is to know where exactly these dollars are coming from.
Implementation challenge
Design an accounting system for Global Vehicles, so that it can answer questions like the following:
Did you say, "Just make sure that you record all required pieces of information when each vehicle sale takes place"? You are absolutely right if you did!
One way of recording the sale transactions can be recording the Continent, Country, Productline, Vehiclemodel, and SalePrice. Thus, its sales data for January 2011 may look something like this:
Continent
Country
Product Line
Model
Sale Price
North America
USA
Passenger Car
Alpha
USD 10,000
Europe
France
Scooter
Gamma
FRF 3000
North America
USA
Passenger Car
Theta
USD 30,000
North America
Canada
Passenger Car
Theta
CAD 33,000
North America
USA
Scooter
Gamma
USD 2,000
Europe
UK
Commercial
Zeta
GBP 40,000
As you can see, one can certainly answer the above questions if your accounting system can record all these attributes for each transaction.
Now let's go one step further. Say Global Vehicles has about 100 dealerships in the USA and wants to know the sales performance for each dealership. How can we address this additional requirement? Simple, by recording the dealership as an additional attribute for all the sales transactions.
You probably realize now that designing the structure of accounting information to be recorded is driven by how you wish to use the data. This structure (collection of all required attributes) is known as the Chart of Accounts (COA). All the attributes in COA are termed Chartfields in PeopleSoft parlance.
You would also be able to appreciate that the number of chartfields that an organization needs, depends on its business requirements. Having few chartfields will make the recording process simpler, but will not offer much insight into the recorded accounting data. On the other hand, having more chartfields will give a more meaningful picture of the accounting transactions, but at the cost of system performance. A PeopleSoft practitioner needs to balance an organization's reporting requirements and ease of use before recommending appropriate Chart of Accounts.
PeopleSoft chartfields
PeopleSoft Financial applications offer the following 25 chartfields:
Chartfield
Length
Comments
Account
10
This is a mandatory chartfield used to record corporate accounts and cannot be used for any other attribute. For example, an organization may use account # 100000 to record fuel expenses, while account # 200000 is used to record salary expenses for employees.
Alternate Account
10
This chartfield is used only for statutory reporting to further classify accounting transactions.
Operating Unit
8
Fund Code
5
Used primarily in education and government accounting systems.
Department
10
Program Code
5
Class Field
5
Budget Reference
8
Product
6
Project Costing Business Unit
5
Used if Project Costing module is implemented to track projects related details.
Project ID / Grant
15
Used to track projects related details in Project Costing module.
Activity
15
Used to track projects related details in Project Costing module.
Source Type
5
Used to track projects related details in Project Costing module.
Category
5
Used to track projects related details in Project Costing module.
Subcategory
5
Used to track projects related details in Project Costing module.
Chartfield 1
10
Additional delivered chartfield by PeopleSoft. Activate it (and relabel if needed) to use.
Chartfield 2
10
Additional delivered chartfield by PeopleSoft. Activate it (and relabel if needed) to use.
Chartfield 3
10
Additional delivered chartfield by PeopleSoft. Activate it (and relabel if needed) to use.
Affiliate
5
Used for inter-unit transactions (transactions between 2 different business units) if only a single inter-unit account is used. This chartfield cannot be used for any other purpose.
Fund Affiliate
10
Used for intra unit transactions (transactions between two separate Funds belonging to the same business unit) if only a single intra unit account is used. This chartfield cannot be used for any other purpose.
Operating Unit Affiliate
10
Used for intra unit transactions (transactions between two separate Operating Units belonging to the same business unit) if only a single intra unit account is used. This chartfield cannot be used for any other purpose.
Scenario
10
Book Code
4
Adjustment Type
4
Statistics Code
Note that some chartfields (such as Account, Alternate Account, Project Costing Business Unit, Affiliate chartfields) are reserved for specific purposes and cannot be used to record any value other than its intended purpose. For example, the Account chartfield has to be used only to record corporate accounts used in accounting. However, there are no limitations on the use of other chartfields. Thus, it is not necessary that the Product chartfield has to be used to record a product. You can very well use it to record any attribute such as 'Country' or 'Continent' in the COA example discussed earlier.
Chartfield configuration
As you can see, the given set of PeopleSoft chartfields may not really satisfy the organization's implementation requirements. This can be due to following factors:
To achieve this, you need to perform chartfield configuration activities.
Tip
Expert tip:
As far as the number of required chartfields is concerned, always think of your system's future requirements. Remember, it is extremely complicated to add a new chartfield to the COA if the system already has data using the old COA. If you think there is a possibility of new chartfield requirements down the line, include them in your COA even if you may not use them. You can simply keep it blank until the time it is needed.
Standard chartfield configuration
The following operations can be performed on PeopleSoft delivered chartfields using standard configuration:
Follow this navigation to perform standard chartfield configuration:
Setup Financials/Supply Chain|Common definitions|Design chartfields|Configure|Standard configuration
The following screenshot shows the partial StandardChartfieldConfiguration page:
The next screenshot shows a part of the bottom half of the page:
In the COA example for Global Vehicles discussed earlier, we need to record the following attributes: Continent, Country, Product Line, and Model. Also, we anticipate that a new chartfield may be required in future to record 'Dealership'. Thus we need five chartfields for the COA (in addition to the Account chartfield). As you can see, PeopleSoft doesn't offer any chartfield by these names.
Therefore, we need to perform the following configuration activities:
Let's say that we decide to use following chartfields for our example (based on the available chartfield lengths):
Required Chartfield
PeopleSoft Chartfield
Continent
Operating Unit
Country
Fund Code
Product Line
Department
Model
Budget Reference
Dealership
Product
Account
Account
To activate any chartfield that is inactive, select the checkbox next to it and click the Activate button:
Advanced chartfield configuration
The following operations can be performed on chartfields using advanced chartfield configuration:
Note that these changes have quite a wide impact on the PeopleSoft system, compared to standard configuration.
Follow this navigation to perform advanced chartfield configuration:
Setup Financials/Supply Chain|Common definitions|Design chartfields|Configure|Advanced configuration
The following screenshot shows the Advanced Chartfield Configuration page:
Tip
Expert tip:
Advanced chartfield configuration is not advised by PeopleSoft. Always try to achieve the desired result by its corresponding action in standard configuration.
Activate an inactive ChartField instead of adding a new ChartField.
Inactivate a ChartField instead of deleting it.
Change the display length rather than the actual field length when reducing the size of a ChartField.
Relabel a ChartField instead of renaming it.
Understanding Business Units and SetID
An ERP system like PeopleSoft financial applications needs to record and store enormous amounts of data. We need to understand the types of data that the system generates before getting into how it is done. Business Units and SetID form the basic structure of how the system records and accesses this data.
In PeopleSoft architecture, the data are categorized into the following two types:
As you can see, amount of transaction data in a table that stores them, will keep on changing frequently as new transactions take place.
Master (Setup) data: These are the data elements that are needed to enable the system to perform its business transactions. For example, Global Vehicles may have a group of vendors from whom it buys components for its vehicles. It also may have a group of banks where it holds its bank accounts for its financial transactions.What key differences do you see between such master data and the transaction data elements?
The first (and somewhat obvious) is the dynamic nature of transaction data. As we saw earlier, the number of sales invoices will always keep changing from day to day. On the other hand, how frequently can we expect changes in the number of vendors? True, there will be additions or deletions of vendors, but these changes will be far less compared to transaction data.
The second difference relates to the purpose of these types of data. Master data is needed to perform regular business transactions. For example, a vendor needs to be set up in the system before we can create a purchase order (a business transaction) to buy something from it. Similarly, we need to set up rules to calculate discount before we can create a sales invoice and decide how much discount can be given to a customer.
The third key difference lies in the way these data elements can be shared or need to be separated from each other. Let's assume that Global Vehicles' business has been structured by geography. Thus, it has following operating divisions: North America, Europe, and Asia.
Now let's consider the master data first. Is it possible that all these divisions can have a common vendor or bank? The answer is yes—a single vendor can sell car seats or tires to all the divisions. Similarly, a bank with a global presence can offer banking services to all these divisions. Thus, theoretically, master data can be shared by various groups within the organizations. Note that the master data doesn't always have to be shared, but can be if needed.
Let's consider the transaction data now. When the European division sells a car, can this transaction (sales invoice) be claimed (in other words, shared) by other divisions? The answer is no—the system must segregate sales invoices of Europe from those of North America and Asia divisions, in order to keep a track of them and ultimately report on the sales performance of each.
Thus, while master data can be shared, transaction data belonging to organizational units must be segregated by the system.
Business Unit
In PeopleSoft parlance, Business Unit is the organizational unit. It can be any entity that needs to maintain its account balances separately from each other for reporting. In the previous examples, we can say that Europe, North America, and Asia will be the business units of the organization.
However, if Global Vehicles wants to be structured by its line of business, we can create the following Business Units: Passenger car, Commercial vehicles, and Two wheelers. Note that transaction data tables will always have Business Unit as their primary key (to identify where they belong to). In other words, sales invoices, purchase orders, accounting journals, and so on are segregated by the Business Unit.
Business Unit configuration needs to be done for each module that is to be implemented. For example, to implement Accounts Payable and General Ledger modules, the Passenger Car BU needs to be configured for both the modules.
Tip
PeopleSoft recommends using BU names that are five characters long. Any BU names having less than five characters can affect the system performance.
Tableset ID
Tableset ID (or SetID, as it is commonly known) is used to segregate the master data. Depending on how we want to group the master data, an appropriate number of SetIDs are created. It is the SetID that determines which Business Unit can access which master data elements. This is a two step process:
Scenario 1
Assume that there are five suppliers (or vendors in PeopleSoft terms) for Global Vehicles. All these vendors need to be used by all its Business Units.
As all the master data elements (vendors) are going to be used by everybody, there is a need for only a single group (SetID) of vendors. Let's call this SetID 'GLOVH'. The Vendor table will contain the data as follows:
SetID (Primary Key)
Vendor ID
GLOVH
VENDOR1
GLOVH
VENDOR2
GLOVH
VENDOR3
GLOVH
VENDOR4
GLOVH
VENDOR5
Tip
SetID names should be only five characters long.
Now, we need to specify which rows of master data can be accessed by each Business Unit.
Business Unit
Master data table
SetID to be accessed
Passanger Car
VENDOR
GLOVH
Commercial Vehicles
VENDOR
GLOVH
Two wheelers
VENDOR
GLOVH
Thus, each BU can now access master data defined under 'GLOVH' SetID from the Vendor table.
Scenario 2
Vendors 1 and 2 should be accessible only by Passenger Car BU, Vendors 3 and 4 should be accessible only by the Commercial Vehicles BU, while Two wheelers BU should have access only to Vendor 5.
Now we need three distinct groups of vendors. In other words, we need three SetIDs. Let's see how the data will be grouped in the Vendor table:
SetID (Primary Key)
Vendor ID
GROUP1
VENDOR1
GROUP1
VENDOR2
GROUP2
VENDOR3
GROUP2
VENDOR4
GROUP3
VENDOR5
And finally, let's specify which BU can access which data rows under Vendor table:
Business Unit
Master data table
SetID to be accessed
Passanger car
VENDOR
GROUP1
Commercial vehicles
VENDOR
GROUP2
Two wheelers
VENDOR
GROUP3
Configuring SetID
Follow this navigation to configure SetID:
PeopleTools|Utilities|Administration|TableSet IDs
The next screenshot shows the TableSet ID page, where we need to configure the new value:
Configuring TableSet Control
TableSet Control determines which master data rows can be accessed by a BU. We saw how to do this in the previous illustration. In reality, due to the very high number of data tables, this access is given for a group of tables, rather than a single data table. Let's take a look at how this is configured.
Follow this navigation to configure Tableset Control:
PeopleTools|Utilities|Administration|TableSet Control
The next screenshot shows the TableSet Control page for a Business Unit US001:
As you can see, the BU US001 can access all master data rows defined under SetID GLOVH in the group of records AM_19. Note that this record group contains the Vendor table among others. For other record groups, US001 will be to access master data values defined under a different SetID called SHARE.
Understanding accounting structure—Ledgers and Journals
The following illustration depicts a high level view of accounting entry creation and processing in PeopleSoft financial applications:
As you can observe, this illustration gives an overview of how different modules, such as Billing, Accounts Receivable, Accounts Payable, Asset Management, Expenses (also known as sub-modules or sub-systems) are integrated with General Ledger module. Each module creates accounting entries for business transactions that take place. For example, the Billing module creates accounting entries for sales invoices for customers; the AssetManagement module creates accounting entries for fixed asset addition and depreciation activities, while the Expenses module creates accounting entries for each employee expense report that is processed. Note that these are just a few sample examples. We'll discuss the details of business transactions in respective chapters.
Once the accounting entries are created by a module, a batch process known as 'Journal Generator' performs subsequent activities. Note that Journal Generator process can create accounting journals from accounting entries generated by external non-PeopleSoft systems as well. It performs three critical tasks as part of the journal processing lifecycle:
Let's consider a simple example to understand this process. Assume that an organization uses following accounts with hypothetical General Ledger balances:
Account
Description
Balance Type
Balance Amount
100000
Trade Receivables
Debit
$50000
200000
Customer sales
Credit
-$150000
Tip
'DR' denotes a 'Debit' transaction, while 'CR' denotes a 'Credit' transaction. PeopleSoft applications always denote credit amounts by a negative sign.
Now let's say that 4 new sales invoices – for $1000, $1500, $2000 and $2500 - are created in the Billing module on a particular day. As part of the invoice processing, the following accounting entries are created:
Invoice ID
Type
Account
Amount
INVOICE1
DR
100000
$1000
CR
200000
- $1000
INVOICE2
DR
100000
$1500
CR
200000
- $1500
INVOICE3
DR
100000
$2000
CR
200000
- $2000
INVOICE4
DR
100000
$2500
CR
200000
- $2500
Each PeopleSoft module has a dedicated table to store these accounting entries. For Billing, above entries are stored in a table 'BI_ACCT_ENTRY'. Now these entries are ready to be processed by the Journal Generator process.
These entries are then consolidated into a journal as follows:
Journal ID
Type
Account
Amount
JOURNAL1
DR
100000
$7000
CR
200000
- $7000
Let's assume that the Journal edit process successfully validates this journal by ensuring that debit and credit totals in the journal are equal. If successfully validated, it marks the journal to be picked by the Journal Post process. Now the Journal Post process picks up this journal and posts these amounts to the appropriate accounts in General Ledger.
Thus, after this journal is posted, the final account balances will be updated as follows:
Account
Description
Balance type
Balance amount
100000
Trade Receivables
Debit
$57000 (50000+7000)
200000
Customer sales
Credit
-$157000 (150000+7000)
Configuring ledgers and Journal Generator
A typical PeopleSoft financials implementation requires the following configuration activities:
As discussed earlier, PeopleSoft ledgers record posted net balances for a set of chartfield values (depending on how many chartfields are activated in the configuration) for each accounting period (such as month) and fiscal year.
A Ledger Template can be considered to be a framework of a ledger's attributes. Rather than using a ledger template for an individual ledger, it is linked to a Ledger Group. As a result, a ledger template applies to all the ledgers in a group. It essentially specifies various records and fields for a ledger that the system needs to report from.
Usually multiple ledgers are clubbed in a LedgerGroup. We'll discuss the need for having multiple ledgers in a ledger group in the chapter for General Ledger. For the time being, let's just note that a ledger group can have one primary ledger and (if needed) up to nine secondary ledgers.
Configuring ledger templates
Follow this navigation to configure ledger templates:
GeneralLedger|Ledgers|Templates
The following screenshot shows a part of the Ledger Template page.
The following screenshot shows the remaining bottom portion of the Ledger Template page:
PeopleSoft delivers several default ledger templates (such as Commitment control ledgers, Standard ledgers, Average Daily Balance ledgers, and so on).
The preceding screenshot shows the ledger template used for standard detail ledgers. Each field in this screen refers to a table used for a specific purpose. Most of the fields in this definition here are used by background processes and do not affect the user transactions.
For a typical implementation, you need not change these default templates. However, we'll discuss a few important fields:
Tip
Expert tip:
The given tables are extremely important in the sense that majority of General Ledger processing is based on them. These tables are used by various batch processes; hence such changes have a large impact requiring many code changes. To the extent possible, avoid making changes to delivered table values. Any changes to the delivered table values in ledger template need to be very carefully analyzed. In the rare event that these values are changed, all the journal processes need to be thoroughly tested to ensure that they are not impacted by these changes.
Click the FieldDefinitions tab to see default field values populated by the system. These defaults are dependent upon the Default Ledger Type value in the previous tab.
The following screenshot shows the details of FieldDefinitions tab:
Implementation challenge
Corporate headquarters of Global Vehicles Inc. is located in the USA. Design a ledger structure to maintain its accounts and report the financial statements in USD. At the same time, it should be able to maintain all accounts in Euros and British Pounds (GBP) for internal reporting.
Solution
For the sake of simplification, we'll assume that COA for reporting in all currencies is the same. This can be achieved by maintaining three separate ledgers – one for USD balances, one for GBP balances and another for Euro balances. PeopleSoft General Ledger allows this flexibility to automatically post the journals simultaneously to multiple ledgers. We'll configure these three ledgers (named GLOBALUSD, GLOBALGBP, and GLOBALEUR respectively) and include them in a ledger group for the business unit. Let's see how to do it.
Configuring ledgers
Follow this navigation to configure ledgers: General Ledger | Ledgers | Detail Ledgers
The following screenshot shows the DetailLedgers page:
Note
Note that ledgers being master data elements (which can be shared by different Business Units) are defined by SetID. As we discussed earlier, a ledger needs to be linked to a ledger template. Thus, it inherits all the attributes that are defined for a ledger template.
Now our ledger is almost ready to start recording the accounting balances. The system knows which database tables and fields to refer to in order to update data from journals or retrieve data for reporting…all courtesy of the ledger template!
Configuring ledger groups
Follow this navigation to configure ledger groups:
General Ledger | Ledgers | Ledger groups
Ledger group configuration serves multiple objectives: Grouping multiple ledgers in a similar group (we'll see why we need to do this), specifying the edit tables for the relevant chartfields being used in the ledger, and specifying chartfield balancing options. Let's see each of these important functions in detail now.
We'll call our ledger group GLOBAL.
The Definition tab in the following screenshot , is where we can include multiple ledgers in a group:
We already saw why we need three different ledgers—to address different currency reporting requirements.
Having multiple currency requirements is just one of the possible reasons we need to define multiple ledgers in a group. Commitment control ledgers groups typically have multiple ledgers. We'll discuss them in detail in the Chapter 9, PeopleSoft Commitment Control.
When there are multiple ledgers in a ledger group, one ledger needs to be designated as the primary ledger, while the others are designated as secondary ledgers. PeopleSoft allows up to nine secondary ledgers in a ledger group. In other words, there can be a maximum of 10 ledgers in a group. Remember, it is not mandatory to always define secondary ledgers. If an organization has very straightforward reporting requirements, they can be addressed by a single primary ledger.
Now let's discuss the important fields that you see on the Definition tab:
The following screenshot shows the Chartfield tab. It is used to specify the edit tables for each chartfield being used by this ledger group:
The next tab on this page - Balancing - in the following screenshot, determines how the accounting entries are balanced:
Let's first understand the concept of balancing.
A sample journal entry looks something like this:
BU
Account
Dept
Op Unit
Product
DR/CR
Amount
US001
123000
455
CPG
INT40
DR
$4500
US001
258000
155
TAX
INT40
DR
$1500
US001
215000
455
CPG
INT40
CR
-$6000
What is the most obvious thing about this accounting entry? Of course, the sum of debit and credit lines is equal. In other words, it is 'balanced'. Now can you say that debit and credit amounts are equal for each of the chartfields?
For BU US001 and Product value INT40, this is true. On the other hand, for Account, Department, and Operating Unit, accounting entries are not balanced.
Note that, no matter what happens, accounting entries have to be balanced for each Business Unit. However, if an organization maintains its balances for each Department or Operating Unit (or any other chartfield), then account balances have to be balanced for that chartfield as well.
The Balancing tab determines the chartfields by which the accounting entries must balance. Business Unit is always selected, while Account and Alternate Account are always excluded from balanced chartfields (in accounting terms, as an account can have only debit or credit balance, entries can never balance for an account). If an organization requires that, its entries should be balanced by additional chartfields, (Operating Unit, for example) the Balance checkbox should be selected for that chartfield. This is necessary when reporting needs to be performed by the Operating Unit.
The Journal Edit process ensures that for any journal, its accounting entries are balanced by the chartfields specified here. So, in the previous example (with entries balanced by BU and Operating Unit), our sample accounting entry would have been flagged as invalid since Operating Unit is not in balance.
Configuring ledgers for a Business Unit
Now that we have built the basic accounting structure in terms of ledgers, ledger groups, and templates, our PeopleSoft system is ready to record accounting balances. The last step is to link required ledgers to a General Ledger Business Unit.
Note that a GL BU can not only have multiple ledgers (or ledger groups) associated with it, but it can also have ledgers belonging to different types. It is possible that a BU may need to have a ledger group to maintain its budgets, another to record its accounting transactions. It also may have 2 different ledger groups to record transactions in different currencies. How many ledgers (and what types) are needed by a BU is entirely driven by the organization's processing and reporting requirements.
In addition to assigning ledgers/ledger groups to a GL BU, we also configure various processing options.
Follow the navigation to assign ledgers for a BU:
Set Up Financials/Supply Chain | Business Unit Related | General Ledger | Ledgers For a Unit
The following screenshot shows the Definition tab of the page. This is where we select ledgers/ledger groups for a BU:
There are three types of ledgers that can be selected here: Detail ledgers, Summary ledger, and Commitment control ledger. In a nutshell, detail ledgers are used to record actual accounting transactions. Summary ledgers on the other hand record only summarized versions of detailed accounting transactions. Commitment control ledgers record control budgets. We'll discuss the commitment control in greater details in Chapter 9, PeopleSoft Commitment Control.
Let's discuss some of the important fields in this tab:
The following screenshot shows the next JournalEditOptions tab. This tab specifies how journal errors should be handled by the system:
Available error processing options are as follows:
The next tab on the page - CurrencyOptions– is shown in the following screenshot:
This tab specifies the default currency options for the given GL BU and the given ledger.
The next tab on the Ledgers for a Unit page is JournalPost. The next screenshot shows details of this tab:
The configuration options on this tab control the posting and unposting of the journals for this ledger group:
The following screenshot shows the next ApprovalOptions tab. The configuration options on this tab control the journal approval workflow process:
Based on organization's requirements, we can specify one of the following three options:
PeopleSoft offers two different workflow methods – Virtual
