Key Concepts

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

Table of Contents{{#if: | | [[{{{2}}}]] }}{{#if: | | [[{{{3}}}]] }}{{#if: | | [[{{{4}}}]] }}{{#if: | | [[{{{5}}}]] }} | Key Concepts{{#if: | | [[{{{next}}}]] }} ⇒

This section is a summary of key concepts you will need to understand as you read the rest of this manual.

Clients, Organizations & Users

ADempiere is built on an organizational model where the Client is the highest level of an independent business entity. Each Client will have one or more Organizations reporting to it. The Client defines the accounting parameters (Accounting Schema, Tree definition, Non Monetary UOM's) that are used by all the Organizations under that client. An Organization is a legal entity (business) with its own banking, and business processes. Each Organization can have a number of Users. The Users can be restricted to an organization, multiple organizations or the client through Roles.

When you login to ADempiere, you are logging is as a User with a specific Role into a specific Client and Organization.

Any implementation of ADempiere for a business starts with creating the Client. See Creating the Client.

Accounting Schema, Combinations, Defaults and keeping track of the money

ADempiere is designed to work with multiple sets of books or "Accounting Schema". Every process that creates accounting consequences does so in all the schema. Schema can be based in different currencies or apply different rules and accounting for a given circumstance.

One of the key benefits of ADempiere is the manner in which accounting consequences are defined. Rather than a single number signifying an account, ADempiere uses a number of fields to generate references to the accounting data. These fields include the traditional account number but add business partners, products, organizations, projects, and other "dimensions". This makes it easy to generate reports or lists of accounting consequences by filtering the various dimensions.

A particular set of dimensions is called a combination and the combinations usually include placeholders for dimensions that will be filled in when a particular transaction takes place. For example the combination defined for product revenue will specify the revenue account but have place holders for the product. The product information will be added when an invoice is completed.

It is important when establishing a new client to completely define the default combinations required by the system in the initial Chart of Accounts. This is a key part of creating a new client. See Chart of Accounts for more information.

Documents and Document Processing

ADempiere is a document based system. The processes in the software mimic a document workflow of generation, checks and approvals, action and follow-up. The documents also go through stages of preparation from draft, to prepared, to complete. They can also be voided, reversed and so on.

Most documents, when they are completed, create some accounting consequences in the system. The consequences are created when the document is "posted" and the process that happens is particular to the document. It is important to understand that no accounting consequences can be created without a document and that any consequence or accounting entry can be traced back to the document that generated it.

The document processing is defined by workflows and every document has one. Workflows can be fully automated with documents created and processed behind the scenes with no user intervention. It is also possible to create complex multi-level approval workflows to manage and provide oversight and control with the documents passed from user to supervisor and back.

Another powerful feature of ADempiere is the inter-organizational transactions that can take place. In a complex logistics environment where one organization/warehouse supplies another, its possible to link the organizations to business partners and the organizations can then "do business" with the other business partner. Behind the scene, when a document is created in one organization, say a purchase order, a counter document, in this case a sales order, is automatically created in the other organization. A shipment generates a receipt and so on. This ensures that the accounting across the client is consistent and it also saves a lot of time.

Database Tables and Common Fields

In ADempiere, most database tables contain a set of common fields that are used by most windows or by the underlying rules and software. These are:

  • AD_Ord_ID
  • AD_Client_ID
  • Created
  • CreatedBy
  • IsActive
  • Name
  • Description
  • Comment/Help
  • Updated
  • UpdatedBy
  • Value/Search Key

There is one other field of the form <table name>_ID that contains the ID key of the records in the table.

Security: Users and Roles

Users are defined as business partner contacts where the business partner is an employee and the user has a password defined. There needs to be a single business partner for each user.

ADempiere implements security through roles which define what elements of the data, menu, processes etc each user has access to. While the administration role may see all aspects of the system and a menu of over 700 entries, a particular functional role may see a menu with a small handful of windows and reports. Roles also help define the workflow and approval levels of the users.

There are a few special users and roles:

  • The System user controls the application dictionary and a few other configuration items for the application. The system user can not access client data.
  • SuperUser is a system level user that has access to all clients and can access any role.
  • For each client, there is an administration user and role created when the client is created and a more restricted user and role.