The information in this section will help you determine which account code fields to use in SpendMap.
Introduction
Many organizations need to report on their spending based on one or more account codes or account code "segments", such as a G/L account, cost center, department, project, fund, etc.
SpendMap includes 5 user-definable fields (with associated Master Files) that can be used to keep track of your Purchase Orders and other transactions. You can then sort and filter many reports by these fields, track charges to the various account codes, search for transactions based on these fields, etc.
While you can change the names of these fields on screens and reports, in this document they are referred to generically as;
•Job
IMPORTANT: The two “primary” account code fields are Cost Center and G/L Account, in that these two fields typically meet the needs of most organizations. Before using any of the other fields, please review Account Code Fields and Segmentation, below.
Why Code Procurement Transactions?
In some organizations, transactions are not coded until very late in the procurement process, often not until the supplier’s invoice is being approved and processed in Accounts Payable. While this might satisfy the needs of the Accounting Department, “late stage” account coding typically means a lack of visibility and control for transactions in the procurement process leading up to the invoice approval stage.
Therefore, a common goal for many organizations when implementing an e-procurement system is to have transactions coded earlier in the procurement process, ideally at the very first stage (requisition creation).
Coding is Optional for Each Transaction
While there are certainly many benefits to coding transactions as early as possible, please note that you can elect to code transactions later in the process if you prefer, or not at all. For example, if account codes are not entered on requisitions, they can be filled in later during the approval process, or perhaps even later when the Purchase Order is processed, or possibly not until the invoice approval stage.
You can either rely on your internal policies and user training to determine which transactions are coded or you can make account code fields mandatory so that users are forced to fill in the account code(s) either throughout the entire system or on specific screens.
Account Code Fields and Segmentation
SpendMap includes 5 user-definable fields (with Master Files) that can be used for coding transactions. While you can change the names of these fields on screens and reports, in this document they are referred to generically as Cost Center, G/L Account, Project, Job and Request-By.
The two “primary” account code fields are Cost Center and G/L Account, in that these two fields typically meet the needs of most organizations, while Project, Job and Request-By are typically used by organizations with more complex account coding needs, such as larger public, government or non-profit organizations.
Selecting the Fields to Use
The information in this section will help you choose the account coding fields that will best meet your needs, based on the available functionality for each field. If in doubt, please speak with your SpendMap Implementation Specialist.
TIP: Do not select fields to use in SpendMap just because SpendMap's default field terminology happens to match your company's existing nomenclature. For example, if you currently use the term "project" or "job" for one of your account code segments, that does not necessarily mean that you would be best served by using SpendMap's default Project or Job fields. Rather, you should start with the Cost Center field (which, again, can be renamed) before using the other fields, since the Cost Center Field has some features and reporting that are not available for other fields. So, for example, if you are tracking your spend to projects, consider renaming the Cost Center field to "Project", rather than using the default Project field. Again, start with Cost Center and G/L Account, and then only move on to the other fields if you need additional account code segments.
TIP: For some organizations, it makes sense to use a single field to track charges to different types of accounts, rather than using multiple/separate fields. For example, many SpendMap customers need to track charges to both departments and projects, but they are "mutually exclusive". That is, an individual item will only ever be charged to EITHER a department OR a project, but never both at the same time. In cases like this, you might consider renaming the Cost Center field to something generic like "Charge-To", and then you can load both your departments and projects into the Cost Center Master File, and then users will select one or the other when entering POs and other transactions. Again, this is just something to consider, but if you will be charging individual items to BOTH a department AND a project simultaneously, then you will need to use two fields.
Suppressing Unwanted Fields and Customizing Field Behavior
•If you will not be using some of the account code fields, you can optionally suppress (lock out) unwanted fields so that they are not accessible. Alternatively, you can just rely on your internal policies and user training to determine which fields will be filled in by users.
•You can make one or many of the account code fields mandatory (i.e. must be filled) on all data entry screens throughout the system in User Definable Field Settings. Alternatively, you can make the fields mandatory on selected screens with the Field Access Restrictions utility.
•You can change the order of the account code fields so that they show in a difference sequence on data entry screens.
•You can select whether to display 1) the code or 2) the description when displaying account codes on screens.
