Aggregated Procurement Ecosystem

In an aggregated procurement scenario the cycle is somewhat different. First of all, the procurement life cycle involves 3 parties, namely (1) the buyer, (2) the aggregator (procurement broker), and (3) the supplier (the rationale for this changed model is described in the section titled About Aggregated Procurement). In other words, the classic procurement cycle is extended with the aggregator acting as an intermediary between the buyer and supplier, which adds a few extra steps to the cycle, as explained next.

Instead of the buyer sending the order directly to the supplier, the order is sent to aggregator, where the buyer's PO serves as the source document for the aggregator's Sales Order; when the aggregator receives the buyer's PO, it uses it to create a Sales Order. The buyer thus 'buys' from the aggregator. On the basis of this Sales Order the aggregator now creates its own PO and forwards it to the supplier. Since the aggregator does not keep stock it has to procure the goods from the supplier, hence the aggregator PO.

The aggregator's PO in turn serves as the source document for the supplier's Sales Order; when the supplier receives the aggregator's PO, it uses it to create a Sales Order. Goods are delivered (by the supplier), directly to the buyer, but the Supplier Invoice goes to the aggregator. The aggregator puts this invoice to book (in the General Ledger of its accounting system), and in turn creates a Customer Invoice which it forwards to the buyer.

insert pic

Unlike traditional procurement systems, the big notable difference is the use of a single digital procurement object throughout the entire procurement cycle. In a traditional procurement arrangement each party creates its own transaction documents by referencing the source documents of the other party in the commercial exchange. In other words, the supplier would typically (manually) capture/create a SO based on the PO received from the buyer. In the aggregated procurement ecosystem the digital object is created only once, and is then electronically exchanged between the various parties involved. There is thus no recapturing of already-existing information - it is only adding additional facts to the existing object as it progresses through the procurement cycle.

Another distinguishing aspect of the aggregated procurement system is that it provides 2 options, or variations, of the procurement cycle, namely the Buyer-Originating Procurement Transaction Cycle and the Supplier-Originating Procurement Transaction Cycle. The Buyer-to-Aggregator-to-Supplier sequence as described previously (see above), follows the classic model (it extends the classic model with the aggregator being 'inserted' into the transaction cycle); this model is referred to as a Buyer-Originating Procurement Transaction. Because of certain realities this 'classic-style' procurement cycle is not always practical, thus requiring an alternative (second) approach, the Supplier-Originating Procurement Transaction.

In both cases the transaction is initiated by the buyer; the difference between the 2 lies in where the transaction is first captured (in other words, who created the initial digital procurement object first, the buyer or the supplier). Where the supplier creates the object it is referred to as a Supplier-originating Procurement Transaction; it basically means the buyer makes a telephonic/email request for goods from the supplier, upon which the supplier captures a sales order transaction (the procurement digital object thus starts its life as a Sales Order at the supplier side, which is then sent 'backward' to the other parties in the chain). So instead of the PO being 'pushed' from the buyer, the supplier's SO starts the cycle.

<insert pic>

More details about these steps are provided in the linked sections below:

NEXT:

Buyer-Originating Procurement Transaction

Supplier-Originating Procurement Transaction

Catalogs & Master Procurement Lists

Buyer Portal Functions

Supplier Portal Functions

Aggregator Portal Functions