Constraints allow an organization to limit the chart of accounts values users can assign based on their hierarchy, role, account, or user ID. Constraints of different types can be combined to fine-tune a user’s access to accounting code values. For example, you might belong to a hierarchy named Organization Personnel. Your J.P. Morgan implementation manager can assign specific charts of accounts—such as Project and Fund—to the Organization Personnel hierarchy. This way, you can only access the Project and Fund charts of accounts.
PaymentNet does not limit the number of constraints you can apply to a chart of accounts. However, as a best practice, you should use the smallest number of constraints possible, and leverage include constraints more than exclude constraints, to achieve your goal.
Any chart of accounts constraint in a hierarchy level lower than a hierarchy with an exclude constraint is not applied. For example, if the following chart of accounts constraints were applied at these hierarchies:
Root = include
Level 2 = exclude
Level 3 = include
The constraint at Level 3 would not be applied because of the exclude constraint at level 2. An exclude constraint always takes precedence over an include constraint when constraints overlap.
When adding multiple constraints, be careful to avoid conflicts as this may cause issues when allocating transactions. For example, if you define an include constraint for Segment 2 for a particular hierarchy, and you also set an exclude constraint for Segment 2 for the Card Holder role, cardholders will not be able to view Segment 2 for allocations even though Segment 2 is included at the cardholders' hierarchy level.
This section explains the following: