Platform API Endpoint: Import Organisation Sales Order

Within the SQUIZZ.com Application Programming Interface (API) it contains an endpoint that allows one organisation using 3rd party software to talk to the SQUIZZ.com API, to import a sales order against one of the organisation's customer accounts. This allows the organisation to have sales orders be imported from selling systems, such as Ecommerce websites, online marketplaces, Customer Relationship Management (CRM) systems, Enterprise Resource Planning (ERP) systems, or spreadsheet applications or databases via the SQUIZZ.com Connector software, that are storing the sales order data, using this API endpoint to automate the ordering process. To use the API endpoint you will need to have knowledge in building software applications, and how to make requests over the internet to call RESTful web services, which the platform's API endpoint is based on.

Topics

Prerequisites

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

Overview

The endpoint is used by an organisation to push one or more sales orders into the SQUIZZ.com platform and have it validated, optionally repriced, any sales order rules applied against it, and send across to connected freight and business systems.

This endpoint can be used by an organisation to have its sales orders that are raised across multiple selling systems, such as Ecommerce websites, 3rd party marketplaces, customer relationship management (CRM) systems, and any other business systems that create orders, have those orders flow through the SQUIZZ.com platform, perform the neccessary order validation, then have those sales orders be feed back into the back end system(s) that are already integrated into the SQUIZZ.com platform. This may reduce the amount of complexity by using existing business system integrations, saving time and money, whilst providing more automation. If a sales order is successfully imported, the endpoint will return a sales order containing the most up to date and accurate order data, including pricing data, product data, surcharge data, location data, and payment data.

Note that this endpoint should not be used by customer organisations to push through orders, since otherwise this would give permission for customers to set any pricing they wished for the sales orders, as well as other security issues. Instead customer organisations should use the Procure And Send Purchase Order To Supplier endpoint to push through their purchase orders, that can be correctly validated and priced based on their relationship to the supplying organisation.

The endpoint will look through each sales order given to it and try to find matching products that the organisation sells, as well as matching up the surcharges, locations, payment types, and customer account. Once all order data have been matched then if required the endpoint will try to reprice each product based on the quantities, sell unit and customer account assigned to the order. If repricing is not required then the endpoint will check that all product lines and surcharges have had all pricing set. Only if all products and surcharges in the sales orders have been priced, and all other data matched will the endpoint then create one or more sales orders for the organisation and have the sales orders be marked as submitted for processing by the supplier organisation. Note that the sales order rules will also be run, allowing additional surcharges location data, and freight providers to be optionally applied to the order. If successfultThe endpoint will then return each of the sales orders that were created, allowing the requesting system to know the costs of the sales order and be able to update the sales order based on the sales order totals.

Endpoint Requirements

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

The organisation needs to have previously imported the customer accounts into SQUIZZ.com that sales orders are to be imported against
The organisation needs have previously imported taxcodes, sell units, products, price-levels, price-level pricing/customer account pricing into SQUIZZ.com, that allows products to be validated and priced for the sales order product lines.
If surcharges need to be applied against the order then the organisation needs to have previously imported surcharges into SQUIZZ.com. If the surcharges need to be repriced then sales order rules need to have been previously set up that specify when a surcharge should be applied against sales orders, and how the surcharges are priced.
The organisation needs to have previously imported payment types into SQUIZZ.com, based on the payment types set within the sales order.
The assigned customer account must be active and allow orders to be created against it
Every product in the sales orders must match the organisation's products based on either of the following:
- The sales order product line's Product Code must match either a previously imported product's Product Code
- The sales order product line's Key Product ID must match either a previously imported product's Product Code
If the imported sales order needs to be repriced then the pricing for the product must be previously imported. This includes price-level pricing that is assigned to the customer account that the order is associated to, or any customer account specific pricing for the order's customer account.
If the imported sales order does not need to be repriced then the sales order product lines priceExTax, priceIncTax, priceTax, priceTotalExTax, priceTotalIncTax and priceTotalTax fields must have values set.
If the imported sales order does not need to be repriced then the sales order surcharges need to have price values set for the priceExTax, priceIncTax and priceTax values.
The sales order's currency must match the organisation's currency configured against the Organisation Settings.
The organisation must have enough trading tokens in the platform to cover the sales order transaction.

