One embodiment is directed to a computer system, and more particularly, to a computer system that automatically generates financial documents, such as purchase orders.
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.
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.
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.
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.
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.
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.
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.
In one embodiment, the purchasing system can determine a value of multiple legal entities flag 510 of
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
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.
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.
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.
Number | Date | Country | |
---|---|---|---|
62024858 | Jul 2014 | US |