Supply chain management system and method

Abstract

Instantiating a transaction ledger block chain supporting a plurality of entities of the supply chain processing system; in response to a change in a ledger block, an existing inventory for a given item identifier is determined based on a reported sales history and an inventory block that includes inventory metadata that describes a temporal snapshot of the existing inventory. A unit and cost allocation for the existing inventory is determined, and a true acquisition cost for the given item identifier is determined. A special price agreement (SPA) cost is determined based on an SPA block containing terms of the SPA, and a rebate amount corresponding to the given item identifier is calculated based on the SPA cost and the true fetch cost. A total rebate is determined, another inventory block is generated based on the revised inventory, and a rebate blockchain is updated based on the determined total rebate.

Description

Background Art

[0001] The present invention relates to the electrical, electronic and computer fields, and more particularly to computerized supply chain management systems and methods and blockchain technology.

[0002] Special Price Agreements (SPAs) (referred to herein as SPAs and agreements; also referred to in the art as rebate contracts, customer price agreements, distributor price agreements, and ship and debits) enable manufacturers / suppliers, distributors, contractors, end customers, and the like to negotiate special pricing and / or terms among supply chain participants. SPAs can take a variety of styles / forms. Generally speaking, each SPA contains three main components: to whom the SPA is offered, what is included in the SPA, and the price and / or terms (and corresponding qualification period). SPAs typically define the cost that a distributor pays for an item from a manufacturer, referred to as the SPA cost or rebate cost, and are based on the negotiated cost that the manufacturer is willing to provide the item to a given distributor.

[0003] For example, who is provided with a SPA is based on the identity of the distributor (including whether the SPA covers all distributor branches, all locations, all end customers of the distributor, and the like), the identity of the distributor branches (and their corresponding end customers), the type of the distributor's end customers (e.g., residential contractors, individuals, and the like), the identity of the end customers (including their delivery locations), the locations of the end customers, and the like. In some cases, in order to save time and administrative effort, manufacturers assign multiple distributor branches and end customers to the same SPA.

[0004] Manufacturers can potentially extend special pricing to some or all of the stock keeping units (SKUs) in their product portfolio. SPAs may apply to the entire catalog (most general), a portion of a manufacturer's product line / group (e.g., a SKU group; less general), or a specific SKU (most specific). In addition, SPAs may follow a point-in-time SKU consistency policy or a current SKU consistency policy. A point-in-time SKU consistency policy means using the terms of the SPA that was effective on (e.g.,) the date of the sales order to the end customer to determine whether the SPA costs apply. A current SKU consistency policy means using the criteria (e.g., the current consistency of the SKU) of the day (e.g., the date of the sales order to the end customer) of the SPA. Pricing multipliers (e.g., a multiplier of 0.78) can be based on list prices (e.g., a standard price quoted by a manufacturer / supplier) or on distributors' warehousing costs (the cost paid by the distributor to get the item into the distributor's inventory, e.g., $0.10). Net prices (e.g., $10.50) can be used for certain SKUs. The price of the item is usually the primary focus, but other terms, such as payment terms (net 30 (N30), net 60 (N60), and the like) may be equally important. In addition, distributors and the like may be eligible for total rebates, such as volume-based rebates aggregated across SPAs, across both SPA and non-SPA transactions, and the like. (As used herein, a rebate is, for example, a partial refund of the cost of an item, such as the difference between the warehousing cost (or true acquisition cost as described more fully below) and the SPA cost).

[0005] In an example case, a distributor negotiates a "cost" (SPA or rebate cost) with, for example, a manufacturer during the SPA initiation or revision process. For example, assume that a distributor currently purchases an item with a given SKU for $10; that is, the "inbound cost" of the distributor's inventory is $10. The distributor encounters an opportunity to sell 1 million (1M) units at $8 (end customer price). The distributor may submit a request to the manufacturer for a better cost to serve the opportunity. The manufacturer may respond by, for example, offering a SPA or rebate cost of $7.50. In this example, the distributor obtains a gross profit of $0.50 / unit ($8 (end customer price) minus $7.50 (new SPA cost)). The distributor will request a rebate of $2.50 per unit ($10 (inbound cost) minus $7.50 (SPA or rebate cost) = $2.50 / unit). Summary of the invention

[0006] The principles of the present invention provide techniques for supply chain management. In one aspect, an exemplary method for processing rebates on a supply chain processing system based on a blockchain architecture includes the following operations: instantiating an inventory blockchain supporting multiple entities of the supply chain processing system; in response to a change in a ledger block of a transaction ledger blockchain, determining an existing inventory of a given item identifier based on a reported sales history and an inventory block, the inventory block including inventory metadata describing a time snapshot of the existing inventory; using the inventory metadata to determine a unit and cost allocation for the existing inventory; determining a true acquisition cost for the given item identifier based on the inventory metadata and the determined allocation of the inventory block; determining a special price agreement cost based on a special price agreement block, the special price agreement block including terms of a special price agreement; calculating a rebate amount corresponding to the given item identifier based on the special price agreement cost and the true acquisition cost; determining a total rebate based on the rebate amount and sales quantity corresponding to the given item identifier; generating another inventory block based on the revised inventory; and updating the rebate blockchain based on the determined total rebate.

[0007] In one aspect, an exemplary method includes the following operations: instantiating one or more transaction ledger blockchains supporting multiple entities; accessing an enterprise system of one of the multiple entities to retrieve special price agreement participant data designated for blockchain input; verifying the accessed data designated for the blockchain input; identifying a transaction ledger blockchain among the one or more transaction ledger blockchains for inputting the verified data; preprocessing the verified data, the preprocessing including formatting the verified data for input into a ledger block of the identified transaction ledger blockchain having a timestamp corresponding to the accessed data; and populating the preprocessed data into the ledger block of the identified transaction ledger blockchain.

[0008] In one aspect, a non-transitory computer-readable medium includes computer-executable instructions that, when executed by a computer, cause the computer to perform a method for processing rebates on a supply chain processing system based on a blockchain architecture, the method comprising the following operations: instantiating an inventory blockchain for multiple entities supporting the supply chain processing system; determining, in response to a change in a ledger block of a transaction ledger blockchain, an existing inventory for a given item identifier based on a reported sales history and an inventory block, the inventory block including inventory metadata describing a time snapshot of the existing inventory; determining units and cost allocations for the existing inventory using the inventory metadata; determining a true acquisition cost for the given item identifier based on the inventory metadata and the determined allocations of the inventory block; determining a special price agreement cost based on a special price agreement block, the special price agreement block including terms of a special price agreement; calculating a rebate amount corresponding to the given item identifier based on the special price agreement cost and the true acquisition cost; determining a total rebate based on the rebate amount and sales quantity corresponding to the given item identifier; generating another inventory block based on the revised inventory; and updating the rebate blockchain based on the determined total rebate.

[0009] In one aspect, a non-transitory computer-readable medium includes computer-executable instructions that, when executed by a computer, cause the computer to perform the following method: instantiating one or more transaction ledger blockchains supporting multiple entities; accessing an enterprise system of one of the multiple entities to retrieve special price agreement participant data designated for blockchain input; verifying the accessed data designated for the blockchain input; identifying a transaction ledger blockchain among the one or more transaction ledger blockchains for inputting the verified data; pre-processing the verified data, the pre-processing including formatting the verified data for input into a ledger block of the identified transaction ledger blockchain having a timestamp corresponding to the accessed data; and populating the pre-processed data into the ledger block of the identified transaction ledger blockchain.

[0010] In one aspect, a device includes a memory and at least one processor coupled to the memory, and is operable to perform a method for processing rebates on a supply chain processing system based on a blockchain architecture, the method comprising the following operations: instantiating an inventory blockchain for multiple entities supporting the supply chain processing system; in response to changes in a ledger block of a transaction ledger blockchain, determining an existing inventory for a given item identifier based on reported sales history and an inventory block, the inventory block including inventory metadata describing a time snapshot of the existing inventory; using the inventory metadata to determine a unit and cost allocation for the existing inventory; determining a true acquisition cost for the given item identifier based on the inventory metadata and the determined allocation of the inventory block; determining a special price agreement cost based on a special price agreement block, the special price agreement block including terms of a special price agreement; calculating a rebate amount corresponding to the given item identifier based on the special price agreement cost and the true acquisition cost; determining a total rebate based on the rebate amount and sales quantity corresponding to the given item identifier; generating another inventory block based on the revised inventory; and updating the rebate blockchain based on the determined total rebate.

[0011] In one aspect, an apparatus includes a memory and at least one processor coupled to the memory and operable to perform operations including: instantiating one or more transaction ledger blockchains supporting multiple entities; accessing an enterprise system of one of the multiple entities to retrieve special price agreement participant data designated for blockchain input; verifying the accessed data designated for the blockchain input; identifying a transaction ledger blockchain among the one or more transaction ledger blockchains for inputting the verified data; preprocessing the verified data, the preprocessing including formatting the verified data for input into a ledger block of the identified transaction ledger blockchain having a timestamp corresponding to the accessed data; and populating the preprocessed data into the ledger block of the identified transaction ledger blockchain.

[0012] As used herein, "facilitating" an action includes performing the action, making the action easier, assisting in performing the action, or causing the action to be performed. Thus, by way of example and not limitation, instructions executing on one processor may facilitate an action performed by instructions executing on a remote processor by sending appropriate data or commands to cause the action to be performed or to assist in performing the action. For the avoidance of doubt, where an actor facilitates an action by means other than performing the action, the action is still performed by some entity or combination of entities.

[0013] One or more embodiments of the present invention or its elements may be implemented in the form of a computer program product, which includes a computer-readable storage medium (a non-transitory computer-readable medium including computer-executable instructions) having a computer-usable program code for performing the indicated method steps, and the computer-executable instructions, when executed by a computer, cause the computer to perform the disclosed method steps. In addition, one or more embodiments of the present invention or its elements may be implemented in the form of a system (or device) including a memory and at least one processor, the at least one processor being coupled to the memory and operable to perform the exemplary method steps. In addition, in another aspect, one or more embodiments of the present invention or its elements may be implemented in the form of a component for performing one or more method steps described herein; the component may include (i) a hardware module, (ii) a software module stored in a computer-readable storage medium (or multiple such media) and implemented on a hardware processor, or (iii) a combination of (i) and (ii); any of (i) to (iii) implements the specific techniques described herein.

[0014] The technology of the present invention can provide substantial beneficial technical effects. For example, one or more embodiments provide one or more of the following:

[0015] Less computing resources are used to process SPAs;

[0016] Fewer computing resources are used for record keeping;

[0017] Increased security for sensitive information;

[0018] A blockchain architecture for supply chain management that enables a shared integrated supply chain processing platform and connects multiple entities involved in the supply chain while providing data privacy and security;

[0019] Supply chain inventory allocation and costing system for monitoring inventory and generating and / or verifying rebate claims using a blockchain architecture, including allocating inventory to appropriate costing batches (bins);

[0020] Use blockchain architecture to effectively determine the true acquisition cost of inventory;

[0021] Verify transaction data with SPA number on the transaction line;

[0022] Prevent rewriting or changing transaction history;

[0023] The ability to incorporate traditional SPA into blockchain supply chain management systems;

[0024] Reduced administrative and processing costs;

[0025] Reduced financial losses due to miscalculation of rebates by manufacturers, distributors, and the like;

[0026] Eliminate the confusion typically encountered when dealing with SPAs and rebates;

[0027] Increased sales due to performance management of existing SPAs;

[0028] expanding sales into other complementary product lines;

[0029] Improvement of SPA profitability and pricing strategy management; and

[0030] Improved SPA client engagement in planning, forecasting, marketing and incentives.

[0031] These and other features and advantages of the present invention will be apparent from the following detailed description of illustrative embodiments thereof, which should be read in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] 1A and 1B illustrate an example conventional SPA according to the prior art;

[0033] FIG. 2A illustrates an example of the relationship between participants in a supply chain according to the prior art;

[0034] Figure 2B illustrates some examples of communications between participants in a supply chain according to example embodiments;

[0035] Figure 3 is a high-level system diagram of a first example embodiment of a supply chain management system according to an example embodiment;

[0036] FIG4A is an overview of an example SPA according to the prior art;

[0037] Figure 4B Describing details of rebate requirements associated with an example SPA according to an example embodiment;

[0038] Figure 4C is a visual representation of the state of a SPA according to an example embodiment;

[0039] Figure 5A is a high-level system diagram of a first example embodiment of a blockchain version of a supply chain management system according to an example embodiment;

[0040] Figure 5B Describe the relationships of entities in a supply chain in an example blockchain embodiment of a supply chain processing platform according to an example embodiment;

[0041] Figure 5C is a swim lane diagram of an example supply chain case according to an example embodiment;

[0042] Fig. 6Ais a flow chart of an example method for initiating a special pricing agreement according to an example embodiment;

