SYSTEM THAT PROVIDES PROCUREMENT BY A LEGAL ENTITY ON BEHALF OF ANOTHER LEGAL ENTITY

Abstract

A system is provided that facilitates procurement by a first legal entity on behalf of a second legal entity. The system receives a request to generate an electronic financial document including an electronic financial document line that includes the second legal entity. The system further defines a sold-to legal entity as the first legal entity in response to a determination that a supply chain financial orchestration flow is not defined for the electronic financial document. The system further determines whether procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document. The system further generates the electronic financial document including the defined sold-to legal entity, the first electronic financial document line, and the second electronic financial document line when it is determined that procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority of U.S. Provisional Patent Application Ser. No. 62/024,858, filed on Jul. 15, 2014, the subject matter of which is hereby incorporated by reference.

FIELD

One embodiment is directed to a computer system, and more particularly, to a computer system that automatically generates financial documents, such as purchase orders.

BACKGROUND

A purchase order is a contractually binding document between a buying organization and a selling organization. It contains information pertaining to goods and/or services that a buying organization commits to buy, where the information can include, for example, an item, a description of a service, a quantity, and a price.

A “legal entity” is an association, corporation, partnership, proprietorship, trust, individual, or other type of entity that has legal standing in the eyes of the law. A “legal entity” has a legal capacity to enter into agreements or contracts, assume obligations, incur and pay debts, sue and be sued in its own right, and be held responsible for its actions. A purchase order is a financial and legal contract between a buyer and a seller. A “sold-to legal entity” on a purchase order represents a buying entity associated with the purchase order who assumes any obligations originating from the purchase order, and who incurs and pays debts originating from the purchase order.

Corporations often have multiple legal entities across countries and at times multiple legal entities are registered even within a country. In order to be cost effective, members of closely related legal entities can devise ways to reap scale efficiencies. These ways can include: enabling one legal entity to procure goods for consumption by another legal entity, thus benefiting from volume purchases; leveraging a tax structure governing a given legal entity; utilizing a competitive advantage of a country, containing any legal exposure to a specific legal entity while insulating the other legal entities, or containing administrative overhead related to tax reporting requirements to a central unit. Thus, requirements regarding an assignment of a sold-to legal entity on a purchase order can range from simple to extremely complex. Thus, corporations may often require a way to streamline centralized purchases within a country through a single legal entity on behalf of all other legal entities co-located within the same country.

SUMMARY

One embodiment is a system that facilitates procurement by a first legal entity on behalf of a second legal entity. The system receives a request to generate an electronic financial document including an electronic financial document line that includes the second legal entity. The system further defines a sold-to legal entity as the first legal entity in response to a determination that a supply chain financial orchestration flow is not defined for the electronic financial document. The system further determines whether procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document. The system further generates the electronic financial document including the defined sold-to legal entity, and the electronic financial document line when it is determined that procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document.

BRIEF DESCRIPTION OF THE DRAWINGS

Further embodiments, details, advantages, and modifications will become apparent from the following detailed description of the preferred embodiments, which is to be taken in conjunction with the accompanying drawings.

FIG. 1 illustrates a block diagram of a system that can implement an embodiment of the invention.

FIG. 2 illustrates a sold-to legal entity associated with a purchase order, sourcing award, and invoice, according to an embodiment of the invention.

FIG. 3 illustrates procurement models according to an embodiment of the invention.

FIG. 4 illustrates an example transaction according to a local-global hybrid procurement model, according to an embodiment of the invention.

FIG. 5 illustrates an example user interface of a purchasing system that is used to define whether a legal entity is allowed to procure items on behalf of other legal entities, according to an embodiment of the invention.

FIG. 6 illustrates an example user interface of a purchasing system that is used to create a first requisition, according to an embodiment of the invention.

FIG. 7 illustrates a user interface of a purchasing system that displays an inventory organization associated with a deliver-to location of the first requisition, according to an embodiment of the invention.

FIG. 8 illustrates a user interface of a purchasing system that displays a legal entity associated with an inventory organization of the first requisition, according to an embodiment of the invention.

FIG. 9 illustrates an example user interface of a purchasing system that is used to create a second requisition, according to an embodiment of the invention.

FIG. 10 illustrates a user interface of a purchasing system that displays an inventory organization associated with a deliver-to location of the second requisition, according to an embodiment of the invention.

FIG. 11 illustrates a user interface of a purchasing system that displays a legal entity associated with an inventory organization of the second requisition, according to an embodiment of the invention.

FIG. 12 illustrates a user interface of a purchasing system that is used to process the first requisition onto a purchase order, according to an embodiment of the invention.

FIG. 13 illustrates another user interface of a purchasing system that is used to process the first requisition onto a purchase order, according to an embodiment of the invention.

FIG. 14 illustrates a user interface of a purchasing system that is used to process the second requisition onto a purchase order, according to an embodiment of the invention.

FIG. 15 illustrates a user interface of a purchasing system that is used to create a purchase order, according to an embodiment of the invention.

FIG. 16 illustrates a user interface of a purchasing system that is used to edit a purchase order, according to an embodiment of the invention.

FIG. 17 illustrates another user interface of a purchasing system that is used to edit a purchase order, according to an embodiment of the invention.

FIG. 18 illustrates an example of billing associated with a transaction according to a local-global hybrid procurement model, according to an embodiment of the invention.

FIG. 19 illustrates an example of requisitioning business units that are serviced by a common bill-to business unit that processes invoices for the requisitioning business units, according to an embodiment of the invention.

FIG. 20 illustrates another example of billing associated with a transaction according to a local-global hybrid procurement model, according to an embodiment of the invention.

FIG. 21 illustrates a user interface of a purchasing system that is used to edit a purchase order, according to an embodiment of the invention.

FIG. 22 illustrates a user interface of a purchasing system that displays a bill-to business unit associated with a supplier site, according to an embodiment of the invention.

FIG. 23 illustrates a user interface of a purchasing system that displays a bill-to business unit associated with a purchase order, according to an embodiment of the invention.

FIG. 24 illustrates a user interface of a purchasing system that displays a bill-to business unit associated with a supplier site, according to an embodiment of the invention.

