Working with Tree Concepts
This topic provides an overview of working with tree concepts.
This topic discusses general concepts used by PeopleSoft Tree Manager, such as levels, effective dates, and setIDs.
Levels provide a way to organize tree nodes. In most trees, all nodes at the same level represent the same kind of information. For example, in a tree that reflects the organizational hierarchy, all division nodes appear on one level and all department nodes on another. Similarly, in a tree that organizes your product catalog, the nodes representing individual products might appear on one level and the nodes representing product lines on the next higher level.
Sometimes you want to be able to identify all of the nodes on the same level as a group, even when they do not share the same parent. For example, you might create a PeopleSoft nVision layout that summarizes the data for a division, then define a PeopleSoft nVision scope that creates one report instance for each division, regardless of what company it is in. To allow you to refer to all the nodes at a level, PeopleSoft Tree Manager enables you to name each level. You will use the level name when you define the scope for your PeopleSoft nVision report (rather than identifying all the nodes individually). Naming your levels gives you another way to “slice” the data in the tree. Level names can appear next to the node description.
For each tree structure, you can determine how trees use levels:
When levels are not used the nodes in the tree have no real hierarchy or reporting structure but do form a logical summarization structure.
Strictly enforced levels mean that the named levels describe each node’s position in the tree.
This is natural for most hierarchies. Strict levels have the following advantages:
You can skip a level if a portion of the hierarchy does not have a node at that level.
The appearance of your tree more precisely matches the real-life hierarchy.
If you use summary ledgers in PeopleSoft General Ledger, you can also create summary trees, which are based on levels in the corresponding detail tree.
If you decide later that you need to change a tree from strict levels to loose levels, you can do so.
You cannot change a loose level tree to strict levels, because the level names are not connected to specific positions in the tree.
Loosely enforced levels mean that the nodes at the same visual level of indentation do not all represent the same kind of information, or nodes representing the same kind of information appear at multiple levels.
With loosely enforced levels, you assign a level to each node individually; the level is not tied to a particular visual position.
In the previous example, the first two levels are clear: Corporation and Division. However, within the Sales and Manufacturing divisions, the structure is different. This tree could be created with strict levels, but would become distorted because the Plant and Line levels would need to appear either "above" or "below" the Region and District levels when in fact they are parallel. You could define a strict level tree with a level name such as Plant/Region or even Level3, but this makes it harder to identify just the regions, districts, and so on for reporting or other purposes. With loose levels, the plants within the Manufacturing division can be referred to as a level independent of the regions in the Sales division.
In a loose level tree, the level is an attribute of the node and is only loosely related to its position. The level becomes a way of identifying a group of nodes that serve a common function within the organization.
For most trees, you will want to use levels. Consider the following reasons before selecting the Level Not Used option:
You cannot add levels to a tree later.
If you use summary trees (generally used with PeopleSoft General Ledger), levels are required.
PeopleSoft nVision enables you to build a report by nPloding the tree from a specified node to a specified level.
This makes levels very useful on account hierarchies, for example.
Using effective dates with trees enables you to specify new objects, departments, reporting relationships, or organizational structures in advance and have them take effect automatically. You can also use trees with past, present, or future effective dates when reporting on current or historic data.
Using Effective Date is required for all types of trees.
Most data in control tables is stored by setID. Trees can be identified by four key values: setID, user key value, tree name, and effective date.
When using a setID as a key value for your tree, you should assign the same setID as the record on which your tree is built.
Note: You should not user key value for a newly created trees.
Nodes define the hierarchical relationship within the tree. Nodes can be either categories (as in a group of assets) or items that need to be placed in a relationship with other items, such as an item in a catalog.
Each detail value reports to a tree node at the next higher level of the organization. Each tree node represents the group of detail values that report to it. Referring to the node is a shorthand way of referring to the group of detail values under it. For example, if a report refers to the Office of the President, it includes data from all the detail values under the Office of the President node — including the detail values under the Human Resources department, because Human Resources reports to the Office of the President.
In turn, each tree node reports to another tree node at a higher level of organization until you reach the top level of the hierarchy, called the root node.
Family Tree Terminology
Terminology derived from the idea of a family tree is used when talking about trees. The nodes that report to the root node are called its children. They are also called child nodes. The root node is their parent. Nodes that have the same parent are called siblings.
Detail values, or leaves, link a roll-up structure to the supporting detail. For example, the nodes in an account tree are not the actual accounts but categories of accounts. Using this example, the account tree has a node called Assets, with detail values specifying a range of accounts from 1000 to 1999 rolling up to it.
The tree illustrated in the following example shows summarization rules for the PERSONAL_DATA field. In other words, it is an organizational chart for the offices in a company’s headquarters. Individual offices, such as 8200, represent the lowest level of organization and appear at the far right of the tree. The leaves representing the offices are called detail values. Detail values have leaf icons and square brackets [ ] surrounding their names.