The system provides sub-account, cost center, project, and SAF analysis to be used for additional analytical reporting on transactions. SAF analysis is optional, but lets you create detailed views of data.

Using SAFs, you can analyze a single account in many different ways by filtering based on the SAF codes included in the postings to the account. A carefully planned set of SAF structures avoids the need to set up separate COA elements for individual reporting.

SAF analysis can be applied to all standard GL accounts, except for bank, closing, and tax accounts. SAF analysis is not supported for system accounts, except for Purchase Order Receipts. You can apply SAF analysis to both revenue and expenses, and you would normally create a separate SAF structure for each of these types of transaction.

SAF analysis is managed through a combination of three elements:

You associate the structure with a GL account, cost center, or project.

Seven SAF concepts are predefined and provided with the system. The predefined SAF concepts are designed to interact with operational transactions, and capture key analysis details used to report the GL effects of operations such as sales by region, sales to OEM customers, or work orders by item type.

The following system concepts are provided:

While the system concepts are specifically designed to capture the details of operational transactions, you can use a combination of system- and user-defined concepts in the same structure, if required.

System concepts cannot be deleted, but can be disabled by clearing the Active field. Data is captured for a concept only when it is active. Since system concepts have a predefined meaning, you cannot modify other fields in the concept or create new system concepts.

Use the SAF Concept activities (25.3.7.1) to create, view, modify, and delete SAF concepts. Changing concepts has the following restrictions:

Use the SAF Code Activities (25.3.7.2) to create the values that you assign to an SAF concept. SAF codes generally correspond to the individual item that requires analysis. For example, you can track transactions relating to a particular vehicle belonging to the organization by creating an SAF code of the vehicle registration number.

Every SAF concept must have at least one default SAF code, defined in the SAF structure where it is used; you can link any number of codes to the same concept.

Build SAF analysis for an account by creating an SAF code for each type of transaction that updates the account.

Use SAF Structure activities (25.3.7.4) to combine up to five SAF concepts in a sequence. You then link the structure to general ledger accounts, cost centers, or projects. You can only associate one SAF structure with a GL account, cost center, or project.

When an SAF structure is associated with a project, cost center, or GL account and a transaction updates that element, the SAF concepts and default codes are displayed in the transaction posting lines.

SAF structures are independent of the entity and domain, and can contain both system and user-defined concepts.

Each structure must contain a minimum of one concept, up to a maximum of five concepts. Each concept must have one and only one default value, which is used to supply a value based on the defaulting logic. Other defaults are optional, but the one associated with the structure is required and used when more specific defaults have not been defined.

After an SAF structure has been used in a transaction, you cannot delete any of the associated SAF concepts.

The following reports provide detailed and summarized information on transactions, filtered by specific SAF codes or concepts.

The Transactions by SAF Related View (25.15.4.4) gives an on screen summary of transactions filtered by SAF code.

The example shows a work order material variance posting and the SAF information carried for the item, product line, and site.

This example is discussed in more detail in Chapter 19, “Work Order Posting” on page 489.

The financial calendar consists of user-defined GL calendar years and GL periods.

By default, the GL calendar year consists of twelve monthly GL periods. Each GL period does not have to correspond to a calendar month. You can define custom start and end dates for each GL period to correspond with your accounting cycles, and the GL calendar year can exceed twelve calendar months in length. The GL calendar year is defined at the domain level; all entities within a domain use the same GL calendar year definition.The system contains two functions related to GL calendars and periods:

Two other system functions can be used to define specialized calendars:

As part of the initial system implementation, set up values in the various control programs on the Operational Acct Controls menu (36.9). The settings in each control program affect operations within a specific business area. Typically, these settings represent a subset of all the settings that affect the related business area. These control settings have been separated because they have a financial effect on all modules, and should be defined only by a financial analyst with security access to this function.

This separation facilitates the segregation of responsibility so that financial personnel can manage the settings that reflect financial and accounting decisions