The discrete enterprise resource planning (ERP) knowledge base addresses discrete manufacturing (distinct items such as auto parts or chairs) as well as non-manufacturing industries. Research vendors that support a range of functionality for production planning, shop floor control, and product costing. The knowledge base also provides information on financials, human resources, and other enterprise management modules.
| Discrete Manufacturing (ERP) Knowledge Tree | Infor - Infor ERP LN 6.1 | WorkWise - TCM (Time Critical Manufacturing) |
|---|
1. FINANCIALS
Financial system modules for bookkeeping and ensuring accounts are paid or received on time. | | |
1.1. GENERAL LEDGER
General ledger keeps centralized charts of accounts and corporate financial balances. It supports all aspects of the business accounting process. In this module, financial accounting transactions are posted, processed, summarized, and reported. It maintains a complete audit trail of transactions and enables individual business units to view their financial information, while parent companies can roll up all business subsidiaries and view the consolidated information. | | |
| 1.1.1. PARAMETERS AND STRUCTURING | | |
| 1.1.1.1. Lean manufacturing accounting practices and methods (i.e., manufacturing overheads based on cycle time including labor) | Supported | Supported |
| 1.1.1.2. Fiscal calendar is defined by the user | Supported | Supported |
| 1.1.1.3. Calendar periods are defined by the user | Supported | Supported |
| 1.1.1.4. Calendar can be defined as uneven periods, adjustment periods, or to a maximum of 366 periods | Supported | Supported |
1.1.1.5. Multiple calendars
Multiple calendars may be useful for different accounting scenarios. For example, different financial entities may need separate fiscal calendars--one set of books might require a quarterly calendar while another would require a different term. If a merger results in two financial entities that have different fiscal calendars, the accounting system will need to maintain both calendars and normalize the data (Q2 for Entity A is equal to Q3 for Entity B). This may also be useful for what-if scenarios. | Supported | Supported |
1.1.1.6. Multi-entity financial reporting
A financial reporting entity is a business unit which can legally make financial reports. | Supported | Supported |
| 1.1.1.7. Twelve or thirteen fiscal months | Supported | Supported |
1.1.1.8. Fiscal quarterly periods can be defined as 4-4-5, 5-4-4, or 4-5-4
The 4-4-5 calendar period uses a four week, four week, five week pattern. Likewise, the 5-4-4 calendar period uses a five week, four week, four week pattern; and analagously for the 4-5-4 pattern. | Supported | Supported |
| 1.1.1.9. Organization of calendar periods determined by the user | Supported | Supported |
1.1.1.10. Calendar may be organized in a variety of ways, supporting 999 periods in a financial year
The calendar can be organized in a limitless form, with up to 999 user periods, per calendar | Supported | Supported |
| 1.1.1.11. Open any number of fiscal years or calendar periods at the same time | Supported | Supported |
| 1.1.1.12. Companies with different regional presences may set a default currency for the financial division of each region | Supported | Supported |
1.1.1.13. Sets reporting entity and its organizational characteristics
The ability to decide how to organize data when defining the organization of an enterprise’s financial information | Supported | Supported |
1.1.1.14. Distinguishes A/P transactions (of the same type) from different entities
account payable (A/P) | Supported | Supported |
| 1.1.1.15. Each entity’s ledger can have its own calendar and chart of accounts | Supported | Supported |
1.1.1.16. Each entity’s ledger can have its own accounting periods opened and closed
By controlling when an account is open and closed, the posting of information in an account period can restricted. | Supported | Supported |
1.1.1.17. User may choose between data collection and real time posting modes
Allows for instant processing or batch processing | Supported | Modification |
1.1.1.18. Tracks items in the G/L and sub-ledger by quantity and value (in whichever currency is used)
general ledger (G/L) | Supported | Supported |
1.1.1.19. Maintains unit and dollar amount postings in GL and sub-ledgers
The ability to change the currency used in balance sheet accounts to another currency using a default rate. It is possible to override this default rate for particular accounts. Moreover, it is possible to set different default rates for different subledgers. | Supported | Supported |
| 1.1.1.20. User-defined criteria for system purges for general ledger transactions, journal vouchers, and accounts payable data based on the number of years or months of data required to maintain--each purge type has its own unique criteria | Supported | Supported |
1.1.1.21. Sub-ledgers closed out prior to performing a purge. The closeout process sets all financial account balances in the sub-ledger to zero by posting an equal and offsetting transaction
This would be part of the year end procedures for offsetting accounts. It can be used in determining, for example, year end sales amounts. This criterion would be considered in relation to whether or not data from the previous year should be kept. | Supported | Supported |
1.1.1.22. Specifies a key and rules to have the system automatically purge all records related to the key throughout the system--sub-ledger accounts, sub-ledger transactions, tables, rates
A general ledger key typically is an identifier attached to accounts to put the accounts into groups. For example, there may be fifteen accounts in the chart of accounts related to payroll, and all fifteen accounts will be assigned the same key (perhaps "PAYROLL"). Thus the system can purge or set other rules to all chart of accounts with the same key. | Supported | Modification |
| 1.1.1.23. Automatic check to ensure that prior to deleting a financial record, the account balance must have been "closed out" (i.e., nets to zero) | Supported | Supported |
1.1.1.24. Translation of balance sheet accounts including the ability to have a default rate (spot) that can be overridden on an exception basis (historic), on an account-by-account basis - do not want to set up a rate for every balance sheet account - the override rates will differ ledger to ledger
The ability to cumulatively incorporate results from the previous accounting period into the current accounting period, but only when the last document generated in the previous period was the financial statement. | Supported | Supported |
| 1.1.1.25. Automatically inserts actual account balances into the elapsed month’s bucket in a future forecast file at the end of each accounting period when the system rolls into the next period | Supported | Modification |
1.1.1.26. Prevents roll from one accounting period to the next unless the last job run is the financial statements
The ability to cumulatively incorporate results from the previous accounting period into the current accounting period, but only when the last document generated in the previous period was the financial statement. | Supported | Modification |
| 1.1.1.27. Audit log required for any changes to table information that may contain rates and information used by the system in any way; log contains before and after, change, date, and user identification | Supported | Supported |
1.1.1.28. Flexible general ledger key with multiple levels
General ledgers are designed to present values for creating financial statements. The multiple level for a ledger key means the system will have a more complex and functional key structure--one that supports a hierarchy of keys. | Supported | Supported |
1.1.1.29. Exception reporting with drill down capabilities
The ability to automatically, rather than manually, identify open receivables exceptions by using user-defined conditions (for example, very large amount invoices, exceeding credit line, etc.) | Modification | Supported |
| 1.1.1.30. Change cross charge percentages without retroactively changing previously published financial information | Supported | Supported |
1.1.1.31. Provision for use of standards that can be automatically propagated throughout the system to the various ledgers
The system can provide a copy function or a program to propagate a chart of accounts for a specific existing business unit to a new business unit. If a US dollar ledger has a chart of accounts, a Canadian dollar ledger can be created by propagating from the US dollar ledger, etc. | Supported | Supported |
1.1.1.32. Integration with ADP electronic transmission of payroll data
ADP refers to automatic data processing. | Supported | Modification |
1.1.1.33. Uses the budget forecast information to create automatic postings; accruals for any potential overhead item, for example, bonus, depreciation, professional fees, new product development, and marketing expense; supports standard (automatically repeating) postings and entries that are generated each month with reference to amounts maintained in budget fields for the month. The amounts may or may not be the same from month to month
For future expenses that have not been received. Upon invoice receipt, differences are posted to a particular G/L account. | Supported | Modification |
1.1.1.34. Automatic year-end rolling of balances in sub-ledgers and general ledger control accounts
This is different from a purge because the balance still exists but has been moved to another account. This allows for the automatic aging of account balances from a current file to a prior file and is required to maintain separate balances relating to customers acquired in the current year and in prior years | Supported | Modification |
| 1.1.1.35. Automatic linking and posting of control accounts from related sub-ledger accounts | Supported | Supported |
1.1.1.36. Processes jobs in edit and update mode
The ability to process jobs that are in the midst of being edited or updated | Supported | Supported |
| 1.1.1.37. Jobs required to include error and warning messages on reports | Supported | Supported |
1.1.1.38. Reports to include a control report that lists pages on which errors and warnings have occurred
The ability to create a report subsection that indicates which pages of the report mention errors and warnings | Supported | Modification |
1.1.1.39. User-defined controls to allow specific jobs to update multiple times in a period
The ability to decide if a particular job should be updated more than once during a given time period | Supported | Supported |
1.1.1.40. Provides posting views at the company, market, and title/SKU level
The ability to look up entries in the ledger by company, by market, and by stock keeping unit (SKU) | Supported | Supported |
1.1.1.41. Table master functionality--sets parameters in a table, has jobs read the table, and creates postings or reports accordingly
The ability to define variables within a tabular array of data so that jobs are performed and postings or reports are created accordingly | Supported | Modification |
1.1.1.42. User-defined field names for tables
This refers to enterprise resource planning (ERP) database tables, not, for example, report tables. | Supported | Supported |
1.1.1.43. Method for verifying keying to ensure only appropriate records updated
The ability check data entry to make sure that only the correct records are updated | Supported | Supported |
| 1.1.1.44. Archiving of transaction history as well as purge from active files | Supported | Supported |
1.1.2. CHART OF ACCOUNTS STRUCTURE
The chart of accounts is a list of ledger account names and account numbers, creating consistency in terminology and eliminates redundant accounts. A chart of accounts structure should include fields for account and ledger descriptions, to prevent shadow accounts from being created. Data tree tools allow users to see the structure of the fields and summaries, to help with reporting requirements, foster change, etc. | | |
1.1.2.1. Account structures, such as the name and order for each part of the account may be defined online
This refers to accessing individual parts of the customer attributes | Supported | Supported |
© Technology Evaluation Centers Inc. 2010.
This document may only be used for internal purposes.
Reproduction and redistribution are strictly prohibited.