FIG. 25 illustrates a flow diagram of the functionality of a legal entity procurement module, according to an embodiment of the invention.

DETAILED DESCRIPTION

According to an embodiment, a purchasing system is provided that facilitates procurement by a first legal entity on behalf of a second legal entity, where the procurement is implemented using a financial document, such as a purchase order. The purchasing system defines whether procurement by a first legal entity on behalf of a second legal entity is allowed for the financial document for a specific requisitioning business unit, and displays an indication as to whether procurement by a first legal entity on behalf of a second legal entity is allowed for the financial document within a user interface. Based on the indication, the purchasing system can treat the definition of the first legal entity procuring one or more items on behalf of the second legal entity within the financial document as an error, a warning (giving control to a user as to whether to generate the financial document), or as a valid scenario. The purchasing system further determines whether a first legal entity is implementing procurement on behalf of a second legal entity using the financial document by determining whether a central sold-to legal entity is defined as being able to procure one or more items on behalf of a sold-to legal entity associated with the financial document. The purchasing system further determines whether it generates the financial document based on whether procurement by a first legal entity on behalf of a second legal entity is allowed for the financial document. The purchasing system can further optionally receive a request to override a sold-to legal entity associated with the financial document. The purchasing system can further optionally determine whether a user associated with the request has an appropriate privilege to override the sold-to legal entity. The purchasing system can further optionally override the sold-to legal entity based on whether the user has the appropriate privilege. Further, according to an embodiment, a purchasing system can relax a requirement of setting up a supply chain financial orchestration flow. By relaxing this requirement, the purchasing system can also optionally provide centralized billing functionality, where a set of one or more business units can require invoice processing services, and another business unit (i.e., a bill-to business unit) can provide the invoice processing services.

FIG. 1 illustrates a block diagram of a system 10 that may implement one embodiment of the invention. In one embodiment, system 10 can be a specialized purchasing system. System 10 includes a bus 12 or other communications mechanism for communicating information between components of system 10. System 10 also includes a processor 22, operatively coupled to bus 12, for processing information and executing instructions or operations. Processor 22 may be any type of general or specific purpose processor. System 10 further includes a memory 14 for storing information and instructions to be executed by processor 22. Memory 14 can be comprised of any combination of random access memory (“RAM”), read only memory (“ROM”), static storage such as a magnetic or optical disk, or any other type of machine or computer-readable medium. System 10 further includes a communication device 20, such as a network interface card or other communications interface, to provide access to a network. As a result, a user may interface with system 10 directly, or remotely through a network or any other method.

A computer-readable medium may be any available medium that can be accessed by processor 22. A computer-readable medium may include both a volatile and nonvolatile medium, a removable and non-removable medium, a communication medium, and a storage medium. A communication medium may include computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any other form of information delivery medium known in the art. A storage medium may include RAM, flash memory, ROM, erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, hard disk, a removable disk, a compact disk read-only memory (“CD-ROM”), or any other form of storage medium known in the art.

Processor 22 can also be operatively coupled via bus 12 to a display 24, such as a Liquid Crystal Display (“LCD”). Display 24 can display information to the user. A keyboard 26 and a cursor control device 28, such as a computer mouse, can also be operatively coupled to bus 12 to enable the user to interface with system 10.

According to one embodiment, memory 14 can store software modules that may provide functionality when executed by processor 22. The modules can include an operating system 15, a legal entity procurement module 16, as well as other functional modules 18. Operating system 15 can provide an operating system functionality for system 10. Legal entity procurement module 16 can provide functionality for facilitating procurement by a first legal entity on behalf of a second legal entity, as is described in more detail below. In certain embodiments, legal entity procurement module 16 can comprise a plurality of modules that each provide specific individual functionality for facilitating procurement by a first legal entity on behalf of a second legal entity. System 10 can also be part of a larger system. Thus, system 10 can include one or more additional functional modules 18 to include the additional functionality. For example, functional modules 18 may include modules that provide additional functionality, such as an “Oracle Fusion Purchasing” product, from Oracle Corporation.

Processor 22 can also be operatively coupled via bus 12 to a database 34. Database 34 can store data in an integrated collection of logically-related records or files. Database 34 can be an operational database, an analytical database, a data warehouse, a distributed database, an end-user database, an external database, a navigational database, an in-memory database, a document-oriented database, a real-time database, a relational database, an object-oriented database, or any other database known in the art.

FIG. 2 illustrates a sold-to legal entity associated with a purchase order, sourcing award, and invoice, according to an embodiment of the invention. As previously described, a “sold-to legal entity” is a legal entity that is liable for a purchase order, or other financial document, and has a relationship with a location of the supplier that is going to fulfill the purchase order. According to an embodiment, a purchasing system can capture a sold-to legal entity associated with a financial document, such as a purchase order, and display the sold-to legal entity within a user interface. The purchasing system can further display the sold-to legal entity as part of a display of the financial document, and can further print the sold-to legal entity as part of a printout of the financial document. According to the illustrated embodiment, FIG. 2 includes user interfaces 210, 220, 230, and 240. User interface 210 displays a purchase order and further displays a sold-to legal entity (“Vision Operations”) associated with the purchase order. User interface 220 displays an invoice that is based on the purchase order displayed within user interface 210 and further displays the sold-to legal entity (“Vision Operations”) associated with the invoice. User interface 230 displays a sourcing award that leads to the purchase order displayed within user interface 210 and further displays the sold-to legal entity (“Vision Operations”) associated with the sourcing award. User interface 240 displays an electronic document representation, such as a Portable Document Format (“PDF”) file representation, of the purchase order displayed within user interface 210, and further displays the sold-to legal entity (“Vision Operations”) associated with the purchase order.

