What is analysis mapping?

Analysis mapping allows you to automate the transfer of information from the SunSystems Order Fulfilment modules into the ledger analysis dimensions when an Order Fulfilment ledger posting is performed.

An Order Fulfilment ledger posting automatically creates a journal within the SunSystems Financial module. Each journal can have up to ten analysis dimensions assigned to it, as defined in Analysis Structure (ANS). This is also known as ledger analysis. If you manually enter a journal, you can enter analysis data (analysis codes or other non-validated data) into these ten analysis dimensions. However, when a journal is created from Order Fulfilment, the system can automatically enter analysis data into these ten analysis dimensions. Analysis mapping defines what data will be placed into each of the ten analysis dimensions on the journal.

Each one of the ten ledger analysis dimensions must be mapped separately. The source of the analysis data can be either transaction analysis or static data relating to the transaction, as described below in What Order Fulfilment Source Data is Available?

Separate mappings must be configured for each of the Order Fulfilment modules from which you require ledger postings: Purchasing, Sales, Inventory (Movement Orders), Inventory Receipts and Inventory Issues, and each of the external Business Line Imports. For example, on the ledger postings generated by Purchasing you may want to insert the supplier code, item code and cost centre code into ledger analysis code fields 1, 2 and 3. Whereas on the ledger postings generated by the Sales module you may want to insert the customer code, sales area code, and cost centre code into the analysis code fields 1, 5 and 3.

The main advantage gained by using analysis mapping is that there is no need to use the analysis dimensions on Order Fulfilment transactions to maintain analysis details that are held elsewhere in the system, just in order for them to be transferred to Financials. You can simply map the information directly as part of the interface. For example, you do not need to maintain the item code in an analysis dimension on Order Fulfilment transactions in order to transfer it on the ledger transactions. Instead you can select it directly from the Order Fulfilment transaction on the mapping (assuming an item is present on the Order Fulfilment transaction).

Analysis mappings are established using Analysis Mappings to Ledger (ANM).

To define an analysis mapping you must identify:

  • the target ledger transaction analysis dimension.
  • the source data to be transferred to the target dimension.
  • if the source data refers to an analyzable entity, that is, the source analysis dimension.
Note:  You must ensure the source data you choose contains the appropriate information for the target dimension. For example, if the target dimension on the ledger transaction is for cost centre codes, you must be sure to pick a source analysis dimension that contains cost centre codes. SunSystems cannot verify that the source and target analysis dimensions contain logical or compatible information.

What Order Fulfilment Source Data is Available?

There is a large amount of source data in the Order Fulfilment modules you can choose to populate any of the ten ledger transactions analysis codes. The list of source data is referred to as the analysis directory. Each directory choice identifies a type of data that can be transferred to Financials, and the choices can be divided into types:

Useable Entities

Useable entities refer to any of the static reference data codes that can be defined in Order Fulfilment and Financials, and referenced either directly or indirectly on sales, purchase and inventory transactions. For example, items, product groups, employees, warehouses, supplier and customer codes, supplier and customer account codes, chart of accounts codes, and asset codes. These codes are defined using specific, predefined SunSystems functions. They are either maintained on the Order Fulfilment transactions, or can be retrieved from other details held on the transactions.

The useable entities include a large number of addresses that can be referenced on Order Fulfilment transactions. For example, purchase line delivery address, customer delivery address.

Analyzable Entities

Analyzable entities are the SunSystems entities that can be analyzed using global analysis dimension codes. Up to ten analysis dimensions can be assigned to an analyzable entity using Analysis Structure (ANS). For example, you can analyze customers, suppliers, assets, ledger accounts, employees, purchase order lines, purchase invoice lines, sales order lines, sales invoice lines and so on.

You can choose to map some of these analysis codes through to the Financials ledger transaction analysis codes. For example, you might have assigned an analysis dimension containing sales area codes to sales invoice lines. You can then choose to transfer the sales area code for a sales invoice line, onto the corresponding ledger transaction that posts the sales invoice into Financials.

Because each analyzable entity can contain up to ten different analysis dimensions, to identify the source data to be mapped you must identify both the analyzable entity and the analysis dimension. For example, using the sales area example above you would need to choose the sales invoice line analyzable entity and the sales area dimension as the source.

An Example of Analysis Mapping

If Ledger Txn Analysis Dimension 1 is set as Project, then when a ledger posting is created, the journal and the account may require an analysis code to be entered in dimension 1; in this example a project code. The system can automatically enter a project code in the journal, and this code can originate either from the transaction line that created it, or from an associated piece of static data.

In the example of the project code originating from a transaction line, the ledger posting might be generated by a purchase order, and if one of the ten analysis dimensions on the purchase order holds the project code, this field can be mapped to the journal project analysis code. It does not have to be analysis dimension 1 on the purchase order.

Alternatively, a piece of static data can be mapped. For example, the item code could be mapped to any ledger analysis dimension. The specific code entered on the journal would be taken from the item code on the transaction line that generated the ledger posting. Other examples include supplier code, customer code, product group code, warehouse code, purchase line delivery address, and customer delivery address. For more information, see What Order Fulfilment Source Data is Available, above.

Determining which Ledger Interface Type the Analysis Mapping Relates to

There are three main types of ledger interface, which can be configured in Ledger Interface (LIS) using the Ledger Interface Value Type control as follows:

  • Transaction Values
  • Inventory Costs
  • External/Business Line Import Values.

In Analysis Mapping to Ledger (ANM), if you define the Business Definition Type as Sales, Purchase or Inventory, then these only apply to postings from a ledger interface whose value type is set to the Transaction Values.

However, if you define the Business Definition Type as Receipts or Issues, then these relate to postings from the Inventory Cost ledger interface type.

Finally, the Business Definition Types of External Sales, External Purchasing, and External Inventory all relate to ledger postings of the type External/Business Line Import Values.

Other Factors that Affect Analysis Mapping to the Ledger

The configuration of the following functions can also affect the analysis codes that are imported or established for each dimension:

  • Ledger Interface - Line Detail: In Ledger Interface (LIS), the Line Detail can be used to suppress and hence post no data, or replace analysis with a fixed code, and these are separately configurable for each journal line that the interface creates.
  • Journal Type: The Journal Type (JNT) can allow or prohibit postings to analysis dimensions. The journal type to be used is defined in Ledger Interface (LIS) header section.
  • Chart of Accounts; In Chart of Accounts (COA), transaction analysis for an account code can be prohibited on the account code itself. The account code to be used for each journal line is defined in Ledger Interface (LIS) - Line Detail.
  • Purchase Type, Sales Type, Movement Type: Analysis not to be transferred from receipt records to issue records can be defined here. This may affect what analysis gets posted for business definitions of the type 'Issue'.

All of the above functions override the settings you configure in Analysis Mapping to Ledger (ANM), and as such you are recommended to plan all of them with a consistent approach. For example, if you require an analysis dimension to be mapped from sales order transactions, it must not be suppressed by the Ledger Interface; it should be included on the Journal Type and should not be prohibited in the Chart of Accounts record corresponding to the account specified in the relevant line of the Ledger Interface Line Detail.