arapXML 
Home  XML Schema OMG submission Use Cases Discussion  Requirements Research About arapXML
Overview of OAGIS postjournal format For General Ledger Data

The OAGIS schemas are at http://www.openapplications.org.   Oagis Post_Journal BOD is a general ledger schema intended for interoperability among many accounting systems and scenarios, particularly among ERP systems.   Post_Journal is a classic double entry (CDEA) header/rows structure.  Note that the Amount and DateTime are also accompanied by "qualifiers" (attributes in XML) not shown on the diagram, but listed in a separate OAGIS segments schema (see listing at bottom of this page).  The concept of qualifiers is quite pervasive in EDIFACT as well as in these core elements of OAG integration specification.

    

1. Post Journal - Revision 004  
 

 1.0 Overview

This section describes the Business Service Request named POST JOURNAL, the Verb being POST and the Noun being JOURNAL.

The purpose of the POST JOURNAL Business Object Document is to transmit data necessary to create a journal entry from any sub ledger business application to a general ledger application.

Many applications in the enterprise environment create data that cause changes in the account balances of a general ledger application. Some components that have activity which will be reflected in a general ledger application are:

 

    1. Benefits
    2. Costing
    3. Human Resources
    4. Inventory Control
  1. Manufacturing
  2. Payroll
  3. Production
  4. Treasury

By no means is this a complete list of all the components that create activity which generate a journal entry. Many tasks that occur within applications cause the creation of a General Ledger journal entry. Tasks relate directly to the Component. For example, the adjustment of inventory value is a task that occurs within the Inventory Control Component. Some of the tasks that would be catalysts for changes in a general ledger include:

 

  1. Receiving Inventory
  2. Issuing Inventory
  3. Transferring Inventory
  4. Adjusting Inventory Value
  1. Adjusting inventory count
  2. Calculating Material Variances
  3. Calculating Labor Variances
  4. Calculating Overhead Variances

Again, this list is only a sample of the tasks that cause updates to balances in a general ledger application via a journal entry. This BSR may be used individually, or as part of a larger interface scenario. The picture below visualizes a possible use of this BSR.

1.1 POST JOURNAL

The Business Service Request POST JOURNAL requires two Data Types:

    1. JEHEADER - Journal Entry Header information. This Data Type is required
    2. JELINE - Journal Entry Detail Lines information. At least one occurrence of this Data Type must exist for each occurrence of the JEHEADER Data Type

1.2 JEHEADER


The Data Type, "JEHEADER", is the first of two Data Types the Business Service Request "POST JOURNAL" uses.

For each journal entry represented in the Business Data Area, there must be one occurrence of the JEHEADER Data Type at the beginning of the Business Data Area.

Listed are all the Field Identifiers and Segments that are valid for use within the JEHEADER Data Type. There may be occasion for a similar field to exist in both the JEHEADER and the JELINE, such as DESCRIPTN.

Required JEHEADER Data

Name

Appendix

GLENTITYS

C

ORIGREF

C

Optional JEHEADER Data

Name

Appendix

AMOUNT(DOCUMENT)(T)

D

DATETIME(DOCUMENT)

D

DATETIME(PAYEND)

D

DESCRIPTN

C

DOCTYPE

C

JEID

C

LEDGER

C

USERAREA  

C

USERID

C

1.3 JELINE

The Data Type, "jeline", is the second of two Data Types the Business Service Request "post journal" uses. There must be at least one occurrence of the JELINE for every occurrence of the JEHEADER. Typically, there will be at least two occurrences given the common accounting rule of every debit requiring an equally balancing credit. Listed are all the Field Identifiers and Segments that are valid within the JELINE Data Type.

Required JELINE Data

Name

Appendix

AMOUNT(ACTUAL)(T)

D

GLNOMACCT

C

DATETIME(ACCOUNTING) or 
(ACCTPERIOD and ACCTYEAR) *

C

