0 оценок0% нашли этот документ полезным (0 голосов)
99 просмотров4 страницы
Setid indirection is the key to why PeopleSoft has been able to compete at the s ame level as Oracle and SAP. It allows complex organizations to use a single ins tance of the application, versus requiring multiple installs, each set up and co nfigured differently.
Setid indirection is the key to why PeopleSoft has been able to compete at the s ame level as Oracle and SAP. It allows complex organizations to use a single ins tance of the application, versus requiring multiple installs, each set up and co nfigured differently.
Авторское право:
Attribution Non-Commercial (BY-NC)
Доступные форматы
Скачайте в формате TXT, PDF, TXT или читайте онлайн в Scribd
Setid indirection is the key to why PeopleSoft has been able to compete at the s ame level as Oracle and SAP. It allows complex organizations to use a single ins tance of the application, versus requiring multiple installs, each set up and co nfigured differently.
Авторское право:
Attribution Non-Commercial (BY-NC)
Доступные форматы
Скачайте в формате TXT, PDF, TXT или читайте онлайн в Scribd
For something as fundamental as Setid indirection, it s surprising how few people
really understand how it works. Hopefully, this will shed some light on the subj ect. Why, when, and how? Setid indirection is the key to why PeopleSoft has been able to compete at the s ame level as Oracle and SAP. It allows complex organizations to use a single ins tance of the application, versus requiring multiple installs, each set up and co nfigured differently. The Structure definition in Oracle Flexfields is intended to provide similar functionality (but less consistently). Setid indirection was something introduced in PeopleTools 2, and to this day, am azes me that PeopleSoft was able to change something so fundamental in its produ cts after the products were initially released. It s also interesting that the app roach for delivering it was to introduce it as a core component of the toolset, versus creating a standard around it. So, we ve talked about the when and why. Let s talk about the how. The best way to e xplain the purpose of Setid indirection is to look at a complex company as an ex ample. One I like to use is Virgin. This is because it s pretty clear that the com pany has multiple disparate lines of business (and helps explain how it works. So, let s look at the high level structure of Virgin: It has a recording label. It has a series of retail stores. It has an airline. We could also complicate matters by looking at the different countries it operat es in, and some of the requirements there as well, but let s get to that later. So, there are 3 different lines of business. In this example, there are definite ly certain things that need to be different across the different lines of busine ss: There are probably different suppliers with different rules of operation. There are definitely different products that are delivered. There are probably different jobs, jobcodes, and unions. However, in any organization, there are certain things that should be the same ( to provide consistency where needed). There needs to be a common chart of accounts for reporting financial information . There usually needs to be a common fiscal calendar (again to allow consistent re porting of financial information). Therefore, there are aspects of the business that need to be kept separate betwe en lines of business, and aspects that need to be shared across lines of busines s. Now, let s add back in the complication of operating in multiple countries. Becaus e each country has its own regulations and currency, some of those business rule s also need to be segregated between countries, but also need to be shared acros s countries. Enter: the Setid. The Setid is the means by which sets of values are given an identifier. The Seti d is generally the topmost key of any table in a PeopleSoft application that doe s not hold transactions. Setids are managed at the table level (or, actually, at the group of table level). So, in the example of Virgin, you could see the foll owing: One common setid for the set of account numbers used to represent the financials . 3 different setids for the different products sold by each line of business. One way to understand setids is to understand the entities in the application th at use it (i.e. the entities where it makes sense to both segment and share defi nitions across lines of business). These are: Entities that would be dimensions in an OLAP cube. These are things like custome rs, vendors, employees, products, and departments. Business rules that govern how processing is to occur in the application. These are things like payment terms, pay cycles, allocation rules, calendars, and time spans. The other main type of table in a PeopleSoft application is the transaction or d ocument. These entities are keyed by a corollary field, called Business Unit. Yo u could think of the business unit as a set of books in financials, or a discret e instance of a set of transactions that stand on their own for other applicatio ns. Examples of business unit keyed tables are Journals, Ledgers (which are just an aggregation of journals), vouchers, receivables, orders, returns, and cases) . In the OLAP world, tables keyed by business unit are generally facts in the sy stem. So, how to business units and setids relate to each other? Good question. Remember, that transaction tables are keyed by business unit. One could also think of a transaction as any business event that happens in an ERP application that needs to be captured or measured. Therefore, the role of setids is to control either the set of values used for things captured in a given tran saction, or the rules used for processing that transaction. This means that there is a relationship between a business unit, and the sets of values that are used for valid data, or for controlling processing (which are s tored in tables). This is done using the tableset controls (which is accessed in the PeopleTools menu, under the administration sub-menu). The mapping of setids to business units occur with the following levels: There s a level that groups similar tables together into a functional group (calle d record groups). This means that if there are 5 tables for storing or processin g journals, you don t have to map those tables individually, they are assigned a g roup and the mapping is at the group level. There s a level called record group controls, that actually performs the mapping. When setting this up, you first provide a business unit value, and then assign s etids for each record group that would be used for that business unit. The shari ng and segregation occurs when you pick different setids for business units (or the same across business units). This means the following: If you use a single share setid across all business units for your account tables, then all business units will use that common set of values. If you use a setid for recording , one for retail , and one for airline four your produ t tables, then whichever business units you assign the airline setid will share a common set of products (you may be in a sharing situation if you set up a differ ent set of books, or business unit, per country the airline operates in). So, what happens when I use the application? Another good question. Let s build on the previous examples by looking at what hap pens when you enter a journal (i.e. a transaction). When you go into the journal page, the first thing it does is ask you what busin ess unit the journal is for. When you pick this value, you have identified what set of record group controls will be used for entering that journal. The first p lace you will se that is in prompting in the page. Pretty much any field, with t he exception of the numeric fields, will use the setid indirection (i.e. the rec ord group controls) to identify what values to use. One example may be the follo wing: When you prompt on the journal source, the setid for sources may be mapped to sha re . When you prompt on the account, the setid for account tables may be mapped to sha re . When you prompt on the department, the setid for the department tables may be ma pped to retail , and so on. When you run any batch program, the first thing you need to supply in the run co ntrol is the business unit for the transactions to be processed. This will ident ify the business rules to be used for that process (such as balancing rules for posting journals). Okay, what about reporting? Another good question, especially for nVision. PeopleSoft reporting tools defini tely need to understand about setid indirection, so that the appropriate values are returned when the report joins transaction data to the attributes of the tra saction (i.e. dimensional information). However, reporting has two extra levels of complexity: It is possible, and quite often desirable, to show data across multiple business unites in a single report (a consolidated balance sheet is a good example). Trees are very important for aggregating data, and need to be shared in a manner similar to the detail values (for example, a tree rolling up department values only makes sense for the setid of those values). So, from a reporting perspective, here is how setid indirection works: Query will automatically perform setid indirection when joining between a transa ction table and a valid value (dimension) table, if that table is set as a promp t table in application designer. Query will perform setid indirection for cascading prompts, as long as the busin ess unit prompt has a sequence prior to the prompts that depend on it. nVision will only do setid indirection for the business unit specified in the re port request (even if the report displays multiple business units). This is very important to know, because it is the key to solving setid indirection issues in nVision). Now, for trees. Trees are mapped separately from tables. This means that you hav e the ability to map the setid for each tree differently for each business unit. However, each business unit has a default setid, and if the default setid for t he business unit is correct for the tree, you don t have to explicitly map it. More on nVision: in design mode of nVision, setids can become even more complica ted. This is because an nVision report layout can be run for different business units (which are supplied at runtime on the report request). This means that in design mode, you don t know what business unit to use for setid indirection (and t hat is why in the layout options dialog in nVision, you can pick the setid to use for prompting of values when designing the report. In a scenario with multiple s etids, this is important to know, because you may have to change the setid when adding criteria for different fields. Applying this to the real world Probably very few of you will be designing the business unit and setid structure of your PeopleSoft application. However, many of you will need to put this to u se when writing reports, creating trees, or even maintaining the list of vendors , customers, accounts, and departments. The first thing to know is that it s very easy to be tripped up by setid indirecti on. I ve handled lots of calls from customers who don t get any data in their report s and think it s a problem with the reporting tool. In the end, it s usually either a setid indirection issue (i.e. the business unit resolves to a setid without an y data for a given field), or an effective dating issue (i.e. the as-of-date res olves to a date before the first effective date). The second is figuring out how to work around limitations in setid indirection. Many organizations will use setid indirection for security purposes (i.e. ensure that only a certain set of departments can be entered for a given business unit ). Unfortunately, if you want to build a tree across the departments, the tree c an only refer to a single setid (and, yes, because the tree is built on the depa rtment, which has its own definition for tableset mapping, the tree is resolved independently of the table it is built on). The only way to build a tree across multiple setids, is to create a single setid with all the values in it (assuming that the department values mean the same thing across setids). I call this creat ing a super-setid . This can be done through PeopleCode (either in an app engine p rogram if batch is acceptable, or in SavePostChg, if it needs to be done immedia tely). Probably the easiest way to accomplish this is to create a view that give s a common setid for all values. You can then build the tree on the super-setid. In nVision, to get to the super-setid, you can create a super-business unit tha t has all the appropriate tableset sharing options for the super-setids. Because the business unit filtering in nVision can be different than that of the report request, this is possible.