Skip to main content

CCP - Open API: Adding an Order

Using our API to add an order into CCP

Chelsea Kelly avatar
Written by Chelsea Kelly
Updated over 4 years ago

The SubmitOrder function can:-

  • Add an order to a customer that already exists

  • Trigger any Create Orders trigger that have been configured against the target sales channel

The SubmitOrder function can't:-

  • Always add the order to the system in a Dispatch ready state

  • Link an order to a shipping rule as it comes into the system, any shipping rules API orders are assigned are calculated as per the properties of the order, in accordance with the other channels

If successful it will return an Order object which returns things required to further update and check the order using other functions:-

  • Content > Order > ID the OrderID you need this to use the order in other API calls, such as making the follow on payment or to check on the status of the order

Tips and Recommendations when using this function

  • nCustomerID is returned as ID in the AddCustomer function result

  • The target sales channel for the order is determined by the customer ID you link to the order using nCustomerID

  • BillingAddress is not required, if this is not provided, the order will use the Admin/Billing address from the customer given in nCustomerID

  • ExternalReference this should be the unique channel reference, note that duplicate orders are checked against this field so you might wish to add a prefix or suffix to make sure it doesn't clash with orders already in the system

  • strReference this is an optional reference and can be used to pass in a reference that is specific and useful to the customer

  • doTriggers can be used to trigger Create Order related triggers you have set up - as most people usually have communications handled on the channel for the orders they are importing, this is commonly set to false

  • When adding line items to an order, we recommend sending values for the following fields only:

    • One of ProductID (CCP) or SKU to identify the product

    • VatRateID to set the tax rate applied to this item, this is

      • 5 for 20%

      • 0 for 0%

    • Quantity

    • Price per unit, this can be a Gross or Net value

    • UseNetPrice determines if prices for item are Gross or Net

    • Discount per unit (only if row has a discount), this can be Gross or Net but value has to match the type (Gross/Net) of the Price

    • DiscountCalculatedInPrice (again, only if row has a discount) determines if Price is value before or after discount

  • Sending any other values in addition to those advised above for each line item can lead to some strange calculation behaviours. Using nodes starting Row is not advised

  • VAT on the final order is determined by the values sent as the order is created and the VatRateID applied on a line by line basis.

  • intPaymentStatus does not necessarily mark the order as paid as you might expect. This is just one setting that can influence the behaviour of the order and there are other factors in play that determine if the orders are paid or not. Note that a value of 1 means the order is marked as Unpaid

Endpoints

All requests for this function need to go to the following endpoint:

LIVE: https://wcfccpservicesbase.cloudcommercepro.com/CCPApiOrderService.svc?wsdl

Link to function in API docs

Marking orders as paid

Once the order has been added in the system, the process of marking orders as paid so that they appear in the dispatch queue will depend on a number of things, such as, but not necessarily limited to

  • The type of customer

    • Trade customers: Proformas can not be paid via the API, but these customers are typically set up as having credit terms which means these orders often fall into the Dispatch Queue without payment

    • Retail customers: Most retail (Public) customers are typically set up as payment before dispatch. These invoices need to be paid via the API before the order will fall into the Dispatch Queue

  • The PaymentTerms of the customer

    • FullPaymentBeforeDispatch - Order is expected to be paid before it will fall into the Dispatch Queue

    • Full credit terms - Order is expected to fall into the dispatch queue before the payment

    • Part credit terms - Order is expected to fall into the dispatch queue as per the standard behaviour for credit

  • The value of the intPaymentStatus that has been passed in on the order

The process of paying invoices is documented in this guide (to add link)

Did this answer your question?