[0043] Figure 6B is a flow chart of an example method for populating a manufacturer ledger block of a blockchain according to an example embodiment;

[0044] Figure 7 is a flow chart of an example method for populating a distributor ledger block of a blockchain according to an example embodiment;

[0045] Figure 8 is a flow chart of an example method for preprocessing blockchain data of manufacturers / suppliers and blockchain data of distributors according to an example embodiment;

[0046] Fig. 9 is a flow chart of an example method for processing rebate claims using an inventory allocation and cost system of a blockchain embodiment of a supply chain processing platform according to an example embodiment;

[0047] Fig.10 is a flow chart of an example method for registering a participant with a blockchain embodiment of a supply chain processing platform according to an example embodiment; and

[0048] Fig.11 Depicting a computer system that may be used to implement one or more aspects and / or elements of the present invention also represents a cloud computing node according to an embodiment of the present invention. DETAILED DESCRIPTION

[0049] 1A and 1B illustrate an example conventional SPA 100 according to the prior art. The example SPA 100 includes an SPA identifier 104, a project / job / location identifier 108, relevant SPA dates 112 (e.g., effective time period), and business details 116 of the SPA 100. An authorized customer account section 120 identifies, for example, which branches of an entity are eligible for the terms of the SPA 100 and the time period for which the eligibility applies. An authorized end user section 124 identifies, for example, which end users are eligible for the terms of the SPA 100 and the time period for which the eligibility applies.

[0050] Section 128 of SPA 100 identifies groups of products (also referred to as product lines, product groups, product segments, and the like) identified by the manufacturer as having special prices during a specific time period. Section 132 of SPA 100 identifies special pricing arrangements for individual SKUs, such as identified by Universal Product Codes (UPCs).