FIG. 3 illustrates procurement models 310, 320, and 330 according to an embodiment of the invention. Procurement model 310 is a local model. Within procurement model 310, organizations “ORG1” and “ORG2” belong to a legal entity “LE1.” Purchase orders, or other financial documents, are created by organization “ORG1” or organization “ORG2” to a supplier site “Site1” of a supplier “Supplier.” The purchase orders, or other financial documents, indicate legal entity “LE1” as a sold-to legal entity. In these scenarios, an organization is engaged with a local supplier and organizational policies dictate that requisitions that are sourced from the local supplier to be processed via purchase orders, where the sold-to legal entity is the legal entity that the line of business (“LOB”), department, cost center, or profit center reports into financially. It is this legal entity that possesses liability for the requested item or service. In procurement model 310, the sold-to legal entity is the legal entity of the organization requesting the item or service (i.e., the legal entity to which the ship-to organization specified on the purchase order, or other financial document, rolls up to). In other words, in procurement model 310, the sold-to legal entity is legal entity “LE1.” In the illustrated embodiment, within procurement model 310, a purchase order is associated with a supplier site “Site1” of a supplier “Supplier.” The requesting organization is either “ORG1” or “ORG2.” The sold-to legal entity is legal entity “LE1.” Further, the ship-to organization is either “ORG1” or “ORG2.”

Procurement model 320 is a global model. Within procurement model 320, organizations “US ORG1” and “US ORG2” roll up to legal entity “US LE1”. Further, within procurement model 320, organization “SG ORG1” rolls up to legal entity “SG LE1.” Purchase orders, or other financial documents, that are created to fulfill requirements from organization “US ORG1” or organization “US ORG2” are generated for a sold-to legal entity “SG LE1,” which is the legal entity of the organization “SG ORG1.” Thus, in scenarios where organization “US ORG1” or organization “US ORG2” is the requesting organization, the sold-to legal entity is not legal entity “US LE1,” and thus, the liability is not assumed by legal entity “US LE1.” Instead, the sold-to legal entity is “SG LE1,” and thus, the liability is assumed by legal entity “SG LE1.” In such scenarios, a requesting organization typically does not have any direct relationship with the supplier site fulfilling the order. Instead, it is a subsidiary that manages, or otherwise engages in a relationship with, the supplier site. In the illustrated embodiment, within procurement model 320, a purchase order is associated with a supplier site “CN Site1” of a supplier “CN Supplier.” The requesting organization is “US ORG1.” However, the sold-to legal entity is legal entity “SG LE1” rather than “US LE1.” The ship-to organization is organization “US ORG1.” Upon receipt into “US ORG1,” “SG LE1” sells the procured goods to “US LE1.”

Procurement model 320 is typically seen in organizations that have built sophisticated supply chains, in which they engage with suppliers all across the world. Procurement model 320 is popular with such organizations because China and Southeast Asian countries have become the manufacturing hub of the world, and an increasing number of companies around the world are outsourcing low-end tasks to low-cost countries. Procurement model 320 is also popular with global corporations that direct their overseas income to low-tax countries to minimize tax expenses. Such companies requires purchases to be financially orchestrated via one or more supply chain financial orchestration flows across multiple legal entities, and, in the process, reap tax efficiencies. In order to orchestrate such a flow, one or more transfer pricing arrangements are agreed upon among various legal entities involved in a transaction.

Procurement model 330 is a local-global hybrid model. Within procurement model 330, organizations “US ORG1” and “US ORG2” roll up to legal entity “US LE1.” Further, within procurement model 330, organization “US ORG3” rolls up to legal entity “US LE2.” In the illustrated embodiment, within procurement model 330, a purchase order is associated with a supplier site “US Site1” of a supplier “US Supplier.” The requesting organization is “US ORG2.” However, the sold-to legal entity is legal entity “US LE2,” rather than legal entity “US LE1.” Further, the ship-to organization is organization “US ORG3” rather than organization “US ORG2.” In countries like the United States, regulations allow a legal entity to procure goods and services on behalf of another legal entity without a formal trade agreement, such as a supply chain financial orchestration flow, or without any additional legal documentation, such as an intercompany accounts receivable invoice and an intercompany accounts payable invoice. Intercompany journal entries can be created in a general ledger once the transaction is accrued.

Regarding procurement model 330, on transactions that are not eligible for supply chain financial orchestration, customers may require a capability of a purchasing system where, even though a purchase order is issued by a single legal entity (i.e., a sold-to legal entity), items procured on the purchase order can be internally charged to a business unit in different legal entities. There are two related but distinct scenarios that are described below that further explain this capability that customers may require.

In the first scenario, a purchase order 101 can be generated by a sold-to legal entity “LE1” to a supplier “Industrial Plastics” to procure items that will be internally charged to a ship-to organization in another legal entity, legal entity “LE2.” The purchasing system should allow purchase order 101 to be processed, and should show legal entity “LE1” as the sold-to legal entity on the purchase order. For example, the purchasing system should have the capability to generate a PDF file representation of the purchase order where legal entity “LE1” is displayed.

In the second scenario, a purchase order 102 can be generated by a sold-to legal entity “LE1” to a supplier “Industrial Plastics” to procure three items, items A, B, and C. The purchase order includes three purchase order lines, the first purchase order line corresponding to item A, the second purchase order line corresponding to item B, and the third purchase order line corresponding to item C. The first purchase order line references legal entity “LE2,” the second purchase order line references legal entity “LE3,” and the third purchase order line references legal entity “LE4.” Thus, the supplier-facing legal entity is legal entity “LE1,” which is the sold-to legal entity, but the three items are internally charged to ship-to organizations in different legal entities (i.e., legal entities “LE2,” “LE3,” and “LE4”).

In accordance with an embodiment of the invention, a purchasing system can facilitate a procurement of an item on a financial document, such as a purchase order, where the procurement is by a first legal entity on behalf of a second entity. There are additional features that can be provided by such a purchasing system in supporting this model, in accordance with an embodiment of the invention. Such additional features are now described below in greater detail.

One feature is allowing customers an ability to turn on, or turn off, a feature for facilitating procurement by a first legal entity on behalf of a second entity within a purchasing system, in accordance with an embodiment of the invention. Regulations in many countries require strict or special documentation to be produced and maintained, if a legal entity within an enterprise is procuring goods for another legal entity. Organizations in such countries would desire the ability to turn off a feature for facilitating procurement by a first legal entity on behalf of a second entity within the purchasing system. The aforementioned feature is most beneficial in countries such as the United States, where regulations allow such purchases without additional documentation. In accordance with an embodiment, a purchasing system can turn off a feature for facilitating procurement by a first legal entity on behalf of a second entity, but can allow organizations to turn on the feature per requisitioning business unit.

