Event Type Requirements

To control which data should be and should not be entered along with an event type, the Event Requirements (ERQ) page is provided. Rules here control data entered on an accounting line and on certain vendor lines. Budget transactions are not included because they do not have accounting lines.

Rules established here are system-wide rules that apply to all users of an event type. When it is found that all users should not have the same rule for an accounting event, then either two event types are required or a COA Required Element page like Fund Department Requirements (FDREQ) is used. The two-event type approach is certainly the easier way to go when evaluated in terms of future maintenance because it is a one-time setup task. When chosen, there will have to be two different transaction codes that have available only one of the event types. Security is then used to give users access to the appropriate transaction code.

As these rules are system-wide, care should be taken that they do not conflict with setup on other reference pages that require or prohibit COA values. If that is the case, a user can get 'stuck' in a transaction as there is no precedence between these types of rules where one will override another. The other areas that supply COA requirement rules are any COA Required Element page (refer to the "Required Elements" topic in the COA User Guide for a description of each) and Required Budget (REQBUD) (refer to the "Required Budgets" topic in the Budget Control User Guide), which plays a very important role in data entry requirements by requiring a budget structure. When that is the case and a user submits a transaction with an event type that calls a posting code that updates the type of activity tracked on that budget structure, the posting lines of the transaction must contain all of the COA necessary to update the lowest required level of that budget. Without the COA, the user will receive the 'Budget line not found' error. Therefore, all of the COA elements on that lowest required level could be set to Optional at a minimum on the Event Requirements record.

Event type requirement rules can be changed after an event type has been used, with the only problem being the modification or cancellation of a transaction processed under the old rules. For example, a Sub Activity was optional before the change and now it is required. On a modification, the Sub Activity code will have to be entered. One can see that if an element was optional or required before but is now prohibited would be a much more serious result of changing an event type requirement rule.

Records should be added to Event Requirements for any custom event types added; otherwise, all parameters on Event Type Requirements are considered optional. Existing records can be also be modified to suit the needs of the site. Keeping a record of these changes is a very good idea in case the baseline event requirements have to be restored.

Fields on the Event Requirements (ERQ) are as follows, with common fields omitted. Unless mentioned, a field has the three values of Optional, Required, and Prohibited.

Field Name	Field Description
Event Type ID	A unique identifier for each event types requirement record.
Transaction Reference	Enforces that a reference to another transaction be made with a Reference Type of Partial, Final, and Inverse.
Memo Transaction Reference	When true there must be a reference made with the Reference Type of Memo. When false and the Transaction Reference setting is Optional, then no reference has to be made (barring transaction code settings) or a reference can be made with any Reference Type except Inverse.
Require Inverse Reference	When true this indication appends to the Transaction Reference rule (which must be Required in order to set the Require Inverse Reference to true) so that a reference must be made to a transaction and the Reference Type must be Inverse.
Vendor	Enforces that a valid and active vendor must be entered.
Customer	Enforces that a valid and active customer account must be entered.
Internal/External Restriction	Enforces whether an Internal or External vendor or customer must be entered, unless set to Not Restricted
Line Amount	Enforces rules on the Line Amount of the accounting line where the amount Must be less than or equal to zero, Greater than or equal to zero, or Unrestricted
Accounting Method	Triggers editing on Procurement and Accounts Payable transactions that the Accounting Method of the Event Types used must match the Accounting Method of the Warehouse used. Valid values are Purchase and Consumption. Setting this indication it for event types not used with warehouse codes will not have transaction processing impacts.
Require Nominal Sub Account for Provider/Seller	When true, the indication means that for event types in several event categories (IP4, IP5, IP6, IP9, IP10, OT1, and OT2) will require a (sub object or sub revenue source). Use of this indication requires the sub element only for the seller/provider where the actual Sub Object or Sub Revenue Source rule would require the field for the receiver/buyer too.
Require Nominal Sub Account for Receiver/Buyer	When true, the indication means that for event types in several event categories (IP4, IP5, IP6, IP9, IP10, OT1, and OT2) will require a sub object or sub revenue source for the buyer/receiver. Use of this indication requires the sub element only for the buyer/receiver where the actual Sub Object or Sub Revenue Source rule would require the field for the seller/provider too.
Bank	Enforces whether or not a bank has to be entered or will infer from the fund entered. Certain transactions must always have a bank (Cash Receipts and Disbursements) and will not read this requirement
Debt ID	Enforces a data entry rule for Debt ID, which is not that the Debt ID has to be a Loan, Lease, or Bond.
COA Elements	Each COA element (except Major Program Funding Profile, Funding Priority, and Funding Profile) is listed to provide a data entry rule.