1. Field of the Invention
The present invention relates generally to the management of business partners in a procurement management system. More specifically, the present invention relates to the management of a plurality of invoicing parties associated with a business partner in a procurement management system.
2. Background of the Invention
Business transactions are essentially exchanges between different business partners. A business partner may be an individual, a group of individuals, a company, or any other entity that is recognizable by other such entities as being capable of participating in exchanges. Typically, a business partner, who is frequently involved in a large number of transactions, may employee or otherwise engage one or more specialized or sub-level business partners to perform the various tasks associated with the transactions. As an example, a large company may have internally designated contact persons, shipping managers, invoicing parties, and a number of other internally designated business partners for handling various specialized transactional tasks. Sometimes, a business partner may also assign performance of some of its business functions to other external business partners. For example, shipping and invoicing functions of a business partner may be contracted or otherwise assigned to external companies or individuals who specialize in providing such services. Under certain circumstances, business partner tasks such as invoicing tasks, may be assigned to a creditor of the business partner. In this way, the business partner may allow the creditor to directly receive funds from the business partner's transaction.
Many of today's business transactions are carried out using specialized software and systems. For example, a procurement management system may be provided to facilitate procurement-related transactions, including purchase order placements, invoice issuances, and a variety of other suitable transactions. The procurement management system may allow user interactions through a variety of user interfaces. At least one business partner may be referenced in each of these interfaces. As an example, in a purchase order entry interface, the procurement management system may verify and save one or more vendors, one or more purchasers, and any other business partners involved in the purchase. As another example, when displaying an invoice to the user, the procurement management system may identify which vendor the product came from, the sales agent that had carried out the sale, any invoicing party that is to be paid, and any other suitable business partner. Thus, in order to properly carry out and document the transactions, the procurement management system relies heavily on its capability to accurately identify the business partners involved.
While accurate identification of business partners is important in a procurement management system, current identification procedures in these systems remain associated with a very simplistic categorization scheme. For example, in such a system, business partners may be simply identified as vendors, invoice recipients, and a few other rather general categories of business partners. This simplistic categorization operates based on a number of assumptions, including, for example, the assumption that a vendor is responsible for providing a whole range of functions including provision of goods and services, shipping the goods and/or delivering the services, invoicing the transactions, and performing any other seller-oriented functions. This blanket assumption ignores the fact that, in actuality, very few vendors handle every one of the above functions without further delegation to other sub-level or external business partners. Thus, in the above system, the vendor bears the burden of manually filtering and forwarding the appropriate information, which the procurement management system has generally categorized as vendor information, to the appropriate designated sub-level or external business partners.
Accordingly, it is desirable to provide a method and system that enables the creation and management of related business partners so that appropriate information and tasks in a procurement management system may be directed to the appropriate business partners who will use the information and/or perform the tasks. More specifically, it is desirable to provide a method and system that enables the creation and management of a business partner having multiple associated invoicing parties, so that appropriate information and tasks may be assigned and forwarded to the appropriate invoicing party.
Consistent with the principles of the present invention, a system and method is disclosed for managing a plurality of invoicing parties associated with a business partner in a procurement management system.
Consistent with the principles of the present invention, the procurement management system may provide a series of interfaces in which the user may input, edit, and manage business partner-related information, including a business partner's relationships with one or more associated invoicing parties. The system may suggest an invoicing party as a default invoicing party in an invoice associated with the business partner. The suggested invoicing party may be selected from the plurality of invoicing parties associated with the business partner. The procurement management system may allow the user to replace the suggested default invoicing party in the invoice with another invoicing party from the plurality of invoicing parties associated with the business partner.
Consistent with the principles of the present invention, the procurement management system may suggest a vendor for an invoice based on an invoicing party associated with the invoice. The procurement management system may make such a suggestion by first determining for which business partners the invoicing party associated with the invoice serves as default invoicing party. Based on this determination, the procurement management system may suggest one of the determined business partners as the vendor in the present invoice. The procurement management system may select one of the determined business partners based on a variety of criteria including, for example, a priority of the business partners associated with the invoicing party or any other suitable criteria.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as claimed. The foregoing background and summary are not intended to provide any independent limitations on the claimed invention.
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate various embodiments and aspects of the present invention. In the drawings:
The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar parts. While several exemplary versions and features of the invention are described herein, modifications, adaptations and other implementations are possible, without departing from the spirit and scope of the invention. For example, substitutions, additions or modifications may be made to the components illustrated in the drawings, and the exemplary methods described herein may be modified by substituting, reordering or adding steps to the disclosed methods. Accordingly, the following detailed description does not limit the invention. Instead, the proper scope of the invention is defined by the appended claims.
As mentioned above, business partner-related data is critical to various functions of a procurement management system. Due to its importance, definition and modification of such data may be restricted to authorized users. An authorized user may be, for example, an individual who is designated to perform business partner management-related activities by the proprietor of the procurement management system or designated as an authorized user through any other suitable means. Consistent with the principles of the present invention, the scope of the business partner management activities that an authorized user may perform may be restricted, for example, based on the user's role or other suitable user characteristics. In one example, an external vendor, who is designated as an authorized user, may have limited authority to modify its own associated group of invoicing parties. Consistent with the principles of the present invention, the authorized user may perform business partner management-related activities in various user interfaces.
Consistent with the principles of the present invention, the authorized user may create a new business partner using interface 100. To create the new business partner, the user may first specify a type or category to which the new business partner will belong. The assignment of a type or category allows the new business partner to be referenced and assigned to tasks in its appropriate capacity based on its associated type or category. The types or categories of business partners that the user may choose to assign to the new business partner may be pre-defined and divided into external business partner types and internal business partner types. The external business partner types may include bidder, vendor, invoicing party, contact person, ship-from address, and any other suitable external business partner type. A bidder may be, for example, any company that is able to submit bids in response to a bid invitation. A vendor may be any business partner from whom goods and services may be obtained. An invoicing party may be an individual or suitable entity designated by a vendor to send out invoices and, in many cases, receive payments. A contact person may be a specific individual designated by a bidder or vendor to represent the bidder or vendor in a limited capacity. Ship-from address may be the primary outbound delivery address from which the goods are shipped.
Internal business partner types, on the other hand, may include requester, purchasing company, goods recipient, ship-to address, location, invoice recipient, and any other suitable internal business partner type. A requester may be, for example, a business partner who requests a particular procurement-related activity such as an invoice entry. A purchasing company may be a company that uses the procurement management system for purchasing-related tasks. A goods recipient may be an employee in a company that confirms goods receipt or performance of service. A ship-to address may be a delivery address for goods purchased. A location may be an address such as a processing plant location. An invoice recipient may be a business partner to whom the invoice is sent. The list of both internal and external business partner types may be supplemented or otherwise modified without departing from the spirit of the present invention.
Consistent with the principles of the present invention, the user may select an internal or external business partner type, for example, from drop down menu 104. Consistent with the prin, the list of business partner types that may be selected from drop down menu 104 may be restricted to a subset of the entire list of pre-defined business partner types, for example, based on user authorization, or any other suitable consideration.
The user may create a new business partner of the selected business partner type using, for example, create button 106. Once a business partner is created, the user may select the business partner for viewing and editing. For example, the user may input a business partner of types including, for example, bidder, vendor, invoicing party, or any other suitable type, for editing in field 108. The user may search for such a business partner for editing using search button 110. When the desirable business partner is found, the user may invoke editing of data associated with the business partner using, for example, edit button 112. Edits of any suitable type may be performed separately from edits of other business partner types. As an example, in interface 100, searching and editing of the type location may be invoked separately, for example, using field 114 and buttons 116 and 118.
Sometimes, it may be desirable for the user to edit data associated with a business partner concurrently with data associated with the business partner's various employees. In the present example, interface 100 provides simultaneous editing of both business partner and its associated employees through related fields 120, 122 and buttons 124-128.
Consistent with the principles of the present invention, the user, when creating a business partner of a particular type, may choose the data associated with the business partner from a stored source. In the present example, user selection of business partner data may be performed in connection with a drop down menu 130. The user may assign a particular business partner type to the selected business partner data using another drop down menu 132. The selections made in drop down menus 130 and 132 may be used to create a new business partner using button 134. Consistent with the principles of the present invention, the business partner data of drop down menu 130 may be chosen by the procurement management system based on a variety of criteria, including, for example, the identity of the authorized user.
Consistent with the principles of the present invention, data associated with an existing business partner may be copied and converted into a new business partner of another type. As an example, the user may input or search for an existing business partner for conversion using field 136 and button 138. Once the existing business partner is identified, the user may select the new business partner type into which the existing business partner is to be converted, for example, from drop down menu 140. The conversion may be executed using button 142.
Consistent with the principles of the present invention, a business partner may have one or more associated employees. In interface 100, the user may input and create an employee for a business partner using field 144 and button 146. Consistent with the principles of the present invention, an employee may also have an associated user. As an example, an employee may be associated with a user who has certain authorizations that may, for example, enable the user/employee to manage business partner-related information. In interface 100, a user may be created for an employee using field 148 and button 150.
Consistent with the principles of the present invention, one or more business partners may be closely related, so that the existence of one is dependent upon the existence of the other. As an example, a contact person may be a dependent of a vendor or bidder and cannot exist as an independent business partner if the vendor or bidder upon whom it depends does not exist. Accordingly, when creating a dependent business partner, it may be required that the business partner upon whom the dependent business partner depends be specified. Consistent with the principles of the present invention, certain business partners may be required to have associated dependent business partners. As an example, a vendor may be required to have an associated contact person. In such a situation, when the primary business partner is created, the system may require the creation of a necessary dependent business partner.
Consistent with the principles of the present invention, the procurement management system may allow the deletion of business partners and employees of business partners. Prior to a deletion, the procurement management system may check and verify that the business partner and/or employee is not associated with any open transactions or any other pending or open activities. Consistent with the principles of the present invention, a deletion of a business partner may include the deletion of one or more associated business partners, employees, users, or any other suitable entities that depend upon the business partner. Thus, the procurement management system may additionally verify that these dependent business partners and other suitable entities are not associated with open transactions or activities prior to deletion. In interface 100, the user may request deletion of a business partner or employee of a business partner using fields 152 and 154 and delete buttons 156 and 158. Interface 100 may additionally provide editing of business partners of type purchasing company using, for example, button 160.
It will be understood that interface 100 is merely illustrative of such an interface for managing business partners in a procurement management system. Elements may be added or omitted from interface 100 without departing from the spirit of the present invention.
As mentioned above, a business partner, such as a vendor, may have one or more associated business partners of type invoicing party. An invoicing party may also serve the invoicing needs of one or more business partners. In order to accommodate these possible multilateral relationships, when a business partner of type invoicing party is created in the procurement management system, for example, using an interface such as interface 100 of
Management of various multilateral relationships between invoicing parties and the business partners that the invoicing parties serve may be provided through one or more interfaces in the procurement management system. As an example, an interface, such as interface 200 of
In response to such a request, the procurement management system may provide the authorized user with options to edit information, including invoicing party relationships, associated with a business partner. For example, tabs 202-208 may be provided to enable the user to access the various types of information associated with the business partner. It will be understood that tabs 202-208 may be added, removed, made inactive, or otherwise modified without departing from the spirit of the present invention.
In the present example, the user may use tab invoice flag 206 to access the invoicing party relationships associated with the current business partner. Consistent with the principles of the present invention, two types of invoicing party relationships may be included in an interface such as interface 200. The two types of invoicing party relationships may include relationships in which the current business partner serves as the invoicing party for other business partners, such as vendors, and relationships in which the current business partner has one or more designated invoicing parties.
In the present example, relationships in which the current business partner serves as invoicing party for other business partners are shown in table 210. In table 210, some attributes of each business partner, including various names or other references for referring to the business partner, may be shown. The one or more business partners listed in table 210 may be automatically selected by the system based on, for example, the identity of the current business partner or any other suitable criteria. Alternatively, the listed business partners may be selected by the user or selected by any other suitable means. It will be understood that any suitable business partners may be selected for the above list without departing from the spirit of the present invention.
Consistent with the principles of the present invention, the current business partner may simultaneously serve as invoicing party for any number of associated business partners listed in table 210. Accordingly, a selection mechanism such as a set of checkboxes, which allows the user to select more than one business partners to whom to serve as invoicing party, may be provided in table 210.
Consistent with the principles of the present invention, the current business partner may also be associated with one or more designated invoicing parties. As an example, a business partner that is an international vendor may have different invoicing parties in two or more of its regions or countries of operation. As another example, a vendor, who has an in-house invoicing party, may designate one of its creditors as the invoicing party in some of its transactions so that the creditor may be directly paid by the buyers. Through these examples, it is easy to see the advantages of allowing a business partner to have more than one associated invoicing party. However, when more than one invoicing party is associated with a single business party, confusion may arise as to which invoicing party is responsible for a particular transaction. To address such confusion, the procurement management system may require the designation of one of the business partner's associated invoicing parties as the responsible invoicing party in each of the business partner's transactions.
While the above requirement resolves the confusion as to which invoicing party is responsible for a transaction, it may be too tedious and repetitious for the business partner to perform on a regular basis. Accordingly, the procurement management system may additionally allow the designation of a default invoicing party for a business partner. The default invoicing party may be, for example, the most often used invoicing party among the plurality of invoicing parties associated with the business partner or a default invoicing party selected based on any other suitable criteria. When preparing an invoice, the procurement management system may suggest the default invoicing party as the responsible invoicing party for that invoice. If desired, the business partner may be allowed to replace the suggested default invoicing party with another invoicing party from its plurality of invoicing parties.
In the present example of
It will be understood that interface 200 is merely illustrative of such an interface for facilitating the management of invoicing party relationships. Any other suitable screens or interfaces may be used without departing from the spirit of the present invention.
A load data section 302 may be provided on screen 300. In this section, the user may insert items into the invoice, for example, by loading data associated with the items from one or more related documents in the system. In this particular example, the user is allowed to load item data from a number of existing purchase orders. For example, the user may provide a known purchase order number of a related purchase order in field 304. The user may obtain this number, for example, from a received invoice, which references the purchase order.
In accordance with a system consistent with the principles of the present invention, the user may press button 306 to display a new screen or interface in which the user may enter or select multiple purchase orders, for example, using a mechanism for multiple selection. In the event that the user does not know the specific purchase order number of one or more related purchase orders, the user may request a general search for the one or more purchase orders using, for example, the find purchase order option 310. In this option, the user may use various criteria, such as a vendor, an invoicing party, or any other suitable criteria, to search for a related purchase order. While data loading from related documents such a purchase order is specifically described above, it is not the only way to input item data into an invoice. The user may manually input various invoice and item data or use any other suitable input means for entering such data without departing from the spirit of the present invention.
In addition to loading invoice data from preexisting documents, data may also be inputted into various fields of the invoice entry. Consistent with the principles of the present invention, the procurement management system may automatically suggest an invoicing party in invoicing party field 312. As an example, the procurement management system may suggest an invoicing party that has been previously selected as a default invoicing party, for example, from the plurality of invoicing parties associated with the vendor involved in the current invoice, as shown in interface 200 of
When inputting invoicing data in screen 300, certain types of information may be prevented from user modification, for example, to prevent human errors or unauthorized data manipulation. Prevention of user modification may be achieved by, for example, making the data field inactive or by using any other suitable method. In the present example, the field invoice recipient 322 is made inactive. This may prevent a user, who may be the invoice recipient, from making modification to this field. An inactive field or other such restricted information may be made available for modification, for example, when the user is identified as an authorized user for making such modifications.
In portion 324 of screen 300, an overview of the various line items included in the invoice may be displayed. Some attributes or specifics to each of the line item, such as, for example, a description, a net value, quantity, net price, tax, etc. may be displayed. The user may add or modify items manually using the provided input means (e.g., text boxes and drop down menus). Alternatively, the user may choose to add an item and its associated data from a stored catalog by, for example, selecting the item from catalog 326.
It will be understood that invoice entry interface 300 is merely illustrative of such an interface. Any other suitable screens or interfaces may be used without departing from the spirit of the present invention.
At step 404, the system may suggest an invoicing party from the plurality of invoicing parties associated with the business partner as a default invoicing party in an invoice associated with the business partner. As an example, the business partner may be a recognized vendor of an invoice, for example, an invoice as shown in interface 300 of
At step 406, the procurement management system may allow the user to replace the suggested default invoicing party in the invoice with another invoicing party from the plurality of invoicing parties associated with the business partner. The user may make such a replacement, for example, using the invoicing partner search button 320 of
At step 504, the procurement management system may suggest a vendor for an invoice based on an invoicing party associated with the invoice. As mentioned above, a vendor may be a business partner to whom a plurality of invoicing parties is associated. Also as mentioned above, each business partner, including a vendor, may have a designated default invoicing party. When an invoicing party associated with an invoice is known, for example, from an existing purchase order related to the invoice, from a goods receipt related to the invoice, from user input, or from any other suitable source, the procurement management system may determine for which business partners the invoicing party serves as the default invoicing party. Based on this determination, the procurement management system may suggest one of the determined business partners as the vendor in the present invoice. The procurement management system may select one of the determined business partners based on a variety of criteria including, for example, a priority of the business partners associated the invoicing party or any other suitable criteria.
A computer system may be used to install a software application implementing a system consistent with the principles of the present invention. The computer system may be a computer network, as shown in
As shown in
PC 604 may include a bus line 608 connecting a plurality of devices such as a processor 610, memory devices 612 for storage of information, diskette drives 614, a fixed disk drive 616, a monitor or display 618, other I/O devices 620, and a network interface card (NIC) 622. Processor 610 may be a microprocessor such as an Intel Pentiumâ„¢ chip for processing applications. Memory devices 612 may include read-only memories (ROM) and/or random access memories (RAM). Diskette drives 614 may include a floppy drive and/or a compact disk (CD) drive. Fixed disk drive 616 may be a hard drive. I/O devices 620 may include a keyboard and/or a mouse for receiving input from a user of PC 604. Monitor or display 618 may display output from processor 610, and may also echo the input of the user. PC 604 may be connected to network path 606 through NIC 622.
A web application may be installed on server 602. An individual desiring to enter data into the application on server 602 may use a web browser loaded on PC 604, and may communicate with server 602 through NIC 622 and network path 606. In one aspect, software application for implementing a system consistent with the principles of the present invention may be stored in PC 604 and processor 610 of PC 604 may execute the software application locally within PC 604 and interface with a web application on server 602. Particularly, the software application may be stored on a floppy disk, a CD, or any other suitable readable media, which may be accessible by diskette drive 614, fixed disk drive 616, or any other suitable mechanism. In another aspect, the software application for implementing a system consistent with the principles of the present invention may be stored in server 602, which may execute the software application, and processor 610 of PC 604 may communicate with server 602 to send information to server 602 and retrieve the results of the execution of the software application from server 602.
Through the execution of the software application implementing a system consistent with the principles of the present invention, either locally within PC 604 or remotely within server 602, an interface may be provided on a user display, which enables the user to input, view, and interact with an invoice having one or more line items of different line item types.
Alternatively, as shown in
A software application implementing a system consistent with the principles of the present invention may be stored on a floppy disk or a CD accessible by diskette drive 708 or on fixed disk drive 710. Processor 704 may execute the software application stored in the floppy disk the CD or the fixed disk drive 710. An individual, through monitor or display 712 and I/O devices 714, may interact with processor 704, which may execute the software application. A software application implementing a system consistent with the principles of the present invention may be written in any number of programming languages, including but not limited to JavaScript, Visual Basic, Flash, ABAP coding, or any other suitable language. Similarly, the present invention is not limited to use with certain applications, Internet browsers or operating systems.
Furthermore, the invention may be practiced in an electrical circuit comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic elements or microprocessors. The invention may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, including but not limited to mechanical, optical, fluidic, and quantum technologies. In addition, the invention may be practiced within a general purpose computer or in any other circuits or systems.
While the present invention has been described in connection with various embodiments, many modifications will be readily apparent to those skilled in the art. One skilled in the art will also appreciate that all or part of the systems and methods consistent with the present invention may be stored on or read from computer-readable media, such as secondary storage devices, like hard disks, floppy disks, and CD-ROM; a carrier wave received from a network such as the Internet; or other forms of ROM or RAM. Accordingly, embodiments of the invention are not limited to the above described embodiments and examples, but instead is defined by the appended claims in light of their full scope of equivalents.