Another feature is allowing a privileged user to override a defaulted sold-to legal entity. In the absence of a “supply chain financial orchestration flow,” where a “supply chain financial orchestration flow” defines a trade relationship between a first legal entity and a second legal entity, a sold-to legal entity can be determined by a ship-to organization in which a purchase order, or other financial document, is expended or cost account for. There may be cases in which a sold-to legal entity suggested by a purchasing system is sub-optimal and may need to be overridden. Organizations may need privileged users to be able to override the sold-to legal entity recommended by the purchasing system. An example supply chain financial orchestration flow is disclosed in U.S. Pat. App. Pub. No. 2014/0095361.

As an example, a purchasing system can recommend a “Vision Services” legal entity as a sold-to legal entity based on a ship-to organization, which in turn is determined by a ship-to location (i.e., “V10 Virginia”) associated with a purchase order. However, it is possible that a different legal entity is authorized to buy an item the user is about to procure. In this situation, a privileged user should have the capability to override the sold-to legal entity.

According to an embodiment, a purchasing system can solve the problems that arise in procurement model 330 by facilitating a procurement of an item on a financial document, such as a purchase order, where the procurement is by a first legal entity on behalf a second entity. This facilitation is further described below in greater detail. Certain prior purchasing systems addressed the problem rather invasively by treating procurement model 330 as procurement model 320. As a consequence, customers were forced to perform elaborate setup steps to support global procurement flow. This approach generates intercompany invoices that are not needed, and adds unnecessary steps while setting up the prior purchasing systems.

Further, other prior purchasing systems attempted to solve the problem without exhaustive setup steps needed for global procurement, but did not go as far as customers wanted. For example, certain prior purchasing systems did not provide any capability for a legal entity to be specified as a sold-to legal entity on a purchase order, or other financial document, and at the same time allow items procured on the financial document to be internally charged to a ship-to organization in a different legal entity, without requiring special documents. As described below in greater detail, in accordance with an embodiment, a purchasing system can allow such a configuration.

Additionally, certain prior purchasing systems did not allow multiple items to be purchased on a single financial document, where the multiple items were internally charged to ship-to organizations in different legal entities. As described below in greater detail, in accordance with an embodiment, a purchasing system can introduce a flexibility to turn on or off a feature for facilitating procurement of an item by a first legal entity on behalf a second legal entity, given that, in many parts of the world, such a process is not allowed. According to the embodiment, when the purchasing system cannot determine an orchestration flow to apply to a purchase order, or other financial document, the purchasing system can look up a requisitioning business configuration setup of a requisitioning business unit of the purchase order, or other financial document. The setup can include an attribute called “Multiple Legal Entities on Order.” If this attribute is set to a value of “Allow” or a value of “Warning,” then the purchasing system can look up a default legal entity of the requisitioning business unit from the business unit definition and determine this legal entity to be the sold-to legal entity of the purchase order, or other financial document. If the attribute is set to a value of “Error,” then the purchasing system can determine the legal entity of the ship-to organization to be the sold-to legal entity of the purchase order, or other financial document.

Even further, certain prior purchasing systems did not provide flexibility to override, or otherwise change, a sold-to legal entity on a purchase order, or other financial document. As described below in greater detail, in accordance with an embodiment, a purchasing system can allow a privileged user to override, or otherwise change, a sold-to legal entity recommended by the purchasing system.

FIG. 4 illustrates an example transaction according to a local-global hybrid procurement model, according to an embodiment of the invention. The transaction involves two legal entities in the United States: legal entity 410 (i.e., “Vision Operations LE”) and legal entity 420 (i.e., “Vision Leasing LE”). Both legal entities 410 and 420 can utilize supplier 430 (i.e., “GE Capital”) as a supplier. Further, legal entity 410 can procure items from supplier 430 for itself and can also procure items from supplier 430 for legal entity 420. In other words, legal entity 410 can engage in procurement on behalf of legal entity 420. This can be done, even though there are no supply chain financial orchestration flows defined between legal entity 410 and legal entity 420.

FIG. 5 illustrates an example user interface 500 of a purchasing system that is used to define whether a legal entity is allowed to procure items on behalf of other legal entities, according to an embodiment of the invention. According to an embodiment, an administrator can configure a purchasing system to allow procurement by a first legal entity on behalf of a second legal entity. This configuration can include defining the first legal entity as being able to procure one or more items on behalf of the second legal entity. This configuration can be performed for one or more specific requisitioning business units. In accordance with the embodiment, the administration can set a multiple legal entities flag 510 that is displayed within user interface 500 to one of three values: “Allow”; “Warning”; or “Error.” A value of “Allow” indicates that multiple legal entities are allowed within a purchase order, or other financial document (i.e., that procurement by a first legal entity on behalf of a second legal entity is allowed for the purchase order, or other financial document). A value of “Warning” indicates that multiple legal entities are allowed within a purchase order (i.e., that procurement by a first legal entity on behalf of a second legal entity is allowed for the purchase order), but that a warning message is to be displayed within a user interface when a purchase order includes multiple legal entities (i.e., when a first legal entity is defined as procuring one or more items on behalf of a second legal entity within the purchase order). A value of “Error” indicates that multiple legal entities are not allowed within a purchase order (i.e., that procurement by a first legal entity on behalf of a second legal entity is not allowed for the purchase order), and that an error message is to be displayed within a user interface when a purchase order includes multiple legal entities (i.e., when a first legal entity is defined as procuring one or more items on behalf of a second legal entity within the purchase order).

Thus, when a purchasing system receives a request to generate a purchase order that includes multiple legal entities (i.e., that includes a first legal entity that is defined as procuring one or more items on behalf of a second legal entity within the purchase order), the purchasing system can determine the value of multiple legal entities flag 510. If the value of multiple legal entities flag 510 is “Allow,” the purchasing system can generate the purchase order that includes multiple legal entities (i.e., that includes the first legal entity that is defined as procuring one or more items on behalf of the second legal entity within the purchase order). If the value of multiple legal entities flag 510 is “Warning,” the purchasing system can display a warning message within a user interface, and can generate the purchase order that includes multiple legal entities (i.e., that includes the first legal entity that is defined as procuring one or more items on behalf of the second legal entity within the purchase order) in response to a user confirmation (e.g., via a user interaction with a button, field, or other display element within the user interface). If the value of multiple legal entities flag 510 is “Error,” the purchasing system can generate an error message within a user interface, and the purchase order that includes multiple legal entities (i.e., that includes the first legal entity that is defined as procuring one or more items on behalf of the second legal entity within the purchase order) is not generated. By allowing a purchase order with multiple entities (i.e., that includes a first legal entity that is defined as procuring one or more items on behalf of a second legal entity within the purchase order) to be generated, the purchasing system can facilitate the procurement of one or more items by a first legal entity on behalf of a second legal entity using a purchase order, where the first legal entity is a sold-to legal entity associated with the purchase order, even if the one or more items are ultimately delivered to the second legal entity.

