Patent Application
20130073437
Enterprise resource planning (ERP) systems integrate internal and external management information across an entire organization. ERP systems may embrace finance/accounting, manufacturing, sales and service, customer relationship management, human resource management, and the like. ERP systems may be used to automate activities between these different resources within an integrated software application. One purpose may be to facilitate the flow of information between business functions across boundaries of an organization, and to manage the connections between outside stakeholders and internal resources.
Each resource within an ERP system may include many subsystems to manage various resources. For example, a finance/accounting application in an ERP system may be distributed among many different departments within an organization, and may be used to manage many different types of financial accounts. The finance/accounting application may include various traditional accounting features, such as various ledgers, subledgers, journals, and a general ledger. Each of these accounting features is typically implemented with their own interfaces and applications within the ERP. Therefore, improvements in the art may be desirable.
In one embodiment, a method of previewing projected balance impacts in an Enterprise Financial Accounting System is presented. The method may include receiving one or more journal entries that have not been posted to an accounting ledger and displaying the one or more journal entries in a journal portlet. The method may further include receiving a selection of a first journal entry from the one or more journal entries. In one embodiment, the first journal entry may comprise a first amount. The method may also include determining a first ledger that is associated with the first amount. The method may additionally include receiving a start date, and receiving a beginning balance representing a balance of the first ledger on the start date. The method may further include receiving an activity total comprising a sum of journal entries posted to the first ledger between the start date and a current date, and determining a projected balance representing a combination of the beginning balance, the activity total, and the first amount. The method may also include displaying a projected balances portlet together with the journal portlet, wherein the projected balances portlet may include the beginning balance, the activity total, the first amount, and the projected balance.
In one embodiment, the method may also include receiving an indication that the first amount should be posted to the first ledger; determining that posting the first amount to the first ledger requires an authorization; sending a request to authorize posting the first amount to the first ledger; receiving the authorization to post the first amount to the first ledger, wherein the authorization is based at least in part on the projected balance; and automatically posting the first amount to the first ledger in response to receiving the authorization. In another embodiment, the method may further include displaying an indication to a user that posting the first amount to the first ledger requires the authorization. The method may additionally include determining that the first journal entry further comprises a second amount; determining a second ledger that is associated with the second amount; receiving a second beginning balance representing a balance of the second ledger on the start date; receiving a second activity total comprising a sum of journal entries posted to the second ledger between the start date and the current date; determining a second projected balance representing a combination of the second beginning balance, the second activity total, and the second amount; and displaying, in the projected balances portlet together with the beginning balance, the activity total, the first amount, and the projected balance: an identifier of the first ledger, an identifier of the second ledger, the second beginning balance, the second activity total, the second amount, and the second projected balance.
In one embodiment, the method may further include receiving a selection of a second journal entry from the one or more journal entries, where the second journal entry may comprise a second amount; determining that the second amount of the second journal entry is associated with the first ledger; and displaying in the projected balances portlet the second amount, where the combination representing the projected balance may further include the second amount. In another embodiment, the method may also include receiving a selection of a second journal entry from the one or more journal entries, where the second journal entry may comprise a second amount; determining that the second amount is associated with a second ledger; receiving a second beginning balance representing a balance of the second ledger on the start date; receiving a second activity total comprising a sum of journal entries posted to the second ledger between the start date and the current date; determining a second projected balance representing a combination of the second beginning balance, the second activity total, and the second amount; and displaying, in the projected balances portlet together with the beginning balance, the activity total, the first amount, and the projected balance: an identifier of the first ledger, an identifier of the second ledger, the second beginning balance, the second activity total, the second amount, and the second projected balance.
In one embodiment, the start date may be the beginning of an accounting period. In another embodiment, displaying the projected balances portlet occurs automatically in response to the selection of the first journal entry. In yet another embodiment, the combination of the beginning balance, the activity total, and the first amount may comprise an arithmetic sum of the beginning balance, the activity total, and the first amount. In yet another embodiment, the first amount may comprise a first currency and the second amount may comprise a second currency, and the projected balance portlet may convert the first amount into the second currency. In one embodiment, the request to authorize posting the first amount to the first ledger may be part of a work flow; and posting the first amount to the first ledger may be part of the same workflow.
In another embodiment, a computer-readable memory is presented the memory may have stored thereon a sequence of instructions which, when executed by one or more processors, causes the one or more processors to preview projected balance impacts in an Enterprise Financial Accounting System by receiving one or more journal entries that have not been posted to an accounting ledger, and displaying the one or more journal entries in a journal portlet. The one or more processors may further operate by receiving a selection of a first journal entry from the one or more journal entries, where the first journal entry may include a first amount, and determining a first ledger that is associated with the first amount. The one or more processors may also operate by receiving a start date and receiving a beginning balance representing a balance of the first ledger on the start date. The instructions may additionally cause the one or more processors to operate by receiving an activity total including a sum of journal entries posted to the first ledger between the start date and a current date, and determining a projected balance representing a combination of the beginning balance, the activity total, and the first amount. The instructions may also cause the one or more processors to operate by displaying a projected balances portlet together with the journal portlet, where the projected balances portlet may include the first amount, and the projected balance.
In yet another embodiment, a system including one or more processors, and a memory is presented. The memory may be communicatively coupled with and readable by the one or more processors and have stored therein a sequence of instructions which, when executed by the one or more processors, cause the one or more processors to preview projected balance impacts in an Enterprise Financial Accounting System by receiving one or more journal entries that have not been posted to an accounting ledger; and displaying the one or more journal entries in a journal portlet. The instructions may also cause the one or more processors to operate by receiving a selection of a first journal entry from the one or more journal entries, where the first journal entry may include a first amount, and determining a first ledger that is associated with the first amount. The instructions may additionally cause the one or more processors to operate by receiving a start date and receiving a beginning balance representing a balance of the first ledger on the start date. The instructions may further cause the one or more processors to operate by receiving an activity total comprising a sum of journal entries posted to the first ledger between the start date and a current date, and determining a projected balance representing a combination of the beginning balance, the activity total, and the first amount. The instructions may also cause the one or more processors to operate by displaying a projected balances portlet together with the journal portlet, where the projected balances portlet may include the first amount, and the projected balance.
A further understanding of the nature and advantages of the present invention may be realized by reference to the remaining portions of the specification and the drawings, wherein like reference numerals are used throughout the several drawings to refer to similar components. In some instances, a sub-label is associated with a reference numeral to denote one of multiple similar components. When reference is made to a reference numeral without specification to an existing sub-label, it is intended to refer to all such multiple similar components.
In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of various embodiments of the present invention. It will be apparent, however, to one skilled in the art that embodiments of the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.
The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the appended claims.
Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
The term “ machine-readable medium” includes, but is not limited to portable or fixed storage devices, optical storage devices, wireless channels and various other mediums capable of storing, containing or carrying instruction(s) and/or data. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc., may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine readable medium. A processor(s) may perform the necessary tasks.
Described herein, are embodiments for validating and/or previewing account journal entries in an Enterprise Financial Accounting System. A journal portlet may be provided wherein a user can edit and/or enter journal entries for a particular journal. Journal entries may include multiple transactions that may be posted to multiple accounts. In one embodiment, the user may select one or more journal entries comprising one or more transactions, and subsequently see the effect that posting the selected journal entries will have on accounting ledgers that are associated with the journal entries. A projected balance for each of the account ledgers may be displayed in a separate projected balance portlet that is displayed at the same time as the journal portlet. An accounting period may be selected, such as the period-to-date, and the projected balances portlet may be configured to display for each account, a beginning balance, activity since the start of the accounting period, any amounts from the selected journal entries, and a balance if the selected journal entries were to be posted.
Additionally, after reviewing the projected balances, it may be determined that the journal entries in the journal portlet may be posted to their respective ledgers. In order to post transactions to some ledgers, an authorization may be required from the manager. The user entering transactions into the journal portlet may provide an input indicating an intent to post transactions to the ledgers, some embodiments may automatically determine that an authorization is required, and send an indication to a manager requesting such authorization. The manager may authorize the journal entries after reviewing the projected balances and allow them be posted to the ledgers. Alternatively, the manager may reject the journal entries, and send them back to the user for deletion or correction.
Prior to this disclosure, entering transactions into an accounting journal was a process that was susceptible to many errors. Accountants often enter transactions into journals when they receive an invoice, bill, purchasing order, requisition, and/or like. In many cases this involved manually transcribing data from a document into an accounting application. Because of the tedious and often repetitive nature of the data entry process, transcription errors and typos often found their way into accounting journals. The only way to detect these errors was to manually examine the data as it is being entered. Because data entered into accounting journals were not reflected in the accounting ledgers with which the transactions were associated, obvious errors affecting the balance of these accounting journals often went undetected.
In order to determine how data entered into an accounting journal affects the balance in an associated accounting ledger, the journal entries had to first be posted to the accounting ledger. This involves importing the data from the transactions in the accounting journal into the accounting ledger as debits and credits, then recalculating the balance of the accounting ledger. However, because posting journal entries affects the balance of the accounting ledgers, and because the accounting ledgers are used to produce legally required financial statements, posting journal entries often requires authorization from the supervisor, such as an accounting manager. In existing software systems, the approval workflow is separate from the accounting software itself. Therefore, in order to post a journal entry, the journal entry must be approved through a first workflow, and then posted through a second workflow. This required two separate transactions by an accountant.
As used herein, the term “journal entry and preview interface” may be used to describe any user interface that provides for editing and updating a journal while providing real-time projected balances generated by any changes to the journal. The journal entry and preview interface may be textual, and indications may be textual descriptions of the various ledgers and balances. In another embodiment, the journal entry and preview interface may be graphical, and indications may be in the form of graphical icons that may be selected by an input device. The journal entry and preview interface may be provided on many possible output devices. In one embodiment, the journal entry and preview interface may be provided on a computer screen, while other embodiments may use the screen on a mobile phone, a laptop computer, a projector, a tablet computer, a PDA, and/or the like.
In some embodiments, the journal entry and preview interface may provide both a summary and detailed view of the status information for various journals and ledgers. A summary view may cut across a broad set of information at an overview level. It may show the status of selected journal entries and the associated account ledgers for a selected accounting period. Status changes may be effected and seen across the various ledgers from within the journal entry and preview interface with a single request. At the same time, a user may drill down into the status details of a particular journal entry to more closely review the effect of each individual component of a transaction.
Each of the embodiments disclosed herein may be implemented in a computer system.
In some embodiments, the system 100 may also include a network 115. The network may can be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available protocols, including without limitation TCP/IP, SNA, IPX, AppleTalk, and the like. Merely by way of example, the network 115 may be a local area network (“LAN”), such as an Ethernet network, a Token-Ring network and/or the like; a wide-area network; a virtual network, including without limitation a virtual private network (“VPN”); the Internet; an intranet; an extranet; a public switched telephone network (“PSTN”); an infra-red network; a wireless network (e.g., a network operating under any of the IEEE 802.11 suite of protocols, the Bluetooth protocol known in the art, and/or any other wireless protocol); and/or any combination of these and/or other networks such as GSM, GPRS, EDGE, UMTS, 3G, 2.5 G, CDMA, CDMA2000, WCDMA, EVDO etc.
The system may also include one or more server computers 120, 125, 130 which can be general purpose computers and/or specialized server computers (including, merely by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers rack-mounted servers, etc.). One or more of the servers (e.g., 130) may be dedicated to running applications, such as a business application, a web server, application server, etc. Such servers may be used to process requests from user computers 105, 110. The applications can also include any number of applications for controlling access to resources of the servers 120, 125, 130.
The web server can be running an operating system including any of those discussed above, as well as any commercially-available server operating systems. The web server can also run any of a variety of server applications and/or mid-tier applications, including HTTP servers, FTP servers, CGI servers, database servers, Java servers, business applications, and the like. The server(s) may also be one or more computers which can be capable of executing programs or scripts in response to the user computers 105, 110. As one example, a server may execute one or more web applications. The web application may be implemented as one or more scripts or programs written in any programming language, such as Java™, C, C# or C++, and/or any scripting language, such as Perl, Python, or TCL, as well as combinations of any programming/scripting languages. The server(s) may also include database servers, including without limitation those commercially available from Oracle®, Microsoft®, Sybase®, IBM® and the like, which can process requests from database clients running on a user computer 105, 110.
In some embodiments, an application server may create web pages dynamically for displaying on an end-user (client) system. The web pages created by the web application server may be forwarded to a user computer 105 via a web server. Similarly, the web server can receive web page requests and/or input data from a user computer and can forward the web page requests and/or input data to an application and/or a database server. Those skilled in the art will recognize that the functions described with respect to various types of servers may be performed by a single server and/or a plurality of specialized servers, depending on implementation-specific needs and parameters.
The system 100 may also include one or more databases 135. The database(s) 135 may reside in a variety of locations. By way of example, a database 135 may reside on a storage medium local to (and/or resident in) one or more of the computers 105, 110, 115, 125, 130. Alternatively, it may be remote from any or all of the computers 105, 110, 115, 125, 130, and/or in communication (e.g., via the network 120) with one or more of these. In a particular set of embodiments, the database 135 may reside in a storage-area network (“SAN”) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers 105, 110, 115, 125, 130 may be stored locally on the respective computer and/or remotely, as appropriate. In one set of embodiments, the database 135 may be a relational database, such as Oracle 10g, that is adapted to store, update, and retrieve data in response to SQL-formatted commands.
The computer system 200 may additionally include a computer-readable storage media reader 225a, a communications system 230 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and working memory 240, which may include RAM and ROM devices as described above. In some embodiments, the computer system 200 may also include a processing acceleration unit 235, which can include a DSP, a special-purpose processor and/or the like.
The computer-readable storage media reader 225a can further be connected to a computer-readable storage medium 225b, together (and, optionally, in combination with storage device(s) 220) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. The communications system 230 may permit data to be exchanged with the network 220 and/or any other computer described above with respect to the system 200.
The computer system 200 may also comprise software elements, shown as being currently located within a working memory 240, including an operating system 245 and/or other code 250, such as an application program (which may be a client application, web browser, mid-tier application, RDBMS, etc.). It should be appreciated that alternate embodiments of a computer system 200 may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed. Software of computer system 200 may include code 250 for implementing embodiments of the present invention as described herein.
The following methods may be implemented by a computer system, such as computer system 200 in
After journal entry 312 and journal entry 314 have been entered into journal 310, the accountant or data entry clerk may desire to post various transactions to their respective account ledgers. In one embodiment, journal entries may be posted one at a time by selecting them individually. In another embodiment, a batch of journal entries may be posted at once by selecting a group or choosing to post the entire journal in a single operation.
Ledger 340 records transactions for account 1. After posting journal entries from journal 310, transaction 342 and transaction 344 with a debit of $500 and a credit of $100 respectively are posted to ledger 340. After posting, the balance 346 of ledger 340 is recalculated as a debit of $500. Similarly, ledger 360 may receive transaction 362 with a credit of $50. After posting, balance 366 of ledger 360 may be recalculated as a credit of $50. Although in this example ledger 340 and ledger 360 were empty prior to the posting of journal 310, it will be understood that each ledger may have had a previous balance. In this case, the balances of each ledger would reflect the change in the existing balance due to the posted transactions.
Note that in this example of
It may next be determined whether the projected balance is relevant (406). In one embodiment, the user may determine whether the account ledgers to which journal transactions will be posted are of a type for which the balance should be checked. Some accounts may be of greater importance than others. More important accounts could have a relevant projected balance, whereas less important accounts may not. In another embodiment, the transactions in the journal entry themselves may be below a threshold value, and therefore be determined not to have relevant projected balances. For example, journal entries totaling more than $500 may require displaying a projected balance. In another embodiment, transactions that appear to include a typo may require reviewing the projected balance. In yet another embodiment, the experience of the user may determine whether a projected balance should be displayed. For example, a user with less than one year experience may be deemed more likely to be the source of data entry errors, and thus require projected balance review.
The projected balance, if deemed relevant, may be displayed and reviewed in a projected balance portlet (408). Displaying and reviewing the projected balance may take on many forms and various embodiments. For example, the projected balance could appear in a separate window within the journal entry and preview interface. The projected balance could appear in a pop-up window that may, or may not be modal. The projected balance may appear in a notification that requires user confirmation to continue. Specific embodiments may contain particular types of displays in which the projected balance can be reviewed, and will be discussed further later in this disclosure.
After display, it may be determined whether the projected balance is correct (420). If an error is detected in the projected balance, the journal entry and preview interface may allow for additional changes to be made to the journal entry before it is posted (404). If the projected balance is correct, it may then be determined whether approval is required for the journal entry to be posted (422). In the same way that a projected balance is determined to be relevant, the determination as to whether posting the journal entry requires approval may take into account the total value of the journal entry, the accounts which will be posted, and/or the history and experience of the user making the journal entry. If no approval is required, the transactions within the journal entry are posted to their respective account ledgers (424). After posting, the balances of each account ledger may be updated to reflect current balance after posting.
If approval is required to post the journal entry, the journal entry may be submitted for approval (428). In one embodiment, the entire journal entry may require approval, whereas in another embodiment only individual transactions within a journal entry may require approval. For example, a journal entry comprised of debits to the first account and a second account may post the transactions the first account, while requiring approval prior to posting the transaction to the second account. In another embodiment, if one transaction in a journal entry requires approval, then the entire journal entry may require approval.
Journal entries may include a number of different fields that may be reviewed other than the balance. These may include the accounts which transactions we posted, source documents, dates, and/or other transactional information. These other journal attributes may be reviewed as part of the review process (504). Most commonly, however, the reviewer will be required to review the journal line and account amounts for each transaction (506). Just as it was important to review the projected balances during the original data entry step, it may be important for the reviewer to see the projected balances for each transaction prior to approving the transactions for posting. Therefore, it may be determined, either by the reviewer or automatically, that specific projected balances for specific transactions may be relevant or required (508). Again, it may be determined whether projected balances should be displayed based on transaction amounts, account ledgers affected, and/or characteristics or history of the person or process entering the data. If it is determined that the projected balances do not need to be reviewed, the journal entries may be posted to the account ledgers (526), and ledger balances may be updated (528).
If it is determined that the projected balances should be displayed for the reviewer, these valves may be displayed in the journal entry and preview interface (520). This display may be similar to the projected balances displayed when the journal entries were originally created. In another embodiment, projected balances displayed for reviewer may contain more information than was displayed when the journal entries were originally created. For example, the projected balances display may also provide information relevant to a reviewer, such as error rates of a user creating the journal entries. The reviewer may determine whether the projected balances are correct (522). If they are correct, the journal entries may be posted (526). Alternatively, if projected balances are not correct, the reviewer may reject the journal entries (524). In one embodiment, the reviewer may reject portions of the journal entry while accepting other portions for posting. In another embodiment, if any part of a journal entry is rejected, the entire journal entry may be rejected. Rejected journal entries may be sent back to the original creator of the journal entry, along with a notification explaining why the journal entry was rejected. The notification may include the projected balances.
The method may also include displaying the one or more journal entries in a journal portlet (612). The journal portlet may be a window within the journal entry and preview interface. The journal portlet may also be displayed as a standalone application or applet in a web browser. The journal entries may be displayed on a display device of a computer system, such as the output devices 215 of computer system 200 in
The method may additionally include receiving a selection of a first journal entry from the one or more journal entries (614). The selection may be made using an input computer system, such as the input devices 210 the computer system 200. In one embodiment, the selection may include a single journal entry. In another embodiment, the selection may include multiple journal entries. In yet another embodiment, the selection may include individual transactions within one or more journal entries. The selection may be manually provided by a user, or the selection may be made automatically by a computer system. Selections may be chosen automatically based on the criteria for review by a supervisor, such as exceeding a threshold amount. In one embodiment, the first journal entry comprises a first amount. This amount may be associated with a single transaction, and may be a debit or credit to a particular account. For example, the first amount may be an amount to be debited to an accounts payable ledger.
The method may further include determining a first ledger that is associated with the first amount (616). In one embodiment, the first ledger may be included as a part of the journal entry. For example, an accountant recording an invoice from a supplier could record any accounts to be credited or debited from the transaction, along with the amounts. In another embodiment, the first ledger may be automatically determined based on the type of journal entry made. For example, one system may automatically generate journal entries from scanned invoices or other documents. The computer system may determine the first amount and the first ledger to which it corresponds based on information read from the source document. Thus, if a source document contains the name of the supplier, the first amount may be associated with a ledger corresponding to that supplier.
The method may also include receiving a start date (618). In one embodiment, the start date represents a date on which the beginning balance should be determined for displaying the projected balances. The start date may be entered manually by a user, or determined automatically by a computer system. In one embodiment, the start date is automatically determined to be the beginning of the current accountant period. In other embodiments, the start date may be the beginning of the current month, the date when the first ledger was last closed, the beginning of the current year, the date of the last posted transaction, and/or the like.
The method may additionally include receiving a beginning balance (619). In one embodiment, the beginning balance represents a balance of the first ledger on the start date. The beginning balance may also be referred to as an “opening” balance. The method may further include receiving an activity total (620). In one embodiment, the activity total may comprise a sum of journal entries posted to the first ledger between the start date and a current date. In another embodiment, the activity total may also comprise journal entries selected to be posted pending approval. The activity total may be presented as a single sum, or may be presented as a series of line items showing individual transactions.
The method may also include determining a projected balance (622). In one embodiment, the projected balance represents a combination of the beginning balance, the activity total, and the first amount. The combination may be created by calculating the arithmetic sum of these amounts. For example, if the first amount as a debit of $500, the beginning balance is a credit of $1000, and the activity total was a debit of $250, the projected balance could be a credit of $250. In other embodiments, different methods of calculating the balance may be used, and may include additional factors, such as encumbrances and other reserved values in the first ledger.
The method may additionally include displaying a projected balances portlet together with the journal portlet (624). In one embodiment, the projected balances portlet comprises the beginning balance, the activity total, the first amount, and the projected balance. Each of these values may be displayed in a format and labeled such that a user can easily determine how the first amount affects the projected balance. In another embodiment, additional information may be displayed in the projected balances portlet, such as an identifier of an account associated with the first ledger, the start date, an indication of the accounting period, and/or the currency for each value. Additionally, the projected balances portlet may display indications when the projected balance may be incorrect. For example, the projected balances portlet may display a color or other visual indication when the projected balance exceeds a threshold. Alternatively, the projected balances portlet may highlight transactions that deviate from expected value, according to business rules defined by an organization. For example, it may be expected that certain types of invoices that involve debits within a certain value range or using a certain currency are charged to a particular account. The projected balances portlet may display an indication when any of these factors are not within an expected range.
In one embodiment, the projected balances portlet is displayed in the same window as the journal portlet. This may allow a user to see in real-time an effect that posting the selected journal entries may have on their associated accounts. Typos that would normally go undetected, or errors in the source documents may become more apparent when viewed in the context of the accounts which they are posted. Thus, a user may select journal entries one after another and quickly view the effects that these journal entries have on their respective accounts. In another embodiment, the projected balances portlet may be displayed together with the journal portlet as a pop-up window, a modal window, or other form of indication displayed on a screen at the same time.
In existing systems, the process for viewing a journal entry and the process for posting a journal entry are separate. These two processes use different workflows in different systems. Therefore, prior to this disclosure, when a journal entry required approval prior to posting, it would first be sent through an approval workflow. If the journal entry was approved through the approval workflow, then the accountant who originally submitted the entry for approval would receive an indication that it had been approved. The accountant could then submit the journal entry for posting via a journal entry posting workflow. Often, these two processes were kept separate because they were parts of different software packages. The approval workflow was always a part of task management software, whereas the journal posting workflow was a part of an accounting software package. In some cases, these two processes used separate computer systems and relied on messages passed between the two computer systems.
Embodiments disclosed herein combine these two processes, or workflows, into a single integrated process, or workflow. In one embodiment, the method in
The method may also include determining that posting the first amount to the first ledger requires an authorization (704). In one embodiment, this does not require entry into a separate workflow from the journal posting workflow. Instead, receiving an input to post a journal entry that requires approval automatically begins the steps necessary to acquire approval. In one embodiment, this process may be transparent to a user, such that no indication needs to be provided of the impending approval process. However, in another embodiment, an indication may be provided to a user that the journal posting may be temporarily delayed pending approval.
The method may additionally include sending a request to authorize posting the first amount to the first ledger (706). In embodiments where the approval workflow and the posting workflow are combined, a request originating in the journal portlet may be sent directly to a manager's workstation for approval. Alternatively, the request may be combined with requests in a batch for approval. In one embodiment, the same software system may provide interfaces for both the journal portlet and an approval portlet provided to a manager or other approving authority.
The method may further include receiving the authorization to post the first amount to the first ledger (708). In one embodiment, the authorization is based at least in part on the projected balance. In other words, an approval portlet provided to the approving authority may include a projected balance portlet similar to that which was provided when the journal entry was originally made. In one embodiment, the authorization may be received based on an automatic approval process. For instance, in cases where the projected balance represents a change below threshold percentage, the approving authority may authorize the approval portlet, and/or the computer system to automatically approve the journal entry posting.
The method may also include automatically posting the first amount to the first ledger in response to receiving the authorization (720). In one embodiment, as soon as authorization is received, the journal entry may automatically be posted. This process may be completely transparent to both the approving authority and the accountant who originally generated the journal entry. In another embodiment, the journal posting may still occur automatically, but an indication may also be sent to one or more of the approving authority and the accountant.
In many cases, the journal entry may comprise several transactions. Each transaction may include different amounts that are debited or credited to difference accounting ledgers or subledgers.
The method may also include determining a second ledger that is associated with the second amount (804). In one embodiment, the second ledger is different from the first ledger, such that the first and second amounts are associated with different account ledgers. In another embodiment, the second ledger and the first ledger are the same, such that both the first and second amounts are associated with the same account ledger. This determination may be made using the same methods described in block 616 of
The method may additionally include receiving a second beginning balance representing a balance of the second ledger (806). In one embodiment, the second balance represents the balance of the second ledger on the start date. The method may further include receiving a second activity total for the second ledger (808). In one embodiment, the second activity total may comprise a sum of journal entries posted to the second ledger between the start date and the current date. The method may also include determining a second projected balance for the second ledger (820). In one embodiment, the second projected balance may represent a combination of the second beginning balance, the second activity total, and the second amount. Note that blocks 806, 808, and 820 are similar to blocks 619, 620, and 622 of
The method may additionally include displaying the projected balance information for the first ledger and the projected balance information from the second ledger together in the projected balances portlet (822). In one embodiment, the projected balance information may include an identifier of the first ledger and an identifier of the second ledger. The projected balance information may further include the second beginning balance and the first beginning balance, the second activity total and the first activity total, the first amount and the second amount, and the first projected balance and the second projected balance. The projected balance information for each ledger may be displayed together in the same window of the projected balances portlet, or the projected balance information for each ledger may be displayed separately in windows within the projected balances portlet.
In addition to providing projected balances for different transactions within the same journal entry, some embodiments provide projected balances for different transactions within different journal entries.
The method may also include determining that the second amount of the second journal entry is associated with the first ledger (904). In this case, the two journal entries include transactions that debit or credit amounts to the same account ledger. Therefore, it may be beneficial to display the effect that both journal entries would have on the projected balance of a single account ledger.
The method may additionally include displaying, in the projected balances portlet, the second amount (906). In one embodiment, the combination of the beginning balance, the activity total, and the first amount representing the projected balance further includes the second amount. In other words, the projected balance may begin with the beginning balance of the first account, add the activity total, and then add the first and second amounts to calculate the projected balance for the first account ledger. The projected balances portlet may display the first amount and the second amount individually, or alternatively, the first and second amount may be combined into a single amount representing the transaction total from the selected journal entries.
The method may also include determining that the second amount is associated with a second ledger (1004). As explained above, second amounts may be associated with the second ledger for a number of different methods. The method may additionally include receiving a second beginning balance, representing a balance of the second ledger on the start date (1006). The method may further include receiving a second activity total comprising a sum of journal entries posted to the second ledger between the start date and the current date (1008). The method may also include determining a second projected balance representing a combination of the second beginning balance, the second activity total, and the second amount (1020). The method may additionally include displaying information associated with the second projected balance in the projected balances portlet together with the beginning balance, the activity total, the first amount, and the projected balance (1022). In one embodiment, the information associated with the second projected balance may comprise an identifier of the first ledger, an identifier of the second ledger, the second beginning balance, the second activity total, the second amount, and the second projected balance. Note that blocks 1004, 1006, 1008, 1020, and 1022 are similar to blocks 804, 806, 808, 820, and 822 of
It should be appreciated that the specific steps illustrated in
Alternatively, the user may select a journal line when the projected balance portlet is already open (1122). In another embodiment, the portlet need not be open, but rather a software process controlling the projected balance portlet may be operating in the background. When a user selects a journal line the projected balance portlet may automatically be opened, and the start date and accounts may be verified that point. If an account and/or start date cannot be verified, a message may be displayed to the user instructing the user to enter a valid start date and/or an account to associate with the transactions (1104). If these values can be validated, the balance information for the relevant accounting period may be read in to the projected balance portlet (1126). These values may be read from the general ledger database 1124, or from a multidimensional database that keeps aggregated totals in memory.
The user may also select between accounted or entered amounts to be used in the analysis (1128). If multiple balances are loaded, the user may also select between multiple accounting periods, such as period-to-date, quarter-to-date, or year-to-date (1140). It may then be determined whether journal entries have been posted during the relevant accounting period (1144). If they have been posted, the projected balance portlet may display the opening balance, the line amount, and the balance, and then calculate activity for the currency during the accounting period (1146). If they have not been posted, the projected balance portlet may display an opening balance, the activity since the beginning of the accounting period, and the line amount, and then calculate the balance for the currency and the accounting period to date.
Interface 1200 also includes a projected balances portlet 1204. The projected balances portlet includes a projected balance for each of the two accounts referenced by the two journal entries in the journal portlet 1202. In this example, account 01.480.8510 is shown in the top half of the projected balances portlet 1204. Also displayed is the opening balance of a debit of $25,765 (1220), $0.00 of activity since the beginning of the accounting period (1222), a debit of $12,000 (1224) from the first transaction of “Line 1” in the expense journal 1206, and the resulting projected balance of a debit of $37,765 (1226) in the account if “Line 1” were to be posted. The relevant accounting period is also shown as “PTD” (period-to-date) along with the currency, which is “USD”. In one embodiment, currencies may be normalized and/or converted within the projected balances portlet 1204. For example, the transaction entered into the journal portlet 1202 may use a different currency than what is displayed in the projected balances portlet 1204. The projected balances portlet 1204 may then convert the transaction in the differing currency into the currency of the account displayed in the projected balances portlet 1204.
The projected balances portlet 1204 also shows a projected balance for account number 01.612.6252 in the lower half of the window. This account is associated with “Line 10” in the expense journal 1206. It displays an opening balance of a debit of $343,543.00 (1228), an activity of a debit $654.00 (1240) since the beginning of the accounting period, a debit of $2000.00 (1242) from “Line 10” of the expense journal 1206, and a projected balance of a debit of $346,197.00 (1244) if the journal entry were to be posted.
In this example, the journal entries corresponding to Line 1 and Line 10 could be selected from a plurality of entries within the expense journal 1206. In another embodiment, multiple journals can be displayed within the journal portlet 1202 at the same time. Journal entries could be selected from different journals, and have their projected balances displayed in the projected balances portlet 1204. In one embodiment, the user must select journal entries to be displayed in the projected balances portlet 1204, while in another embodiment any journal entries entered into the journal portlet 1202 may have their projected balances displayed in the projected balances portlet 1204.
A review and authorization module 1402 may be provided to review journal entries that are posted from the journal management module 1410. Review and authorization module 1402 may utilize both the projected balances module 1404 and the projected balances portlet 1406 during the review process. At the completion of the review process, a general ledger module 1408 may receive and post journal entries for final recording in a general ledger and/or subsidiary ledgers.
In one embodiment, the various modules in
In the foregoing description, for the purposes of illustration, methods were described in a particular order. It should be appreciated that in alternate embodiments, the methods may be performed in a different order than that described. It should also be appreciated that the methods described above may be performed by hardware components or may be embodied in sequences of machine-executable instructions, which may be used to cause a machine, such as a general-purpose or special-purpose processor or logic circuits programmed with the instructions to perform the methods. These machine-executable instructions may be stored on one or more machine readable mediums, such as CD-ROMs or other type of optical disks, floppy diskettes, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, flash memory, or other types of machine-readable mediums suitable for storing electronic instructions. Alternatively, the methods may be performed by a combination of hardware and software.
The present application claims benefit under 35 USC 119(e) of U.S. Provisional Application No. 61/536,971, filed on Sep. 20, 2011 by Ramsay et al, and entitled “Mechanism To View Embedded Analytics (Financial Impacts Of A Particular Transaction That Is About To Be Entered) In The Transactional Flow Pages,” of which the entire disclosure is incorporated herein by reference for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 61536971 | Sep 2011 | US |
