Patent Application
20060184433
The present invention relates to an application for populating business transaction information in a general ledger table or record table based on transformation rules.
In particular, the present invention has application for capturing financial details involved in a business transaction using a posting pipeline process based on meta data driven transformation rules.
Accounting applications or software can generate financial documents such a sales invoice, credit memo, vendor invoice and other documents, which include transactions for a particular customer, vendor or financial account. For accounting purposes, the transactions in these documents must be populated or posted to related financial accounts or a general ledger. For example, transactions or items in a sales invoice are generally posted in an income account, cost of goods and services (COGS) account and accounts receivable (A/R).
Postings can be implemented by a posting engine to generate account postings. However, different business rules in different countries can require different posting options and it can be difficult to adapt the posting engine. The present invention provides a solution for posting or populating transactions by isolating the transformation rules and making the posting process totally data driven, thereby increasing the adaptablity of the posting engine.
The present invention relates to an application or method of populating a transaction from one document to another document using procedures associated with the transaction or document type. In the embodiments described, the application or method posts a financial transaction from a financial document, such as a sales invoice or vendor bill to a set of financial accounts, such as A/R or COGS. In embodiments described, the application or method employs posting procedures for posting types associated with the document type and document line type of the document.
Meta data on the document, document line types and posting classes determine what type of posting classes are invoked during the posting process and what postings are generated per document line for a document.
The present invention relates to a system for posting or populating a transaction, such as a financial transaction to an account or document. The invention can be implemented in a computing environment as illustrated in
The computing system environment 100 shown in
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Those skilled in the art can implement aspects of the present invention as instructions stored on computer readable media based on the description and figures provided herein.
The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
With reference to
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 100. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier WAV or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, FR, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during startup, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way o example, and not limitation,
The computer 110 may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed above and illustrated in
A user may enter commands and information into the computer 110 through input devices such as a keyboard 162, a microphone 163, and a pointing device 161, such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 190.
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110. The logical connections depicted in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user-input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
It should be noted that the present invention can be carried out on a computer system such as that described with respect to
The present invention provides a data driven approach to encapsulate the posting rules for documents representing a real word business transaction. Embodiments of the posting process described in the invention or application transform inputs from a document, document lines to output that creates entries for a general ledger in an accounting application. The transformation process embodies several stages analogous to a pipeline model.
As shown in
In the embodiment shown, the document 204 includes a header 220, a document identification 222 and a document type attribute 224, such as invoice. The header 220 of the document includes, for example, customer or vendor information. The document lines 202 include a document line identification 226 and a document line type attribute 228, such as invoice item.
The document 204 is attributed to a posting type 208 and the posting type 208 is attributed to the document type 224 and document line type 228 to generate a transaction posting. The document is also attributed to the document line type 228 and the document line type 228 is attributed to the document type 224 to associate the document line with the document. For example, for a sales invoice document type, the document line types=(itemline type, summary line type).
The posting type 208 is attributed with the document type 224 and document line type 228 to implement the posting for the associated document type and document line type. The posting procedure 206 retrieves posting details from the document and document lines to generate the posting lines 200 as previously described based upon the document type 224 and document line type 228.
In a particular illustrated embodiment, the document attribute includes a posting notation [IsTranactional=True] to indicate that the document supports posting. This or other attributes can be automatically selected or generated based upon the document type created in the accounting or management application.
The posting procedures post transactions to a particular posting account 214 based upon the posting class or type, document type and/or document line type. The posting account 214 can include a source account and offset account. In particular, the posting procedure includes posting account information 230 to post the transaction based upon the document type and/or document line type 228.
For different posting types, posting account details are retrieved from the document through account attributes 232 associated with the document or document line. For example, the posting type may generate a posting to a customer or financial account, the identification of which is retrieved from the document. Depending upon the posting type, the posting procedure can post to an offset account, for example, for a sales invoice document, a CustomerAccount is attributed with [IsOffsetAccount=True] to post to an offset account for double entry accounting.
In the embodiment shown, the rules table 250 includes an association for an item line of a sales invoice document to income and COGS posting types. The application uses this association to call or invoke the income and COGS posting procedures to post the item line transaction of the invoice document. This call or posting can be automatically invoked for example upon completion of the document when the document is saved or as directed by a user through an application interface.
In an illustrated embodiment, the application uses posting classes, such as FIFO (First-In-First-Out) Posting Class, SubTotal Posting Class, Deposit Posting Class, Payment Posting Class, Journal Posting Class and Tax Posting Class to invoke different posting types. Posting classes stamp every posting with a posting type specific for that posting class. A posting class can implement multiple posting types, but multiple posting classes cannot implement the same posting type.
As previously described, the posting procedures generate posting lines 200 as illustrated in
For example, the posting procedures retrieve the transaction ID 260 from the document identification 222, the Line ID 262 from the document line identification 226 and the amount from the document line 202. The transaction or amount is posted to source and offset account defined in the posting procedure for the document type. In one embodiment, specific customer or item account numbers or details for the posting account 266, 268 are retrieved by the posting procedure from the document.
For example, for an invoice document, the income posting procedure retrieves customer and item accounts and generates an income posting to inventory asset and an offset to A/R and for COGS posting type, the posting procedure retrieves a customer account and item account and generates a posting to COGS with offset to A/R and to A/R and offset posting to an inventory asset account for the customer and item account details retrieved from the document.
The posting engine or module 210 previously shown in
In one embodiment, the present invention implements tax postings for sales or purchase documents using a tax posting class or type which implements different tax postings, such as line tax posting, sales tax posting, value added tax (VAT) posting. As illustrated in
The tax engine 280 will return a number of tax lines containing the taxvendorID, Tax amount based upon applicable taxes depending upon the source or origin of the transaction, such as sales tax or value added tax (VAT). In particular, the tax posting lines 282 are generated based on tax codes common to the particular sales or purchase tax group 284, e.g. for a customer or vendor and item group or identification 286 as illustrated in
Some transaction postings such as payments include a settlement against other transactions. For instance, in the case of a customer or vendor payment against several invoices, the paid amount against each invoice needs to be settled against the corresponding invoice or document.
Settlement includes the following attributes:
Hence, in the case of a payment document settled against an invoice, the document lines in the document will contain the TransactionIDs associated with each invoice (or settlement document) against which the payment is to be settled.
The following table identifies examples of posting types and posting accounts for different financial documents and accounting applications, although application is not limited to the specific examples shown.
The following table illustrates example posting types for various document types and document line types, however, application is not limited to the specific examples included.
Although the present invention has been described with reference to particular embodiments, workers skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the invention. In particular, embodiments of the present invention have been described with respect to financial transaction postings. Application of the present invention is not limited to financial transaction postings and can be used to populate other data management applications such as work load management system.
