Difference between revisions of "Purchase order"

From ZUGSEIL Wiki
Jump to navigation Jump to search
(Created page with "Once a buyer and a seller have finalized their negotiations in the so called offer phase a legally binding contract is created between them. From such a contract one or multiple pairs of '''procurement orders''' and customer orders can be spawned. The procurement order is the business object on the customer side, the customer order is the business object on the vendor side. They are bound together through the b-op network, i...")
 
 
(33 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Once a buyer and a seller have finalized their negotiations in the so called [[Procurement Offer Phase|offer phase]] a legally binding contract is created between them. From such a contract one or multiple pairs of '''procurement orders''' and [[Customer Order|customer orders]] can be spawned. The procurement order is the business object on the customer side, the customer order is the business object on the vendor side. They are bound together through the b-op network, if both participants have their [[Digital|b-op digitals]] and they share enough trust.
[[File:Purchasing Process.png|thumb|Purchasing order contracting process]]A purchase order is a '''one sided declaration''' of a customer towards a supplier, which requires a contract to exist to be legally binding for the customer and the supplier side.    


If there is not an existing contract that governs the relationship between buyer and seller, the purchase order can be used in place of a contract. This offers legal protection for both buyer and seller. Each purchase order is assigned it’s own unique number, known as the purchase order number.  
== Interaction with suppliers / Contracting ==
Before a purchase order is created by the customer, the contracting phase is started, which means that customer and suppliers exchange offers until a mutual agreement is found ([[Purchasing contract|purchase contract]]).


There are various types of purchase orders, the most common are standard purchase orders and blanket purchase orders. Standard purchase orders cover a specific purchase with no recurrence. Blanket purchase orders are used to commit buyers to purchase products or services on an ongoing basis until a certain threshold is reached.
<u>Purchase order, created with contract reference (master contract based purchase order)</u>


== Purchase Contract Basics ==
Once this [[Purchasing contract|purchase contract]] exists, a purchase order can be filed from the customer to the supplier with a reference to this contract. In this case, the supplier's digital only checks if the [[Customer Order|customer order]] positions and conditions adhere to the contract and can auto-approve it.
All purchase contracts share certain common requirements, and should ideally contain as much detail as possible. That’s because once a purchase contract is formally accepted by a vendor, it becomes a ''legally binding agreement'' between the vendor and the purchaser. In general, purchase contracts should contain:


* Detailed and complete vendor information
* A detailed description and quantity of goods or services to be purchased
* Quality specifications
* Full pricing information as agreed upon between buyer and seller side
* Delivery terms and conditions
* Payment terms and conditions


== Purchase Contract Varieties ==
Different types of purchase orders fulfill specific purposes.


=== Standard Purchase Contract ===
<u>Purchase order, created without contract reference (Individual purchase order)</u>
When you are making a one-time purchase create a standard purchase order. It’s the most common type of purchase order, and the simplest. Basic purchases, like replenishing office supplies, are of this type.


=== Planned Purchase Contracts ===
Purchase orders can also be filed to the supplier without a contract reference. In this case the positions and conditions of the purchase contract are considered to bear a purchasing contract proposal. The purchase order is showing a [[Customer Order|customer order]] on the supplier side, which is subject to approval on the customer side. Once approved by the supplier, the system automatically forms a purchasing contract and links the purchase order and the customer order to this contract.
When you are partnering with a single supplier as your sole source of specific goods or services, this type is right. You can create a single contract, and then schedule purchase orders released during the timespan of the contract. This contract type has the benefits, that you and the vendor can plan regarding liquidity demand (you) and stock demand (vendor)


=== Blanket Purchase Orders ===
For more information please read up the [[Dev:Purchase order processing|purchase order processing]] article.
If you find yourself with a need to purchase a specific good or service, but you’re not sure about your precise time frame or quantities required, use a blanket PO. Also known as ''standing purchase orders'', blanket orders have a limited shelf life and cover a specific period of time. They’re useful in locking down pricing terms with a given vendor before making purchases from them. Placing a ''blanket release'' against the blanket purchase order will create a binding purchasing agreement, and they can be encumbered as required by the terms of the blanket or standard purchase order.


=== Contract Purchase Orders ===
== Purchase orders in the b-op network ==
The “contract” in the name of this purchase order is a hint at its true nature. Rather than a binding legal agreement for a specific purchase, contract purchase orders create a high-level, ''long-term'' agreement. This legally binding contract spells out in meticulous detail the exact terms, pricing, and conditions of all purchases made from the supplier by your company, but not specific purchases themselves.
When transmitted to a supplier by the [[Dev:B-Op supply chain network connector|B-Op supply chain network connector]], a purchase order is transformed within the b-op network to a [[Customer Order|customer order]].  


These POs have no expiration date, and the framework itself lets you issue standard POs that conform to the terms and conditions established within the contract purchase order. Automation is a boon to this process, as it seamlessly connects financial and legal information and populates fields as required to ensure compliance by both parties for every regular purchase order placed. Encumbrance can be handled more easily as well, since all parties involved will have transparent access to financial and budget data for individual transactions and total spend.
ZUGSEIL software also supports non b-op based supplier relationships. In this case, the [[Dev:B-Op supply chain network connector|B-Op supply chain network connector]] always assumes that the supplier accepts the order and creates a contract and the expected deliveries and shipments as proposed by the customer.  
{| class="wikitable"
|'''ASPECT'''
|'''STANDARD'''
|'''PLANNED'''
|'''BLANKET'''
|'''CONTRACT'''
|-
|Established Terms & Conditions
|YES
|YES
|YES
|YES
|-
|Goods & Services Specified
|YES
|YES
|YES
|NO
|-
|Pricing Specified
|YES
|YES
|POSSIBLE
|NO
|-
|Quantities Specified
|YES
|YES
|NO
|NO
|-
|Account
|YES
|YES
|NO
|NO
|-
|Established Delivery Schedule
|YES
|POSSIBLE
|NO
|NO
|-
|Potentially Encumbered
|YES
|YES
|NO
|NO
|-
|Potentially Encumbered Releases
|N/A
|YES
|YES
|N/A
|}


== Purchase Orders Power Productivity and Profitability ==
== Structure ==
Rejecting the chaos of rogue spend and unrecorded financial data is the first step out of the wilderness and into the realm of civilized business. Understanding the types of purchase orders available, and putting them to their best use, can help your company spend smarter, reduce waste, and ensure you receive the goods and services you need to thrive, at the prices and terms you expect—and deserve.
Each purchase order has the same structure containing a header and one or multiple positions. The '''header''' holds information, which regulates general information like target supplier and holds status information. On '''position''' and '''subposition''' level the information on the products to purchase and the requried [[Delivery option|delivery options]] are defined.  
 
For more information please read up the [[Dev:Purchase order processing|purchase order processing]] article.
== Related Articles ==
 
* [[Procure-To-Pay]]
* [[Purchasing contract]]
 
== Related development articles ==
* [[Dev:Purchase order processing]] - Developer information page on purchase order
 
 
[[Category:Glossary]]

Latest revision as of 11:40, 6 July 2024

Purchasing order contracting process

A purchase order is a one sided declaration of a customer towards a supplier, which requires a contract to exist to be legally binding for the customer and the supplier side.

Interaction with suppliers / Contracting

Before a purchase order is created by the customer, the contracting phase is started, which means that customer and suppliers exchange offers until a mutual agreement is found (purchase contract).

Purchase order, created with contract reference (master contract based purchase order)

Once this purchase contract exists, a purchase order can be filed from the customer to the supplier with a reference to this contract. In this case, the supplier's digital only checks if the customer order positions and conditions adhere to the contract and can auto-approve it.


Purchase order, created without contract reference (Individual purchase order)

Purchase orders can also be filed to the supplier without a contract reference. In this case the positions and conditions of the purchase contract are considered to bear a purchasing contract proposal. The purchase order is showing a customer order on the supplier side, which is subject to approval on the customer side. Once approved by the supplier, the system automatically forms a purchasing contract and links the purchase order and the customer order to this contract.

For more information please read up the purchase order processing article.

Purchase orders in the b-op network

When transmitted to a supplier by the B-Op supply chain network connector, a purchase order is transformed within the b-op network to a customer order.

ZUGSEIL software also supports non b-op based supplier relationships. In this case, the B-Op supply chain network connector always assumes that the supplier accepts the order and creates a contract and the expected deliveries and shipments as proposed by the customer.

Structure

Each purchase order has the same structure containing a header and one or multiple positions. The header holds information, which regulates general information like target supplier and holds status information. On position and subposition level the information on the products to purchase and the requried delivery options are defined.

For more information please read up the purchase order processing article.

Related Articles

Related development articles