Platform API Endpoint: Procure And Send Purchase Order To Supplier

Before reading on please ensure that you have understood the following topics:

• Getting Started/Overview
• Personal Signing Up To SQUIZZ.com
• Registering An Organisation
• Organisational Data
• Organisation Settings
• Connecting Organisations
• Trading Tokens and Pricing
• Connecting Business Systems
• Integrate Software Into SQUIZZ.com
• Platform API

The endpoint is used by a customer organisation to push one or more purchase orders into the platform and have it procured by a designated supplier organisation. "Procure" means for the customer organisation to find and buy goods/services off the supplying organisation. This endpoint allows a customer organisation to automate purchasing off selected supplier organisations registered in the platform. Additionally it helps a supplier organisations to automate selling to existing customer organisations.

The endpoint will look through each purchase order given to it and try to find matching products that the chosen supplying organisation sells. Once all ordered products have been matched then the endpoint will price each product based on the quantities, relationship and customer account that the supplier organisation has assigned to the customer organisation. Only if all products in the purchase orders have been priced will the endpoint then create one or more sales orders for the supplier organisation and have the sales orders be marked as submitted for processing by the supplier organisation. The endpoint will then return each of the sales orders that were created, allowing the customer organisation to know the costs of the sales order and be able to update the purchase order based on the sales order totals.

Optionally the endpoint may also forward on the generated sales order to the supplier's nominated freight provider's ssytem, from where it may create a consignment note or other freight artifacts.

Endpoint Requirements

To use this endpoint the following conditions need to be met:

• The customer organisation needs to be connected to the supplier organisation on the SQUIZZ.com platform.
• The supplier organisation's Trading Status must be set to Fully Trading or Selling Only.
• The customer organisation's Trading Status must be set to Fully Trading or Buying Only.
• The supplier organisation needs to have assigned at least one customer account to the customer organisation
• The assigned customer account needs to have an "On Account" payment type set, allowing the customer organisation to pay for the ordered products at a later date, based on agreed terms with the supplier organisation.
• The assigned customer account must be active and allow orders to be created against it (not on hold or outside terms and limits).
• Every product in the purchase orders must match to the supplying organisation's products based on either of the following:
  • The customer's product code matches supplier's product code
  • The customer's product is assigned to an alternate code that matches the supplier's product code, and the alternate codes have been previously imported into the platform by the customer organisation.
  • The customer's product has previously been mapped to the supplier's product based on a previous order being submitted, either through this endpoint, or by a person using the Order Procurement feature within the platform.
• The supplier organisation is able to price all matched products in the purchase orders.
• The supplier organisation has enough trading tokens in the platform for the sales order transaction.

The purchase orders being imported must be placed into the Body of the HTTP request in the form of a conforming to one of the following:

• JSON purchase order document in the Ecommerce Standards Document standard.
• XML purchase order document in the xCBL version 3.0 standard (earlier or later versions may have limited support)
• XML purchase order document in the cXML version 1.2 standard (earlier or later versions may have limited support) 
• Text based 850 purchase order document in the ANSI x12 standard (earlier or later versions may have limited support)

Before using this endpoint we recommend that you understand what the Ecommerce Standards Documents are and how you can convert purchase order data from your system into the standards document, or otherwise understand creating purchase orders documents in either the xCBL or cXML standards. It is highly recommended that any purchase order data uploaded using this endpoint be compressed using the GZIP compression algorithm. Note that there are trading token costs to the supplying organisation to have the sales orders created by default, or otherwise the customer organisation may need to pay the trading tokens cost if nominated by the supplying organisation. The relevant organisation must have enough tokens to allow to do. See the Trading Tokens and Pricing  page for more details. The endpoint can be used without creating a session first, but then requires the customer organisation's API credentials to be passed across. It is recommended to create a session first before using this endpoint when multiple purchase orders need to be passed across, since it will reduce the amount of time required to authenticate each request.

HTTP Request

Example Raw HTTP Request

HTTP Response

HTTP Response Example:

When making a HTTP request to the API endpoint, in the body of the HTTP request a Purchase Order Ecommerce Standards Document (ESD) needs to be placed in its serialised JSON form, containing one or more purchase order records within it.

Within the retrieved Purchase Order JSON document, each purchase order record is conforms to the Order Purchase ESD Record format. The following table shows the record fields that this endpoint in the SQUIZZ.com API supports and reads from:

Purchase Order Line Records

For each Purchase Order Record in the lines property it may store an array of Purchase Order Line Records, with each record specifying one type of product/goods that is to be ordered and a chosen quantity.

Each purchase order line record is conforms to the Order Purchase Line ESD Record format. The following table shows the line record fields that this endpoint in the SQUIZZ.com API supports and reads from:

The Procure And Send Purchase Order To Supplier API endpoint supports receiving a purchase order in the cXML data standard. This may be required if the customer's system that is sending the purchase order only supports the cXML standard. Although it's not recommended to use this standard since has several limitations compared to the Ecommernce Standard Documents standard for Purchase Orders, the endpoint does support cXML purchase orders if required.

When calling endpoint with a HTTP request, if the "convert_from_document" parameter is set to "CXML1.2", then the body of the request will need to provide XML data that's formatted in a cXML purchase order (as shown below). The API endpoint will then attempt to parse the XML data, and internally convert it to a Purchase Order record in the Ecommerce Standard's Document format. Below are the field mappings it uses during this conversion process between standards. It's recommended to provide version 1.2 of the cXML purchase order, however future or past versions may successfully be processed if the required field names occur in the document. In the future other versions of the standards may be explicitly be supported by default values being set for the "convert_from_document" parameter.

The API endpoint optionally supports returning a cXML Response within the HTTP response body, if the "response_data_type" parameter is set in the request to the value "CXML1.2". Do note that only limited information can be provided if using this return type.