The sales orders being imported must be placed into the Body of the HTTP request in the form of a conforming Ecommerce Standards Sales Order Document JSON string. Before using this endpoint we recommend that you understand what the Ecommerce Standards Documents are and how you can send sales order data from your system into the standards document. It is highly recommended that any sales order data uploaded using this endpoint be compressed using the GZIP compression algorithm. Note that there are trading token costs to the organisation to have the sales orders imported, of which the organisation must have enough tokens to allow to do. See the Trading Tokens and Pricing page for more details.

HTTP Request

Headers
HTTP Method	POST
HTTP URL	https://api.squizz.com/rest/1/org/import_sales_order_esd/session_id?reprice_order=[reprice_order]
Content-Type	application/json
api-org-key	Conditional, only set this heading if create_single_request_session parameter is set to Y. Set it to the API key of the organisation sending the purchase order to authenticate the request.
api-org-pw	Conditional, only set this heading if create_single_request_session parameter is set to Y. Set it to the API password of the organisation sending the purchase order to authenticate the request.
Parameters	Data Type	Mandatory	Description
session_id	STRING	Conditional	ID of the API session. Place the session ID within the URL. Must be set if the create_single_request_session parameter is not set to Y.
reprice_order	ENUM(Y, N)	No	If set to Y (Yes) then all product lines and surcharges in the sales order(s) will be repriced. If set to N (No) then the endpoint will check that all mandatory pricing fields in the sales order, product lines and surcharges have been provided.
create_single_request_session	ENUM(Y,N)	No	If set to Y, then indicates that this endpoint is being called without any session being created first, and that api credentials have been passed in the HTTP request headers to authenticate the request. If the correct credentials are given then a session will be created for just the order import then once finished the session will be destroyed. This in effect allows systems to authenticate and send sales orders in the same request, which may be required when systems have no way of retaining session data between HTTP requests. Note that this option will cause the request to take longer to process due to the additional authentication checks that need to be made. If this parameter is set to Y then the value of the session_id in the URL will be ignored.
response_http_error_code	INTEGER	No	Set to a HTTP response status code that should be returned if any error occurs when calling the endpoint. The system calling this endpoint may require a non 200-OK response code to be returned in the response to identify a failed sales order import attempt. It is preferred for systems to parse the JSON response returned by this endpoint instead of using HTTP response status codes to determine if orders were successfully processed. This allows systems to more accurately report what error occurred. Where that is not possible then set the parameter in the URL.
Body	JSON	Yes	Body contains a Sales Order Ecommerce Standards Document that has one or more sales order records. The document is serialized into its JSON data string.

To see more information about the sales order fields that the endpoint supports you can find more information at Sales Order Records Fields.

Example Raw HTTP Request

POST https://api.squizz.com/rest/1/org/import_sales_order_esd/402934A8234E1B997D51F23974?reprice_order=N HTTP/1.1
Host: api.squizz.com
Content-Length: 3031
Content-Type: application/json