*  Note: In addition to the required AMOUNT  and GLNOMACCT, OAGIS requires that each JELINE must also include one of the following:

        1) DATETIME(ACCOUNTING) or,
        2) ACCTPERIOD and ACCTYEAR      

Optional JELINE Data

Name

Appendix

AMOUNT(ACTUAL)(F)

D

BUSNAREA

C

COSTCENTER

C

DEPARTMENT

C

DESCRIPTN

C

DIVISION

C

ELEMENT1 - ELEMENT999

C

FUND

C

GEOGRAPHY

C

GLENTITYD

C

ITEM

C

PRODCTLINE

C

PRODORDER

C

PROFITCTR

C

PROJACTVTY

C

PROJECT

C

PROJRESEL1 - PROJRESEL9

C

REASONCODE

C

REF1 - REF999

C

SALESORDID

C

UNIT

C

USERAREA

C

WAREHOUSE

C

WORKORDER

C

 

 

Selected Definitions from Appendices C and D

glentitys

G/L Entity source code

GLENTITYS is the primary balancing segment of the GL Account structure. Typically, this is the owning entity for the transaction. A G/L entity is the smallest organizational unit for which individual financial statements must be drawn up according to relevant commercial law. P&L statements are required at this level.

Synonyms


origREF

original REFERENCE identifier

ORIGREF is the link that ties back to a sub ledger transaction entry ID. It is the identifier of an original transaction or document. For example, it could be the receipt or the summarized inventory activity. This is the singular field that refers to an audit record. Together with the Sender information, the ORIGREF is part of the referencing system, which will enable drill back audit trail functionality.

Synonyms


Amount

The amount segment is used to communicate any monetary data between applications.

Amount

- Qualifier

- Type

- Value

- NumOfDec

- Sign

- Currency

- DrCr

Qualifier

Qualifier is a 10-character field which "qualifies" the Amount segment. This field is left justified with trailing spaces. The Qualifier value must be a valid value of the Qualifiers defined for the Amount segment.

Each Qualifier value is defined in more detail in the following pages of this appendix.

Type

Type determines whether the currency of the AMOUNT is transactional or functional. Transactional currency represents the currency of the transaction or document. Functional currency represents the currency stored and reported by the General Ledger entity. A transaction may only have one transactional currency yet multiple functional currencies may be used. An example of multiple functional currencies exists when subsidiaries report on a different currency than the headquarters.

Current valid values are:

    1. T (Transactional)
    2. F (functional)

Value

Value is a 40-character field that stores the value of the monetary amount. The Value field is numeric only, right justified with leading zeros. No decimal indicators or thousand separators are allowed. The only valid characters in the Value field are:

0, 1, 2, 3, 4, 5, 6, 7, 8, or 9

NumOfDec

NumOfDec is a one-character field that indicates the number of decimals represented in the value field. The NumOfDec field is numeric only. The only valid characters in the NumOfDec field are:

0, 1, 2, 3, 4, 5, 6, 7, 8, or 9

Sign

Sign is a one-character field that indicates whether the Amount is a positive or negative monetary amount. If the Value is zero, the Sign must be positive. The only valid characters in the Sign field are:

"+" Or "-"

Currency

Currency is a three-character field that indicates the currency of the monetary amount. Valid currency codes are listed in ISO standard number 4217.

DrCr

DrCr is a one-character field that indicates whether the Amount is a debit or a credit when posting to accounting applications. The only valid characters, other than space, in the Sign field are:

"D" = Debit

"C" = Credit

The DrCr field may be filled with a space. If the DrCr is a space, the receiving application will default the debit or credit status based on the Sign. If the Sign is "+", the default for the DrCr field is "D" (Debit). If the Sign is "-", the default for the DrCr field is "C" (Credit).


 

amount (ACTUAL)

ACTUAL amount

This segment is the actual monetary amount of the transaction.


DateTime