FIG. 6 illustrates an example user interface 600 of a purchasing system that is used to create a first requisition, according to an embodiment of the invention. User interface 600 displays one or more fields where a user can enter or select values within the one or more fields. Within user interface 600, a user selects a value of “V1—New York City” within a deliver-to location field 610. Thus, a deliver-to location for the first requisition is “New York.”

FIG. 7 illustrates a user interface 700 of a purchasing system that displays an inventory organization associated with a deliver-to location of the first requisition, according to an embodiment of the invention. From a deliver-to location of the first requisition, the purchasing system can derive an inventory organization. In the illustrated embodiment, a deliver-to location 710 is “New York,” and an inventory organization 720 is “Vision Operations.”

FIG. 8 illustrates a user interface 800 of a purchasing system that displays a legal entity associated with an inventory organization of the first requisition, according to an embodiment of the invention. From an inventory organization of the first requisition, the purchasing system can derive a legal entity. In the illustrated embodiment, an inventory organization 810 is “Vision Operations,” and a legal entity 820 is “Vision Operations.”

FIG. 9 illustrates an example user interface 900 of a purchasing system that is used to create a second requisition, according to an embodiment of the invention. User interface 900 displays one or more fields where a user can enter or select values within the one or more fields. Within user interface 600, a user selects a value of “M2—Boston” within a deliver-to location field 910. Thus, a deliver-to location for the second requisition is Boston.

FIG. 10 illustrates a user interface 1000 of a purchasing system that displays an inventory organization associated with a deliver-to location of the second requisition, according to an embodiment of the invention. From a deliver-to location of the second requisition, the purchasing system can derive an inventory organization. In the illustrated embodiment, a deliver-to location 1010 is “Boston,” and an inventory organization 1020 is “Boston Manufacturing.”

FIG. 11 illustrates a user interface 1100 of a purchasing system that displays a legal entity associated with an inventory organization of the second requisition, according to an embodiment of the invention. From an inventory organization of the second requisition, the purchasing system can derive a legal entity. In the illustrated embodiment, an inventory organization 1110 is “Boston Manufacturing,” and a legal entity 1120 is “Vision Leasing.”

FIG. 12 illustrates a user interface 1200 of a purchasing system that is used to process the first requisition onto a purchase order, according to an embodiment of the invention. According to the embodiment, user interface 1200 displays the first requisition created by a user using user interface 600 of FIG. 6. In one embodiment, a user can enter a requisition number (i.e., “10502692”) corresponding with the first requisition within requisition field 1210 of a query criteria that is displayed within user interface 1200, and the purchasing system can display the first requisition in response to a user clicking on, or otherwise interface with, a search button. The user can select the first requisition that is displayed within user interface 1200 and click on, or otherwise interact with, add to document builder button 1220 to add the first requisition to a document builder, where the document builder is a module of the purchasing system used to generate a purchase order.

FIG. 13 illustrates a user interface 1300 of a purchasing system that is used to process the first requisition onto a purchase order, according to an embodiment of the invention. According to the embodiment, user interface 1300 displays one or more requisition lines. In an embodiment, user interface 1300 can display one or more requisition lines that satisfy a query criteria, where the query criteria is determined based on the requisition displayed within user interface 1200 of FIG. 12. The user can confirm the selection of the requisition lines, and the requisition lines can be added to the document builder.

FIG. 14 illustrates a user interface 1400 of a purchasing system that is used to process the second requisition onto a purchase order, according to an embodiment of the invention. According to the embodiment, user interface 1400 displays the second requisition created by a user using user interface 900 of FIG. 9. In one embodiment, a user can enter a requisition number (i.e., “10502703”) corresponding with the second requisition within requisition field 1410 of a query criteria that is displayed within user interface 1400, and the purchasing system can display the second requisition in response to a user clicking on, or otherwise interface with, a search button. The user can select the second requisition that is displayed within user interface 1400 and click on, or otherwise interact with, add to document builder 1420 to add the second requisition to a document builder, where the document builder is a module of the purchasing system used to generate a purchase order.

FIG. 15 illustrates a user interface 1500 of a purchasing system that is used to create a purchase order, according to an embodiment of the invention. User interface 1500 displays a sold-to legal entity 1510. According to the embodiment, sold-to legal entity 1510 (i.e., “Vision Operations”) is a legal entity associated with the first requisition. In one embodiment, a user associated with an appropriate override privilege can override sold-to legal entity 1510. This is because there are situations where the sold-to legal entity is not optimal. According to the embodiment, the purchasing system can determine whether a user has an override privilege. If the user has the override privilege, the purchasing system can display a list of possible sold-to legal entities at sold-to legal entity field 1510. The user can select a sold-to legal entity from the list of possible sold-to legal entities displayed within sold-to legal entity field 1510.

FIG. 16 illustrates a user interface 1600 of a purchasing system that is used to edit a purchase order, according to an embodiment of the invention. User interface 1600 displays a sold-to legal entity 1610. Sold-to legal entity 1610 (i.e., “Vision Operations) is identical to sold-to legal entity field 1510 of FIG. 15. User interface 1600 further displays a first purchase order line based on the first requisition and a second purchase order line based on the second requisition. The first purchase order line includes a deliver-to location 1610 (i.e., “V1—New York City” or “New York”). As previously described, the legal entity “Vision Operations” is associated with deliver-to location 1610. The second purchase order line includes a deliver-to location 1620 (i.e., M2—Boston” or “Boston”). As previously described, the legal entity “Vision Leasing” is associated with deliver-to location 1620. Thus, the legal entity associated with the second purchase line is different from sold-to legal entity 1610.