{
"resultStatus":"1",
"message":"The purchase order data has been successfully obtained.",
"configs":{},
"dataTransferMode": "COMPLETE",
"version": 1.1,
"totalDataRecords": 1,
"dataRecords":
[
{
"keySalesOrderID":"111",
"salesOrderCode":"SOEXAMPLE-123",
"salesOrderNumber":"345",
"keyCustomerAccountID":"3",
"customerAccountCode":"ACM-002",
"customerAccountName":"Acme Supplies",
"currencyISOCode": "AUD",
"deliveryContact":"Jane Doe",
"deliveryOrgName":"Acme Industries",
"deliveryEmail":"js@someemailaddress.comm",
"deliveryPhone":"+6144433332222",
"deliveryFax":"+6144433332221",
"deliveryAddress1":"Unit 5",
"deliveryAddress2":"22 Bourkie Street",
"deliveryAddress3":"Melbourne",
"deliveryPostcode":"3000",
"deliveryRegionName":"Victoria",
"deliveryCountryName":"Australia",
"deliveryCountryCodeISO2":"AU",
"deliveryCountryCodeISO3":"AUS",
"billingContact":"John Citizen",
"billingOrgName":"Acme Industries International",
"billingEmail":"ms@someemailaddress.comm",
"billingPhone":"+61445242323423",
"billingFax":"+61445242323421",
"billingAddress1":"43",
"billingAddress2":"High Street",
"billingAddress3":"Melbourne",
"billingPostcode":"3000",
"billingRegionName":"Victoria",
"billingCountryName":"Australia",
"billingCountryCodeISO2":"AU",
"billingCountryCodeISO3":"AUS",
"instructions":"Leave goods at the back entrance",
"isDropship":"N",
"lines":
[
{
"lineType":"PRODUCT",
"quantity": 4,
"priceExTax": 5.00,
"priceIncTax": 5.50,
"priceTax": 0.50,
"priceTotalExTax": 20.00,
"priceTotalIncTax": 22.00,
"priceTotalTax": 2.00,
"unitName": "EACH",
"productCode": "TEA-TOWEL-GREEN",
"productName": "Green tea towel - 30 x 6 centimetres"
},
{
"lineType":"PRODUCT",
"quantity": 2,
"priceExTax": 5.00,
"priceIncTax": 5.50,
"priceTax": 0.50,
"priceTotalExTax": 10.00,
"priceTotalIncTax": 11.00,
"priceTotalTax": 1.00,
"unitName": "EACH",
"productCode": "TEA-TOWEL-BLUE",
"productName": "Blue tea towel - 30 x 6 centimetres"
}
]
}
]
}

HTTP Response

Parameters	Data Type	Description
Response Data Type	JSON

