Skip to end of metadata
Go to start of metadata

INTRODUCTION TO INFORMATION ARCHITECTURE

Compiere has an advanced information structure allowing structural changes in midstream breaking the limitations of the old fashioned 'Set of Books' system used by most competitors.

The Multi-­Organization capability of Compiere enables different organizational entities to share data or make sure that private data is not accessible by other entities. Secure and structured sharing of data is a prerequisite for centralized functionality, outsourcing or service centre operation.

Compiere was designed to maintain different organizations and supports three entity levels as follows:

  • System
  • Tenant
  • Organization (and its associated hierarchy)

System level data is mostly infrastructure information, but can also include system wide business partners, products, accounting schema(s), etc. The system level is equivalent to the database installation. Compiere provides tools to synchronize different systems.

Compiere automatically supports multiple Legal Entity accounting, ensuring that transactions crossing legal entity boundaries are accounted correctly. This can include calculation of cost charges (e.g. selling organization is a different legal entity than the product owning organization).

Multi-Accounting

An entity may be required to account in multiple, parallel accounting standards due to any combination of the following:

  • Accrual and Cash-­based Accounting
  • Different accounting standards (e.g., US GAAP, UK SAP, German HGB)
  • Different inventory costing methods (e.g., Standard, Average, FIFO)
  • Different currencies

Usually, a Set of Books is defined as a set of transactions with the same Chart of Accounts, Calendar, Accounting Currency, Accounting Standard and Costing Method. In some situations, it is sufficient to convert or translate a Set of Books to another Set of Books. For most competing applications, this is the only option. There are situations, where this is not sufficient due to the following:

  • Unacceptable rounding and conversion differences
  • High manual effort to convert
  • Missing audit trail
  • Unacceptable time delay of availability of results
  • Inability to convert as detail information is missing

Most applications replicate transaction data to be able to support the different accounting dimensions. Compiere was designed to support multiple accounting requirements. The concept of Set of Books was improved with the concept of Accounting Schema. An Accounting Schema is any combination of the following:

  • Chart of Accounts
  • Accrual or Cash based accounting
  • Accounting standard
  • Costing method
  • Accounting currency
Note: that in contrast to a Set of Books, a Calendar is not directly part of an Accounting Schema, as multiple calendars per accounting schema may exist. The calendar is reduced to transaction support functions (open/close periods, summary postings, allocation definition and ease of entry).

In contrast to most other applications, Compiere differentiates transaction and the resulting accounting consequences with the following benefits:

  • Transaction data is not replicated
  • An accounting schema can be added or discontinued at any time
  • Accounting information for historical transactions can be generated
  • Any attribute can be modified or replaced (and optionally the accounting regenerated)
  • Accounting schemas are easy to extend and maintain
  • The system is error tolerant because it can be corrected and regenerated.

It is possible for customers to extend accounting rules (by programmed modifications), if the predefined accounting rules are not sufficient (internally, accounting rules are defined using an accounting rule engine). Additional accounting rules may be implemented to address such matters as commitment accounting.

Multi-Tax

Compiere supports Sales Tax and Value Added Tax, including multiple taxes where a tax is charged based on say, a product cost plus a state based tax (e.g. for Canada). The tax engine determines the correct tax, its amount and date based on the following:

  • Transaction time
  • Product category
  • Ship from/to location
  • Invoice from/to location

Multi-Costing

Using different costing methods (Standard, Average) can result in different financial results. Compiere supports using more than one costing method, e.g. for legal accounting and business decision making.

Compiere maintains the information for the following costing methods:

  • Standard Costing
  • Actual Costing (Average)
  • FIFO
  • LIFO

Multi-Lingual

Compiere provides for the translation of the following system elements:

  • Screens
  • Reports
  • Messages
  • Seed Data (e.g. status information like Open/Close, etc)
  • Transactions

Many applications allow the translation of Screens, Reports and Messages, but few allow the translation of seed data and even fewer, the translation of transactions. Not to mention, the ability to switch language as a user of the system.

  • System translatable in one (base) language
  • Users can decide, which language to use
Note: Most systems have one base language.

Finally, the system must have the ability to create documents in the language of a customer or vendor.

Very few applications support this because it requires printing the translated word for 'Invoice' as well as providing for different address formats, description of products, etc. (see also Multi­-Currency for business partner specific currency).

Compiere allows users to translate all elements, allowing different users to have their screens and reports in their language and whilst allowing documents to be printed in the format and language of the customer or vendor. Dates and address formats are also printed in the format specified for the country of destination.

As the translation is dictionary based, the translation is much more consistent than other applications with different tool­sets for translating the different elements.

For more Information on Multi's, refer to the The Multi's Chapter.

STRUCTURAL CHANGES MID-STREAM

After an application is in production or even during implementation, users often request changes in the information structure. There are many reasons for this need to change. During the use of the application, people realize that information is not needed or additional information is required for decision-making. In addition, changes in the business may require the collection of additional information.