Example Raw HTTP Request

cXML1.2 Purchase Order Data Mappings To ESD Purchase Order Record

Below are the data mappings that are used by the API endpoint to convert a xCML 1.2 formatted purchase order to purchase order in the Ecommerce Standards Document. Note that XPath and JSON Path notation is used to show that nested field mappings.

HTTP Response

HTTP Response Example With cXML 1.2 Success Response:

HTTP Response Example With cXML 1.2 Fail Response:

The Procure And Send Purchase Order To Supplier API endpoint supports receiving a purchase order in the ANSI x12 data standard. This may be required if the customer's system that is sending the purchase order only supports the ANSI x12 standard. Although it's not recommended to use this standard since has several limitations compared to the Ecommernce Standard Documents standard for Purchase Orders, the endpoint does support ANSI x12 purchase orders if required.

When calling endpoint with a HTTP request, if the "convert_from_document" parameter is set to "ANSIX12", then the body of the request will need to provide plain text data that's formatted in a ANSI x12 purchase order 850 EDI message standard (as shown below). The API endpoint will then attempt to parse the textual data, and internally convert it to a Purchase Order record in the Ecommerce Standard's Document format. Below are the field mappings it uses during this conversion process between standards. It's recommended to provide the latest version ANSI x12 850 EDI message standard, however future or past versions may successfully be processed if the required field names occur in the document. In the future other versions of the standards may be explicitly be supported by default values being set for the "convert_from_document" parameter.

Example Raw HTTP Request

ANSI x12 - 805 Purchase Order Data Mappings To ESD Purchase Order Record

Below are the data mappings that are used by the API endpoint to convert a ANSI x12 formatted purchase order in the 805 message format to purchase order in the Ecommerce Standards Document.

Can partial quantities be ordered of a supplier's product if not all of the quantities specified in the purchase order are in stock?

Whether partial available quantities of a supplier organisation's products can be ordered through the endpoint is based on if the supplier organisation allows out of stock products to be ordered or not. The endpoint can allow orders to go through even when a supplier's product is out of stock, but this can only happen if the supplier has given permission for out-of-stock products to be ordered, known as back ordering. 
If the supplier allows back-ordering for each of its products in an order, then it doesn't matter if the products are in stock or not, the order will still go through. If the supplier does not allow back-ordering for a product, and the quantity of the product within the purchase order is greater than the available stock amount then the endpoint would return an error and not process the order (it would not allow a partial quantity to be ordered).
If this second scenario was enforced by the supplier then it would be recommended to call the "Retrieve Organisation Data" endpoint first and get the available stock quantities for the products you wish to order, that way you could check if there was enough products in stock before sending a purchase order, otherwise advise the purchasing person of the out-of-stock products, and to seek alternative options such as ordering from a different supplier or wait to products are back in stock again. 

Supplier organisations can set up the permissions for the products that can be back ordered through the use of Data Sharing Policies. Policies can be set to cover the entire customer base, or be assigned to specific customer organisations and people allowing targeted customers to order out of stocked products or not. These same policies also give permission if products can be ordered at all for targeted customers.

Is there an ability to find out the products in a purchase order sent to the endpoint that had no stock available?

Yes, if the procurement endpoint finds a supplier product that is out of stock then the endpoint will return the SERVER_ERROR_ORDER_MAPPED_PRODUCT_STOCK_NOT_AVAILABLE result code, as well as in the "orders_with_unstocked_lines" attribute the index of the lines in the purchase order that contained the unmapped/out of stock products. 

When this error occurs a message could be returned to your user, such as "For purchase order X, lines 2,3 and 5 could not be matched up to the supplier's products because the products are out of stock.". You can determine the purchase orders lines that were out of stock by looking at the "configs.orders_with_unstocked_lines" attribute returned by the endpoint that specifies the index of the purchase orders and lines that were a problem.

When a purchase order is sent to the endpoint if one line in the order is unmapped or unpriced will the order still get processed?

No, the endpoint will not be able to process a purchase order and convert it into a supplier's sales order if one or more product lines in the purchase order cannot be mapped or priced to supplier's product. This ensures that supplier organisations only receive accurate and fully qualified orders, allowing for full automation in receiving the order and dispatching the ordered goods and services.

When calling the endpoint and a Product Not Mapped (matched to a supplier's product) or Product Price Not Found error occurs, what should my software do?

If your software calls the endpoint and it returns either SERVER_ERROR_ORDER_PRODUCT_NOT_MAPPED, SERVER_ERROR_ORDER_MAPPED_PRODUCT_STOCK_NOT_AVAILABLE or SERVER_ERROR_ORDER_MAPPED_PRODUCT_PRICE_NOT_FOUND result codes then it indicates that no product from the supplier organisation was able to found, priced, in stock, or able to be purchased. When this occurs there are a number of options that your software could do. The simplest option would be to raise the error with the person who is in charge of purchasing and advise them of errors with the lines. That person could then do the following:

• Enter a different product code to match the supplier's product.
• Choose a different product to purchase off the supplier.
• Remove the line from the purchase order and choose not to purchase the product.
• For stock issues reduce the quantity of the product requesting to be ordered.
• Contact the supplier organisation and determine why a product cannot be purchased (it could be out of stock, no longer stocked, or the supplier is unwilling to sell the product any more).

Alternatively your software could detect when there's an invalid line and make decisions of its own. It could remove the problematic/unmapped line from the purchase order and try to submit it again. It could put the purchase order aside and raise the issues to a purchasing person to fix up at a later date. It could reassign the problematic purchase order lines to a different supplier (if multiple suppliers exist).
The best option really depends on how a business wishes to handle the exceptional circumstance where the products they want to purchase cannot be found against the supplier, or are unavailable for purchasing.