result	ENUM (SUCCESS or FAILURE)	Either "SUCCESS" or "FAILURE". If successful then the sales order data was imported into the platform against the organsiation.
configs.api_version	DECIMAL	Version of the SQUIZZ.com platform's API used to handle the request
configs.result_code	STRING	Status code of trying to import the ESD document data. The following codes could be returned: SERVER_SUCCESS The sales orders were successfully validated and imported. The order may have been sent out to organisation connected business and freight systems. SERVER_ERROR_ORG_DOES_NOT_EXIST The organisation could not be found or is not active within the platform. This could occur if the organisation was deleted at the time the endpoint was called, or it's closure status was set. SERVER_ERROR_SESSION_INVALID The session used to call the endpoint has expired, or never existed. Look at calling the Create Session endpoint to get another session ID. SERVER_ERROR_ORG_NOT_SELLING The supplier organisation is not currently selling on the platform. The supplier organisation would need to change its Trading Status to Fully Trading or Selling Only to allow the purchase orders to be procured. SERVER_ERROR_NO_CUSTOMER_ACCOUNT_FOUND For the customer account assigned to the sale order, it could not be matched to any customer account previously imported into the SQUIZZ.com platform against the organisation. Check that a customer account exists and matches either the keyCustomerAccountID or customerAccountCode fields that are set within the sales order document. SERVER_ERROR_ORDER_PRODUCT_NOT_MATCHED One or more of the products in the sales order lines received cannot be matched to any products previously imported against the organisation. Check that a product exists and matches either the keyProductID or productCode fields that are set within the sales order lines. See the "configs.orders_with_unmatched_lines" attribute returned by the endpoint to determine the lines within the sales orders that have been unmatched and may require a person to resolve. SERVER_ERROR_ORDER_LINE_PRICING_MISSING One or more of the lines in the sales orders received was matched to the organisation's product, however no pricing could be found for the product(s). If the "reprice_order request" parameter was set to N (No) then this error indicates that not all line pricing fields were set valid prices. If the "reprice_order request" parameter was set to Y (Yes) then this error indicates that the line could not be priced, indicating either the organisation has intentionally not set a price for the customer account, or the organisation has not imported pricing for the product(s) into the platform as yet. See the "configs.orders_with_unpriced_lines" attribute returned by the endpoint to determine the lines within the sales orders that have been unpriced and may require a person to resolve. SERVER_ERROR_ORDER_SURCHARGE_NOT_FOUND One or more of the surcharges in the sales order(s) received cannot be matched to any surcharges previously imported against the organisation. Check that a surcharge exists and matches either the keySurchargeID or surchargeCode fields that are set within the sales order surcharges. See the "configs.orders_with_unmatched_surcharges" attribute returned by the endpoint to determine the surcharges within the sales orders that have been unmatched and may require a person to resolve. Note that this error only occurs if the "reprice_order request" parameter was set to N (No), otherwise the surcharges set against sales order being imported will be ignored. SERVER_ERROR_ORDER_SURCHARGE_PRICING_MISSING One or more of the surcharges in the sales orders received was matched to the organisation's surcharge, however no pricing could be found for the surcharge(s). This only occurs if the "reprice_order request" parameter was set to N (No) and this error indicates that not all surcharge pricing fields were set valid prices. See the "configs.orders_with_unpriced_surcharges" attribute returned by the endpoint to determine the surcharges within the sales orders that have been unpriced and may require a person to resolve. SERVER_ERROR_ORDER_PAYMENT_NOT_MATCHED One or more of the payments in the sales orders received could not be matched against a payment type previously imported into SQUIZZ.com against the organisation. Check to make sure that the Payment Type has been imported against the organisation and can match based on the keyPaymentTypeID assigned to the sales order. See the "configs.orders_with_unmatched_payments" attribute returned by the endpoint to determine the payments within the sales orders that have been unmatched and may require a person to resolve. SERVER_ERROR_PAYMENT_STATUS_NOT_SUPPORTED The payment status set against one of the sales orders being imported is not supported. Check that the paymentStatus field of each sales order is set to either "UNPAID", "PENDING", "PAID" or "NONREQUIRED". SERVER_ERROR_ORDER_SALE_SUBMISSION_PAYMENT_STATUS_NOT_CORRECT The payment status set against one of the sales orders being imported is not supported. Check that the paymentStatus field of each sales order is set to either "PAID" or "NONREQUIRED" SERVER_ERROR_ORG_NOT_ENOUGH_CREDITS The organisation does not have enough trading tokens within the platform to allow the sales orders to be created. The organisation needs to purchase more trading tokens to allow it to import sales orders through this endpoint. SERVER_ERROR_DATA_JSON_WRONG_CONTENT_TYPE The content type set in the HTTP Request Header is missing or not correctly set to "application/json". Ensure that the body of the HTTP request also has the purchase order data set in the JSON data format.
configs.orders_with_unmapped_lines	STRING	Contains a comma delimited list of key value pairs (that each are colon delimited) that specifies the index of the sales order record and the index of the line within the record that could not be matched to a organisation's product. For example if this value was set to "1:2,1:3,4:0", Then it would specify that the 2nd sales order record (index 1) within the dataRecords array of the sales orders uploaded in the endpoint request has lines 3 and 4 that have unmatched products (line indexes 2 and 3), and for the 5th sales order record (record index 4) the 1st order line has an unmatched product (line index 0).
configs.orders_with_unpriced_lines	STRING	Contains a comma delimited list of key value pairs (that each are colon delimited) that specifies the index of the sales order record and the index of the line within the record that could not be priced for a organisation's product. This indicates that products were found for the sales order lines but that the organisation had not set any pricing of the products, based on the customer account that that the customer organisation was assigned to, or otherwise not all pricing fields were set if the order is not to be repriced. For example if this value was set to "2:1,2:3,5:0", Then it would specify that the 3rd sales order record (index 2) within the dataRecords array of the sales orders uploaded in the endpoint request has lines 2 and 4 that have unpriced products (line indexes 1 and 3), and for the 6th sales order record (record index 5) the 1st order line has an un-priced product (line index 0).
configs.orders_with_unmatched_surcharges	STRING	Contains a comma delimited list of key value pairs (that each are colon delimited) that specifies the index of the sales order record and the index of the surcharge record within the order record that could not be matched to a organisation's surcharge. For example if this value was set to "1:2,1:3,4:0", Then it would specify that the 2nd sales order record (index 1) within the dataRecords array of the sales orders uploaded in the endpoint request has surcharge records 3 and 4 that have unmatched surcharge (surcharge record indexes 2 and 3), and for the 5th sales order record (record index 4) the 1st order surcharge record has an unmatched surcharge (surcharge record index 0).
configs.orders_with_unpriced_surcharges	STRING	Contains a comma delimited list of key value pairs (that each are colon delimited) that specifies the index of the sales order record and the index of the surcharge within the record that could not be priced for a organisation's surcharge. This indicates that not all pricing fields were set against the surcharge if the order is not to be repriced. For example if this value was set to "2:1,2:3,5:0", Then it would specify that the 3rd sales order record (index 2) within the dataRecords array of the sales orders uploaded in the endpoint request has surcharge records 2 and 4 that have unpriced surcharges (surcharge indexes 1 and 3), and for the 6th sales order record (record index 5) the 1st order surcharge record has an un-priced surcharge (line index 0).
configs.orders_with_unmatched_payments	STRING	Contains a comma delimited list of key value pairs (that each are colon delimited) that specifies the index of the sales order record and the index of the payment record within the order record that could not be matched to a organisation's payment type. For example if this value was set to "1:2,1:3,4:0", Then it would specify that the 2nd sales order record (index 1) within the dataRecords array of the sales orders uploaded in the endpoint request has payment records 3 and 4 that have unmatched payment type (payment record indexes 2 and 3), and for the 5th sales order record (record index 4) the 1st order payment record has an unmatched payment (payment record index 0).
dataRecords	JSON ARRAY	List of Sales Order Ecommerce Standards Records. Each record contains details of the corresponding sales order that was generated from each imported sales order. These details include sales order number, order line pricing, surcharge prices (such as freight and shipping)

