Invoice is a legal document that describes details of a transaction or consignment between sellers and buyers. Enterprises today typically handle invoices in an electronic form. Services Oriented Architecture (SOA) services may be used for handling electronic invoices. For example, the SOA services may be used for creating, modifying, cancelling, and confirming invoices. A format of the invoice may differ for different business processes or different industries. For example, the format of the invoice related to a retail industry would be different from the format of the invoice related to a power and gas industry. Usually, software applications are developed specifically for handling different types or different formats of invoices. For example, there may be a specific software application for handling the power and gas industry based invoices and another specific software application for handling the retail industry based invoices.
The applications for processing the invoices are accessed through application-specific interfaces. Typically, a vendor (e.g., service provider) provides reference of different application-specific interfaces to their business partners. A business partner may select the application-specific interface of their choice, generally, based upon the format of the invoice the business partner requires. The business partner may specify the application-specific interface in an invoice-related request to be sent to the service provider. The service provider receives the request and the request is processed through the specified application-specific interface.
However, it may be a burden on the business partner to specify the application-specific interface while sending the request. Further, it may be inconvenient for the business partner to specify the application-specific interface each time they send the request. Moreover, there is a probability of specifying a wrong application-specific interface mistakenly. Additionally, for each software application (developed for handling specific invoices) separate modules are developed for handling error, validation, and confirmation (i.e., redundant development) which may be wastage of time, effort, and resources.
Various embodiments of systems and methods for handling invoice based services are described herein. In one aspect, a method executed by one or more computers in a network of computers includes receiving an invoice service message and analyzing the invoice service message. Based upon the analysis, a business-specific implementation is identified, from one or more business-specific implementations, for processing the invoice service message. The business-specific implementation is executed to process the invoice service message. The automatic identification of the business-specific implementation for processing the invoice service message relieves a business partner from specifying an application-specific interface for processing the invoice service message.
These and other benefits and features of embodiments of the invention will be apparent upon consideration of the following detailed description of preferred embodiments thereof, presented in connection with the following drawings.
The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments of the invention, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for handling invoice based services are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
The invoice service message 220 may be the request for creating, canceling, or updating the invoice. The request may be an A2A (application to application) request, e.g., request within a same company (intra-company request) or the request may be a B2B (business to business) request, e.g., request sent from one company to another (inter-company request). For example, the invoice service message 220 may be the A2A invoice create request, the A2A invoice cancel request, the A2A invoice update request, the B2B invoice update request, or the B2B invoice create request.
Once the invoice service message 220 is received, the process configurator 230 analyzes the content (e.g., configuration) of the invoice service message 220. The content of the invoice service message 220 may include, e.g., the type of the business partner sending the invoice service message, the one or more fields related to the business process, a BillToPartner field, a ProductRecipientPartner field, a BillToParty field, a BillFromParty field, a special contract or document field, and the request identifier or ID indicating the services requested by the business partner, etc. The request ID may indicate the requested services like creating, canceling, or updating an invoice, etc. The process configurator 230 analyzes the request ID and other contents of the invoice service message 220.
Once the invoice service message 220 is analyzed, the invoice processing framework 210 may validate the invoice service message 220. Typically, the invoice processing framework 210 includes a validation module 410 (refer to
Once the invoice service message 220 is validated, the invoice service message 220 may be forwarded to an inbound mapping module 430 for performing an inbound mapping. Typically, based upon the business process (e.g., retail) of the invoice service message 220, the process configurator 230 selects a business-specific inbound mapping implementation 510(2) (in
Typically, the inbound mapping module 430 is associated with one or more business-specific inbound mapping implementations 510 (1-n) (shown in
Once the inbound mapping is performed, one or more transformed data (not shown) may be generated. The transformed data may be forwarded to an application processing module 440 (refer to
Typically, the process configurator 230 selects the application processing implementation 520(2) by analyzing the invoice service message 220. The selected application processing implementation 520(2) is called or executed by the invoice processing framework 210. Typically, the invoice processing framework 210 forwards the transformed data to the application processing implementation 520(2) for processing the invoice service message 220.
The application processing implementation 520(2) may be executed by executing one or more predefined application programming interfaces (APIs) associated with the application processing implementation 520(2). For example, the application processing implementation 520(2) may be executed by executing an API 610(2) (refer to
Once the internal data is processed by the application processing implementation 520(2), the returned internal data may be forwarded to an outbound mapping module 450 for performing outbound mapping. The outbound mapping module 450 is associated with one or more business-specific outbound mapping implementations 530 (1-n) to perform outbound mapping related to various business processes. For example, the outbound mapping module 450 is associated with a business-specific outbound mapping implementation 530(2) to perform outbound mapping related to ‘retail’ based invoice service message 220.
Typically, the process configurator 230 selects the business-specific outbound mapping implementation 530(2) (refer to
Once the outbound mapping is performed, a confirmation message may be sent by a confirmation module 460. In one embodiment, the confirmation module 460 is associated with one or more business-specific confirmation implementations 540 (1-n) for performing confirmation related to various business processes. For example, the confirmation module 460 may be associated with a business-specific confirmation implementation 540(2) to perform confirmation related to ‘retail’ based invoice service message 220. In one embodiment, the process configurator 230 selects a business-specific confirmation implementation 540(2) (refer to
In one embodiment, if it is analyzed that the ‘BillToPartner’ field and the ‘ProductRecipientPartner’ field of the invoice service message 220 is the same then the invoice processing framework 210 may call or execute a standard invoice implementation (not shown) for processing the invoice service message 220. Typically, the standard invoice implementation process the invoice service message 220 meant for standard invoices.
Each of the business-specific implementations 300(1-n) includes their respective business specific inbound mapping implementations 510(1-n), application processing implementations 520(1-n), outbound mapping implementations 530(1-n), and confirmation implementations 540(1-n), as illustrated in
In one embodiment, a new business-specific implementation (not shown) may be defined for a new business process. The new business-specific implementation may be integrated with the invoice processing framework 210. The new business-specific implementation may include a new business-specific inbound mapping implementation (not shown), a new business-specific outbound mapping implementation (not shown), a new application processing implementation, and a new business-specific confirmation implementation. The new business-specific inbound mapping implementation and the new business-specific outbound mapping implementation may be integrated with the corresponding inbound mapping module 430 and the outbound mapping module 450. Similarly, the new application processing implementation and the new business-specific confirmation implementation may be integrated with the corresponding application processing module 440 and the confirmation module 460.
The embodiments enable an automatic selection of the business-specific implementation for processing the invoice service message. Therefore, the business parties may be relieved from the burden of identifying and providing an application-specific interface for processing their invoice service messages. Further, various business-specific processing/implementation provides an efficient mechanism for handling various formats of invoices for different business processes. Additionally, common or generic modules for handling error and validation related to various business processes obviates redundant development and saves resources, time, and effort of the service provider. Moreover, the business-specific functionalities (e.g., inbound mapping, outbound mapping, and invoice processing, etc) and general functionalities (e.g., validation and error handling, etc) provide a standardized structure based upon SOA implementations guidelines.
Some embodiments of the invention may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments of the invention may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic indicator devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the invention may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the invention may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system, e.g., an ERP system, and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however that the invention can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details to avoid obscuring aspects of the invention.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments of the present invention are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the present invention. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made to the invention in light of the above detailed description. Rather, the scope of the invention is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.