Introduction to Hierarchies

Hierarchy is primarily used in PaymentNet to:

Permit grouping of employees, accounts, and transactions by elements and levels within the organization chart/hierarchy.
Restrict functionality to certain levels of the hierarchy (for example, a given chart of accounts can be used in one hierarchy but not another).
Define what various user roles can do and see within the system (that is, to how much of the organization chart an individual user’s authority extends).
Define how data will be organized or displayed in reports.
Drive approval workflow by routing transactions to transaction approvers.

A hierarchy tree is a graphical representation of the hierarchy, with expandable and collapsible nodes represented as folders. Levels of indentation represent parent-child relationships.

New hierarchies are automatically created with a base entry called “ROOT”. All structures are built down from the root node. The root serves as the top-most parent node, and any nodes that branch from it are considered to be its children. A hierarchy can have a maximum of 25 levels beneath the root node; however, as a best practice, you should limit the hierarchy depth to between 6 and 10 levels.

Each hierarchy node is represented by an alphanumeric hierarchy ID and a description. For example, in a hierarchy node named 1001 Travel Card, 1001 is the hierarchy ID and Travel Card is the description.

If your organization has the duplicate hierarchy ID function enabled, node names can be reused, but the hierarchy path—from the root node to a hierarchy ID—must be unique. For example, Root > West > Sales and Root > East > Sales would both be valid hierarchy paths, even though the Sales node is duplicated in each path. The system identifies the complete hierarchy string as the node name. If your organization does not use the duplicate hierarchy ID function, each node name must be unique. Contact your J.P. Morgan relationship manager to have the duplicate hierarchy ID function enabled.

Two default nodes are created in the basic hierarchy structure under the root node: UNASSIGNED and DELETED.

During the initial implementation, when accounts are created, they are automatically placed in the UNASSIGNED hierarchy node. Each account must then be moved to the correct node. If PaymentNet is used to add accounts to an existing program, a hierarchy can be specified as part of the new account setup process.
The DELETED node may be used for J.P. Morgan administrative purposes. You can also create your own Deleted node under the root node to house historical data that is no longer in use. For example, if an employee leaves the company, the employee should be placed in your client-created Deleted node in order to maintain a history of their account usage.

Note:If an account is moved to a client-created Deleted node, the transactions associated with that account will no longer be associated with their previous hierarchy node. The transactions follow the accounts and will be moved to the Deleted node as well. This affects hierarchy-based reporting.

Hierarchy Setup Best Practices
Lessons Learned	Recommendation	Rationale
Do not set up the hierarchy with individuals’ names.	Restrict the naming convention to the names of departments, divisions, cost centers, and so on.	This minimizes the maintenance needed when an individual moves or leaves the organization.
Do not make the hierarchy overly complicated.	Keep to the minimum width and depth. The maximum depth is 25 children levels; however, as a best practice, limit the hierarchy to between 6 and 10 levels.	Overly complex hierarchy will hinder your ability to effectively manage reporting, transaction approval routing, and so on. It may also impact system performance.
Create unique hierarchy IDs for program-specific hierarchies.	Use a “P” or “C” in the hierarchy ID (or description) to define unique hierarchy IDs for a specific program (Purchase Card vs. Corporate Card).	This is a simple way to clearly identify a program at any hierarchy level.
Where possible, create the hierarchy ID to match your company’s internal IDs.	For example, if the Accounting department reports up to Finance and is referenced as department “123”, then set up Accounting as a child node to the parent node Finance and incorporate “123” into the Accounting hierarchy ID. If your organization has the duplicate hierarchy ID function enabled, node names can be reused, but the hierarchy path—from the root to the hierarchy ID—must be unique. If your organization does not use the duplicate hierarchy ID function, each node name must be unique.	Structuring the PaymentNet hierarchy to be consistent with your existing system will be more intuitive for users.
A cardholder should typically have their account and their user ID in the same hierarchy.	The account hierarchy ID, the employee (user) hierarchy ID, and the role & scope hierarchy should all be the same.	This clearly designates the employee to whom the account belongs. Also, when an employee moves, the accounts will move with him or her.