HTTP Response Example:

{"result":"SUCCESS", "api_version":"1.0.0.0", "result_code":"SERVER_SUCCESS", "dataRecords":[list_of_sales_order_records]}

Sales Order Record Fields

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

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

Field Name	Data Type	Mandatory	Default Value	Max Length	Description
Data Type	Sales Order Record
keySalesOrderID	STRING	No	[EMPTY STRING]	50	Unique identifier of the sales order that uniquely identifies the order within the organisation's selling system. The keySalesOrderID may be the same as the sales order code, or may be based on an different internal unique identifier created in a business system's database, such as an auto-incrementing number, UUID, or GUID identifier.
keyCustomerAccountID	STRING	Conditional	[EMPTY STRING]	50	The unique identifier of the customer account that the customer organisation has linked to the sales order. If not given the customerAccountCode must be given and match a customer account already imported into SQUIZZ.com against the organisation.
customerAccountCode	STRING	Conditional	[EMPTY STRING]	60	Code the customer account that has been linked to the sales order. If not given then the keyCustomerAccountID must be given and match a customer account already imported into SQUIZZ.com against the organisation.
salesOrderNumber	STRING	No	[EMPTY STRING]	50	Number of the sales order, may or may not be a unique identifier of the order. The code will be used as a reference in the sales order of the organisation.
purchaseOrderNumber	STRING	No	[EMPTY STRING]	50	Number of the purchase order, may or may not be a unique identifier of the order. The code will be used as a reference to link back to originating purchase order of the customer.
keyPaymentTypeID	STRING	No	[EMPTY STRING]	50
paymentStatus	ENUM(UNPAID, PENDING, PAID, NONEREQUIRED)	No	[EMPTY STRING]	20
paymentMethod	ENUM(ACCOUNT, PROPRIETARY, CREDITCARD, CASHONDELIVERY, DIRECTDEPOSIT, QUOTE, NONE)	No	NONE	20
paymentProprietaryCode	STRING	No	[EMPTY STRING]
paymentReceipt	STRING	No	[EMPTY STRING]
paymentAmount	DECIMAL	No	0.0000	14,4
keySalesRepID	STRING	No	[EMPTY STRING]	50
salesRepCode	STRING	No	[EMPTY STRING]	50
keyLocationID	STRING	No	[EMPTY STRING]	50
locationCode	STRING	No	[EMPTY STRING]	50
customerEntity	ENUM
customerPersonName	STRING	No	[EMPTY STRING]
createdDate	LONG INTEGER	No	0		Date that the order was created. Date is in the form of a number in milliseconds since the 01-01-1970 12:00am Epoch in UTC time-zone, stored as a long integer.
instructions	STRING	No	[EMPTY STRING]	21,844	Text describing the instructions on how to handle or deliver the order. May contain comments on the order.
deliveryOrgName	STRING	No	[EMPTY STRING]	50	Name of the organisation that the ordered products/goods will be delivered to.
deliveryContact	STRING	No	[EMPTY STRING]	50	Contact person at the delivery address where the ordered products/goods will be delivered to.
deliveryEmail	STRING	No	[EMPTY STRING]	100	Email address that notifications about the order delivery are to be sent to.
deliveryAddress1	STRING	No	[EMPTY STRING]	90	1st address field to deliver the ordered products/goods to. Typically set the unit/apartment number, building name, street number and/or street name.
deliveryAddress2	STRING	No	[EMPTY STRING]	90	2nd address field to deliver the ordered products/goods to. Typically set the steet number and name within this field.
deliveryAddress3	STRING	No	[EMPTY STRING]	90	3rd address field to deliver the ordered products/goods to. Set the suburb, city or town within this field.
deliveryRegionName	STRING	No	[EMPTY STRING]	70	Name of the region, state or province to deliver the ordered products/goods to. If the field is not set then it may be auto filled by the platform based on the delivery post code/zip code.
deliveryCountryName	STRING	No	[EMPTY STRING]	70	Name of the country, state or province to deliver the ordered products/goods to. If the field is not set then it may be auto filled based on the country that the customer organisation is registered to.
deliveryPostcode	STRING	No	[EMPTY STRING]	20	Postcode or zip code that the ordered products/goods are delivered to.
billingContact	STRING	No	[EMPTY STRING]	90	Contact person where the order will be billed to.
billingOrgName	STRING	No	[EMPTY STRING]	50	Name of the organisation that the order will be billed to.
billingEmail	STRING	No	[EMPTY STRING]	100	Email address that notifications about billing of the order are to be sent to.
billingAddress1	STRING	No	[EMPTY STRING]	90	1st address field to bill the order to. Typically set the unit/apartment number, building name, street number and/or street name.
billingAddress2	STRING	No	[EMPTY STRING]	90	2nd address field to bill the order to. Typically set the steet number and name within this field.
billingAddress3	STRING	No	[EMPTY STRING]	90	3rd address field to bill the order to. Set the suburb, city or town within this field.
billingRegionName	STRING	No	[EMPTY STRING]	70	Name of the region, state or province to bill the order to. If the field is not set then it may be auto filled by the platform based on the billing post code/zip code.
billingCountryName	STRING	No	[EMPTY STRING]	70	Name of the country, state or province to bill the order to. If the field is not set then it may be auto filled based on the country that the customer organisation is registered to.
billingPostcode	STRING	No	[EMPTY STRING]		Postcode or zip code that the billing of the order will be sent to.
isDropship	ENUM (Y,N)	No	N	1	Denotes if the order should be delivered direct from the organisation to a specified end consumer, as set in the delivery fields. If set to Y then the order is marked as a drop ship order. The delivery address's organisation name may indicate who is raising this order onto the packaging to make it look like the ordered products/goods came from the requesting organisation.
freightCarrierCode	STRING	No	[EMPTY STRING]
freightCarrierName	STRING	No	[EMPTY STRING]
freightSystemRefCode	STRING	No	[EMPTY STRING]
freightCarrierConsignCode	STRING	No	[EMPTY STRING]
freightCarrierTrackingCode	STRING	No	[EMPTY STRING]
freightCarrierServiceCode	STRING	No	[EMPTY STRING]
freightCarrierAccountCode	STRING	No	[EMPTY STRING]
lines	ARRAY (ESDRecordOrderSaleLine)	Yes	[Empty ARRAY]	-	An array of Sales Order Line ESD Records that specify the products/goods that are to be ordered and purchased.
surcharges	ARRAY (ESDRecordOrderSurcharge)	No	[Empty ARRAY]	-	An array of Order Surcharge ESD Records that specify additional surcharges to be added to the order. Covering costs such as freight fees, credit card fees, minimum order fees.
payments	ARRAY (ESDRecordOrderPayment)	No	[Empty ARRAY]	-	An array of Order Payment ESD Records that specify multiple payments that have been applied against the order. Only set if the order has multiple payments applied to it, otherwise use the order's payment fields.

