Account administration

While users represent an individual person, accounts represent a single purchasing entity. For the most part accounts can have the same types of data stored against them as users — attributes, permissions, etc; this data can then be shared amongst many different people.

In addition to these, accounts have an optional pricebook property. This is only relevant in a system where a product can have a different price depending on who the user is, and is used as a lookup key in custom pricing modules.

Account hierarchy structure

Accounts are identified by a code, which must be unique system-wide. This code is a text string and so can contain any value.

For large purchasing organisations, it is also possible to group together accounts into a hierarchy. This is done by creating parent accounts, account objects that should not be used for purchasing but can instead be used to share data among a large number of sub-account entities.

For example, a large company could be split up into the hierarchy shown in Figure 1.

  • Large Company X
    • Europe
      • UK
      • Spain
      • France
    • US
    • Asia
      • China
      • Japan
Fig. 1 - An example account hierarchy

Data could be shared among the European branches of "Large Company X" by storing it on the "Europe" parent account, or used by the entire company by storing it on the root-level account.

Note that the account codes for these group entities would have to be unique system-wide, their values in Figure 1 are merely illustrative. In practice they should be verbosely set, e.g. "Large Company X/Europe/UK". If the actual purchasing accounts are fed from a separate back-office system then grouping accounts should use a different naming scheme to the back-office, as the codes of the purchasing accounts cannot be controlled in Mercatum under these circumstances.

Data is not currently inherited from parent accounts automatically, and so parent accounts should not be used to manage catalogue visibility or permissions. Other data can be inherited in a specific implementation of functionality, by manually traversing any parent accounts in JTP or scripts until the relevant data is found.

Attribute data

Account attribute data is separated into one of two different types:

  1. simple strings — for example, a sales office code.
  2. attribute sections — collections of strings that contain multiple properties (such as addresses), same as for user attribute data.

Accounts also support attachments in the same way that users do.