FIG. 17 illustrates another user interface 1700 of a purchasing system that is used to edit a purchase order, according to an embodiment of the invention. When a user is ready to submit the purchase order for approval, the user can click on, or otherwise interact with, submit button 1710. Subsequently, the purchasing system can implement validation logic, or other computer-readable instructions, to determine that the purchase order includes multiple entities, and to further determine whether multiple entities within a purchase order are allowed (i.e., whether procurement by a first legal entity on behalf of a second legal entity is allowed).

In one embodiment, the purchasing system can determine a value of multiple legal entities flag 510 of FIG. 5. If the value of multiple legal entities flag 510 is “Allow,” the purchasing system can submit the purchase order for approval. If the value of multiple legal entities flag 510 is “Warning,” the purchasing system can display a warning message within user interface 1700 (not shown in FIG. 17), and submit the purchase order for approval in response to a user confirmation (e.g., via a user interaction with a button, field, or other display element within user interface 1700). If the value of multiple legal entities flag 510 is “Error,” the purchasing system can generate an error message within user interface 1700 (not shown in FIG. 17), and the purchase order is not submitted for approval.

Thus, in an embodiment, a sold-to legal entity for a purchase order can be determined based on a legal entity that is associated with an inventory organization, where the inventory organization is associated with a deliver-to location, where the deliver-to location is associated with a purchase order line that is part of the purchase order. The sold-to legal entity for the purchase order can be determined, even if the purchase order includes other purchase lines with other legal entities. Thus, within a definition of a business unit, a central legal entity can be defined as a sold-to legal entity, where the central legal entity can procure items on behalf of other legal entities. Further, a supply chain financial orchestration flow is not required to generate the purchase order.

As previously described, procurement models 320 and 330 of FIG. 3 are similar in that one legal entity is procuring on behalf of another legal entity. One difference between the two procurement models is that, in procurement model 320, there is a need for supply chain financial orchestration; whereas, in procurement model 330, there is no need for supply chain financial orchestration. In procurement model 320, the two legal entities are in two different countries or regions, and thus, have two different general ledgers. Thus, the two legal entities require a supply chain financial orchestration flow. In procurement model 330, the two legal entities are in the same country or region, and thus, have the same general ledger. Thus, the two legal entities do not require a supply chain financial orchestration flow. According to an embodiment, a purchasing system can relax a requirement of setting up a supply chain financial orchestration flow. By relaxing this requirement, the purchasing system can also provide centralized billing functionality, where a set of one or more business units can require invoice processing services, and another business unit (i.e., a bill-to business unit) can provide the invoice processing services. In certain prior purchasing systems, in order for a business unit to provide invoice processing services for another business unit, the business unit had to setup a supply chain financial orchestration flow with the other business unit, consistent with procurement model 320 of FIG. 3. However, according to an embodiment, a purchasing system does not require a supply chain financial orchestration flow in order to provide centralized billing (i.e., to facilitate a business unit providing invoice processing services for another business unit), consistent with procurement model 330 of FIG. 3.

FIG. 18 illustrates an example of billing associated with a transaction according to a local-global hybrid procurement model, according to an embodiment of the invention. According to the embodiment, there can be multiple business units 1810 that procure items from a supplier 1820, and thus, generate purchase orders, or other financial documents. Supplier 1820 can generate supplier invoices, and can send the supplier invoices to a billing service provider 1830, where billing service provider 1830 is also known as a bill-to business unit. Billing service provider 1830 can provide centralized billing and can be responsible for individually charging business units 1810 for the corresponding charges on the supplier invoices. In other words, billing service provider 1830 can be defined as a centralized billing unit that can provide centralized billing on behalf of multiple business units 1830. According to an embodiment, business units 1810 and billing service provider 1830 are required to have the same general ledger. However, according to the embodiment, it is not required to setup supply chain financial orchestration flows between business units 1810 and billing service provider 1830, as it was required in certain prior purchasing systems.

FIG. 19 illustrates an example of requisitioning business units that are serviced by a common bill-to business unit that processes invoices for the requisitioning business units, according to an embodiment of the invention. FIG. 19 includes multiple business units 1910, where business units include requisitioning business units “BU1,” BU2,” and “BU3,” and also include bill-to and sold-to business unit “BU4.” FIG. 19 also includes purchase order 1920, where purchase order 1920 is generated by a prior purchasing system. The prior purchasing system would be required to setup a supply chain financial orchestration flow between requisitioning business unit “BU1” and bill-to and sold-to business unit “BU4,” in order to process purchase order 1920, as the two business units were different business units. FIG. 19 also includes purchase order 1930, where purchase order 1930 is generated by a purchasing system in accordance with an embodiment of the invention. According to the embodiment, the purchasing system can process purchase order 1930 without being required to setup a supply chain financial orchestration flow between requisitioning business unit “BU1” and bill-to and sold-to business unit “BU4,” as long as the primary ledger for the two business units is the same.

FIG. 20 illustrates another example of billing associated with a transaction according to a local-global hybrid procurement model, according to an embodiment of the invention. The transaction involves two requisitioning business units in Europe: requisitioning business unit 2010 (i.e., “Vision France”) and requisitioning business unit 2020 (i.e., “Vision Italy”). Although requisitioning business unit 2010 is in France, and requisitioning business unit 2020 is in Italy, both requisitioning business units are in countries that utilize the Euro, and thus utilize a same general ledger. Both requisitioning business units 2010 and 2020 can utilize bill-to business unit 2030 (“Vision Italy”) as a bill-to business unit that provides invoice processing services. In other words, bill-to business unit 2030 can provide invoice processing services on behalf of requisitioning business units 2010 and 2020. This can be done, even though there are no supply chain financial orchestration flows defined between requisitioning business units 2010 and 2020 and bill-to business unit 2030.