Sales Order Line Records

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

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

Field Name	Data Type	Mandatory	Default Value	Max Length	Description
Data Type	Sales Order Line Record
lineType	ENUM (PRODUCT,TEXT)	Yes	[EMPTY STRING]	-	Specifies the type of entities being ordered. Set to PRODUCT to denote that a physical or non-physical product is being purchased. Set to TEXT to denote a text line that may contain additional details or instructions and is not a product that needs to be purchased.
keyProductID	STRING	Conditional	[EMPTY STRING]	50	Unique identifier of the product within the organisation's system. The keyProductID may be the same as the productCode, or may be based on an different internal unique identifier created in a business system's database, such as an auto-incrementing number, UUID, or GUID identifier. This must be given and match an organisation's product if the productCode has not been given and matched.
productCode	STRING	Conditional	[EMPTY STRING]	50	Code that allows the product to be identified within the organisation's system. Typically this code is unique to each product that is being purchased. The product code may also be known as a Stock Keeping Unit (SKU), item number, product ID, or item code in certain systems. This code may be used to try to match it to one of the organisation's products where an exact match exists. This must be given and match an organisation's product if the keyProductID has not been given and matched.
productName	STRING	No	[EMPTY STRING]	50	Name of the organisation's product. The name typically contains natural words that allow it easily understood by people on what the product is, or does.
quantity	DECIMAL	Yes	0.0000	14,4	The quantity to be ordered/purchased. Set the quantity based on the sell unit of the organisation's product. If the quantity is set at 0 or less then the quantity will be changed to 1.
keySellUnitID	STRING	No	[EMPTY STRING]	50
priceIncTax	DECIMAL	Conditional	0.0000	14,4	The unit price of the line for each quantity ordered, including taxes. This must be given if the API request has the "reprice_order" set to N (No), otherwise it's not required.
priceExTax	DECIMAL	Conditional	0.0000	14,4	The unit price of the line for each quantity ordered, excluding taxes. This must be given if the API request has the "reprice_order" set to N (No), otherwise it's not required.
priceTax	DECIMAL	Conditional	0.0000	14,4	The unit tax cost of the line for each quantity ordered. This must be given if the API request has the "reprice_order" set to N (No), otherwise it's not required.
priceTotalIncTax	DECIMAL	Conditional	0.0000	14,4	The total price of the line for all quantities ordered, including taxes. This must be given if the API request has the "reprice_order" set to N (No), otherwise it's not required.
priceTotalExTax	DECIMAL	Conditional	0.0000	14,4	The total price of the line for all quantities ordered, excluding taxes. This must be given if the API request has the "reprice_order" set to N (No), otherwise it's not required.
priceTotalTax	DECIMAL	Conditional	0.0000	14,4	The total tax cost of the line for all quantities ordered. This must be given if the API request has the "reprice_order" set to N (No), otherwise it's not required.
salesOrderProductCode	STRING	No	[EMPTY STRING]	60	Set to the product code of the supplier organisation's product. This code may be used to try to match it to one of the supplier organisation's products where an exact match can be found to the supplier's product code.