The DateTime segment is used to communicate the date and time, including the time zone of the Business Object Document, between applications.

DateTime

- Qualifier;

- Year;

- Month;

- Day;

- Hour;

- Minute;

- Second;

- SubSecond;

- TimeZone;

Qualifier

A 10-character field which "qualifies" the DateTime segment. This field is left justified with trailing spaces. The Qualifier value must be a valid value of the Qualifiers defined for the DateTime segment.

Each Qualifier value is defined in more detail in the following pages of this appendix.

Year

Year is a four-character field that represents the year in YYYY format. This field is numeric only and must contain a valid year.

Month

Month is a two-character field that represents the month in MM format. This field is numeric, right justified with leading zeros.

The valid values for the Month are: 01 through 12

Day

Day is a two-character field that represents the day of the month in DD format. This field is numeric only, right justified with leading zeros. Months with fewer than 31 days must not exceed their maximum number of days.

The valid values for the Day are: 01 through 31

Hour

Hour is a two-character field that represents the hour in HH format using the military style of 24 hours a day. For example, 5:00PM would be 17. This field is numeric only, right justified with leading zeros.

The valid values for the Hour are: 00 through 24

The Hour at exactly midnight is 24. Immediately after midnight, the Hour is 00 until 01 o’clock.

Minute

Minute is a two-character field that represents the minute in MM format. This field is numeric only, right justified with leading zeros.

The valid values for the Minute are: 00 through 59

Second

Second is a two-character field that represents the second in SS format. This field is numeric only, right justified with leading zeros.

The valid values for the Second are: 00 through 59

SubSecond

SubSecond is a four-character field that represents the sub second to 1/10,000 precision. This field is numeric only, right justified with leading zeros.

The valid values for the SubSecond are: 0000 through 9999

TimeZone

TimeZone is a five-character field that indicates the time zone of the time indicated. Valid time zone codes are listed in Appendix E of OAGIS.


datetime (document)

document date Segment

This segment is the date of the referenced or original document that caused the transaction to occur.


datetime (PAYEND)

PAYROLL PERIOD END date

This segment is the date of the payroll period ending date.


JeID

Journal Entry identifier

JEID is the externally created identifier for a general ledger journal entry.


LEDGER

LEDGER IDENTIFIER

LEDGER identifies the financial ledger to be used when updating balances.

Synonyms

Ledger type


descriptn

description Identifier

DESCRIPTN is a free-form description of the transaction or any portion of the transaction.

glentityd

g/l entity Destination code

GLENTITYD is the primary balancing segment of the G/L Account structure. P&L statements are required at this level. A G/L entity is the smallest organizational unit for which individual financial statements must be drawn up according to relevant commercial law. Entries here, when they do not match the GLENTITYS value, indicate an inter-company transaction.

Synonyms

 

 


doctype

 

document type

DOCTYPE is a classification of the document or business transaction. It is also known as document code.

 


Userid

user identifier

USERID is the user’s enterprise-wide identifier. It is also known as the user code.

Synonyms


GLNOMACCT

G/l nominal account code

GLNOMACCT is an entry in the GL chart of accounts. It is the "what", not the "who" or "where".

Examples include:
  • Assets
  • Office Supplies
  • Revenues
  • Salaries
  • Travel

 

Synonyms
  • Account Number
  • GL Natural Account
  • Object Account

 


datetime (ACCOUNTING)

ACCOUNTING date

This segment is the date that is used to determine the accounting period the transaction is posted within. It is also known as the effective or post date.


busnarea

business area code

BUSNAREA are special economic or organizational units within an enterprise, such as a division, with a particular activity for which internal balance sheets and P&L statements can be created. This may be used for reporting or second level balancing.


Costcenter

cost center code

COSTCENTER is an accumulator of cost information that may be an organizational unit or area of responsibility. It is an organization code that allows a grouping of expenses and costs.

Synonyms


Time Zones

