Many businesses rely on enterprise resource planning (ERP) computing architectures to electronically manage and coordinate business resources, information, and functions. However, the processing of incoming legal documents continues to involve a substantial amount of manual work. The content of the legal documents must often be analyzed manually by a user in order to decide which steps have to be carried out in the ERP system to cover the business processes associated with the legal document. Afterwards the required processing steps, like posting a goods receipt or invoice receipt, would be executed using standard ERP system transactions. Furthermore, some of the data contained in the incoming legal documents may have to be entered manually into the ERP system to execute the postings accordingly.
For example, the Nota Fiscal eletrônica (NF-e) is a legal document and an electronic invoice which contains tax and logistical information in the form of an XML document with a layout defined by the Brazilian government. The NF-e can involve both Business to Government (B2G) communication (requesting authorization of NF-e from tax administration before billing may take place) as well as Business to Business (B2B) communication (sending the authorized NF-e to the customer).
In the B2B case for an incoming NF-e, the information provided in the document will lead to certain processing steps having to be performed. The reason is that in addition to the regular processing of Goods Receipts (GR) and Invoice Receipts (IR), the processing of the XML messages results in additional process steps that are necessary to carry out, e.g. checking authorization of NF-e with Government etc. Because these documents contain information which belongs to different categories of documents in the ERP system like purchase order, delivery, goods movement or invoice, they can be viewed as a combination of different ERP system documents representing a whole business process which can be automatically executed.
Therefore there is a need for flexible automated processing of electronic documents containing tax and logistical information by existing ERP systems.
For the processing of electronic documents, an existing ERP system (or systems) can benefit from a connection to a separate Governance, Risk, and Compliance system, usually referred to as a GRC system. The goal of GRC is to help a company efficiently put policies and controls in place to address all its compliance obligations while at the same time gathering information that helps proactively run the business and assess potential risks. A GRC system can create a central nervous system that helps a company monitor compliance and manage their business risks more effectively. In this way a GRC system can help a company keep track of transactions and raise an alert when things go off track or when risks appear.
A system for processing electronic documents includes a framework that enables a flexible and customizable process definition for handling incoming documents. Within the process definition all the steps which are desired for handling an incoming document can be predefined. Some of the processing steps like checking the signature and authorization of an incoming legal document can be executed in the GRC system, some other steps like posting a goods receipt or posting an invoice are executed in one of the connected ERP systems. The content of the incoming document is evaluated to determine which business process may be used to carry out the necessary processing steps. To this end an incoming document is automatically analyzed to extract information regarding the relevant parameters evaluated to assign the business process. The assigned business process and a related process flow sequence define the processing steps to be executed.
The control of the execution of the processing steps is carried out in the GRC system. This is done using an extendable status concept for the processing flow so that a linear process where a follow on step always depends on the preceding step can be implemented as well as a more complex non linear process flow where a follow on step may depend on a subsequent step. The business process to be assigned, the process flow sequence and control can all be customized in a flexible manner and new processing steps can even be implemented. For example, the defined process flow sequence may be customized so that it varies depending on certain variables, such as the business partners involved in the assigned business process. If several ERP systems are assigned to one GRC system, the determination of the corresponding ERP system for an incoming document may be made based on the content of the document.
Embodiments of the present invention will now be described in detail, by way of example only, with reference to the accompanying drawings in which identical or corresponding parts/features are provided with the same reference numerals in the figures.
XML document 40 can be, for example, a Nota Fiscal eletrônica (NF-e) which is a legal document and an electronic invoice which contains tax and logistical information in the form of an XML document with a layout defined by the Brazilian government, The NE-e can involve both Business to Government (B2G) communication (requesting authorization of NF-e from tax administration before billing may take place) as well as Business to Business/B2B) or Business to Customer (B2C) communication (sending the authorized NF-e to the customer). Because incoming electronic documents can contain information which requires processing steps like checking the signature and authorization of an incoming legal document that can be executed in the GRC system 30 and information which belongs to different categories of documents in the ERP system like purchase order, delivery, goods movement or invoice, they can be viewed as a combination of different GRC and ERP processes representing a larger business process which can be automatically executed.
For example, in the case of the Nota Fiscal eletrônica the business process determination depends mainly on the CFOP code which is defined by the Brazilian authorities and describes the type of business transaction. However, the meaning of a CFOP code can be changed by the authorities so that the system behavior has to be adjusted. This type of situation can be handled by the extracted content table 60 of GRC system 30, which can be customized so as to adjust the business process determination to changes of the meaning of the CFOP codes or any other extracted content 35.
The GRC system 30 includes a business processes table 70 which defines the processing steps 75 that need to be implemented for each of the business processes 45 that can be implemented by system 10. For example, the definition of the required processing steps 75 for possible business processes 45 like ‘Normal Purchasing’ or ‘Stock Transfer’ which would be implemented in the ERP system 20 or “Signature Authentication” that would be implemented in the GRC system. The business processes 45 can be categorized to be valid for certain document types. The definition and implementation of each of the processing steps 75 is contained in a process steps table 80 in the GRC system. The process steps table 80 defines certain attributes of each processing step 75, for example, if the step can be carried out automatically or also manually and if the step is optional or mandatory within the business process 45.
The GRC system 30 includes a process flow sequence table 90 which defines the sequence of processing steps 75 for a certain business process 45 and if each of the processing steps 75 are to be executed automatically or have been deactivated. The GRC system 30 also includes a control process flow table 100 which defines the prerequisites necessary before implementing each processing step 75 in each business process 45. Therefore with an extendable status concept this allows the control process flow table 100 to define which status of the preceding or subsequent steps are necessary to carry out a certain processing step 75 in a certain business process 45. This allows the implementation of a linear process flow where a follow on step always depends on the preceding step as well as a more complex non linear process flow.
A control parameters table 110 in GRC system 30 allows users to influence the processing steps 75. Depending on the definition of the processing step 75 in process steps table 80 and the at least one extracted content 35, for example the business partners involved in the business process 45, the execution of a processing step 75 can be defined as automatically or manually implemented or can be deactivated, for example for a certain combination of business partners. Therefore, control parameters table 110 allows users to overwrite the criteria defined in the process flow sequence table 90.
As mentioned above the implementation of business process 45 is governed by a function module 120 which acts as the central engine responsible for execution and control of the business process flow.
Shown below are schematic displays of example extracts of some of the tables used in an example business process 45: ‘Normal Purchasing’.
Process flow sequence table 90 used to define the sequence and certain attributes of the processing steps 75 associated with business process 45: ‘Normal Purchasing’:
As shown above, some of the processing steps 75 are defined to be executed automatically and others need a user interaction and therefore are not automatic. In the above example all the steps are defined to be active. However, some of the processing steps 75 can be deactivated if they are not mandatory for business process 45: ‘Normal Purchasing’ as per the definition of each processing step 75 in process steps table 80. To deactivate processing steps 75 that are not mandatory the control parameters table 110 can be used.
For example, if the steps shown below are not mandatory for business process 45: ‘Normal Purchasing’, as per the definition of each processing step 75 in process steps table 80, then control parameters table 110 could be used to influence the sequence (of process flow sequence table 90 above) as shown below:
Furthermore, the control parameters table 110 can change the settings of the process flow sequence for some steps depending on the business partners. As shown above, tax numbers are used which identify a business partner that may be involved in business process 45: ‘Normal Purchasing’.
A control process flow table 100 defines the pre requisites necessary before implementing each processing step 75 in business process 45: ‘Normal Purchasing’, for example by defining which status of the preceding or subsequent steps are necessary to carry out a certain processing step 75 as shown below:
As shown below, process steps table 80 can be used to define the implementation of the processing steps 75 and the step attributes, for example the processing steps 75 shown below are defined as being implemented in the function module 120 of GRC system 30:
Embodiments of the present invention are described in the context of a fully functional computer system, however those skilled in the art will appreciate that modules of the present invention are capable of being distributed in a variety of forms across a plurality of systems. Embodiments consistent with the invention may also include one or more programs or program modules on different computing systems running separately and independently of each other, while in their entirety being capable of performing business transactions in a large enterprise environment or in a “software on demand” environment. These programs or program modules may be contained on signal bearing media that may include: recordable type media such as floppy disks and CD ROMS, and transmission type media such as digital and analog communication links, including wireless communication links.
The foregoing description is not exhaustive and does not limit embodiments of the invention to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from the practicing embodiments consistent with the invention. For example, some of the described embodiments may include software and hardware, but some systems and methods consistent with the present invention may be implemented in software or hardware alone. Additionally, although aspects of the present invention are described as being stored in memory, one skilled in the art will appreciate that these aspects can also be stored on other types of computer-readable media, such as secondary storage devices, for example, hard disks, floppy disks, or CD-ROM; the Internet or other propagation medium; or other forms of RAM or ROM.
This application claims the benefit of U.S. Provisional Application No. 61/541,792, filed Sep. 30, 2011, the contents of which are incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
61541792 | Sep 2011 | US |