Sales Order Surcharge Records

For each Sales Order Record in the surcharges property it may store an array of Order Surcharge Records, with each record specifying one type of surcharge that has been additionally costed against the order.

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

Field Name	Data Type	Mandatory	Default Value	Max Length	Description
Data Type	Sales Order Line Record
keySurchargeID	STRING	Conditional	[EMPTY STRING]	50	Unique identifier of the surcharge within the organisation's system. The keySurchargeID may be the same as the surchargeCode, or may be based on an different internal unique identifier created in a business system's database, such as an auto-incrementing number, UUID, or GUID identifier. This must be given and match an organisation's surcharge if the surchargeCode has not been given and matched on.
surchargeCode	STRING	Conditional	[EMPTY STRING]	50	Code that allows the surcharge to be identified within the organisation's system. Typically this code is unique to each surcharge that is being applied against the sales order. The surcharge code may also be known as a Stock Keeping Unit (SKU), item number, product ID, or item code in certain systems that represent surcharges as items/products. This code may be used to try to match it to one of the organisation's surcharges where an exact match exists. This must be given and match an organisation's surharge if the keySurchargeID has not been given and matched on.
priceIncTax	DECIMAL	Conditional	0.0000	14,4	The price of the surcharge, including taxes. This must be given if the API request has the "reprice_order" set to N (No), otherwise it is not required.
priceExTax	DECIMAL	Conditional	0.0000	14,4	The price of the surcharge, excluding taxes. This must be given if the API request has the "reprice_order" set to N (No), otherwise it's not required.
priceTax	DECIMAL	Conditional	0.0000	14,4	The tax cost of the surcharge. This must be given if the API request has the "reprice_order" set to N (No), otherwise it's not required.