FIG. 21 illustrates a user interface 2100 of a purchasing system that is used to edit a purchase order, according to an embodiment of the invention. User interface 2100 displays a requisitioning business unit 2110. According to the embodiment, requisitioning business unit 2110 (i.e., “Vision France—Organization”) is a requisitioning business unit associated with the purchase order. User interface 2100 further displays a supplier site 2120. According to the embodiment, supplier site 2120 (i.e., “PARIS_HQ”) is a supplier site associated with the purchase order. User interface 2100 further displays a bill-to business unit 2130. According to the embodiment, bill-to business unit 2130 can be defaulted to a value of “Vision Italy” based on the value “Vision France-Organization” for requisitioning business unit 2110. The derivation of the value “Vision Italy” for bill-to business unit 2130 is further described below in greater detail in conjunction with FIG. 22.

FIG. 22 illustrates a user interface 2200 of a purchasing system that displays a bill-to business unit 2230 associated with a supplier site 2210, according to an embodiment of the invention. User interface 2200 displays supplier site 2210 (i.e., “PARIS_HQ”). User interface 2200 further displays that supplier site 2210 includes client business unit 2220 (i.e., “Vision France—Organization”), and bill-to business unit 2230 (i.e., “Vision Italy”).

FIG. 23 illustrates a user interface 2300 of a purchasing system that displays a bill-to business unit associated with a purchase order, according to an embodiment of the invention. User interface 2300 displays a requisitioning business unit 2310. According to the embodiment, requisitioning business unit 2310 (i.e., “Vision Italy”) is a requisitioning business unit associated with the purchase order. User interface 2300 further displays a supplier site 2320. According to the embodiment, supplier site 2320 (i.e., “MILANO ERS_HQ”) is a supplier site associated with the purchase order. User interface 2300 further displays a bill-to business unit 2330. According to the embodiment, bill-to business unit 2330 can be defaulted to a value of “Vision Italy” based on the value “Vision Italy” for requisitioning business unit 2310. The derivation of the value “Vision Italy” for bill-to business unit 2330 is further described below in greater detail in conjunction with FIG. 24.

FIG. 24 illustrates a user interface 2400 of a purchasing system that displays a bill-to business unit 2430 associated with a supplier site 2410, according to an embodiment of the invention. User interface 2400 displays supplier site 2410 (i.e., “MILANO ERS_HQ”). User interface 2400 further displays that supplier site 2410 includes client business unit 2420 (i.e., “Vision Italy”), and bill-to business 2430 (i.e., “Vision Italy”).

Thus, in accordance with an embodiment of the invention, a purchasing system allows a bill-to business unit to share billing functions with other business units within a single ledger. Further, the purchasing system can facilitate a bill-to business unit providing billing services on behalf of other business units without requiring that a supply chain financial orchestration flow be created between two business units. In other words, the purchasing system can defined a centralized billing unit as a bill-to business unit that can provide billing functions on behalf of other business units. This provides a more intuitive experience to a user, because, a user would not normally expect to be required to setup a supply chain financial orchestration flow between a bill-to business unit and another business unit, as a bill-to business unit is not a part of a financial transaction.

FIG. 25 illustrates a flow diagram of the functionality of a legal entity procurement module (such as legal entity procurement module 16 of FIG. 1), according to an embodiment of the invention. In one embodiment, the functionality of the flow diagram of FIG. 25 is implemented by software stored in memory or other computer-readable or tangible medium, and executed by a processor. In other embodiments, the functionality may be performed by hardware (e.g., through the use of an application specific integrated circuit (“ASIC”), a programmable gate array (“PGA”), a field programmable gate array (“FPGA”), etc.), or any combination of hardware and software. In certain embodiments, some, or all, of the functionality may be omitted.

The flow begins and proceeds to 2510. At 2510, a request to generate an electronic financial document is received, where the electronic financial document includes an electronic financial document line that includes a second legal entity. In certain embodiments, the electronic financial document can be a purchase order, and the electronic financial document line can be a purchase order line. Further, in some embodiments, the request to generate the electronic financial document can be automatically received using a computer system. The flow then proceeds to 2520.

At 2520, a sold-to legal entity is defined as a first legal entity. In certain embodiment, the sold-to legal entity can be defined by: receiving a request to override the defined sold-to legal entity with a replacement sold-to legal entity; determining whether a user associated with the request has an override privilege; and overriding the defined sold-to legal entity with the replacement sold-to legal entity when the user associated with the request has the override privilege. Further, in some embodiments, the sold-to legal entity can be automatically defined as the first legal entity using the computer system. Further, the definition of the sold-to legal entity as the first legal entity, as well as the subsequent flow, can be in response to a determination that a supply chain financial orchestration flow is not defined for the electronic financial document. The flow then proceeds to 2530.

At 2530, it is determined whether procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document. In certain embodiments, it can be determined whether procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document by determining a value of a multiple legal entities flag. Further, in some of these embodiments, the multiple legal entities flag can include one of: a value indicating that procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document; a value indicating that a warning message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document; or a value indicating that an error message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document. If it is determined that procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document, the flow proceeds to 2535. If it is determined that a warning message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document, the flow proceeds to 2540. If it is determined that an error message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document, the flow proceeds to 2545. In certain embodiments, it can be automatically determined whether procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document using the computer system.

At 2535, the electronic financial document, including the defined sold-to legal entity, and the electronic financial document line, is generated. In certain embodiments, the electronic financial document can be automatically generated using a computer system. The flow then proceeds to 2560.

At 2540, a warning message is displayed within a user interface. The flow then proceeds to 2550. At 2550, the electronic financial document, including the defined sold-to legal entity, and the electronic financial document line, is generated in response to a user confirmation. The flow then proceeds to 2560.

At 2545, an error message is displayed within a user interface. The flow then ends.

At 2560, a bill-to business unit is derived from a supplier site associated with the electronic financial document, where the electronic financial document includes a first business unit and a second business unit. Further, the generated electronic financial document can include the derived bill-to business unit. The flow then proceeds to 2570.

At 2570, the electronic financial document is stored on a computer system. The flow then proceeds to 2580.

At 2580, the electronic financial document is sent to an external computer system for approval. The flow then ends.

Thus, a purchasing system is provided that allows multiple legal entities on a financial document, such as a purchase order, and further facilitates procurement by a first legal entity on behalf of a second legal entity. The purchasing system can further allow a first billing unit to provide billing services on behalf of a second billing unit. The purchasing system provides significantly improved flexibility for procurement and billing. Further, the purchasing system does not require unnecessary setup records. Thus, the purchasing system can provide necessary choice to the customer without extensive setup steps. As a result, the purchasing system can enhance user productivity and user experience.