[0051] FIG. 2A illustrates an example of a relationship 200 between participants in a supply chain according to the prior art. In one example embodiment, a distributor 212 negotiates prices and / or terms with a manufacturer / supplier 208 to develop a SPA. A group purchasing organization (GPO) 204 may also negotiate prices and / or terms with the manufacturer / supplier 208 on behalf of the distributor 212, end customers 216, and the like. (It should be noted that a GPO 204 may include a group of distributors 212, contractors 220, and the like that participate in the group purchasing organization's projects.) The distributor 212 then purchases the items from the manufacturer / supplier 208 and ships them to the end customer 216 based on the GPO-negotiated SPA or the distributor-negotiated SPA, as appropriate.

[0052] A distributor 212 or GPO 204 may request a rebate from a manufacturer / supplier 208 based on a SPA. For example, consider a distributor 212 with an incoming inventory cost of $20 and an agreed upon SPA or rebate cost of $15 for an item sold to a qualified customer under the terms of a SPA; the distributor 212 will request a settlement payment of $5 as a rebate (determined by the difference between the $20 incoming inventory cost and the agreed upon SPA or rebate cost of $15). The request must be checked against the SPA date, SKU number, product group, end customer 216, and the like of the SPA to ensure that the request is valid. It should be noted that the components of a SPA (e.g., who is on the SPA, what is in the SPA, the addition of new products / groups, expiration dates, pricing multipliers, and the like) may also change over time, thereby complicating the rebate process. It should also be noted that a group purchasing organization (GPO) 204 will typically provide loyalty rewards / volume rebates to end customers 216 based on, for example, the annual purchase volume (if any) received from the manufacturer / supplier 208.

[0053] The extended sales organization and representative (rep) organization of the manufacturer / supplier 208, such as a contract sales team, handles smaller end customers 216. The rep organization facilitates the regular process between smaller customers such as distributors 212 and end customers 216, and closes sales with smaller end customers 216. In addition, contractors 220 purchase items from distributors for and / or on behalf of end customers 216.

[0054] In conventional processes, distributors 212 typically request SPAs for one or more of their end customers 216 and for certain SKUs, product groups, and the like. This is conventionally performed, for example, by the distributor 212 sending the request using a spreadsheet via email. The manufacturer / supplier 208 reviews and approves the SPA request, denies the SPA request, or requests more information from the distributor 212. If approved, the manufacturer / supplier 208 enters the SPA into its system and generates a SPA identification number (e.g., A12345, or any other alphabetic, numeric, and / or alphanumeric nomenclature) that serves as a reference number during the claim process (described more fully below).

[0055] It should be noted that larger manufacturers / suppliers 208 typically have their own internal systems, data structures, different communication methods, and the like, which distributors 212 must adapt to in order to request SPAs and submit rebate claims with the necessary documentation; each manufacturer platform may comply with different standards and documentation specifications, making the process complicated for distributors 212. Therefore, distributors 212 typically use multiple platforms to request SPAs from multiple manufacturers / suppliers 208 and submit their rebate claims. Distributors 212 typically submit their rebate claims with supporting information / documents (e.g., item identifiers, item quantities, end customer 216 identifiers, and the like), such as on a monthly, real-time (e.g., via electronic data interchange), and the like. Manufacturers / suppliers 208 review the claims and approve the claims in whole or in part, deny the claims, or request more information. During this process, manufacturers / suppliers 208 perform checks to determine if the claims are valid. Example checks include, but are not limited to, transaction date, whether a particular distributor 212 (or branch of distributor 212) and / or end customer 216 is eligible for a SPA, whether a particular SKU / product group is eligible, calculated cost (using historical list prices, current list prices, and the like), whether the product is aligned with the correct product group, whether the distributor's submitted SPA or rebate cost matches the cost calculated using the manufacturer's system, and the like. Deficiencies in conventional processes include the inability to determine the true acquisition cost of an item (e.g., the distributor's 212 item cost based on a first-in, first-out (FIFO) method of the distributor's inventory); lack of audit trails; time-consuming, resource (manpower) intensive dispute resolution; inability to verify that a designated end customer 216 is the true recipient of the item; and the like.

[0056] Figure 2BAn example of some communications between participants of a supply chain according to an example embodiment is described. Manufacturers / suppliers 208 communicate with distributors 212, and end customers 216 communicate with distributors 212 and manufacturers / suppliers 208 using various modalities, resulting in a chaotic supply chain management environment. For example, a GPO / representative agency 204 in the real world (as seen in FIG. 2A ) interacts with multiple manufacturers / suppliers 208, distributors 212, and end customers 216. Distributors 212 in the real world interact with multiple manufacturers / suppliers 208, GPOs 204, and end customers 216. Distributors 212 may reach an agreement with manufacturers / suppliers 208 based on the inbound cost (defined as the cost of initially acquiring an item, such as based on an assigned multiplier multiplied by the list price) or other parameters. (Alternatively, the SPA cost or rebate cost is the price of the item specified by the SPA, and is determined, for example, by multiplying the assigned multiplier by the list price, by determining a negotiated price, and the like.) End customers 216 may reach an agreement with manufacturers / suppliers 208 and distributors 212. It should be noted that the manufacturer / supplier 208 may assign the distributor 212 to a particular SPA, and the distributor 212 may also enter into a SPA with the manufacturer / supplier 208 on behalf of one or more end customers 216. Sometimes, the distributor 212 and the manufacturer / supplier 208 pay backend rebates to the end customers 216. As a result, conventional relationships between supply chain entities often prove difficult to manage and are resource intensive. For example, human intervention in many supply chain tasks consumes not only manpower, but also computer resources, such as computing power used to execute numerous user interfaces dedicated to interfacing with individuals for human resource management of the supply chain.

[0057] Figure 3is a high-level system diagram of a first example embodiment of a supply chain management system according to an example embodiment. The example embodiment provides three main functional areas: acquisition and renegotiation; administration (management control); and real-time reporting (performance management). Rebate requests from distributors 212 are processed by manufacturers / suppliers 208 via supply chain processing platform 304. Supply chain processing (SCP) platform 304 provides various services, such as aggregation, automation, analysis, enhancement, distribution with permission, and the like. Supply chain processing platform 304 utilizes, for example, sales orders provided by manufacturers / suppliers 208 and transaction history of distributors 212 to process rebate requests. The true acquisition cost of each item sold is calculated by the inventory allocation and cost system of supply chain processing platform 304 by determining the inbound cost of each item in the distributor's inventory being sold, and calculating the average cost of the item based on the FIFO method and weighted by the number of items at the corresponding inbound cost. For example, if 100 items are sold and 10 of them are acquired at an entry cost of $1.00 and 90 of them are acquired at an entry cost of $1.10, then the true acquisition cost is $1.09 ((10*$1.00+90*$1.10) / 100=$1.09). Sales are also analyzed to determine which transactions qualify for SPA pricing and terms and which transactions do not qualify. It should be noted that distributors 212 and manufacturers / suppliers 208 may utilize different enterprise resource planning (ERP) systems, data structures, communication protocols, and the like, creating a complex heterogeneous environment that has traditionally proven difficult to manage and lacks technical solutions to provide entities with rapid access to management data that is secure and trusted by participants in the supply chain for management purposes.

[0058] The manufacturer / supplier 208 logs all qualified distributors 212 onto the supply chain processing platform 304 (including, for example, registering and authenticating each distributor 212, collecting distributor information, configuring the supply chain processing platform 304 for access by registered distributors 212, and the like), and provides training on how to use the rebate system, such as the process of receiving and approving SPA requests from distributors 212, the process of submitting rebate requests and verification requests from distributors 212, the process of submitting required information, the process of dispute resolution, and the like. In an example embodiment, the basic data requirements of the supply chain processing platform 304 for the manufacturer / supplier 208 include:

[0059] SKU Master with product groupings (product hierarchy), including SKU attribute change log (captures SKU additions / deletions and describes the SKU hierarchy at a given point in time) and historical list price change log (used to calculate list prices at a given point in time);

[0060] The major version of the SPA (including the SPA property change log);

[0061] Distributor sales order (describing the product, quantity, price to be paid and similar);

[0062] Pre-processing logic (generic pre-processing rules and / or logic specific to distributor 212);

[0063] Manufacturer / supplier part number and distributor part number cross-reference database;

[0064] A cross-reference database of distributor numbers and manufacturer's distributor account numbers, including a cross-reference database of distributor position numbers and manufacturer's distributor position account numbers.

[0065] In one example embodiment, the basic data requirements of the supply chain processing platform 304 for the distributor 212 include:

[0066] rebate claim, including the end customer 216's identification, distributor number, distributor branch number, manufacturer / supplier catalog number, universal product code (UPC), order number, order line number, order date, invoice number, invoice line number, invoice date, quantity, standard / inbound cost, rebate cost, SPA reference number, and rebate claim amount (per unit and / or total claim amount);

[0067] Complete sales history for all manufacturer SKUs (to support inventory allocation and cost systems) (product movements between the distributor’s distribution centers (DCs) / branches may be included in this file or may be provided as a separate file); and

[0068] The on-hand inventory balance of each item at different locations.

[0069] Conventional methods for exchanging such information include email (eg, using spreadsheet attachments), electronic data interchange (EDI), flat files (which may require pre-processing), and the like.

[0070] Supply Chain Processing Platform Process

[0071] SPA Initiation

[0072] Once the supply chain processing platform 304 is configured, users (e.g., all authorized users logged into the distributor) can interact with the supply chain processing platform 304 to initiate SPA requests. The supply chain processing platform 304 pre-checks whether the requester has submitted all required / mandatory information (the system checks whether all mandatory fields have been completed and performs basic data validation checks, such as confirming that the product / customer location is configured in the system). After performing data validation checks based on specific rules, logic, and the like, the supply chain processing platform 304 notifies the manufacturer / supplier 208 of the request and, if any, provides an overview of the items that did not pass the relevant business rules (it should be noted that the manufacturer / supplier 208 can configure its business rules and various display items on the supply chain processing platform 304). In one example embodiment, the checks and data validation rules include, for example, whether there is an existing SPA for the identified combination of end customer 216 and SKU (overlapping SPA); whether the end customer 216 purchases products from the same manufacturer from other distributors 212 (to identify price / channel conflicts and the like); whether the manufacturer / supplier 208 (and potentially the distributor 212) rejects any previous agreement; whether the manufacturer / supplier 208 (and potentially the distributor 212) has any historical SPA; suggested pricing from the manufacturer / supplier's pricing engine; and the like.

[0073] The manufacturer / supplier 208 then approves the request, denies the request, or requests additional information, for example, via a portal of the supply chain processing platform 304. If approved, the supply chain processing platform 304 sends a message to the manufacturer / supplier's 208 ERP platform or other SPA management platform to create the SPA (with a SPA reference number) and assign the SPA reference number on the agreement (creating a system of record). (Note that subsequent changes to the SPA, related metadata (e.g., when and where the SPA was created), and the like are also recorded.)

[0074] If additional information is requested, the distributor 212 submits the requested information and / or additional attachments. If the request is for modification of an existing or expired SPA, information regarding the SPA is submitted by the distributor 212. The manufacturer / supplier 208 then reviews the provided information / attachments and approves the request, denies the request, or requests additional information, if necessary. If denied, the manufacturer / supplier 208 provides a reason code, description, and the like to the distributor 212 (or GPO 204) and records it in the supply chain processing platform 304. (It should be noted that in some cases, an automated electronic signature mechanism (e.g., Products (a registered trademark of DocuSign, Inc., San Francisco, California, USA)) to perform SPA.

[0075] In some cases, a distributor 212 may request that a manufacturer / supplier 208 add additional end customers 216, SKUs, product groups, and the like to an existing agreement and / or request price modifications to an existing agreement. Likewise, a manufacturer / supplier 208 may manage its price list prices and / or SKU additions and deletions on the same agreement (as opposed to creating a new agreement). These are also logged to the SPA's change log, with identification of the changed attributes, including the new value, source of the change, timestamp of the change, IP address of the session, and the like.

[0076] After establishing the SPA and selling the purchased items to the corresponding end customers 216, the distributor 212 periodically (e.g., daily, weekly, monthly, and the like) submits its requirements, the sales history of each of the SKUs of the relevant manufacturer, and the existing inventory. For example, the existing inventory is used by the inventory allocation and cost system to allocate the inventory obtained by the distributor 212. As described above, rebates are considered more accurate when they are based on the true acquisition cost of the specific items sold, which generally depends on the time when the items sold were purchased, rather than the replacement cost. In some cases, the distributor 212 also provides its existing inventory instead of or in combination with the complete sales history. The supply chain processing platform 304 then combines the data of the manufacturer / supplier 208 with the data provided by the distributor 212, and performs any, some, or all of the following actions in the indicated order or in an alternate order:

[0077] Determine whether the Agreement is in effect as of the Order Date;

[0078] Determining whether the end customer 216 and / or the distributor 212's branch is listed on the SPA on a given order date;

[0079] Determine if the SKU is covered by the SPA on the order date (if a product group is provided, the corresponding SKU or SKUs can be obtained and verified);

[0080] Determine the agreed multiplier or net price for the SKU;

[0081] determine the list price as of the date of your order; and

[0082] The distributor's 212 inbound costs and / or actual acquisition costs as of the order date are determined.

[0083] It should be noted that the manufacturer / supplier part number and distributor part number cross-reference database may be used to determine and / or confirm the part number for a particular item since, as mentioned above, different manufacturers / suppliers 208 and distributors 212 often use different part numbers for the same item.

[0084] Inventory Allocation and Cost System Process

[0085] The inventory allocation and cost system in the supply chain processing platform 304 tracks the existing inventory of the distributor 212, for example, of a given SKU and performs calculations related thereto. As described above, the distributor 212 periodically acquires inventory of a given SKU at different entry costs. Thus, the oldest batch of inventory of a given SKU (also referred to herein as a box) may have been acquired at a first entry cost (e.g., $10), the newer batch of inventory of a given SKU may have been acquired at a second entry cost (e.g., $10.25), and the latest batch of inventory of a given SKU may have been acquired at a third entry cost (e.g., $10.50). When inventory is sold, for example, to an end customer 216, the oldest inventory is sold first because the inventory is maintained on a first-in, first-out (FIFO) basis. Since the rebate is based on the difference between the entry cost of the sold item and the SPA or the rebate cost (SPA or rebate cost) specified for the item in the SPA, the supply chain processing platform 304 tracks inventory to utilize the appropriate entry cost of the item when each item is sold. (In one or more embodiments, the inventory allocation and cost system is implemented by using a high-level programming language to Figures 6B to 9 The logic in the flowchart of the present invention is programmed and compiled or interpreted into computer executable code, and then the code is executed on one or more computer processors to implement.

[0086] In one example embodiment, the processing by the supply chain processing platform 304 includes identifying the branches and locations of the branches of the distributor 212 based on the sales history provided by the distributor 212. The calculated data including the existing inventory and cost history is merged with the purchase order of the manufacturer / supplier 208 and the sales order to the distributor 212 to allocate the inventory based on the first-in, first-out (FIFO) method. If a deviation is detected (e.g., a mismatch between the expected inventory and the existing inventory), the deviation is reported via the supply chain processing platform 304. If the detected deviation requires the suspension of the inventory allocation and cost process, the process ends and is reported via the supply chain processing platform 304; otherwise, the true acquisition cost of the relevant inventory is determined (e.g., the relevant multiplier is applied to the list price at the time of acquisition to derive the true acquisition cost of the distributor 212, as determined based on the cost history and SPA). The rebate amount per unit (inbound cost minus SPA or rebate cost) is calculated and matched to the requirements of the distributor 212. This is then extended to the quantity sold. Any difference between the requirements and the calculated rebate is reported, including the display of the calculation steps. In one example embodiment, reports are provided to manufacturers / suppliers 208 and distributors 212 .

[0087] Process without inventory allocation and cost system

[0088] In the event that the inventory allocation and cost system is not available or otherwise used to determine the true acquisition cost of the unit, the rebate amount per unit (current incoming cost minus SPA or rebate cost) is calculated and matched to the requirements of the distributor 212. (Note that the current incoming cost is also referred to as replacement cost and day's cost.) This is then extended to the quantity sold. Any difference between the requirements and the calculated rebate is reported, including a display of the calculation steps. In one example embodiment, the report is provided to the manufacturer / supplier 208 and the distributor 212.

[0089] Dispute Resolution

[0090] The supply chain processing platform 304 provides the ability to resolve disputes in the rebate approval process by raising a work order for the rebate request and notifying the supply chain participants involved (e.g., manufacturer / supplier 208 and distributor 212). Distributor 212 provides justification for the request with supporting documentation. Manufacturer / supplier 208 reviews the dispute and accompanying information and approves or rejects the dispute. If necessary, additional rules are added to the rules engine to resolve dispute requests and the like.

[0091] FIG4A is an overview of an example SPA according to the prior art. The overview includes end customer details 404, distributor details 408, and SPA (contract) details 412. In this context, end customer 404 may be contractor 220, a retail customer, an industrial customer (e.g., another manufacturer that utilizes an item in a product or for a service), and the like; and distributor 212 is a distributor or similar entity that initiated the SPA request. Important items in the SPA include the SPA (contract) type and the SPA (contract) start and end dates. Figure 4B 460 summarizes the disputed rebates 440 and the calculated rebate amounts 442 payable for several invoices. Figure 4C is a visual representation of the status of a SPA according to an example embodiment.

[0092] Figure 5Ais a high-level system diagram of a first example embodiment of a blockchain version of a supply chain management system connecting multiple manufacturers and distributors according to an example embodiment. Rebate requests from distributors 212 are processed by manufacturers / suppliers 208 via supply chain processing platform 500. Like supply chain processing platform 304, supply chain processing platform 500 provides various services, such as aggregation, automation, analysis, enhancement, distribution with permission, and the like. As mentioned above, distributors 212 and manufacturers / suppliers 208 conventionally utilize different enterprise resource planning (ERP) systems, different data structures (including different SKU groups, part numbers, and the like), different communication methods, competing interests, and the like, creating a complex heterogeneous environment that has traditionally proven to be difficult to manage due to lack of trust in shared platforms (platforms shared by different enterprises and potentially by competitors) and different data structures (due to security, privacy, antitrust issues, and the like). Typically, conventional shared platforms lack technical solutions to enable entities to quickly access management data that is secure and trusted by participants in the supply chain for management purposes. Excluding a shared platform for supply chain processing results in inefficient use of computing resources and increased processing time for, for example, processing a bill of materials. For example, multiple platforms may need to be accessed to process a bill of materials containing items from different manufacturers; multiple workflows need to be supported, requiring users to learn the protocols of multiple workflows. The architecture described above addresses the security, privacy, and antitrust issues mentioned above, enables support for multiple manufacturers / suppliers 208 and other supply chain participants on an integrated platform, and reduces computer resources and processing time used to manage the supply chain and, for example, the rebate process.

[0093] The supply chain processing platform 500 utilizes a blockchain architecture that is secure and trusted by participants in the supply chain, and automatically generates trusted accurate rebate calculations, for example, using blockchain-compatible inventory allocation and cost systems. It provides a single set of workflows for use by various entities, including entities in a competitive relationship. The supply chain processing platform 500 utilizes blockchain executable files (called "chain codes" and smart contracts) that operate on blocks and data of blocks of the blockchain to provide a series of functionalities to the blockchain environment (chain codes and smart contracts are computerized, code-implemented logic agreed upon by participants of the SCP platform 500). In order to implement the use of the blockchain architecture, in an example embodiment, the purchase / sales order computerized, code-implemented contract 512 parses submitted information, such as purchase orders, sales orders, bills of materials, and the like (which include items purchased from multiple manufacturers / suppliers 208), and separates the information by manufacturer as part of the pre-processing operation to prepare the information to enter the appropriate ledger block of the appropriate blockchain, thereby providing the security and privacy required by participants of the supply chain management system, and achieving the determination of the true acquisition cost required for rebate processing. (Given the teachings herein, one skilled in the art will be able to implement a suitable parser using a language such as Python or Perl.)

[0094] As described above, the distributor ledger data may be added to the blockchain corresponding to the SPA of the item covering the sales report (SPA blockchain), a blockchain dedicated to the distributor 212, a blockchain corresponding to the manufacturer / supplier 208, and the like. In any case, the distributor ledger data corresponding to different manufacturers / suppliers 208 is separated from the distributor ledger data corresponding to other manufacturers / suppliers 208 by the manufacturer / supplier and stored in a separate block, and potentially a separate blockchain.

[0095] The transition to a blockchain architecture also introduces other technical issues compared to conventional database architectures. While data in a blockchain is immutable and therefore provides a degree of trust, immutability results in an ever-increasing number of blocks in the blockchain, and therefore locating information required to process, for example, a rebate claim may prove challenging. Therefore, it should be understood that technical issues arise when seeking to use a blockchain. In one example embodiment, the introduction of an inventory blockchain overcomes the technical issues posed by the immutability of the data, advantageously providing a snapshot of the current inventory levels of a distributor 212, enabling easy access to the required information. When a purchase order is preprocessed, the snapshot is updated to depict the addition of existing inventory of the purchased item identified by the purchase date, quantity, and inbound cost. When a sales order is preprocessed, the snapshot is updated to depict the deletion of existing inventory of the sold item identified by the sale date and quantity (and may also include the SPA price, i.e., the end customer 216 price). Rebate Settlement Computerization, Code Implementation Contract 516 (see below) Figure 5B ) uses a FIFO method to adjust the quantity of each box, where each box corresponds to a specific entry cost, so that the rebate settlement computerized, code-implemented contract 516 can determine the true acquisition cost when the item is sold. A snapshot of the current inventory level of the inventory is stored in the inventory block. The inventory block is indexed by a combination of the manufacturer / supplier 208, the distributor 212, and the item identifier (such as SKU) for easy access and determination of the entry cost and the true acquisition cost. The inventory block can be maintained in the inventory blockchain, the distributor blockchain, the blockchain of the corresponding SPA, and the like.

[0096] In order to provide support for traditional supply chain information (e.g., inventory levels and traditional SPAs), in one example embodiment, information required by the inventory allocation and cost system as described more fully above is imported into the supply chain processing platform 500 as part of a traditional data import process compatible with the blockchain architecture. For example, the SPA initiation computerization, code implementation contract 508 or the rebate settlement computerization, code implementation contract 516 may be responsible for obtaining the current status of the inventory (including, for example, SKUs, corresponding quantities, and corresponding inbound costs). This information may be obtained directly from the distributor 212, or generated by the SPA initiation computerization, code implementation contract 508 or the rebate settlement computerization, code implementation contract 516 based on purchase and sales information provided by the distributor 212 and / or the manufacturer / supplier 208.

[0097] Figure 5BThe relationships of entities of a supply chain in an example blockchain embodiment of a supply chain processing (SCP) platform 500 are illustrated. A blockchain is a distributed shared ledger of data records that records transactions between participants in a network and prevents tampering, access, and modification of the data of the ledger. Data records in the form of cryptographic hash-linked blocks can be sequentially added to the ledger in the blockchain, maintaining a history of transactions that occurred between participants. Each block contains a timestamp of the data added to the blockchain and information linking the block to the previous block. Thus, the blockchain acts as a single source of truth, and participants in the blockchain network can only view those transactions that are relevant to them or that they are otherwise authorized to access. In addition, blockchain executable files (referred to as "chain codes" and smart contracts) operate on the blocks of the blockchain and the data of the blocks to provide a range of functionality to the blockchain environment. Chain codes and smart contracts are computerized, code-implemented logic agreed upon by participants of the SCP platform 500.

[0098] Typically, blockchains are peer-to-peer and can be permissionless or permissioned. Permissionless blockchains allow any user to add new transactions to the blockchain, verify transactions, and add new blocks to the blockchain. Permissioned blockchains allow only authorized users to add new transactions to the blockchain, verify transactions, and add new blocks to the blockchain.

[0099] A blockchain typically resides across a distributed network of users and computers and serves as a private or public ledger of transactions, with each transaction authenticated by the network's peers. Figure 5B In an example embodiment of the present invention, the smart contract manages record keeping and data processing of, for example, a rebate process of a supply chain. The registered smart contract 504, which is a computerized, code-implemented program or business logic (also referred to as chain code), enables the GPO 204 (to avoid Figure 5B 504, the manufacturer / supplier 208, the distributor 212, the end customer 216, the contractor 220, and the like are able to register to participate in the supply chain process, including the rebate process. The registration computerized, code-implemented contract 504 utilizes peer-to-peer authentication technology, where only authenticated entities are allowed to participate in the use of the blockchain corresponding to the registration computerized, code-implemented contract 504. In an example embodiment, the registration of entities such as the manufacturer / supplier 208 and the distributor 212 represents acceptance of the terms and conditions of participating in the blockchain supply chain processing platform 500 and entry into a global directory of participants. For some supply chain participants, the directory is not global; instead, a proper subset of participants is entered into a private directory to create a "walled-off" platform for performing the tasks of the supply chain processing platform 500 by a proper subset of participants. In an example embodiment, approval of at least some of the participants of the supply chain processing platform 500 is required to allow a registered participant or candidate participant to register and / or participate in the "walled-off" platform.

[0100] SPA initiation computerized, code implemented contract 508 enables GPO 204, manufacturer / supplier 208, distributor 212, end customer 216, contractor 220, and the like to initiate (initially establish) and negotiate new SPAs, and renegotiate or otherwise amend existing SPAs. In one example embodiment, to initiate a SPA request, an entity such as distributor 212 submits a request to the blockchain version of supply chain processing platform 500 via SPA initiation computerized, code implemented contract 508. A new blockchain is established for this SPA via SPA initiation computerized, code implemented contract 508. In one example embodiment, a blockchain is established for each SPA. In one example embodiment, a blockchain can support multiple SPAs, and a new SPA can be added to an existing blockchain, which can be identified by an identifier of an existing SPA of the blockchain or by another blockchain identifier. The SPA request includes a subset of end customer details 404, distributor details 408, and SPA (contract) details 412, as defined by SPA initiation computerized, code implemented contract 508. For example, a SPA request may include: a requested time period (which may correspond to the entire SPA, a specific SKU or product group, a specific end customer 216, and the like); an item identifier (e.g., SKU, UPC, and the like); terms (e.g., N30, N60, and the like); etc. In some cases, the requester provides guidance regarding the requested terms, such as item price and quantity discounts. In other cases, no guidance is provided, and the manufacturer responds with terms acceptable to the manufacturer, such as item price and quantity discounts.

[0101] SPA initiates computerized code implementation contract 508 to pre-check whether the requester has submitted all required / mandatory information (the system checks whether all mandatory fields have been completed and performs basic checks and verifications of the information). If the request passes the pre-check, a block with the requester's information is added to the corresponding blockchain. The relevant manufacturer / supplier 208 receives the request and associated information via SPA initiates computerization, code implementation contract 508 and performs various checks and verifications on the request. In an example embodiment, the manufacturer / supplier 208 provides an overview of the items that did not pass the relevant business rules (if any) via SPA initiates computerization, code implementation contract 508 and a new block of the blockchain. The requester can then retrieve the overview via SPA initiates computerization, code implementation contract 508 and provide supplementary information via SPA initiates computerization, code implementation contract 508 and a new block of the blockchain.

[0102] In one example embodiment, checks performed by or on behalf of the manufacturer / supplier 208 (e.g., via a SPA-initiated computerized, code-implemented contract 508) include, for example, whether there is an existing SPA for the identified combination of end customer 216 and SKU (overlapping SPAs); whether the end customer 216 purchases the same manufacturer's products from other distributors 212 (to identify price / channel conflicts and the like); whether the manufacturer / supplier 208 (and potentially the distributor 212) has rejected any prior agreements; whether the manufacturer / supplier 208 (and potentially the distributor 212) has any historical SPAs; suggested pricing from the manufacturer / supplier's pricing engine; and the like.

[0103] The manufacturer / supplier 208 then approves the SPA request, denies the SPA request, or requests additional information via the SPA-initiating computerized, code-implementing contract 508, which adds a corresponding block to the blockchain. Additionally, negotiation of the terms of the SPA may be conducted, for example, between the manufacturer / supplier 208 and the distributor 212, by repeatedly exchanging proposed terms via blocks of the blockchain. If approved, the SPA-initiating computerized, code-implementing contract 508 creates a block containing the SPA (with the SPA reference number), and assigns the SPA reference number on the agreement (creating a system of record). (It should be noted that subsequent changes to the SPA may also be negotiated and recorded via the SPA-initiating computerized, code-implementing contract 508 and the corresponding blockchain.)

[0104] If additional information is requested via the blockchain, the distributor 212 submits the requested information and / or additional attachments in response via the SPA-initiated computerized, code-enforced contract 508. The manufacturer / supplier 208 then reviews the provided information / attachments obtained from the SPA-initiated computerized, code-enforced contract 508 via the blockchain and approves the request, denies the request, or requests additional information if necessary. If denied, the manufacturer / supplier 208 provides a reason code, description, and the like to the requester (e.g., distributor 212, GPO 204, and the like) via the blockchain.

[0105] In some cases, distributors 212 may request that manufacturers / suppliers 208 add additional end customers 216, SKUs, product groups, and the like to an existing agreement, may request price modifications to an existing agreement, and the like. Likewise, manufacturers / suppliers 208 may manage their price list prices and / or SKU additions and deletions on the same agreement (as opposed to creating a new agreement). These changes are also recorded to the blockchain by the SPA-initiated computerized, code-implemented contract 508. It should be noted that in one example embodiment, the SPA-initiated computerized, code-implemented contract 508 and other contract entities are implemented as smart contracts using chaincode.

[0106] Figure 5C 5 is a swim lane diagram 550 of an example supply chain case according to an example embodiment. Initially, distributor 212 submits a registration request to SCP platform 500 (operation 552). The registration request may be submitted directly via a registration blockchain, indirectly via a website or application, and the like. Fig.10 More fully described, registration requests are processed by the registration computerization, code implementation contract 504, and in Figure 5C In the example of , the registration is approved and confirmed (operation 554). Similarly, the manufacturer / supplier 208 submits a registration request to the SCP platform 500 (operation 556). Again, the registration request may be submitted via a registration blockchain, via a website or application, and the like. Figure 5C In the example of , the registration is approved and confirmed by the registry computerized, code-implemented contract 504 via the registry blockchain (operation 558).

[0107] The distributor 212 submits a request to initiate a SPA with the identification of the desired manufacturer / supplier 208 (operation 560). The desired manufacturer / supplier 208 may be identified by accessing a global or other directory provided by the SCP platform 500. The SCP platform 500 responds by creating a SPA blockchain corresponding to the requested SPA (operation 562). In one example embodiment, the blockchain contains details of the requester's offer and is accessible by both the distributor 212 and the manufacturer / supplier 208 for processing the SPA initiation request. In addition, the manufacturer / supplier 208 and the distributor 212 are alerted to the initiation of the candidate SPA via the SPA blockchain (operation 564). The manufacturer / supplier 208 may then respond by accepting the offer, providing a counter-offer, or rejecting the offer. Figure 5C In the example of , the manufacturer / supplier 208 responds with a counter-offer (operation 566). The distributor 212 then reviews and accepts the counter-offer, as in Figure 5C 568), or provide a revised quote. It should be noted that the number of re-quotes and counter-offers varies based on the authority of the manufacturer / supplier 208 and the distributor 212. Once the negotiation is complete and the terms of the SPA are agreed upon, the SCP platform 500 assigns a SPA reference number to the SPA and the SPA blockchain, and alerts the distributor 212 and the manufacturer / supplier 208 of the establishment of the SPA (operations 570 and 572).

[0108] After a certain period of time, the distributor 212 submits its sales report blockchain transaction in the form of distributor ledger data via the appropriate blockchain (operation 574). (The distributor ledger data may be added to the blockchain corresponding to the SPA for the items covering the sales report (SPA blockchain), a blockchain dedicated to the distributor 212, a blockchain dedicated to the corresponding manufacturer / supplier 208, a blockchain dedicated to the distributor 212 and the manufacturer / supplier 208 participating in the corresponding SPA, and the like.) The distributor 212 may then submit a rebate request detailing the calculation of the rebate payable, or may submit a request for the SCP platform 500 to calculate the rebate (if any) payable to the distributor 212. In one example embodiment, the SCP platform 500 automatically calculates the rebate (if any) payable to the distributor 212; that is, the distributor 212 does not need to submit a rebate request. Figure 5C In the example of , the rebate settlement is computerized, the code implementation contract 516 automatically determines the rebate and publishes the rebate report via the rebate blockchain (operations 576, 578). (It should be noted that the end customer 216 and the contractor 220 are not directly involved Figure 5C Example supply chain case depicted in . )

[0109] Purchase / Sales Order Contract

[0110] In one example embodiment, purchase / sales order computerized, code-implemented contract 512 enables distributor 212 to submit information regarding purchase orders and / or sales orders for one or more items via SCP platform 500. (As used herein, a purchase order refers to an order from distributor 212 to manufacturer / supplier 208 or similar entity, and a sales order refers to an order from end customer 216, contractor 220, or similar entity to distributor 212.) After the purchase order is submitted, the recipient of the purchase order (e.g., manufacturer / supplier 208) will invoice the purchaser and will transfer the items to the purchaser (e.g., distributor 212).

[0111] In one example embodiment, purchase / sales order computerized, code-implemented contract 512 enables distributor 212 to submit purchase order information (e.g., purchase orders for items from manufacturer / supplier 208) and sales order information (e.g., transaction history of sales with end customer 216). Purchase order information and sales order information may be submitted periodically, after executing a purchase order or sales order, and in a similar manner.

[0112] In one example embodiment, purchase orders, sales orders, bills of materials, and the like, including items purchased from multiple manufacturers / suppliers 208, items sold to end customers 216, or any combination of the foregoing, are submitted to the purchase / sales order computerization, code implementation contract 512, and the purchase / sales order computerization, code implementation contract 512 parses the submitted information for input into the appropriate ledger block of the appropriate blockchain as part of a pre-processing operation. As described above, the distributor ledger data may be added to the blockchain corresponding to the SPA of the items covering the sales report (SPA blockchain), the blockchain dedicated to the distributor 212, the blockchain of the corresponding manufacturer / supplier 208, the blockchain dedicated to the distributor 212 and the manufacturer / supplier 208 participating in the corresponding SPA, and the like. In any case, the distributor ledger data corresponding to different manufacturers / suppliers 208 is separated by the manufacturer / supplier from the distributor ledger data corresponding to other manufacturers / suppliers 208 and stored in separate blocks and potentially separate blockchains. It is important to note that manufacturers / suppliers 208 and other supply chain participants typically avoid operating on shared platforms due to security, privacy, antitrust issues, and the like. Excluding shared platforms for supply chain processing results in inefficient use of computing resources and increased processing time to, for example, process a bill of materials for items that list different manufacturers / suppliers 208. For example, multiple platforms may need to be accessed to process the referenced bill of materials. The architecture described above enables the security, privacy, and antitrust issues mentioned above to be addressed, enabling support for different manufacturers / suppliers 208 and other supply chain participants on an integrated platform, and reducing computer resources and processing time for managing supply chains and, for example, rebate processes. In order to access a desired block, well-known hashing techniques (e.g., using a random number generator) may be used in the purchase / sales order computerization, code implementation contract 512 to serve as an index to a table based on a given key, thereby ensuring efficient random access to locate a desired block in a corresponding blockchain within a constant amount of time.

[0113] Rebate settlement contract

[0114] After purchasing the items, the distributor 212 may submit its rebate claim via the rebate settlement computerized, code-implemented contract 516, including the sales history and on-hand inventory indication of each of the relevant manufacturer's SKUs. This may be performed periodically (e.g., daily, weekly, monthly, and the like) when the corresponding items are sold, shipped, or delivered, and the like. In an example embodiment, the rebate is automatically calculated by the rebate settlement computerized, code-implemented contract 516 without submitting a rebate claim.

[0115] Whether received from distributors 212 or determined through analysis of purchase orders and sales orders, the on-hand inventory, such as by the inventory allocation and cost system of the rebate settlement computerized, code-implemented contract 516, is used to allocate the inventory acquired by the distributor 212, assign the correct costing batches (bins) to the items sold from the inventory, and calculate the rebate. In some cases, the distributor 212 also provides its on-hand inventory instead of or in conjunction with the complete sales history. The rebate settlement computerized, code-implemented contract 516 then accesses the data of the manufacturer / supplier 208 and the data provided by the distributor 212, and performs any, some, or all of the following actions in the order indicated or in an alternate order:

[0116] Determine whether the Agreement is in effect as of the Order Date;

[0117] Determining whether the end customer 216 and / or the distributor 212's branch is listed on the SPA on a given order date;

[0118] Determine if the SKU is covered by the SPA on the order date (if a product group is provided, the corresponding SKU or SKUs can be obtained and verified);

[0119] Determine the agreed multiplier or net price for the SKU;

[0120] determine the list price as of the order date;

[0121] Determine the distributor's 212 inventory cost and / or actual acquisition cost as of the order date; and

[0122] Calculate rebates.

[0123] It should be noted that a manufacturer / supplier part number and distributor part number cross-reference database may be used to determine and / or confirm the part number for a particular item.

[0124] Fig. 6A6 is a flow chart of an example method 650 for initiating a special price agreement according to an example embodiment. In one example embodiment, a request to initiate a special price agreement is obtained from a special price agreement requester (operation 654), and a special price agreement blockchain corresponding to the special price agreement is established through the special price agreement initiation computerized, code-implemented contract 508 (operation 658). It is determined whether the special price agreement requester has omitted information required for the special price agreement initiation computerized, code-implemented contract 508 (decision box 662). If all required data is verified and exists (the yes branch of decision box 662), then a block is added to the special price agreement blockchain, the block including the requester information (operation 666). If all required data is not verified and does not exist (the no branch of decision box 662), then invalid and / or missing information is requested and obtained (operation 686), and the method 650 continues with operation 662.

[0125] In one example embodiment, an SPA acceptance or counteroffer is obtained from the requestee and a corresponding block is added to the SPA blockchain (operation 670). An acceptance of the original SPA or counteroffer is obtained from the requester (operation 674), and an SPA terms block is added to the SPA blockchain (operation 678).

[0126] Blockchain ledger definition and method

[0127] Figure 6B 6 is a flow chart of an example method 600 for populating a manufacturer ledger block of a blockchain according to an example embodiment. Method 600 is performed periodically to maintain the freshness of the manufacturer ledger block of the blockchain. The manufacturer ledger block is defined, absorbed, and maintained using the purchase / sales order computerization, code implementation contract 512 and rebate settlement computerization, code implementation contract 516 of the blockchain supply chain processing platform 500. It should be noted that data exists in many different forms across manufacturers / suppliers 208, distributors 212, and the like; manufacturers / suppliers 208 may store the data required for the ledger in many different tables on an ERP system or other system. As described above, the basic data requirements of the blockchain supply chain processing platform 500 for manufacturers / suppliers 208 include any, some, or all of the following:

[0128] SKU Master with product groupings (hierarchies), e.g. SKU data for each product grouping, including SKU attribute change log (captures SKU additions / deletions and describes the SKU hierarchy at a given point in time) and historical list price change log (to calculate the point in time list price; all change log data and product hierarchy data are contained in different tables / schemas that are linked / connected);

[0129] The main version of the SPA, including the customer account (SPA property change log to maintain changes in the SPA);

[0130] Distributor sales order (describing the product, quantity and price paid);

[0131] Pre-processing logic (general pre-processing rules and / or logic for each distributor 212);

[0132] Manufacturer / supplier part number and distributor part number cross-reference database; and

[0133] A cross-reference database of distributor numbers and manufacturer's distributor account numbers, including a cross-reference database of distributor position numbers and manufacturer's distributor position account numbers.

[0134] In one example embodiment, a manufacturer / supplier transaction ledger blockchain is instantiated for multiple entities supporting the supply chain processing system 500. The entities may be divisions, subsidiaries, and the like of a single business enterprise, or may be business entities, including cooperating business entities, competing business entities, and the like. Initially, a manufacturer / supplier ERP system is accessed to retrieve the manufacturer / supplier data designated for blockchain input (operation 604). The manufacturer / supplier data designated for blockchain input is verified (operation 608). A new blockchain is instantiated or an existing blockchain is identified for input of the verified data (operation 610), and a check is performed to determine if all data is verified and exists (decision box 612). If all data is unverified and does not exist (the no branch of decision block 612), invalid and / or missing data is requested and obtained (operation 614), and the logic flow returns to operation 604; otherwise (the yes branch of decision block 612), the data is pre-processed to, for example, format the data for input into the ledger of the blockchain, and a timestamp indicating, for example, the time when the purchase order was received is added (operation 616), and the verified manufacturer / supplier data is populated into the corresponding blockchain (operation 620). The method 600 then waits for the availability of additional manufacturer / supplier data designated for blockchain input. It should be noted that the blocks of the blockchain inherently implement a time series record of sales prices and the like. In one example embodiment, during operation 616, an index entry for the block is generated (as described above). The index can be keyed to the manufacturer / supplier 208, the distributor 212, the SKU, and the like.

[0135] Figure 7is a flow chart of an example method 700 for populating a distributor ledger block of a blockchain according to an example embodiment. The distributor ledger block is defined, ingested, and maintained using the purchase / sales order computerization, code-implemented contract 512 and the rebate settlement computerization, code-implemented contract 516 of the blockchain supply chain processing platform 500. The distributor 212 submits its sales history for the manufacturer's SKU and its existing inventory periodically (e.g., daily, weekly, monthly, and the like) or based on events (e.g., when the corresponding item is sold, shipped, or delivered, and the like) so that the inventory allocation and cost system can be used to allocate inventory. (As described above, in an example embodiment, the supply chain processing platform 500 automatically calculates rebates and does not require the distributor 212 to submit a rebate request. The supply chain processing platform 500 can also determine the existing inventory by analyzing the relevant purchase orders and sales orders.) In an example embodiment, the distributor ledger block is populated periodically when an item is sold from the distributor's 212 inventory, and if the sale is related to a purchase order, the distributor ledger block is populated based on an event. In one example embodiment, sales history is submitted for all manufacturers' SKUs listed by the distributor 212. As described above, the basic data requirements of the blockchain supply chain processing platform 500 for the distributor 212 include:

[0136] The rebate request of the end customer 216 , including the distributor number, distributor branch number, manufacturer / supplier 208 catalog number, UPC, order number, order line number, order date, invoice number, invoice line number, invoice date, quantity, standard / warehousing cost, rebate cost, SPA reference number, and rebate request amount;

[0137] Complete sales history for all manufacturer SKUs (to support inventory allocation and costing systems); and

[0138] On-hand inventory balances at different distributor locations.

[0139] In one example embodiment, distributors 212 or similar entities will report item returns associated with previously reported sales so that the inventory allocation and cost system maintains an accurate view of the inventory on hand. It should be noted that some of the required data is provided by distributors 212, while other data is provided by the rebate settlement computerization, code implementation contract 516. For example, the SPA reference number is provided by the distributor 212, while the rebate is determined by the rebate settlement computerization, code implementation contract 516. In addition, the data for the complete sales history may be different. For example, if the terms of the SPA are based on the end customer 216, then information about the end customer 216 will be included, but if the SPA does not consider the identity of the end customer 216, then information about the end customer 216 may be excluded.

[0140] In one example embodiment, the distributor 212 provides: (1) a reference number of a SPA that offers the best terms to the distributor 212; (2) no SPA reference number (in which case the blockchain supply chain processing platform 500 determines the reference number of the SPA that offers the best terms to the distributor 212); or (3) a reference number of a SPA available to the distributor 212 (in which case the blockchain supply chain processing platform 500 determines the reference number of a SPA among the available SPAs that offers the best terms to the distributor 212). The best SPA may be determined by determining the rebate amount for each eligible SPA and selecting the SPA with the highest rebate amount. In one example embodiment, a distributor profile in the blockchain supply chain processing platform 500 is configured during the registration process to indicate whether the blockchain supply chain processing platform 500 is authorized to determine the reference number of the SPA that offers the best terms (e.g., the lowest price) to the distributor 212. In one example embodiment, the authorization to determine the reference number of the SPA that offers the best terms to the distributor 212 is based on a specific rule corresponding to the SPA. For example, the specific rule may indicate that the distributor 212 is entitled to the lowest price available among all eligible SPAs.

[0141] Continue to refer Figure 7, in one example embodiment, a distributor transaction ledger blockchain is instantiated for multiple entities supporting the supply chain processing system 500. The entities may be divisions, subsidiaries, and the like of a single business enterprise, or may be individual business enterprises, including cooperating business enterprises, competing business enterprises, and the like. Initially, a distributor ERP system is accessed to retrieve distributor data designated for blockchain input (operation 704). The distributor data designated for blockchain input is verified (operation 708). For example, a determination is made that the SPA reference number is valid and lists the quantity of the item sold. A new blockchain is instantiated or an existing blockchain is identified for input of the verified data (operation 710), and a check is performed to determine if all data is verified and exists (decision box 712). If all data is unvalidated and does not exist (the no branch of decision block 712), invalid and / or missing data is requested and obtained (operation 714), and the logic flow returns to operation 704; otherwise (the yes branch of decision block 712), the data is pre-processed to, for example, format the data for entry into the ledger of the blockchain and add a timestamp indicating, for example, the time when the purchase order was submitted (operation 716). In one example embodiment, distributor ledger data corresponding to different manufacturers / suppliers 208 is separated from distributor ledger data corresponding to other manufacturers / suppliers 208 by the manufacturer / supplier as part of the pre-processing operation and stored in a separate block of the blockchain, and potentially as part of a separate blockchain. In one example embodiment, during operation 716, an index entry of the generated block is generated (as described above). The index may be keyed to manufacturers / suppliers 208, distributors 212, SKUs, and the like.

[0142] In one example embodiment, an inventory blockchain is maintained to provide a snapshot of the current inventory level of the distributor's 212 inventory (operation 720). When a purchase order is preprocessed, the snapshot is updated to depict the addition of existing inventory of the purchased item identified by the purchase date, quantity, and inbound cost. When a sales order is preprocessed, the snapshot is updated to depict the removal of existing inventory of the sold item identified by the sale date and quantity (which may also include the SPA price, i.e., the end customer price). The rebate settlement computerized, code-implemented contract 516 uses a FIFO method to adjust the quantity of each box, where each box corresponds to a specific inbound cost, so that the rebate settlement computerized, code-implemented contract 516 can determine the true acquisition cost when the item is sold. The snapshot of the current inventory level of the inventory can be stored in an inventory block. The inventory block is indexed by a combination of the manufacturer / supplier 208, the distributor 212, and the item identifier (e.g., SKU) for easy access and determination of the inbound cost and the true acquisition cost. The inventory block can be maintained in the inventory blockchain, the distributor blockchain, the blockchain of the corresponding SPA, and the like. The verified distributor data is then populated into a block of the corresponding blockchain (operation 724), and the method 700 then waits for the availability of additional distributor data designated for blockchain input. As described above, the distributor ledger data may be added to the blockchain corresponding to the SPA for the item covering the sales report (SPA blockchain), a blockchain dedicated to the distributor 212, a blockchain for the corresponding manufacturer / supplier 208, a blockchain dedicated to the distributors 212 and manufacturers / suppliers 208 participating in the corresponding SPA, and the like.

[0143] In one example embodiment, the methods 600, 700 are used to import a traditional special price agreement into the supply chain processing system 500. First, the file-based special pricing agreement in a non-blockchain format is parsed (operations 604, 704), the data in the non-blockchain format is filtered according to the terms of the inventory allocation and cost system of the supply chain processing system 500 (operations 616, 716), the filtered data is processed (operations 616, 716), and the processed data is stored in one or more blocks of the special price agreement blockchain or another designated blockchain (operations 620, 724).

[0144] Figure 86 and 7, respectively, the rebate settlement computerized, code-implemented contract 516 is triggered to access the SPA data and process the data from the ledger block of the manufacturer / supplier 208 and the ledger block of the distributor 212 (operation 804). As described above, the existing inventory data can be obtained from the latest inventory block corresponding to the item under consideration, for example, identified by its SKU. The SPA block can be located and accessed by using the index of the SPA (it should be noted that all relevant terms of the latest version of the SPA can be stored in a single block; alternatively, the rebate settlement computerized, code-implemented contract 516 will determine the relevant terms of the latest version of the SPA by accessing the terms of the original SPA block and compiling the current terms based on the block corresponding to the subsequent amendment to the SPA). Similarly, blocks for manufacturers / suppliers 208 and distributors 216 may be located and accessed by using indexes corresponding to manufacturers / suppliers 208, distributors 216, SKUs, and the like. The rebate settlement computerized, code-implemented contract 516 then performs any, some, or all of the following actions in the indicated order or in an alternate order by, for example, examining the original SPA and subsequent changes to the SPA:

[0145] Determining whether the agreement is valid on the order date (operation 808);

[0146] Determine whether the end customer 216 and / or the branch of the distributor 212 is listed on the SPA on the order date (operation 812);

[0147] Determine whether the SKU is covered by the SPA on the order date (if a product group is provided, the corresponding one or more SKUs may be obtained and verification performed) (operation 816);

[0148] Determining the validity of the negotiated multiplier or net price for the SKU on the purchase order date (operation 820);

[0149] determining the list price as of the purchase order date (operation 824); and

[0150] The inventory entry and / or actual acquisition cost for distributor 212 on the purchase order date is determined (operation 828).

[0151] A check is performed to determine if all data exists and is verified (decision box 832). If all data does not exist and is not verified (no branch of decision box 832), the process is terminated and the distributor 212 is notified (operation 836); otherwise (yes branch of decision box 832), the rebate request is processed (operation 840), as described below in conjunction with Fig. 9 This is more fully described by way of examples.

[0152] Fig. 9 900 is a flow chart of an example method 900 for processing rebate claims using an inventory allocation and cost system of a blockchain embodiment of a supply chain processing platform 500 according to an example embodiment. In one example embodiment, an inventory blockchain supporting multiple entities of the supply chain processing platform 500 is instantiated (operation 902). The inventory allocation and cost system determines the on-hand inventory of a distributor 212 for a given SKU, including the distributor branch and location. This can be based on a description of the on-hand inventory provided by the distributor 212, provided by an analysis of the sales history, purchase history, or both provided by the distributor 212, and the like (operation 904). This can also be done by revising the latest inventory details provided by the distributor 212 based on reported (subsequent) sales (inventory reductions) and purchases (inventory increases). In one example embodiment, the on-hand inventory of the distributor 212 is calculated by analyzing the purchase history and sales history provided by the distributor 212 for each relevant SKU (eliminating the need for the distributor 212 to provide a description of the current inventory). In one example embodiment, the on-hand inventory is determined by accessing the latest inventory block corresponding to a given item.

[0153] The calculated data is merged with the data of the manufacturer / supplier 208 to allocate inventory based on a first-in (first-in) first-out method (operation 908). A check is then performed to determine if a discrepancy is found that requires aborting the method 900 (operation 912). For example, a check is performed to determine if the manufacturer / supplier 208 reports a purchase quantity that is different from that reported by the distributor 212. If a discrepancy is found that requires aborting the method 900 (the yes branch of decision box 912), the discrepancy is reported (operation 932) and the method 900 ends. If a discrepancy is not found that requires aborting the method (the no branch of decision box 912), the true acquisition cost of the inventory of the given SKU sold is determined (e.g., a relevant price multiplier can be applied to the list price to derive the true acquisition cost of the distributor 212 for each box utilized in the sale of the item) (operation 916). (In one example embodiment, the true acquisition cost is maintained as a component of the corresponding inventory block and can be determined simply by accessing the block.) The SPA or rebate cost is determined, the rebate amount per unit is calculated for each unit sold (the inbound cost minus the SPA or rebate cost or the true acquisition cost minus the SPA or rebate cost), and the total rebate based on the rebate amount corresponding to the given item identifier and the quantity sold is determined (operation 920). If a claim has been submitted by the distributor 212, the rebate amount per unit is matched to the distributor 212's claim (operation 924). For example, the rebate amount for each of the ten units would be determined by identifying the ten units with the longest amount of dwell time in inventory, determining the inbound cost and true acquisition cost corresponding to each of the ten units, locating the SPA or rebate cost for each of the ten units using a qualifying SPA, and determining the rebate amount for each of the ten units, and then adding the ten determined rebate amounts. The calculation steps are then reported, and any deviations are reported via a block of the blockchain (operation 928). For example, the rebate blockchain may be updated based on the determined total rebate. In one example embodiment, a new inventory block with a revised description of the current inventory is generated as part of operation 928. It should be noted that the settlement of funds corresponding to the above-mentioned calculated rebate amount is performed in a manner known to those skilled in the art. For example, if the calculated rebate amount is $12,000, then a transfer of $12,000 from the manufacturer / supplier 208 to the distributor 212 is performed using known techniques.

[0154] Fig.101 is a flow chart of an example method 1000 for registering a participant with a blockchain embodiment of a supply chain processing platform 500 according to an example embodiment. In one example embodiment, a registration candidate submits a registration request via, for example, a website, a client application, and the like (operation 1004). A registration blockchain is created based on the registration application submitted by the candidate participant (operation 1008). A check is performed to determine whether all necessary registration data is verified and present (decision block 1012). If all registration data is not verified and does not exist (the no branch of decision block 1012), invalid and / or missing data is requested and obtained (operation 1016), and the check of block 1012 is repeated until a yes is obtained. If and when all registration data is verified and present (the yes branch of decision block 1012), the data is pre-processed to, for example, format the data for input into the registration database and directory of the supply chain processing platform 500 (operation 1020), the registration database and directory are updated to reflect the registration of the new participant (operation 1024), and acceptance of the registration request is confirmed to the requester via the registration blockchain (operation 1028). For example, a block may be added to the registration blockchain detailing the registration's expiration date, the participant's registration number, a temporary user password, and the like.

[0155] Reporting Layer

[0156] In one example embodiment, the smart contracts of the supply chain processing platform 500 provide reporting functionality. For example, the rebate settlement computerization, code implementation contract 516 issues a report detailing the calculations of the rebate verification process, issues an indication of whether the rebate request submitted by the distributor 212 is approved, and the like. The report is automatically generated and can also be accessed upon request to the rebate settlement computerization, code implementation contract 516. The rebate settlement computerization, code implementation contract 516 also provides access to the distributor ledger data and manufacturer / supplier ledger data of the blockchain. For example, the distributor 212 can submit a request to the rebate settlement computerization, code implementation contract 516 to view the ledger data of a specific blockchain. In one example embodiment, the data that can be accessed by an entity such as the distributor 212 can be restricted by the supply chain processing platform 500. For example, the distributor 212 can be prevented from viewing the ledger data (or a portion of the ledger data) of the manufacturer / supplier 208, the manufacturer / supplier 208 can be prevented from accessing the data (e.g., ledger blocks) of the competing manufacturer / supplier 208, and the like. Access to the data may be authorized by the supply chain processing platform 500 based on the access terms defined in the corresponding SPA.

[0157] In one example embodiment, the SPA initiating computerized, code-implemented contract 508 may be queried for terms of the SPA, and the registered computerized, code-implemented contract 504 may be queried for a directory of registered participants of the supply chain processing platform 500 .

[0158] Traditional data import

[0159] In one example embodiment, the SPA originating computerized, code-implemented contract 508 supports the import of legacy SPAs. For example, a legacy SPA may be submitted via an import file. In one example embodiment, custom software is crafted to parse the legacy SPA in its native format, and the custom software formats the parsed data for submission to the SPA originating computerized, code-implemented contract 508, which then generates a blockchain corresponding to the SPA.

[0160] In one example embodiment, the information required by the inventory allocation and cost system as described more fully above is imported into the supply chain processing platform 500 as part of a conventional data import process. For example, the SPA initiated contract computerization, code implementation 508 or the rebate settlement computerization, code implementation contract 516 may be responsible for obtaining the current status of the inventory (including, for example, SKUs, corresponding quantities, and corresponding inbound costs). This information may be obtained directly from the distributor 212, or generated by the SPA initiated computerization, code implementation contract 508 or the rebate settlement computerization, code implementation contract 516 based on information provided by the distributor 212 and / or the manufacturer / supplier 208.

[0161] In view of the discussion thus far, it should be appreciated that distributors 212 and manufacturers / suppliers 208 conventionally have competing interests and utilize different enterprise resource planning (ERP) systems, different data structures (including different SKU groups, part numbers, and the like), different communication methods, and the like, creating a complex heterogeneous environment that has traditionally proven to be difficult to manage due to lack of trust in shared platforms and different data structures (due to security, privacy, antitrust issues, and the like). Typically, conventional shared platforms lack technical solutions to enable entities to quickly access management data that is secure and trusted by participants in the supply chain for management purposes. Excluding shared platforms for supply chain processing results in inefficient use of computing resources and increased processing time for, for example, processing bills of materials. For example, multiple platforms may need to be accessed to process a bill of materials containing items from different manufacturers; multiple workflows need to be supported, requiring users to learn protocols for multiple workflows. The architecture described above addresses the security, privacy, and antitrust issues mentioned above, enables support for multiple manufacturers / suppliers 208 and other supply chain participants on an integrated platform, and reduces computer resources and processing time for managing the supply chain and, for example, rebate processes.

[0162] The supply chain processing platform 500 utilizes a blockchain architecture that is secure and trusted by participants in the supply chain, and automatically generates trusted accurate rebate calculations, for example, using blockchain-compatible inventory allocation and cost systems. It provides a single set of workflows for use by various entities, including those in a competitive relationship. To enable the use of the blockchain architecture, in one example embodiment, the purchase / sales order computerization, code implementation contract 512 parses submitted information, such as purchase orders, sales orders, bills of materials, and the like (which include items purchased from multiple manufacturers / suppliers 208), and separates the information by manufacturer as part of a pre-processing operation to prepare the information for entry into the appropriate ledger block of the appropriate blockchain, thereby providing the security and privacy required by participants in the supply chain management system, and enabling the determination of the true acquisition cost required for rebate processing. As described above, the distributor ledger data can be added to the blockchain corresponding to the SPA of the items covering the sales report (SPA blockchain), the blockchain dedicated to the distributor 212, the blockchain corresponding to the manufacturer / supplier 208, and the like. In any case, distributor ledger data corresponding to different manufacturers / suppliers 208 is separated by the manufacturer / supplier from distributor ledger data corresponding to other manufacturers / suppliers 208 and stored in separate blocks, and potentially separate blockchains.

[0163] Compared to conventional database architectures, the transition to a blockchain architecture also introduces other technical issues. Although the data in the blockchain is immutable and therefore provides a certain degree of trust, the immutability leads to an increasing number of blocks in the blockchain, and therefore locating information required to process rebate claims, for example, may prove to be challenging. Therefore, it should be understood that technical problems arise when seeking to use blockchain. In an example embodiment, the introduction of an inventory blockchain overcomes the technical problems caused by the immutability of the data, advantageously providing a snapshot of the current inventory level of the distributor 212, enabling easy access to the required information. When a purchase order is preprocessed, the snapshot is updated to depict the addition of the existing inventory of the purchased items identified by the purchase date, quantity, and entry cost. When a sales order is preprocessed, the snapshot is updated to depict the deletion of the existing inventory of the sold items identified by the sale date and quantity (which may also include the SPA price, i.e., the final customer 216 price). The rebate settlement computerization, code implementation contract 516 uses a FIFO method to adjust the quantity of each box, where each box corresponds to a specific entry cost, so that the rebate settlement computerization, code implementation contract 516 can determine the true acquisition cost when the item is sold. A snapshot of the current stock level of the inventory is stored in the inventory block. The inventory block is indexed by a combination of manufacturer / supplier 208, distributor 212, and item identifier (e.g., SKU) for easy access and determination of inbound cost and true acquisition cost. The inventory block may be maintained in the inventory blockchain, distributor blockchain, blockchain of the corresponding SPA, and the like.

[0164] In order to provide support for traditional supply chain information (such as inventory levels and traditional SPA), in one example embodiment, the information required by the inventory allocation and cost system as described more fully above is imported into the supply chain processing platform 500 as part of a traditional data import process compatible with the blockchain architecture. For example, the SPA initiation contract computerization, code implementation 508 or the rebate settlement computerization, code implementation contract 516 can be responsible for obtaining the current status of the inventory (including, for example, SKU, corresponding quantity and corresponding inbound cost). This information can be obtained directly from the distributor 212, or generated by the SPA initiation computerization, code implementation contract 508 or the rebate settlement computerization, code implementation contract 516 based on the purchase and sales information provided by the distributor 212 and / or the manufacturer / supplier 208.

[0165] Generally speaking, according to aspects of the present invention, an exemplary method for processing rebates on a supply chain processing system 500 based on a blockchain architecture includes the following operations: instantiating an inventory blockchain for multiple entities supporting the supply chain processing system 500 (operation 902); determining, in response to changes in a ledger block of a transaction ledger blockchain, an existing inventory of a given item identifier based on a reported sales history and an inventory block, the inventory block including inventory metadata describing a time snapshot of the existing inventory (operation 904); determining a unit and cost allocation for the existing inventory using the inventory metadata (operation 908); determining a unit and cost allocation for the existing inventory based on the inventory metadata of the inventory block (operation 909); determining a unit and cost allocation for the existing inventory based on the inventory metadata of the inventory block (operation 910); determining a unit and cost allocation for the existing inventory based on the inventory metadata of the inventory block (operation 911); determining a unit and cost allocation for the existing inventory based on the inventory metadata of the inventory block (operation 912); determining a unit and cost allocation for the existing inventory based on the inventory metadata of the inventory block (operation 913); determining a unit and cost allocation for the existing inventory based on the inventory metadata of the inventory block (operation 914); determining a unit and cost allocation for the existing inventory based on the inventory metadata of the inventory block (operation 915); determining a unit and cost allocation for the existing inventory based on the inventory metadata of the inventory block (operation 916); determining a unit and cost allocation for the existing inventory based on the inventory metadata of the inventory block (operation 917); determining a unit and cost allocation for the existing inventory based on the inventory metadata of the inventory block (operation 918); determining a unit and cost allocation for the existing inventory based on the inventory metadata of the inventory block (operation 919 ...1); determining a unit and cost allocation for the existing inventory based on the The invention relates to a method for determining a real acquisition cost of the given item identifier based on the data and the determined allocation (operation 916); determining a special price agreement cost based on a special price agreement block, the special price agreement block including the terms of the special price agreement (operation 920); calculating a rebate amount corresponding to the given item identifier based on the special price agreement cost and the real acquisition cost (operation 920); determining a total rebate based on the rebate amount and sales quantity corresponding to the given item identifier (operation 920); generating another inventory block based on the revised inventory (operation 928); and updating the rebate blockchain based on the determined total rebate (operation 928).

[0166] In an example embodiment, determining the allocation of the existing inventory further includes merging the reported sales history with the purchase order of the manufacturer / supplier 208 based on a first-in, first-out method (operation 908). In an example embodiment, the total rebate is compared with the submitted rebate claim (operation 924); and the rebate calculation step between the total rebate and the submitted rebate claim is reported via a block of the rebate blockchain (operation 928). In an example embodiment, one or more of the determination and calculation operations are repeated, one or more deviations that require aborting the processing of the rebate are detected (operation 912), and the deviation is reported via a block of the rebate blockchain (operation 932).

[0167] In one example embodiment, a determination is made as to whether the special price agreement is valid on a given order date by checking the original special price agreement as defined in the special price agreement blockchain and any subsequent changes to the special price agreement (operation 808), determining whether at least one of the end customer 216 and the distributor 212's branch is listed on the special price agreement based on the given order date (operation 812), determining whether the stock holding unit is covered by the special price agreement on the given order date (operation 816), determining the validity of at least one of the agreed multiplier and the net price for the stock holding unit on the given order date (operation 820), determining the list price of the stock holding unit corresponding to the given order date (operation 824), and determining at least one of the stocking cost and the true acquisition cost for the distributor 212 on the given order date (operation 828). In one example embodiment, the calculation steps of the rebate process are accessed via the rebate blockchain, a rebate claim report is generated, and the rebate claim report is provided via the rebate processing computerization, code implementation contract 504.

[0168] In one example embodiment, a request to initiate a special price agreement is obtained from a special price agreement requester (operation 654), a special price agreement blockchain corresponding to the special price agreement is established through the special price agreement initiation computerized, code-implemented contract 508 (operation 658), a determination is made through the special price agreement initiation computerized, code-implemented contract 508 whether the special price agreement requester has omitted information required by the special price agreement initiation computerized, code-implemented contract 508 (operation 662), a block is added to the special price agreement blockchain, the block including the requester information (operation 666), a special price agreement approval or counter-offer is obtained from the special price agreement requestee via the approval block of the blockchain (operation 670), and a special price agreement terms block is added to the special price agreement blockchain (operation 678). In one example embodiment, an assigned special price agreement reference number is obtained from the special price agreement requestee, wherein the special price agreement blockchain includes the assigned special price agreement reference number. In one example embodiment, the requester information includes the terms of the special price agreement offer.

[0169] In one example embodiment, a counteroffer is obtained from the special price agreement requestee (operation 670); and an acceptance of the counteroffer by the special price agreement requester is obtained (operation 674). In one example embodiment, the ledger data is accessed via the corresponding blockchain, a ledger report is generated, and the ledger report is provided via the special price agreement initiating computerized, code-implemented contract 508. In one example embodiment, access to specified data of at least one of the rebate blockchain and the transaction ledger blockchain by a specified entity is controlled based on one or more access rules. In one example embodiment, at least one access rule is based on one or more of: enabling access for all entities specified on the corresponding special price agreement, enabling access for all entities specified in the access profile, blocking access for all entities that are not in the enabled entity list in the access profile, and blocking access for all entities that are not in the corresponding special price agreement. In one example embodiment, the access profile is maintained by the supply chain processing platform 500.

[0170] In one example embodiment, a search is performed for blocks in the special price agreement blockchain that include original terms of the special price agreement and modified terms of the special price agreement, the original terms and modified terms corresponding to the searched blocks are obtained, a summary of the terms of the special price agreement effective on a specified date is generated, the summary of the terms excludes expired terms of the special price agreement, and the summary of the terms is provided via the special price agreement initiation computerized, code-implemented contract 508 (operation 920). In one example embodiment, the file-based special pricing agreement in a non-blockchain format is parsed (operations 604, 704), the data in a non-blockchain format is filtered according to the terms of the inventory allocation and cost system of the supply chain processing system 500 (operations 616, 716), the filtered data is processed (operations 616, 716), and the processed data is stored in one or more blocks of the special price agreement blockchain (operations 620, 724). In one example embodiment, the inventory and sales data are loaded in one or more additional blocks of at least one of the special price agreement blockchain and the transaction ledger blockchain (operations 620, 724, 928).

[0171] In one example embodiment, a registration application to register with the supply chain processing system 500 is obtained from a registration requester (operation 1004), a registration blockchain is created by the registration computerized, code-implemented contract 504 based on the registration application submitted by the registration requester (operation 1008), the registration application is pre-processed to format the registration data of the registration application for input into the registration database and participant directory of the supply chain processing system 500 (operation 1020), the registration database and the participant directory are updated to reflect the registration of the registration requester (operation 1024), and the acceptance of the registration request is confirmed to the registration requester via the registration blockchain (operation 1028). In one example embodiment, it is determined whether the registration data required by the registration computerized, code-implemented contract 504 is verified and exists (decision box 1012), and in response to determining that the registration data is not verified and does not exist, at least one of invalid data and missing data is requested and obtained (operation 1016). In one example embodiment, the participant directory includes a proper subset of the registered participants.

[0172] In one aspect, an exemplary method includes the following operations: instantiating one or more transaction ledger blockchains supporting multiple entities (operations 610, 710); accessing an enterprise system of one of the multiple entities to retrieve special price agreement participant data designated for blockchain input (operations 604, 704); verifying the accessed data designated for the blockchain input (operations 608, 708); identifying a transaction ledger blockchain among the one or more transaction ledger blockchains for inputting the verified data (operations 610, 710); preprocessing the verified data, the preprocessing including formatting the verified data for input into a ledger block of the identified transaction ledger blockchain having a timestamp corresponding to the accessed data (operations 616, 716); and populating the preprocessed data into the ledger block of the identified transaction ledger blockchain (operations 620, 724).

[0173] In an example embodiment, the special price agreement participant data includes a sales history of a given SKU and an identification of existing inventory corresponding to the given SKU for use by the inventory allocation and cost system to allocate distributor inventory. In an example embodiment, the additional ledger block is at least one of: populated periodically, populated when an item is sold from the inventory of the distributor 212, and populated when a sale is executed corresponding to a purchase order. In an example embodiment, the identified transaction ledger blockchain is at least one of a blockchain corresponding to a special price agreement covering the special price agreement participant data, a blockchain dedicated to a manufacturer associated with the special price agreement participant data, a blockchain dedicated to a distributor associated with the special price agreement participant data, a blockchain dedicated to a group of manufacturers, and a blockchain dedicated to a group of distributors. In an example embodiment, pre-processing further includes separating data referencing items corresponding to multiple entities according to corresponding entities, and wherein populating the pre-processed data into the ledger block populates the separated data into corresponding separated blocks, each separated block corresponding to one of the multiple entities (operations 616, 716). In one example embodiment, inventory metadata is generated based on at least one of the purchase order information and the sales order information, the inventory metadata indicating the size of each inventory box and the inbound cost of each inventory box, and inventory blocks are created based on the inventory metadata (operation 928).

[0174] In one aspect, a non-transitory computer-readable medium includes computer-executable instructions that, when executed by a computer, cause the computer to perform a method for processing rebates on a supply chain processing system based on a blockchain architecture, the method comprising the following operations: instantiating an inventory blockchain for multiple entities supporting the supply chain processing system 500 (operation 902); determining, in response to changes in a ledger block of a transaction ledger blockchain, an existing inventory of a given item identifier based on a reported sales history and an inventory block, the inventory block including inventory metadata describing a time snapshot of the existing inventory (operation 904); determining a unit and cost allocation for the existing inventory using the inventory metadata (operation 905); The method comprises the steps of: determining a real acquisition cost for the given item identifier based on the inventory metadata of the inventory block and the determined allocation (operation 916); determining a special price agreement cost based on a special price agreement block, the special price agreement block including terms of a special price agreement (operation 920); calculating a rebate amount corresponding to the given item identifier based on the special price agreement cost and the real acquisition cost (operation 920); determining a total rebate based on the rebate amount and sales quantity corresponding to the given item identifier (operation 920); generating another inventory block based on the revised inventory (operation 928); and updating a rebate blockchain based on the determined total rebate (operation 928).

[0175] In one aspect, a non-transitory computer-readable medium includes computer-executable instructions that, when executed by a computer, cause the computer to perform the following method: instantiating one or more transaction ledger blockchains supporting multiple entities (operations 610, 710); accessing an enterprise system of one of the multiple entities to retrieve special price agreement participant data designated for blockchain input (operations 604, 704); verifying the accessed data designated for the blockchain input (operations 608, 708); identifying a transaction ledger blockchain among the one or more transaction ledger blockchains for inputting the verified data (operations 610, 710); pre-processing the verified data, the pre-processing including formatting the verified data for input into a ledger block of the identified transaction ledger blockchain having a timestamp corresponding to the accessed data (operations 616, 716); and populating the pre-processed data into the ledger block of the identified transaction ledger blockchain (operations 620, 724).

[0176] In one aspect, a device includes a memory and at least one processor coupled to the memory, and is operable to perform a method for processing rebates on a supply chain processing system based on a blockchain architecture, the method comprising the following operations: instantiating an inventory blockchain for multiple entities supporting the supply chain processing system 500 (operation 902); determining, in response to changes in a ledger block of a transaction ledger blockchain, on-hand inventory for a given item identifier based on reported sales history and an inventory block, the inventory block including inventory metadata describing a time snapshot of the on-hand inventory (operation 904); determining units and cost allocations for the on-hand inventory using the inventory metadata (operation 908); determining, based on The inventory metadata of the inventory block and the determined allocation determine the actual acquisition cost of the given item identifier (operation 916); determine the special price agreement cost based on the special price agreement block, the special price agreement block including the terms of the special price agreement (operation 920); calculate the rebate amount corresponding to the given item identifier based on the special price agreement cost and the actual acquisition cost (operation 920); determine the total rebate based on the rebate amount and sales quantity corresponding to the given item identifier (operation 920); generate another inventory block based on the revised inventory (operation 928); and update the rebate blockchain based on the determined total rebate (operation 928).

[0177] In one aspect, an apparatus includes a memory and at least one processor coupled to the memory, and is operable to perform operations including: instantiating one or more transaction ledger blockchains supporting multiple entities (operations 610, 710); accessing an enterprise system of one of the multiple entities to retrieve special price agreement participant data designated for blockchain input (operations 604, 704); verifying the accessed data designated for the blockchain input (operations 608, 708); identifying a transaction ledger blockchain among the one or more transaction ledger blockchains for inputting the verified data (operations 610, 710); preprocessing the verified data, the preprocessing including formatting the verified data for input into a ledger block of the identified transaction ledger blockchain having a timestamp corresponding to the accessed data (operations 616, 716); and populating the preprocessed data into the ledger block of the identified transaction ledger blockchain (operations 620, 724).

[0178] One or more embodiments may utilize software running on a computer. Fig.11 , this implementation may employ, for example, a processor 1102, a memory 1104, and an input / output interface formed, for example, by a display 1106 and a keyboard 1108. The term "processor" as used herein is intended to include any processing device, such as, for example, a processing device including a CPU (central processing unit) and / or other forms of processing circuitry. In addition, the term "processor" may refer to more than one individual processor. The term "memory" is intended to include memory associated with a processor or CPU, such as, for example, RAM (random access memory), ROM (read only memory), fixed memory devices (such as hard disk drives), removable memory devices (such as floppy disks), flash memory, and the like. In addition, the phrase "input / output interface" as used herein is intended to include, for example, one or more mechanisms for inputting data to the processing unit (e.g., a mouse), and one or more mechanisms for providing results associated with the processing unit (e.g., a printer). The processor 1102, the memory 1104, and the input / output interface (e.g., a display 1106 and a keyboard 1108) may be interconnected, for example, via a bus 1110 as part of a data processing unit 1112. Suitable interconnects (e.g., via bus 1110) may also be provided to a network interface 1114 (e.g., a network card that may be provided to interface with a computer network) and a media interface 1116 (e.g., a disk or CD-ROM drive that may be provided to interface with media 1118 (a USB port that interfaces with a so-called "thumb" drive is another example)).

[0179] Thus, as described herein, computer software including instructions or codes for performing the methods of the present invention may be stored in one or more associated memory devices (e.g., ROM, fixed or removable memory), and when ready for use, partially or fully loaded (e.g., loaded into RAM) and executed by the CPU. Such software may include, but is not limited to, firmware, resident software, microcode, and the like.

[0180] As used herein, including in the claims, a "server" includes a physical data processing system (e.g., a computer) running a server program. Fig.11 It should be understood that this physical server may or may not include a display and keyboard.

[0181] It should be noted that any of the methods described herein may include the additional step of providing a system including different software modules embodied on a computer-readable storage medium; a module may include, for example, any or all of the elements depicted in the block diagrams and / or described herein. The method steps may then be performed using the different software modules and / or sub-modules of the system executed on one or more hardware processors 1102 as described above. Furthermore, a computer program product may include a computer-readable storage medium (e.g., tangible and non-transitory) having code adapted to be implemented to perform one or more method steps described herein, including providing the different software modules to the system.

[0182] In any case, it should be understood that the components described herein can be implemented in various forms of hardware, software, or a combination of hardware and software. Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), functional circuit systems, one or more appropriately programmed general-purpose digital computers with associated memory, and the like are all examples.

[0183] Given the teachings of the invention provided herein, one of ordinary skill in the art will be able to contemplate other implementations.

[0184] Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments and that various other changes and modifications may be made by those skilled in the art without departing from the scope or spirit of the invention.

Claims

1. A method for processing rebates on a supply chain processing system based on a blockchain architecture, comprising: Instantiating an inventory blockchain for a plurality of entities supporting the supply chain processing system; In response to a change in a ledger block of a transaction ledger blockchain, determining on-hand inventory for a given item identifier based on a reported sales history and an inventory block including inventory metadata describing a time snapshot of the on-hand inventory; Determining unit and cost allocations for the on-hand inventory using the inventory metadata; determining a true acquisition cost for the given item identifier based on the inventory metadata and the determined allocation for the inventory block; determining a special price agreement cost based on a special price agreement block, the special price agreement block including terms of the special price agreement; Calculating a rebate amount corresponding to the given item identifier based on the special price agreement cost and the actual acquisition cost; determining a total rebate based on the rebate amount and the sales quantity corresponding to the given item identifier; generating another inventory block based on the revised inventory; and The rebate blockchain is updated based on the determined total rebate.

2. The method of claim 1, wherein said determining said allocation of said on-hand inventory further comprises merging said reported sales history with purchase orders from manufacturers / suppliers based on a first-in, first-out method.

3. The method according to claim 1, further comprising: Compare the stated total rebate with the submitted rebate claim; and The rebate calculation steps between the total rebate and the submitted rebate claim are reported via a block of the rebate blockchain.

4. The method according to claim 1, further comprising: Repeating one or more of the determining and calculating operations; detecting one or more deviations from said processing that require suspension of the rebate; and The deviation is reported via a block of the rebate blockchain.

5. The method according to claim 1, further comprising: determining whether the special price agreement is valid on a given order date by checking the original special price agreement and any subsequent changes to the special price agreement as defined in the special price agreement blockchain; determining whether at least one of the end customer and the branch of distributor 212 is listed on the special price agreement based on the given order date; determining whether a SKU is covered by the special price agreement on the given order date; determining the validity of at least one of an agreed-upon multiplier and a net price for the SKU on the given order date; determining a list price for the stock keeping unit corresponding to the given order date; and At least one of an inbound cost and a true acquisition cost for the distributor on the given order date is determined.

6. The method according to claim 1, further comprising: The calculation steps of accessing the rebate process via the rebate blockchain; Generate rebate claim reports; and The rebate claim report is provided via a computerized rebate processing, code implementation contract.

7. The method according to claim 1, further comprising: Obtaining a request to initiate the special price agreement from a special price agreement requester; initiating, via a special price agreement, a computerized, code-implemented contract to establish said special price agreement with said special price agreement blockchain corresponding to said special price agreement; determining, via said special price agreement initiation computerized, code implemented contract, whether said special price agreement requestor has omitted information required by said special price agreement initiation computerized, code implemented contract; Adding a block to the special price agreement blockchain, the block including requester information; obtaining special price agreement approval from a special price agreement requestee via an approval block of the blockchain; and Adding a special price agreement terms block to the special price agreement blockchain.

8. The method of claim 7, further comprising obtaining an assigned special price agreement reference number from the special price agreement requestee and wherein the special price agreement blockchain includes the assigned special price agreement reference number.

9. The method of claim 7, wherein the requestor information includes terms of a special price agreement offer.

10. The method according to claim 7, further comprising: obtaining a counter-offer from the special price agreement requestee; and An acceptance of the counteroffer by the special price agreement requester is obtained.

11. The method of claim 1 , further comprising accessing the ledger data via a corresponding blockchain; Generate ledger reports; and The ledger report is provided via a computerized, code-implemented contract initiated via the special price agreement.

12. The method of claim 1, further comprising controlling access by a designated entity to designated data of at least one of the rebate blockchain and the transaction ledger blockchain based on one or more access rules.

13. A method according to claim 12, wherein at least one access rule is based on one or more of the following: enabling access for all entities specified on the corresponding special price agreement, enabling access for all entities specified in an access profile, blocking access for all entities in a list of enabled entities that are not in the access profile, and blocking access for all entities that are not in the corresponding special price agreement.

14. The method according to claim 7, further comprising: Searching the special price agreement blockchain for a block including the original terms of the special price agreement and the modified terms of the special price agreement; obtaining the original terms and the modified terms corresponding to the searched block, generating a summary of the terms of said special price agreement effective as of a specified date, said summary of terms excluding expiration terms of said special price agreement; and Initiating a computerized, code-implemented contract providing said overview of terms via said special price agreement.

15. The method of claim 1, further comprising: Parsing special file-based pricing agreements in non-blockchain formats; filtering the data in the non-blockchain format according to the terms of the inventory allocation and cost system of the supply chain processing system; processing the filtered data; and The processed data is stored in one or more blocks of the special price protocol blockchain.

16. The method of claim 15, further comprising loading inventory and sales data into one or more additional blocks of at least one of the special price agreement blockchain and the transaction ledger blockchain.

17. The method of claim 1, further comprising: obtaining a registration application for registering with the supply chain processing system from a registration requester; creating, by a registry computerized, code-implemented contract, a registry blockchain based on said registration application submitted by said registration requestor; pre-processing the registration application to format the registration data of the registration application for input into a registration database and a participant directory of the supply chain processing system; updating the registration database and the participant directory to reflect the registration of the registration requester; and Acceptance of the registration request is confirmed to the registration requestor via the registration blockchain.

18. The method according to claim 17, further comprising: Determine whether the registration data required for the said registration computerization and code implementation contract is verified and exists; and In response to determining that the registration data is not verified and does not exist, at least one of invalid data and missing data is requested and obtained.

19. The method of claim 17, wherein the participant directory includes a proper subset of registered participants.

20. A method comprising: Instantiating one or more transaction ledger blockchains supporting multiple entities; accessing an enterprise system of one of the plurality of entities to retrieve special price agreement participant data designated for blockchain input; verifying the accessed data designated for the blockchain input; identifying a transaction ledger blockchain of the one or more transaction ledger blockchains for inputting the verified data; preprocessing the verified data, the preprocessing comprising formatting the verified data for input into a ledger block of the identified transaction ledger blockchain having a timestamp corresponding to the accessed data; and The pre-processed data is populated into the ledger block of the identified transaction ledger blockchain.

21. A method according to claim 20, wherein the special price agreement participant data includes the sales history of a given inventory holding unit and an identification of the existing inventory corresponding to the given inventory holding unit for use by the inventory allocation and cost system to allocate distributor inventory.

22. The method of claim 20, wherein the additional ledger blocks are at least one of: populated periodically, populated when items are sold from a distributor's inventory, and populated upon an executed sale corresponding to a purchase order.

23. A method according to claim 20, wherein the identified transaction ledger blockchain is at least one of a blockchain corresponding to a special price agreement covering the special price agreement participant data, a blockchain dedicated to a manufacturer associated with the special price agreement participant data, a blockchain dedicated to a distributor associated with the special price agreement participant data, a blockchain dedicated to a group of manufacturers, and a blockchain dedicated to a group of distributors.

24. A method according to claim 20, wherein the preprocessing further includes separating data referencing items corresponding to multiple entities according to the corresponding entities, and wherein the populating the preprocessed data into the ledger block populates the separated data into corresponding separated blocks, each separated block corresponding to one of the multiple entities.

25. The method of claim 20, further comprising: generating inventory metadata based on at least one of the purchase order information and the sales order information, the inventory metadata indicating a size of each inventory box and a warehousing cost of each inventory box; and An inventory block is created based on the inventory metadata.

26. A non-transitory computer-readable medium comprising computer-executable instructions, which when executed by a computer cause the computer to perform a method for processing rebates on a supply chain processing system based on a blockchain architecture, the method comprising the following operations: Instantiating an inventory blockchain for a plurality of entities supporting the supply chain processing system; In response to a change in a ledger block of a transaction ledger blockchain, determining on-hand inventory for a given item identifier based on a reported sales history and an inventory block including inventory metadata describing a time snapshot of the on-hand inventory; Determining unit and cost allocations for the on-hand inventory using the inventory metadata; determining a true acquisition cost for the given item identifier based on the inventory metadata and the determined allocation for the inventory block; determining a special price agreement cost based on a special price agreement block, the SPA block including terms of the special price agreement; Calculating a rebate amount corresponding to the given item identifier based on the special price agreement cost and the actual acquisition cost; determining a total rebate based on the rebate amount and the sales quantity corresponding to the given item identifier; generating another inventory block based on the revised inventory; and The rebate blockchain is updated based on the determined total rebate.

27. A non-transitory computer-readable medium comprising computer-executable instructions which, when executed by a computer, cause the computer to perform the following method: Instantiating one or more transaction ledger blockchains supporting multiple entities; accessing an enterprise system of one of the plurality of entities to retrieve special price agreement participant data designated for blockchain input; verifying the accessed data designated for the blockchain input; identifying a transaction ledger blockchain of the one or more transaction ledger blockchains for inputting the verified data; preprocessing the verified data, the preprocessing comprising formatting the verified data for input into a ledger block of the identified transaction ledger blockchain having a timestamp corresponding to the accessed data; and The pre-processed data is populated into the ledger block of the identified transaction ledger blockchain.

28. An apparatus comprising: Memory; and At least one processor is coupled to the memory and is operable to execute a method for processing rebates on a supply chain processing system based on a blockchain architecture, the method comprising the following operations: Instantiating an inventory blockchain for a plurality of entities supporting the supply chain processing system; In response to a change in a ledger block of a transaction ledger blockchain, determining on-hand inventory for a given item identifier based on a reported sales history and an inventory block including inventory metadata describing a time snapshot of the on-hand inventory; Determining unit and cost allocations for the on-hand inventory using the inventory metadata; determining a true acquisition cost for the given item identifier based on the inventory metadata and the determined allocation for the inventory block; determining a special price agreement cost based on a special price agreement block, the SPA block including terms of the special price agreement; Calculating a rebate amount corresponding to the given item identifier based on the special price agreement cost and the actual acquisition cost; determining a total rebate based on the rebate amount and the sales quantity corresponding to the given item identifier; generating another inventory block based on the revised inventory; and The rebate blockchain is updated based on the determined total rebate.

29. An apparatus comprising: Memory; and At least one processor coupled to the memory and operable to perform operations including: Instantiating one or more transaction ledger blockchains supporting multiple entities; accessing an enterprise system of one of the plurality of entities to retrieve special price agreement participant data designated for blockchain input; verifying the accessed data designated for the blockchain input; identifying a transaction ledger blockchain of the one or more transaction ledger blockchains for inputting the verified data; preprocessing the verified data, the preprocessing comprising formatting the verified data for input into a ledger block of the identified transaction ledger blockchain having a timestamp corresponding to the accessed data; and The pre-processed data is populated into the ledger block of the identified transaction ledger blockchain.

Images