Sales Order Payment Records

For each Sales Order Record in the payments property it may store an array of Order Payment Records, with each record specifying one type of payment that hsa been applied against an order.

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

Field Name	Data Type	Mandatory	Default Value	Max Length	Description
Data Type	Sales Order Line Record
keyPaymentTypeID	STRING	Conditional	[EMPTY STRING]	50	Unique identifier of the payment type within the organisation's system. The keyPaymentTypeID may be the same as the paymentTypeCode, or may be based on an different internal unique identifier created in a business system's database, such as an auto-incrementing number, UUID, or GUID identifier. This must be given and match an organisation's payment type previously been imported against the organisation within SQUIZZ.com
paymentMethod	ENUM(ACCOUNT, PROPRIETARY, CREDITCARD, CASHONDELIVERY, DIRECTDEPOSIT, NONE)	Yes	[EMPTY STRING]	20	The payment method that was used to apply the payment against. It can be set to one of the following options: ACCOUNT The payment is paid against the customer account that the organisation has set up for the customer. This may indicate a future payment that will be applied against the account's balance. PROPRIETARY The payment was payed through a proprietary payment system, such as Afterpay, Applepay, Zippay, Paypal, etc... CREDITCARD The payment was payed via a credit card payment. CASHONDELIVERY The payment was/will be paid once the ordered goods are delivered. When delivered they are paid by an on the spot cash payment. DIRECTDEPOSIT The payment was/will be paid via a direct deposit, also known as a direct bank transfer between banking acounts. NONE No payment was applied against the order.
paymentAmount	DECIMAL	Yes	0.0000	14,4	The monetary amount that was applied against the order. The currency of the payment is based on the same currency set against the sales order.
paymentReceipt	STRING	No	[EMPTY STRING]	50	The receipt number that may have been issued with a payment transaction occurred within the payment system used. Typically is set for credit card payments or payments through proprietary payment systems, and may be used to track the transaction.

Document last modified on the 24th November 2021