MOD: Controls, Privileges and Delegation

Introduction

As is common in IES Business, the Manufacture On Demand Module exhibits extensive, but appropriate and easy-to-manage User Control mechanisms. While the MOD Module is devoid of traditional Menus, a User gains access to the MOD Wizard with all it's functions by having the Manufacture Module listed on his / her IES Business Module Profile. Once the User has access to the MOD Wizard, he / she is further guided and overseen in terms of access and privileges by 2 secondary Business Profiles: -

  • The Manufacture On Demand Profile
  • The MOD Purchase Order Profile

The 1st Profile covers the general privileges of the User in MOD, while the 2nd deals specifically with Purchase Orders executed from within MOD.

The User also has the privilege of Delegating some of his / her privileges to other Users, and Delegation is done on 2 distinct levels: -

  • Primary Privileges
  • Secondary Privileges

Primary Privileges relate to Authorizer and Controller statuses of a Sheet. All MOD Sheets are public to MOD Users in terms of Enquiry, but private in terms of execution. Secondary Privileges relate to execution of MOD Sheet functions while the Sheet is in WIP (work in progress) phase.

The Manufacture On Demand Profile

All Access Control reside in the ACCESS PROFILES Module, including not only the Menu Access, but also the Secondary Business Profiles for other IES Business Modules. The Business Profiles are accessed from the User Master Profile, which is normally accessed by opening 'Access Profiles', then choosing 'User Master Options', and then choosing 'Maintain User'. On the User Master Screen, we find a button called 'Business Profiles', and we show an example below -

  1. Shows a cut of the User Master Profile Screen, which is accessed inside the IES Business DataMart where Business Profiles need to be set up.
  2. Shows the BUSINESS PROFILES button, which, when clicked, produces the list of Business Profiles from which to select which Profile Type to Open for definition, editing or maintenance.
  3. Shows where to find the Manufacture On Demand Profile (which will now be discussed).
  4. Shows where to find the MOD Purchase Order Profile (which will be discussed immediately after the Manufacture On Demand Profile).

The Manufacture On Demand Profile, when opened, shows (see below) the User for whom the Profile is being defined, shows who is the User who last Updated or Modified this Profile, and then deals with 2 distinct sections: -

  1. Master Privileges
  2. Working Privileges

Master Privileges are concerned with MOD system control, and whether this User may be allowed to use the listed control functions of the system, e.g. to Define WIP Message Master Types, Define new Cost Elements, Define Clauses (these are Contract Clauses which are standard objects that may be included with Quotations), and whether this User may access the MOD Control Parameters.

Working Privileges relate to the User's privileges with regard to MOD Sheets.

  1. Sheet Access - Sheet Access can be defined as 'Own Only' or 'Any'. The 'Any' option is usually only given to Executive Users, because this option will allow entry to all MOD Sheets that are in statuses before the WIP stage, even though 'belonging' to someone else. Once a Sheet enters the WIP stage, all MOD Users can enter it, but can only perform functions on it as allowed, depending on whose Sheet it is, i.e. who the Controller of the Sheet is, and whom he / she may have delegated privileges to. In statuses prior to WIP, the Sheet is considered private, and can only be used by the Originator, the Authorizer and the Controller of the Sheet. However, all MOD Users may QUERY (rather than Update) any Sheet at any stage.
  2. May Create New Quotes / Sheets - Any User with this privilege has the right to open new Quotations, and prepare them for Approval for release (of the Quotation).
  3. May Approve Own Quotes - 'Best Practice' determines that nobody may Authorize their own Quotes, and therefore act as continued Authorizer for the entire duration of the Sheet. However, there are circumstances where this may be allowed, e.g. in a small set up where a single User controls the entire Manufacture Administration Process, or perhaps where an Executive User has enough Authority to demand that he / she will do so anyway.
  4. Acts as an Authorizer - This will be checked for Users who may act as Authorizers. Once a User is an Authorizer, he / she may act as Authorizer for Quotations, and subsequently be responsible for all further Budget Additions and Purchase Order Approvals on that Sheet, after the Quote has been accepted by the Customer. So this Value is very much restricted to Users who may act as Authorizers in an overall sense.

  1. Acts as a Controller - This privilege is given to Users who will act as Manager or Administrator of a Manufacture Project. We use the term 'Controller' instead. The Controller is assigned by the Authorizer when approving the Quote, and the Controller, once the Quotation is accepted, becomes responsible for controlling and executing the Manufacture Job. The Controller may then be assisted by Users to whom he / she delegates the privilege to do so, and who may then access the MOD Sheets 'owned' by this Controller, and perform WIP functions on these Sheets.

The MOD Purchase Order Profile