The features, structures, or characteristics of the invention described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, the usage of “one embodiment,” “some embodiments,” “certain embodiment,” “certain embodiments,” or other similar language, throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. Thus, appearances of the phrases “one embodiment,” “some embodiments,” “a certain embodiment,” “certain embodiments,” or other similar language, throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.

Claims

1. A computer-readable medium having instructions stored thereon that, when executed by a processor, cause the processor to facilitate procurement by a first legal entity on behalf of a second legal entity, the facilitating comprising:

receiving a request to generate an electronic financial document comprising an electronic financial document line that comprises the second legal entity;

defining a sold-to legal entity as the first legal entity in response to a determination that a supply chain financial orchestration flow is not defined for the electronic financial document;

determining whether procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document; and

generating the electronic financial document comprising the defined sold-to legal entity, and the electronic financial document line when it is determined that procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document.

2. The computer-readable medium of claim 1, the facilitating further comprising:

displaying a warning message within a user interface when it is determined that a warning message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document; and

generating the electronic financial document comprising the defined sold-to legal entity, and the electronic financial document line in response to a user confirmation when it is determined that a warning message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document.

3. The computer-readable medium of claim 1, the facilitating further comprising:

displaying an error message within a user interface when it is determined that an error message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document.

4. The computer-readable medium of claim 1,

wherein the determining whether procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document comprises determining a value of a multiple legal entities flag; and

wherein the multiple legal entities flag comprises one of: a value indicating that procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document; a value indicating that a warning message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document; or a value indicating that an error message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document.

5. The computer-readable medium of claim 1, the facilitating further comprising:

deriving a bill-to business unit from a supplier site associated with the electronic financial document, wherein the electronic financial document comprises a first business unit and a second business unit;

wherein the generated electronic financial document further comprises the derived bill-to business unit.

6. The computer-readable medium of claim 1, wherein the defining the sold-to legal entity further comprises:

receiving a request to override the defined sold-to legal entity with a replacement sold-to legal entity;

determining whether a user associated with the request has an override privilege; and

overriding the defined sold-to legal entity with the replacement sold-to legal entity when the user associated with the request has the override privilege.

7. The computer-readable medium of claim 1, further comprising storing the electronic financial document on a computer system.

8. The computer-readable medium of claim 7, further comprising sending the electronic financial document to an external computer system for approval.

9. The computer-readable medium of claim 1,

wherein the electronic financial document comprises an electronic purchase order;

wherein the electronic financial document line comprises an electronic purchase order line.

10. The computer-readable medium of claim 1,

wherein the receiving the request to generate the electronic financial document further comprises automatically receiving the request to generate the electronic financial document using a computer system;

wherein the defining the sold-to legal entity as the first legal entity further comprises automatically defining the sold-to legal entity as the first legal entity using the computer system;

wherein the determining whether procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document further comprises automatically determining whether procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document using the computer system; and

wherein the generating the electronic financial document further comprises automatically generating the electronic financial document using the computer system.

11. A computer-implemented method for facilitating procurement by a first legal entity on behalf of a second legal entity, the computer-implemented method comprising:

receiving a request to generate an electronic financial document comprising an electronic financial document line that comprises the second legal entity;

defining a sold-to legal entity as the first legal entity in response to a determination that a supply chain financial orchestration flow is not defined for the electronic financial document;

determining whether procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document; and

generating the electronic financial document comprising the defined sold-to legal entity, and the electronic financial document line when it is determined that procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document.

12. The computer-implemented method of claim 11, further comprising:

displaying a warning message within a user interface when it is determined that a warning message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document; and

generating the electronic financial document comprising the defined sold-to legal entity, and the electronic financial document line in response to a user confirmation when it is determined that a warning message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document.

13. The computer-implemented method of claim 11, further comprising:

displaying an error message within a user interface when it is determined that an error message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document.

14. The computer-implemented method of claim 11,

wherein the determining whether procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document comprises determining a value of a multiple legal entities flag; and

wherein the multiple legal entities flag comprises one of: a value indicating that procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document; a value indicating that a warning message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document; or a value indicating that an error message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document.

15. The computer-implemented method of claim 11, further comprising:

deriving a bill-to business unit from a supplier site associated with the electronic financial document, wherein the electronic financial document comprises a first business unit and a second business unit;

wherein the generated electronic financial document further comprises the derived bill-to business unit.

16. A system for facilitating procurement by a first legal entity on behalf of a second legal entity, the system comprising:

a request receiving module configured to receive a request to generate an electronic financial document comprising an electronic financial document line that comprises the second legal entity;

a legal entity definition module configured to define a sold-to legal entity as the first legal entity in response to a determination that a supply chain financial orchestration flow is not defined for the electronic financial document;

a multiple legal entity determination module configured to determine whether procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document; and

an electronic document generation module configured to generate the electronic financial document comprising the defined sold-to legal entity, and the electronic financial document line when it is determined that procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document.

17. The system of claim 16, further comprising:

a display module configured to display a warning message within a user interface when it is determined that a warning message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document;

wherein the electronic document generation module is further configured to generate the electronic financial document comprising the defined sold-to legal entity, and the electronic financial document line in response to a user confirmation when it is determined that a warning message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document.

18. The system of claim 16, further comprising:

a display module configured to display an error message within a user interface when it is determined that an error message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document.

19. The system of claim 16,

wherein the multiple legal entity determination module is further configured to determine a value of a multiple legal entities flag; and

wherein the multiple legal entities flag comprises one of: a value indicating that procurement by the first legal entity on behalf of the second legal entity is allowed for the electronic financial document; a value indicating that a warning message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document; or a value indicating that an error message should be displayed when the first legal entity is defined as procuring one or more items on behalf of the second legal entity within the electronic financial document.

20. The system of claim 16, further comprising:

a business unit derivation module configured to derive a bill-to business unit from a supplier site associated with the electronic financial document, wherein the electronic financial document comprises a first business unit and a second business unit;

wherein the generated electronic financial document further comprises the derived bill-to business unit.