The following set of codes are used within the DateTime segment to indicate which time zone is being used for the Business Object Document. The time zone is represented as a five-character code. The first character indicates the direction from the Coordinated Universal Time (UTC) (sometimes referenced as Greenwich Mean Time or Zulu Time) by using a positive (+) character for time zones which are east of the zero meridian (i.e. ahead of UTC) 

OAG-members are responsible for any adjustments due to zones that use the daylight savings time zones.

UTC Timezones for US locations

-1000   Hawaii
-0900   Alaska
-0800   Pacific Time (US & Canada)
-0700   Mountain Time (US & Canada)
-0600   Central Time (US & Canada)
-0500   Eastern Time (US & Canada)


UserArea

user area

USERAREA identifies the user’s unique area for data that is implementation specific. It is a named but unspecified Open Applications Group Field Identifier. Directions for use of this special Field Identifier are below.

The USERAREA is defined by embedding meta data tags for each new Field Identifier or new Segment needed within this meta data area. When a new Field Identifier or a new Segment is determined to be necessary, and it is not included in the OAGIS specification, new tags can be developed by the project team for the specific integration project. These new tags can then be used to describe the fields and segments within the USERAREA. The USERAREA may contain multiple fields or segments coded in this way. These are all embedded within the one special field called USERAREA.

This results in a special case where we have Field Identifiers and Segments defined within a Field Identifier. This use of double meta data tags is intended to be a temporary, but practical solution, and is not a violation of OAGIS compliance.

The new Field Identifiers and the new Segments may then be submitted to the Open Applications Group as proposed additions to OAGIS. The Open Applications Group will make best efforts to quickly consider all proposed submissions.

The USERAREA is always the last Field Identifier in a Data Type.




Datetime qualifiers in OAGIS

 <!ENTITY % SEG_DATETIME_QUALIFIERS "(ACCOUNTING | ACTEND | ACTSTART | APPREQ | APPROVAL | AVAILABLE | BKTEND | BKTSTART | CANCEL | CHANGEDATE | COMPDATE | CREATION | CUMULATIVE | DELIVACT | DELIVSCHED | DISCNT | DOCUMENT | DUE | EARLSTEFF | EARLSTSHIP | EFFECTIVE | ENGCHG | EXECFINISH | EXECSTART | EXPIRATION | FAILDATE | FORECASTF | FORECASTS | FROM | GENERATION | IMPL | INVOICE | LABORFINSH | LABORSTART | LASTUSED | LOADING | MATCHING | MSMENTDATE | NEEDDELV | OPFINISH | OPSTART | PAYEND | PLANEND | PLANSTART | PO | PROMDELV | PROMSHIP | PYMTTERM | RECEIVED | REPORTDATE | REPORTNGFN | REPORTNGST | REQUIRED | RESORCDWNF | RESORCDWNS | 
RSPDDATE | RSPDOCGEN | SCHEND | SCHSTART | SETUPFINSH | SETUPSTART | SHIP | SHIPSCHED | STATUSDATE | TEARDOWNF | TEARDOWNS | TO |  %SEG_DATETIME_QUALIFIERS_EXTENSION;)">

 

Amount qualifiers in OAGIS


<!ENTITY % SEG_AMOUNT_QUALIFIERS "(ACTUAL | APPRVORD | AVAILABLE | BUDGET | COMMISSION | DECLAREVAL | DSCPRCNT | DSCVALUE | DISCNT | DOCUMENT | ESTENGIMP | ESTFREIGHT | ESTHRS | ESTIMATE | ESTMANIMP | ESTUCOST | EXTENDED | FREIGHT | ITEM | OPENITEM | ORDER | ORDLIMIT | PAYRATE | RATE | PRCBRK | TAX | TAXBASE | TOTAL | TOTLIMIT | %SEG_AMOUNT_QUALIFIERS_EXTENSION;)">

The above is copyrighted OAGI, reprinted with permission.