Procurement, also called Purchasing, is a powerful and flexible integrated Business Module in IES Business. Quite apart from the standard Purchase Orders administered in the Procurement Module, the Purchasing function is also partially delegated in the form of Departmental Direct Ordering (we call this ERPODO), with it's own subset of Procurement Controls, and likewise, the Purchasing function is also delegated to Manufacture, where direct Access to Purchase Orders that are strictly for MOD, is available. All Purchase Order functional access is controlled by the all-powerful Purchase Order Profiles, that allow for all the split controls necessary to manage and control modern Procurement. Due to the delegation capabilities of the Procurement system, it is necessary also to split the Access Controls in order to ensure that MOD Users cannot operate on Orders that belong solely to the Purchasing Department, nor access Departmentally owned ERPODO Orders. For this reason, MOD has separate Purchase Order Profiles specifically for MOD Purchase Orders, and these do not interfere with privileges on ERPODO or Standard Orders for which the same User may have separate privileges.

No User is allowed to work on MOD Purchase Orders without having one the Profiles shown above.

The Procedural Checks include the following, i.e. whether this User may: -

  • Accept Reduced Invoice Price
  • Capture Deliveries
  • Auto GRV
  • Perform Cancellations
  • Capture Invoices
  • Auto Invoice
  • Capture Goods Return
  • Capture Credit Notes
  • File Nonstock Items
  • Authorize Own Orders
  • Perform PA/WS Actions
  • Post Landed Costs
  • Reverse Landed Costs

The Value Limits include the following: -

  • New Orders Auth Limit
  • Limit for Supplements
  • Limit on Surplus Deliveries
  • % Tolerance on Order Price Variance
  • % Tolerance on Invoice Price Variance
  • Max Number of Price Adjustments per Order

It is unusual for any User to have all of the above privileges, since it is specifically by splitting the Controls, i.e. the privileges between different Users, that good Control against questionable practices is achieved. (The prompts are somewhat self-explanatory, but they do have further on-line help, if you need further explanation. These prompts are also identical to those used with Standard Orders in the Procurement Module, and with ERPODO Departmental Direct Orders.)

The MOD Purchase Order Profiles are designed for you to be able to implement the control level that you need to achieve for your Business. For example, in a situation where there are 1 or 2 Authorizers who need to Approve all MOD Budgets, and all overruns on Invoices, only the Authorizers will have any Invoice Variance Tolerance, and all Controllers and other MOD users will have 0% Tolerance. This will effectively translate to a situation where, when an Invoice does not agree exactly with the approved Order Price(s), the Invoice has to revert to the Authorizer for Approval. As another example, an Authorizer may automatically approve all Purchase Orders on a Sheet where he / she is the Authorizer, but if the Order Value exceeds the stated limit, then another Authorizer (with 'Any' Sheet Access), has to approve such an Order. In another set up example, various Users may have varying % Tolerance levels, i.e. where Authorizers may only want to know if the Invoice varies by more than 10%, for example.

Delegation

Below we show the User Delegation Screen.

Any MOD User has access to his / her Delegation Screen, but unless the User is either an Authorizer or a Controller of MOD Sheets (or both), it has little meaning.

Primary Delegation is permission for another User to act in your behalf as Authorizer or Controller. In the example above, Philip is delegating such authority to Gordon. This may mean that Philip is going to be out of Office, and is arranging for Gordon to act on Sheets where Philip is Authorizer or Controller while he is away, or it may simply mean that this is a working arrangement, i.e. whenever Philip is not available, or wishes for Gordon to perform Actions in his behalf, this may be allowed. Delegation may be changed on demand at any time.

Secondary Delegation is only relevant with regards to Controller authority on a MOD Sheet in WIP state. While the Sheet is in 'work in progress' phase, the Controller of the Sheet is responsible for, and has access to, all the WIP functions available on the Sheet. Once again, a Controller may delegate this kind of permission due to being away or unavailable, or simply as a working arrangement. For instance, Philip may be Controller of many Sheets, and Gordon and Suzanna may be his Assistants, each performing certain actions on these WIP Sheets, e.g. Stock Issues, placing new Purchase Requisitions, etc. When a User is acting on behalf of someone who has delegated authority to him / her, the User has standard Controller Access to functions on the WIP Sheets where the Delegator is the Controller, but in terms of any Purchase Order Processing, he / she is still acting within the privileges of his or her MOD Purchase Order Profile, which may be totally different to that of the Controller of the Sheet. Therefore, there may be occasions where the real Controller still has to perform certain actions on the Purchase Orders, i.e. where superior privileges are required.

It should be noted that Delegation merely gives a User some Access to certain functions which he / she may execute on behalf of someone else, but the User is not assuming the other's name, and IES always knows who is doing what, and will still record actions in the name of the real User who performs the actions, not in the name of the 'on behalf'. In other words, where IES records a User Audit Trail of Transactions executed, these Transactions (if executed by Suzanna), will show Suzanna's own name as the User who performed the Transactions, even though Suzanna is acting on behalf of Philip.

© Infolab, 2005.