Most applications do not allow any change mid stream or alternatively a change requires the same effort as implementing the system from scratch.

Tree Structure

Compiere allows the user to define additional dimensions. These dimensions can be validated via lists or table look-ups. All dimensions allow the definition of trees. These summary levels allow the user to reflect the organization structure or the balance sheet and income statement positions in a logical tree structure. Changes to the tree structure are possible at any time and are reflected in the data structures immediately.

Every information dimension has a primary tree and can have additional summary trees. This may be required if it is desired to maintain the 'old' and 'new' structure for comparison ­or if it is necessary to support different parallel business partner hierarchies, e.g. one by Industry, another by category (wholesale, retail, consumer).

Many applications do not have the ability to structure information dimensions, which results in unnecessary data entry and overhead. For example: if a user wants information on branch and division levels and divisions are made up of branches, the user may have to enter the two fields branch and division and define rules, so that users cannot enter a wrong branch for a given division and vice versa.

INFORMATION, DIMENSIONS, AND TREES

Compiere provides an extensive list of predefined dimensions:

  • Organization
    • Owning  (balance sheet organization)
    • Transacting (executing organization or service center)
  • Natural Account
  • Date and Time
    • Transaction
    • Accounting
  • Product and Product Category
  • Business Partner and Business Partner Category
  • Project
  • Marketing
    • Channel
    • Campaign
  • Location (Warehouse, Business Partner)
    • From
    • To
  • Activity (for activity based costing)

Standard Costing

In Standard Costing, the system maintains a standard cost and accumulates the differences between actual costs and standard costs over time. Due to changing prices, it is necessary to set new standard prices periodically. The new standard price can be set manually or from sources like:

  • Current Average Price
  • Last PO
  • (Purchase) Pricelist

When an item is received, it is posted with the standard cost price. When the matched invoice is posted, the difference between the standard price and the actual price is posted to a standard cost differences account. If product related credit memos or early payment discounts are received later, or realized currency gain/losses occur, these amounts are also posted to the cost difference account. The balance on that account reflects how closely the standard cost price matches the actual costs.

Actual Costing

The actual cost price is adjusted when products with changed costs are received.

When an item is received, it is posted at the actual cost price. If there is no current actual cost price, the standard cost price is used, or if that does not exist the purchase order price is used. When the matched invoice is posted, the difference between the cost price used and the actual price is posted and the costs are adjusted. If product related credit memos or early payment discounts are received later, or realized currency gains/losses occur, these amounts are also posted to the product account.

One major issue in actual costing is correcting the costs if the product has been sold before receiving the invoice. Presently, Compiere does not retroactively adjust the costs used in the receipt and sales transaction, but adjusts the actual cost price for future use.

LIFO and FIFO Costing

With effect from the release of the enhanced product costing version, additional product costing options such as LIFO and FIFO will be supported together with the use of average costing for accounting purposes as well as the recording of averages as performed in earlier versions.

For more information on costing, refer to the Costing Chapter.

AUTOMATIC DATA COLLECTION

Data entry needs to be as efficient as possible, which is equivalent to entering as few fields as possible. Compiere provides a framework, which derives information automatically from the transaction context to minimize the amount of data that the user needs to enter. Users can also select choices.

This is a significant advantage over other applications. For example, the Order Entry functionality is not usually 'aware' of the information needs of Customer Relationship functionality, this results in information that is not available or needs to be derived from existing data with subsequent loss of required detail.

Getting the information right from the source is a tremendous benefit. But, if the information is not needed, the user is not asked.

COMBINATION OF DIMENSIONS

For reporting purposes, the user can slice and dice any combination of information dimensions. For all transactions the source and accounting currency information is maintained in addition to unit of measure and quantity.

Users can view financial results by Business Partner and Region or Product Group and date or period.

LOCATING THE ACCOUNTING BOOK

An Accounting Book is often defined as the combination of Chart of Accounts, Calendar, Currency, with implied accounting rules. Compiere broadens that definition by storing the information on the lowest level of granularity (transactions). The traditional reporting is then just a summary level.

The information required for a business decision is often not found in traditional accounting systems, so additional data warehousing systems maintain parallel data to accommodate this need. Compiere is based on a data warehousing architecture to allow flexible reporting.

Compiere maintains both the accounting and transaction date. This is required for revenue recognition rules of service contracts or if the costs were for another period, (e.g. next year's rent). If it is necessary to account using different accounting principles (e.g. accrual and cash based), the accounting periods can be different. Reporting can be based on either view.

This bottom up approach also allows meeting the Italian, French and Latin-American accounting requirements without artificial constructs. As the generation of accounting lines is rule based, no superfluous accounting lines are generated. Compiere makes the accounting easy to understand and reconcile. It even reconciles differences between disparate accounting methods (e.g. cash and accrual based or using different costing methods).

Labels
  • None