Skip to content

Topic COA

Jump to bottom Edit New page
Chris Travers edited this page Jul 5, 2017 · 7 revisions

Requirements

If you are looking for implementation see:

Strategic Requirements

The basic Chart of Accounts structure must be free-standing. It must not depend on other functionality of the database because it is a bootstrapped piece of functionality. Ideally we should have an interface which is such that the COA could be split off to a PostgreSQL extension, Perl modules, and a web front-end, perhaps with the basic journal and ledger support to be done later.

The Chart of Accounts structure must support hierarchical representation of the accounts themselves in a single hierarchy and must support manual translation.

Accounts may be deleted only when never used, but may be set inactive if and only if they have a current balance of 0.

Account Categorisation

Accounts may be categorised into any of 7 classifications with a number of important options:

  • Asset
  • Liability
  • Equity (Permanent)
  • Equity (Temporary)
  • Income
  • Expense
  • Suspense

Permanent equity accounts usually represent investment and de-investment (buying in and buying out) as well as retained earnings. Temporary equity accounts represent drawing accounts, dividends, and the like. Suspense accounts represent temporarily uncategorised amounts, and we should expect that during closing transactions we can enforce a 0 balance on closing dates.

Asset, temporary equity, and expense accounts have a normal balance of debit. Liability, permament equity, income, and suspense accounts have a normal balance of credit.

Other Attributes

Accounts may be "contra" accounts and have a normal balance will be opposite what it would normally be.

Compatibility

For compatibility purposes, it may be necessary to disable removing this attribute once set for now.

Mapping to Application Contexts

Accounts may be mapped to application contexts. This is purely forward looking. Specific lines in a transaction MAY map to an application context.

  • Application contexts (outside of the COA module) are not defined here.
  • Changing an application context MUST NOT change the reporting of that line in the future
  • Application components MAY set application contexts on line items of transactions
  • Summary, tax, and recon classifications will be moved to contexts.

Application contexts take on the role previously used by the account_link as well as a few other cases. In other words they are a superset, functionality-wise, of the old account_link functionality. There are, however, several major differences.

  • Responsibility: * All account_link entries are the responsibility and property of the accounts themselves.
    * Application contexts are the responsibility of the functional modules (AR, AP, Inventory, Assets, etc).
  • Applicability: * The account_link system annotates accounts. * Application contexts annotate mappings anywhere in the system. * Possible that other main contexts (entity class for example) could be moved to this.

A few possible case studies show the direction we can go here.

  1. Changing default account mapping structure for ECA's * Currently these are hardwired into the ECA table * We could map an ECA context (entity_class today) to an account context module ('customer' -> 'ar') * It would then be easy to query applicable accounts and allow these to be set by a more dynamic front-end.
  2. Cash Flow Statement * Cash flow report lines are determined by the functional role of the journal line aggregated.
    • Account is not really the right abstraction
    • Neither is the transaction type itself (since transactions can cross applicable types particularly with adjustments).
    • Only the functional role that the journal line had in the transaction can safely be used to determine this. * Currently any cash flow statement we could possibly generate would follow accounts rather than line items
    • Account links are not safe to use here
    • They are properties of an account rather than an account mapping * A future cash flow statement could use application contexts for line items
    • Receipts determined by journal line context * In this case the journal line context tells us the role of the line item, not the transaction * Therefore we could enable adjustments to take context into account
  3. Extensions * Currently we rely on a custom flag on account_link to show which ones are not managed by us * However in this case, automatic hierarchy becomes easier, and the client can decide what contexts to manage. * Result is looser coupling than we have with account_link

COA contexts

The following contexts are assigned to the COA module.

  • Tax -- accounts with this context may be used for additional taxes
  • Recon -- accounts with this context may be set up for reconciliation workflows

Removing a context from an account MAY prevent further entries made on that context but MUST NOT have any backwards-facing implications on reporting for any rewritten portions of the application. In other words, removing an account's AR Payment context MUST NOT prevent existing payments from displaying properly.

Compatibility

The above rules regarding application context handling may not be enforced until the rewrite of appropriate contexts however.

Operational Requirements

when I create an account object
and I save it
the web service returns it to me

Given an account object with no transactions
and I delete it
and I try to retrieve it again
the web server returns a 404 error

URL layout

Here BASE_URL will be set by other aspects. We set our API component url based on the ledgersmb web service model.

Version 1.0 and higher:

GET BASE_URL/account/:version/

Retrieves the COA list with balances (compatible with current behavior)

PUT BASE_URL/account/:version/new

Creates a new account and redirects to it.

GET BASE_URL/account/:version/:number

retrieves the current COA, without balance.

POST BASE_URL/account/:version/:number

saves the COA with the specified ID.

GET BASE_URL/account/:version/:number/translation

Gets the manual translations of the account in all languages.

GET BASE_URL/account/:version/:number/translation/:language

Gets the manual translation for a single language

POST BASE_URL/account/:version/:number/translation/:language

Sets a manual translation for a single language

PATCH BASE_URL/account/:version/:number/translation/

Updates supplied languages.

GET BASE_URL/account/:version/trunk

Returns a list of account trunk nodes, sorted topologically.

WS API specifications, version 1.0

  • Every account entry submitted MUST have a hierarchy attribute set. This MUST be either 'trunk' OR 'leaf'
    • Trunk nodes map to account headers
    • Leaf nodes map to accounts themselves
  • Trunk fields:
    • Required fields
      • id: Int (or null if new trunk node)
      • number: alpha
      • description: alpha
    • Optional fields
      • parent: Int (set if not a top-level node)
  • Leaf fields:
    • Required fields
      • id: Int (or null if new account)
      • parent: Int (id of header)
      • number: alpha
      • description: alpha
      • type: char, one of
        • A = Asset
        • L = Liability
        • D = Temporary Equity (Dividend/Drawing)
        • Q = Permanent Equity (Capitalization/Retained Earnings)
        • I = Income
        • E = Expense
        • S = Suspense
    • Optional fields
      • contra: bool
      • contexts: Object { key: bool }
  • Translation object structure
    • key/value, key is language code, value is translation string
    • null means delete the language code
    • No facilities for replacing all language translations without querying first.
Add a custom footer
Add a custom sidebar
Clone this wiki locally