Organisations Selling On SQUIZZ

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

• Getting Started/Overview
• Personal Signing Up To SQUIZZ.com
• Registering An Organisation
• Connecting People and Employees
• Connecting Organisations
• Organisation Settings
• Organisational Data
• Trading Tokens and Pricing
• Connecting Business Systems

For an organisation to start selling within the SQUIZZ.com platform the following organisational data listed below needs to be first imported into the platform. This data allows the platform determine the products being sold to customers and how to price the products for each customer. This data may be imported into the platform from a business system that the organisation has, or managed within spreadsheets (or other data sources) and imported into the platform using the SQUIZZ.com Connector software. Read the Connecting Business Systems document for more details on to connect up an organisation's business systems into the platform to import the following data.

Required Organisational Data For Selling

• Taxcodes
  Taxcodes are used to calculate the amount of tax that needs to be applied for products. Taxcode data should be imported before product data is imported.
   
• Price Levels
  Price levels allow multiple prices to be set against each product, from where customer accounts can be assigned to one price level. A price level is assigned to one or more customer accounts, which controls the pricing that those customers will see when buying off the organisation. Price level data should be imported before customer account data is imported.
   
• Sell Units
  Sell units control how products are individually sold, or in packs, boxes, and other defined bundling. One sell unit should be designated as the default unit that products can be individually purchased as. Each of the product's prices need to apply to a sell unit to allow the platform to correctly calculate pricing. Products can also be assigned to sell units to define the available units that each product can be bought it. Sell units should be imported before products, and pricing data.
   
• Payment Types
  Payment types define how customers can pay to purchase products sold to them. Each payment type defines a payment method that controls what method the customers will use to pay for the products. Customer accounts can be assigned to multiple payment types to control what methods customers are allowed to pay for products with. For a customer organisation or person to be able to buy products they must be assigned to a customer account that has at least one payment type set against it. Payment Types should be imported first by any customer accounts are imported to an organisation on the SQUIZZ.com platform.
   
• Products
  Products define the goods or services that an organisation can sell. Products should be imported before product price-level pricing, product customer account pricing, or location data is imported. Sell Units should be imported before importing product data to ensure that products are assigned to sell units and are able to be sold.
   
• Customer accounts
  Customer accounts define the customers that the organisation has relationships with. Customer accounts may also be known as debtors, customers, business partners, customer cards, or clients, depending on the business system an organisation uses. Each customer account is associated to sales orders, invoices and other accounting records, allowing the organisation to track the amount of money each customer owes and has purchased historically. Customer accounts should be imported before any product customer account pricing is imported. Sales representatives can also be linked to the customer accounts and allow sales people to create sales orders on behalf of specific customers, and manage customer relationships and conversations, also known as Customer Relationship Management (CRM).
   
• Product price-level pricing, product customer account pricing
  Product price-level pricing define the different prices that products can be sold for, based on setting prices against price levels for each product. Product customer account pricing contains unique pricing that has been set for each individual customer account, and this allows highly customised pricing to be tailored for each customer account. Either product price-level pricing or customer account pricing needs to be imported before the platform can calculate the price of products for associated customers. Sell units, price levels, taxcodes, customer accounts, and product data must be imported first before importing any pricing data, otherwise the prices may not be able to be applied against non-existent products and customer accounts.

Optional Organisational Data For Selling

The following data may not need to be imported before an organisation can start selling on the platform, but may be useful to help the organisation more effectively sell.

• Sales Representatives
  Sales representatives define the people (such as employees) or organisations that may sell on behalf of an organisation. Sales representatives can be assigned to selected customer accounts, and also have people or organisations linked to the sales representatives records. This allows these linked people or organisations to create sales orders for their assigned accounts, as well as view conversations linked to the customer accounts, as well as invoices, sales orders, back orders, payments or credit records. Sales Representatives should be imported before customer account data.
   
• Product price-level quantity pricing
  For each product quantity based price-level pricing may be imported, which allows a product to be sold at a different price-level price based on a customer ordering a certain quantity. Product price-level quantity pricing can be an effective sales tool to entice customers to buy more product quantities knowing that they will receive a cheaper unit price in doing so. Sell units, taxcodes, price-levels and product data needs to be imported first before trying to import pricing data, otherwise the platform won't be able to apply pricing to non-existent products.
   
• Locations
  Locations may define the stores, warehouses, offices, or other places where an organisation may store its products, or where sales orders should be processed within. When a sales order is created a location can be optionally assigned to it or the sales order lines. When the sales order is sent to the organisation's connected business system the business system may use the location to determine where the order's stock should be delivered from, or where it should be processed.
   
• Categories and Category Trees
  Categories and Category Trees help customers find products based on navigating through the category trees, also known as catalogues when logging into SQUIZZ.com, or if the catagories are downloaded from the API. This allows customers to find products based on navigating through a hierachy of categories, where each category represents a collection of similar products. Multiple category trees may be set up to represent different catelogues, such as seasonal products, or brands.

For the platform to be able to calculate the price of a product for a customer of the organisation the following conditions must be met first:

• The customer (organisation or person) is assigned to a customer account that is marked as Is Active = Yes.
• The product is marked as Is Active = Yes.
• The product is assigned to a taxcode.
• A base sell unit has been set for the organisation, or a specific sell unit has been assigned to the product.
• Either the customer account is assigned to a price level that the product has pricing for, or the product has pricing set for the customer account purchasing the product.

Only once all these conditions have been then the platform will calculate the price of the product based on the following rules.

• Obtain all the price-level pricing assigned to the product that is the same price-level assigned to the customer account.
• Obtain all the price-level quantity pricing assigned to the product that is the same price-level assigned to the customer account and matches the quantity that the customer is purchasing.
• Obtain all customer account pricing assigned to the product that  directly matches is assigned to the customer account and matches the quantity that the customer is purchasing.
• Obtain all customer account pricing assigned to the product that matches a price group that the customer account is assigned to, and matches the quantity that the customer is purchasing.
• Determine the cheapest price of the product from the price-level, price-level quantity, and customer account pricing found, based on all matching the sell unit that the customer wishes to purchase with.
• If a customer account price exists that references a "forced price contract" then choose the contract price even if it is more expensive then any other price. If multiple forced contract prices are found then choose the cheapest forced contract price.

Only once a price is found and is greater than 0 then the following calculation is made to determine the final price of the product for the customer account.

Product Final Price (Including Tax) = Unit Price x Quantity x Taxcode%

If the product has been marked so that all of its pricing is inclusive of tax then following calculation is made:

Product Final Price (Including Tax) = Unit Price x Quantity

If a price could not be found then the customer will not be able to purchase the product. If the price found is zero or less than then the customer will not be able to purchase the product.

Sales order rules can be set up so that when a sales order is created for an organisation, that different aspects of the sales order can be modified or set before the customer confirms and submits the order. Sales order rules could be used for the following:

• Add an additional freight surcharge to the sales order based on how far the ordered products need to be delivered. Rules could be set up to factor in freight carrier charges, or an organisation's own courier charges.
• Add an additional handling surcharge to the sales order based on the processing and handling required within the organisation's locations to deliver the ordered goods.
• Add an additional credit-card or other payment surcharge based on if the sales order was paid using a credit card payment method, or other payment method.
• Add an additional minimum order surcharge if the total price of the order is under a specified limit.
• Set the location assigned to the sales order based on the delivery address assigned to the order, or other factors.
• Set the freight provider assigned to the sales order, allowing the freight carrier to be determined and how the ordered goods are going to be delivered to the customer.

The platform allows each organisation to create a wide variety of rules on how a sales order is modified. This can includes placing conditions where the details of a sales order can only be set once certain aspects are met, such as not charging for freight when the customer orders over a certain amount, or for specific customers setting a particular warehouse location to the sales order. There is large amount of flexibility and customisation that can occur when setting up sales order rules.

Sales Order Rule Types

When setting up sales order rules for an organisation there are four different kind of rules that can be created, these are:

• IF Rule
  This rule checks if conditions of the order have been met, and only if so then the child rules hanging under the If rule within the tree are allowed to be processed. The IF rule allows for up to 5 conditions to be checked within one rule, and this can be used to check many aspects about an order, such as the postcode set within the delivery address, or the customer account that is assigned to the order.
   
• ACTION Rule
  This rule allows an aspect of the order to be set or modified. ACTION rules can be used to set a surcharge in the sales order, set the location of the sales order, set the freight provider, set the freight unit, or assign values to place holders that can be checked in IF rules further down the sales order rules tree.
   
• LOOP Rule
  This rule can loop over the same set of rules for a specified amount of times. A LOOP rule could be used to loop through each of the products assigned to the order, then IF rules could be set to check if a certain product has been added to the order, then if so set or change an aspect of an order. LOOP rules allows the same part of the sales order rules tree to be processed several times.
   
• Folder Rule
  The Folder rule allows for a number of rules to be grouped and labelled within the sales order rules tree. They can be used to make it easier for administrator people of an organisation to understand why certain rules have been set up. Example could be that all rules related to setting a freight surcharge in an order could be placed within a folder called "Freight Calculations".

The sales order rules are set within a tree structure. When a sales order is created the platform it will process each "rule" within the tree, then all child rules that hang off another rule. If a rule is condition then only if the condition evaluates to True will any of its child rules be processed, otherwise if the condition is False the process will go to the next sibling rules.

Create A Sales Order Rule

To create a sales order rule you must first be connected to the organisation and be designated as an administrator of the organisation. Once you have the credentials then follow the steps to create a sales order rule:

1. Login to the SQUIZZ.com platform from the Home page or mobile app.
2. Click on the Organisations menu button in the top header bar.
3. Scroll through your connected organisations and find the organisation you wish to test the sales order rules for.
4. Click on the Profile button.
5. Within the organisation profile click on the Admin button.
6. Click on the Sales Order Rules button.
7. Click on the Sales Order Rules tree node.
8. Click on the Add Rule menu item.
9. Click on either the Add IF Rule, Add Action Rule, Add Loop Rule, or Add Folder menu item.
10. In the Order Rule Details dialog fill out the details of the rule based on the type selected.
11. Click on the Save button.

A rule will be added to the sales order rules tree. To add rules under an existing rule click on the parent rule and follow steps 8 to 11. To remove a sales order rule click on the rule and select the Delete Rule menu item.

Test Sales Order Rules

When setting up sales order rules for an organisation there is the ability to test out the rules on an existing sales order. This can help an administrator person determine how the rules are being evaluated and check that the rules are modifying sales orders in a correct way.

To test out sales order rules you must first be connected to the organisation and be designated as an administrator of the organisation. Once you have the credentials then follow the steps to test sales order rules:

1. Login to the SQUIZZ.com platform from the Home page or mobile app.
2. Click on the Organisations menu button in the top header bar.
3. Scroll through your connected organisations and find the organisation you wish to test the sales order rules for.
4. Click on the Profile button.
5. Within the organisation profile click on the Admin button.
6. Click on the Sales Order Rules button.
7. Click on the Test Sales Order Rules button.
8. In the Sales Order Code textbox type in the code of an existing sales order.
9. Click the Run Test button.

The sales order rules will be run against the sales order based on the code given. Against each sales order rule a number will show advising of the order in which the sales order rules were run. Additionally other information about each rule will be shown based on the rule type. A summary of the changes that would be applied to the sales order are listed at the bottom of the dialog.

Each organisation selling on the SQUIZZ.com platform may set up a number sales representatives who can manage customers, and can generate sales on behalf of customers. Sales representatives records can be imported from an organisation's connected business system. Once done sales representative records can be assigned to customer accounts. This is used to control the customers that a sales representative can manage. People connected to the organisation can then be assigned to one or more sales representative records. This effectively allows the person to become a sales representative, and see all the purchases and account details of the customer accounts that they have access to. Additionally the sales representative may be able to create sales orders with the customer accounts they are assigned to.

Sales representatives can be an effective way for an organisation's sales/accounts people to manage a number of customers, since these people can generate new sales through the relationships they have with the customer.

Within the Admin area of each organisations profile there is the ability to run the Product Diagnostics report. The report allows administrators to check if a product can bought by a particular customer account, and see how the platform calculates the price of a product for the given account and quantity. To run the report you must first be connected to the organisation and be designated as an administrator of the organisation. Once you have the credentials then follow the steps to run the Product Diagnostics report:

1. Login to the SQUIZZ.com platform from the Home page or mobile app.
2. Click on the Organisations menu button in the top header bar.
3. Scroll through your connected organisations and find the organisation you wish to run the report for.
4. Click on the Profile button.
5. Click on the Admin button.
6. Click on the Product Diagnostics button.
7. In the Product Diagnostics Report dialog, for the Product Code textbox type in the code of a product you wish to check.
8. In the Customer Account Code textbox type in the code of the customer account that you wish check if they can buy the product with.
9. In the Ordered Quantity textbox type in a number of the quantity that the customer may purchase.
10. Optionally in the Sell Unit Code textbox type in the code of the sell unit that the customer may purchase the product with. If you leave the textbox empty then the platform will try to find pricing associated to the product based on the base sell unit if one exists.
11. Click on the Check button.

The report will check if the product and customer account exist based on the codes given. If both are found then the report will show a number of checks as well as all the pricing that if has found for the product. The report will also show the final price calculated for the product, highlighting the pricing that was chosen based on the price-level pricing and customer account pricing.

The Order Procurement Process allows an organisation to sell products to its customers by the customers converting their purchase orders into sales orders of the supplier organisation. This conversion process can occur within the SQUIZZ.com platform by the customer, or can occur by a customer's business system(s) pushing purchase orders into the platform through its Application Programming Interface (API). The order procurement process leverages all of the connections that the platform offers to both customers and suppliers to enable selling to occur.

Benefits Of The Order Procurement Processes

There are a number of using this process, which include:

• The supplier organisation does not need to do any manual data entry and sales orders can flow automatically into the supplier organisation's connected business system(s).
• The amount of processing required to do by the supplier organisation is reduced, allowing products ordered to more quickly be dispatched and received by the customer.
• The customer organisation no longer needs to manually send purchase orders using email, phone, fax, or mail.
• The customer organisation can find out the exact cost of purchasing products before the sales order is submitted.
• The customer organisation can find out the stock availability of purchasing products before a sales order is submitted.
• The amount of manual data entry is reduced as more of the customer's purchase orders are converted into the supplier's sales orders. This occurs since the platform can remember the product code mappings between the customer's products, and the supplier's products.
• The customer organisation can automate purchasing, cutting down manual labour, time and costs from their end.

Requirements

In order for the order procurement process to be used the following needs to be set up:

• For the customer organisation:
  • Needs to register within the SQUIZZ.com platform.
  • Needs to connect with the supplier organisation in the platform.
  • Needs to connect its business system directly to the platform, or indirectly to platform through the SQUIZZ.com Connector software.
  • Needs to import supplier accounts into the platform the business software. Not required if purchase orders are pushed into the platform through the API.
  • Needs to assign the supplier organisation to a supplier account. Not required if purchase orders are pushed into the platform through the API.
  • A purchasing person within the customer organisation needs to connect personally to the supplier organisation. Not required if purchase orders are pushed into the platform through the API.
• For the supplier organisation:
  • Needs to register within the SQUIZZ.com platform.
  • Needs to connect with the customer organisation in the platform.
  • Needs to import all required data from selling within the SQUIZZ.com platform.
  • Needs to assign a customer account to the connected customer organisation.
  • Needs to connect with a purchasing person within the customer organisation.

How The Processes Work

There are two different work flows for customer organisations to be able procure orders and buy off the supplier organisation. These are workflows include the "Pull In Order and Push" Workflow, and the "Push" workflow.

Pull In Order and Push Workflow

This workflow requires purchasing person of the customer organisation to log into the SQUIZZ.com platform, pull a purchase order from their connected business system, then push the purchase order to the supplier organisation for processing, allowing a sales order to be generated for the supplier organisation. This workflow allows a person to fix any issues and selectively choose the orders that need to be procured, and may leverage the SQUIZZ.com Connector software. It does however require additional labour and time for a person to perform this work.
This work flow requires the following steps to take place:

1. First a connection is made between customer and supplier organisations, and their business systems are connected to the platform.
2. A purchasing person for the customer organisation finds the supplier account assigned to the supplier organisation.
3. The purchasing person loads the purchase orders assigned to the supplier account from the customer's business system.
4. The purchasing person selects one or more purchase orders to convert to sales orders for the supplier organisation.
5. For each selected purchase order the purchasing person types in the product codes of the supplier for each purchase order line where the platform cannot find any previous match.
6. The purchasing person validates the purchase order details and the purchase orders are converted into sales orders.
7. The sales order rules of the supplier organisation are run and the final details of the sales order are set.
8. The purchasing person submits each sales order one-by-one, or all at the same time.
9. The sales orders are sent through the supplier organisation's business system if possible.
10. The sales orders are optionally sent through to a freight provider to allow a consignment note to be raised, and have a freight carrier notified of products that need to be transported.
11. A notification is sent to people in the supplier organisation who are listening to the Sales Order notification category and are informed of the new submitted orders and their status.

Note that once a purchasing person has retrieved a purchase order from their own system and loaded it into the SQUIZZ.com platform, they have the ability to modify the ordered quantities, remove order lines, as well as change the details of the contact person in the billing and delivery addresses. It is important to note that such changes would not be reflected in the original purchase order stored in the external system where it came from, to do so a person would currently need to go back to that system to alter the purchase order manually.

Within the procurement dialog the purchasing person may be able to see the stock availability of the products that the are matched to the supplier (if the supplier has given permission through using data sharing policies). The purchasing person may be able to see the current available stock quantity of the supplier's product, and/or see the stock availability as a stock level, based on one of the following levels:

• HIGH
  The supplier indicates that the product has a high amount of stock available (coloured in green)
   
• LOW
  The supplier indicates that the product has a low amount of stock available (coloured in orange)
   
• NONE
  The supplier indicates that the product has no stock available (coloured in red)

If the purchasing person can see the available stock quantity of a product then the available stock number may also be coloured to denote the stock level. This stock availability may help guide the purchasing person if they should still buy the product or switch to buy a different product.

Within the procurement dialog the purchasing purchase will be able to see the latest pricing of the supplier's products that the platform was able to find. The colour of the pricing may changed based on the following:

• Green Pricing
  The price of the supplier's product was found to be cheap than the price specified within the purchase order.
   
• Orange Pricing
  The price of the supplier's product was found to be more expensive than the price specified within the purchase order.
   
• Black Pricing
  The price of the supplier's product was found to be the same as the price specified within the purchase order.

If the purchasing person hovers over the pricing with their mouse they will be able to see the exact price differences between the price set within the purchase order line, and the last pricing of the supplier's product. This may help the purchasing person detect if any major pricing variations have occurred, or see if any special pricing has become activated.

Push Order Workflow

This workflow allows for a customer organisation's software to push a purchase order into the SQUIZZ.com platform through its API. The purchase order is then converted into a supplier organisation's sales order and sent to the organisation for processing. This workflow requires the customer organisation's software to be capable of pushing purchase orders into the SQUIZZ.com platform's API. It may require software developer people with the skill to be to modify the customer organisation's software, or provide addon solutions to all the software to talk with the platform. The benefits of this workflow is that it may not require human intervention to buy off the supplier organisation. provided that the customer organisation's software knows the product codes of the supplier.
Once done this work flow requires the following steps to take place:

1. First a connection is made between customer and supplier organisations, and their business systems are connected to the platform. The supplier organisation assigns a customer account to customer organisation.
2. The customer organisation's software makes a connection to the platform's API and sets up a session.
3. The customer organisation's software sends one or more purchase orders to the API's procurement endpoint.
4. The API endpoint attempts to match the products in the purchase order to the supplier's products, based on finding matching products or alternate codes, or specified supplier codes, or previous mappings.
5. The purchase orders details are validated and the purchase orders are converted into sales orders.
6. The sales order rules of the supplier organisation are run and the final details of the sales order are set. The sales orders status is updated to being confirmed.
7. The sales orders are sent through the supplier organisation's business system if possible.
8. The sales orders are optionally sent through to a freight provider to allow a consignment note to be raised, and have a freight carrier notified of products that need to be transported.
9. A notification is sent to people in the supplier organisation who are listening to the Sales Order notification category and are informed of the new submitted orders and their status.
10. The API endpoint returns a list of sales orders to the customer organisation's software system to allow it to be notified of the sales orders that were created.

Matching Products In a Customer's Purchase Order To A Supplier's Products

Using either the "Pull In Order And Push" workflow or the "Push Order" workflow requires the platform to find the supplier's products that match the products within the customer's purchase order. Without this the platform has no way of knowing which product the customer wishes to order. There are 4 ways that the platform will try to find a product, in the following order:

1. Check if the "supplier item code" or "sales order product code"within the customer's purchase order exactly matches an active product that the supplying organisation has previously imported into the platform.
2. Check if the product/item code within the purchase order matches an alternate code previously imported into the platform by the customer organisation and the alternate code is marked as "Is Supplier Code". Then obtain the alternate code and check if it matches the product code of an active product that the supplying organisation has previously imported into the platform.
3. Check if the product/item code within the purchase order matches a supplier's product code that was previously matched on, based on a previous purchase order successfully being procured and converted into a supplier's sales order through the platform.
4. Check if the product/item code within the purchase order exactly matches an active product that the supplying organisation has previously imported into the platform.

Each of the checks are made sequentially and if one check succeeds then no further checks are performed. Note that even if a supplier's product can successfully be found that the customer must still be able to purchase the supplier's product based on the following:

• The product is active
• The customer organisation has permission to buy the product based on the data sharing policy the supplier organisation assigned to the customer organisation,
• The product has stock available or the customer organisation has permission to purchase out of stock products (based on the assigned data sharing policy)
• The product has at least one sell unit assigned to it
• The product has a taxcode assigned to it
• The product has pricing set for the customer account that the customer is buying the product with

For organisation's selling on the SQUIZZ.com platform, there are multiple features that can help manage and automate several processes around the costing of freight, dispatch, and delivery/shipping for ordered goods. This can heavily reduce manual key entry, reducing costs, saving time, and remove errors. This can be valuable when organisations are selling stock at volume, or dealing with large amount of orders with one or many customers. It can also be valuable for an organisation's customers, since they can know the cost of freight earlier, either during the order checkout process, or at the time when a  customer is pushing through a purchase order to be procured.

Customise Freight Surcharges For Sales Orders Using Rules

For an organisation selling on the SQUIZZ.com platform, at the time a sales order is being raised for a customer (individual person or another organisation purchasing), there is the ability to set a freight surcharge against the order. Using the Sales Orders Rules feature, the organisation selling can set up rules that determine when a freight surcharge should be applied to a sales order, and how much the surcharge should cost. Many highly customisable rules can be set up that can conditionally determine when a freight surcharge needs to apply. Rules can target many aspects of an order, such as the customer who's ordering, where they wish to have the ordered products delivered to (postcode, country, state/region, suburb), the types and quantities of products they are ordering, among many other aspects.

If the sales order has been raised in the Basket/Order Checkout process then the customer review the order seeing the freight surcharge costs. If the sales order has been raised by a customer using the procurement process to push through a purchase order, the sales order data returned to customer can include any surcharges. In both processes the customer can be aware of the freight costs at the time the order has been raised, and in cases update their purchase orders with this costing then, as opposed to waiting for the final invoice. This can provide greater certainty on costings for the customer, and may be important when they are ordering in bulk.

Integrate and Automate Freight Providers and Freight Carriers

When sales orders are raised against an organisation selling on the SQUIZZ.com platform, there is the capability to send the sales orders across to a freight provider system, to allow consignments to automatically be created in those systems. These consignments can then be assigned out to the organisation's chosen freight carrier(s), containing the neccessary order and freight data, whilst reducing manual data entry, either in the warehouse, and in the office.

At the time a sales order is raised for an organisation within the SQUIZZ.com platform, sales order rules can be set up that controls the freight provider that is assigned to handle raising the consignment with the designated freight carrier. Additionally the freight units can be determined, controlling how the ordered products can be packaged up and set in the consignment. Using sales order rules a different freight unit can be determined by looking at different data set within a sales order. For example a "Carton" freight unit could be set against an order when the order's total weight, volume, or a product's dimensions is over or under a certain threshold. By setting up these rules it may reduce the amount of workload for the dispatch staff within a warehouse, reducing manual key entry, and providing a guide for how to package the ordered products. This can also be used to determine any freight surcharges, and allow freight provider systems to more accurately cost the freight/shipping, as well as the freight carriers performing the deliveries.

Send and Automate Freight Delivery Notifications To Customers

For organisations selling the SQUIZZ.com platform there is a feature that allows freight delivery notices to be sent through the platform, that contain information about the goods being delivered to the customers (individual people and organisations). These delivery notices can contain several pieces of information, including who the freight carrier is, delivery status, location, sales order or invoice its relevant to, freight tracking code, among other details.

External software can use the SQUIZZ.com platform's to push through freight delivery notices, with the notices flowing all the way back to the customer systems. This can provide great levels of automation, allowing customers to have greater awareness of when ordered products can expect to be delivered, and have the notifications be viewable against their customer account, as well as for customer organisations to have delivery notices land in their own systems, against purchase orders and supplier invoices. This data can then be used further down the supply chain to provide better analytics and forward planning, reduce wait times and other inefficiencies.

After a person logs into the SQUIZZ.com platform, on the Home page there is a listing that features organisations who have registered on the SQUIZZ.com platform, passed its trust checks, and is actively selling on the platform. This listing can help an organisation gain awareness to the increasing user base in SQUIZZ.com, for an organisation that is actively selling on the SQUIZZ.com platform. This may lead to increased connections, either from individual people, or from other organisations who wish to set up trading relationships. The list can also highlight a small sample of products that the organisation may be selling, and if set up allow individual people to purchase those products directly from within the list (such as selling into the retail space), or lead people to the organisation's Product Catalogue page. This may lead to increased sales on the SQUIZZ.com platform.

Listing Requirements

The Featured Trusted Sellers listing will choose at random the trusted organisations to show in any one loading. To get an organisation on the list the following needs to have been set up:

• The organisation has been registered on the SQUIZZ.com platform.
• The organisation's Is Active setting is set to Active.
• The organisation's Trading Status setting is set to either "Fully Trading" or "Selling Only".
• An administrator person of the organisation has made a request to become trusted, and the trust request has been accepted.

To set the organisation's settings read Modify Organisation Settings.
Optionally to show products within the Featured Trusted Sellers listing the following needs to have been set up:

• On or more Products have been imported into the SQUIZZ.com platform and are active. Products have either been imported using the SQUIZZ.com Conenctor software, or other software that has called the platform's Application Programming Interface (API). 
• A Data Sharing Policy has been set up, and has set permissions that allows one or more products to be viewed, with the policy's View Products permission set to Yes. By default a policy is already set up when an organisation first registers.

Optionally to allow a product to show its pricing, be added to basket and purchased from the Featured Trusted Sellers listing the following needs to have been set up:

• Sell Units, Taxcodes, Price Levels and Product Pricing records have been imported into the SQUIZZ.com platform and .
• One or more Payment Type records have been imported into the SQUIZZ.com platform. For credit card payment types that a Payment Gateway has been set up.
• One or more Customer Account records have been imported into the SQUIZZ.com platform.
• A Selling Region has been set up, and a customer account assigned to it. This allows people not connected to the organisation to buy "retail" from the organisation, at the price that the Customer Account controls. Additionally the Customer Account is assigned to one or more payment types that determine the payment methods that customers can use to pay for the products being purchased.
• The Selling Region is assigned to a Data Sharing Policy that allows one or more products to be purchased, with the Buy Products permission set to Yes.

These requirements are also similar to selling to individual people or other organisations on the SQUIZZ.com platform outside of the Featured Trusted Sellers listing. An integration will most likely will need to occur between the organisation's business system to import many of the key records required to sell. See the Organisation Integration Guide and the Integrate Software Into SQUIZZ.com Platform page to learn more about how to integrate the organisation's data from its business systems or other data sources.

The "Send Invoice To Customer" Process allows an organisation to send invoices to its customers, by converting customer invoices into supplier invoices (also known as bills) for a customer. This conversion process can occur within the SQUIZZ.com platform by the customer when querying invoices from a connected business system, or it can occur by a supplier organisation's business system(s) pushing customer invoices into the platform through the Application Programming Interface (API). The Send Invoices To Customers process leverages all of the connections that the platform offers to both customers and suppliers to enable invoicing to occur, either in a completely automation fashion, or with human decision making involved.

Benefits Of The Send Invoices To Customers Processes

There are a number of using this process, which include:

• The supplier organisation does not need to do any manual data entry and customer invoices can flow automatically into the customer organisation's connected business system(s).
• The amount of processing required to do by the customer organisation is reduced, allowing invoices to enter the customer's organisation quicker, reducing data entry, and enabling payments to be made quicker back to the supplier organisation.
• The supplier organisation no longer needs to manually send invoices back to the customer using email, phone, fax, or mail.
• The customer organisation can see the exact cost to pay for the supplied goods and services, based on the latest invoice data being retrieved from the supplier organisation's system.
• The customer organisation can see the stock that has been delivered (or is being delivered) with an associated invoice.
• The customer organisation can automate purchasing, cutting down manual labour, time and costs from their end.

To view the details of an organisation's sales order created within the SQUIZZ.com platform you first must be connected to the organisation and be assigned to a People Group that has the View All Sales Orders permission set to Yes. Once you have the credentials then follow the steps below to find a sales order and view its details

1. Login to the SQUIZZ.com platform from the Home page or mobile app.
2. Click on the Organisations menu button in the top header bar.
3. Scroll through your connected organisations and find the organisation you wish to view sales orders for.
4. Click on the Sales Orders button.
5. Scroll down through the list of sales orders and find the sales order that you wish to view the details for. Alternatively in the Search Orders textbox type in the code of the sales order.
6. Click on the View link.

The Sales Order Detail dialog will display showing the details of the sales order, including the following:

• Sales Order Number
• Customer Account
• Sales Representative
• Billing Address
• Delivery Address
• Product Lines
• Activity
• Dispatching/Freight Data

After a customer has submitted a sales order to the supplying organisation, the platform can try to send the sales order to the supplying organisation's connected business system if allowed to. If the connection to the connected business system is unavailable or requires a person to send the order, then to do so you first must be connected to the organisation and be assigned to a People Group that has the Administer Sales Orders permission set to Yes. Once you have the credentials then follow the steps below to send or resend a sales order to a connected organisation's business system:

1. Login to the SQUIZZ.com platform from the Home page or mobile app.
2. Click on the Organisations menu button in the top header bar.
3. Scroll through your connected organisations and find the organisation you wish to send/resend a sales order with.
4. Click on the Sales Orders button.
5. Scroll down through the list of sales orders and find the sales order that you wish to send/resent. Alternatively in the Search Orders textbox type in the code of the sales order.
6. Next to the Order Status click on either the Send or Resent link.

The platform will try to send the sales order to the connected business system based on the system configured within the Connector Settings configured in the organisation's profile. If the order was successfully sent then  the sales order status will be changed to SENT.

After a customer has submitted a sales order to the supplying organisation, the platform can try to send the sales order to the supplying organisation's connected freight provider system if allowed to. If the connection to the connected business system is unavailable or requires a person to send the order, then to do so you first must be connected to the organisation and be assigned to a People Group that has the Administer Sales Orders permission set to Yes. Once you have the credentials then follow the steps below to send or resend a sales order to a connected organisation's freight provider system:

1. Login to the SQUIZZ.com platform from the Home page or mobile app.
2. Click on the Organisations menu button in the top/side header bar.
3. Scroll through your connected organisations and find the organisation you wish to send/resend a sales order with.
4. Click on the Sales Orders button.
5. Scroll down through the list of sales orders and find the sales order that you wish to send/resent. Alternatively in the Search Orders textbox type in the code of the sales order.
6. Next to the Freight Order Status click on either the Send or Resend link.

The platform will try to send the sales order to the connected freight provider system based on the system configured within the Freight Providers section, configured in the Admin section of an organisation's profile. If the order was successfully sent then  the freight order status will be changed to SENT.

Troubleshooting

If the order fails to send to a freight provider's system, there could be a number of reasons for this, they are:

• The Squizz.com platform cannot connect to the freight providers system, either their system is offline, unaccessible, or is experiencing high demand.
• The Squizz.com platform fails to receive a response from the freight providers system in a timely manner. Either the freight provider's system is taking too long to process the order, or it fails to return a response. The Squizz.com platform will give up if it receives no response within 60 seconds.
• The freight provider's system is failing to connect to other software, such as freight carriers, or its own software hosted on a business's own premises. This could also be due to network/internet connection issues.
• The internet that connects the Squizz.com platform is unavailable.

When these issues occur you can try the following troubleshooting steps:

• When sales orders cannot be sent to a freight provider then check that the Freight Provider settings have been correctly configured in SQUIZZ.com. This can be found by an Administrator person of the organisation by going to the organisation's profile, viewing the Admin section of the organisation, clicking on Freight Providers, and viewing the freight provider that is being used to submit the order. The freight provider that does this configured within the Sales Order Rules.
• If orders were previously being submitted then check with your freight provider that its servers are up and not experiencing technical difficulties.
• If you are running freight provider software on your own premises check that it is running and your freight provider can connect to it. Check that your premises internet connection is still running.
• If after investigating these steps your freight provider has advised that their service is running as expected then fill out the Report Feedback/Issue form in SQUIZZ.com to advise us of the issue and for us to investigate further.

Each organisation registered on the SQUIZZ.com can setup and give the option for customers to pay for sales orders and invoices with credit card payments. This can help organisations to get paid quicker, by making it easier for customers to access orders and invoices without out having to login to separate websites and systems. Once an organisation has connected their business system into the platform and setup a payment gateway, then the organisation can offer multiple payment options to selected customer accounts.

Requirements

To allow customers to pay for invoices with credit card payments the following requirements need to be met by an organisation:

• The organisation is registered on the SQUIZZ.com platform
• Customer accounts have been imported into the SQUIZZ.com platform, by either using the SQUIZZ.com connector, or other software that talks to the platform's API.
• At least one payment type has been imported into the SQUIZZ.com platform and its payment method is set to Credit Card. Payment types can imported by either using the SQUIZZ.com connector, or other software that talks to the platform's API.
• The credit card payment type has been assigned to the customer accounts that are allowed to pay for sales orders and invoices with, and these relationships have been imported into the SQUIZZ.com platform with the customer acocunt data.
• The organisation has setup a merchant bank account with a preferred bank. Choose a bank that supports a payment gateway that integrates with the platform. See Payment Gateways for a list of payment gateway providers that the platform supports.
• The organisation has signed up to a payment gateway provider that is supported by the SQUIZZ.com platform. See Payment Gateways for a list of payment gateway providers that the platform supports.
• For invoice payments the organisation has connected their business system to the platform, and allows SQUIZZ.com to request the invoice data. The SQUIZZ.com Connector can be setup as a web service that acts as a bridge for retrieving invoices from a connected business system. Alternatively certain business software may support retrieving invoice data directly, or else software can be written that conforms to the platform's request format, see the Get Supplier Account Enquiry Records and Get Supplier Account Enquiry Record outgoingAPI endpoints.
• The currency of the organisation's invoices matches the currency set in the organisation's settings.

Setup A Payment Gateway

To allow customers to payment for sales orders and invoices with credit card payments an organisation must first have set up a merchant bank account with a bank, then signed up to a payment gateway provider linked to their merchant bank account. Once this is done then in the SQUIZZ.com platform a payment gateway can be set up. To do so you must first be an administrator of the organisation that you wish to set up the payment gateway. Follow these steps to set up a payment gateway:

1. Login to the SQUIZZ.com platform from the Home page or mobile app.
2. Click on the Organisations menu button in the top header bar.
3. Scroll through your connected organisations and find the organisation you wish to setup a payment gateway for.
4. Click on the Profile button.
5. Within the organisation profile click on the Admin button.
6. Click on the Payment Gateways button.
7. Click on the Add Payment Gateway button.
8. In the Payment Gateway dialog for the Payment Gateway Type select the payment gateway provider that the organisation has set up a payment gateway with.
9. In the Payment Gateway Code field set a code that allows the payment gateway to be uniquely identified within the platform.
10. In the Gateway/Customer ID field set the identifier or customer ID that was issued by the payment gateway that is required to be passed to the payment gateway when a credit card payment is made.
11. In the Payment Gateway Password field set the password that the payment gateway gave you that is required to be passed to the payment gateway when a credit card payment is made. Note that same payment gateways may not require a password to be set. Also note that the password may not be the same password to login into the payment gateways web interface.
12. In the Accepted Card Types tick from the credit cards that you wish to allow customers to be able to make payments with.
13. Click on the Save button.

The payment gateway will then be created for the organisation. Before it can be used by customers the payment gateway needs to be assigned to a payment type.

Assign A Payment Gateway To a Payment Type

Assigning a payment gateway to a payment type allows organisations to control which payment gateways selected customers use to make credit card payments with, since payment types are assigned to selected customer accounts.  To assign a payment gateway to a payment type a payment gateway must first be created (see steps above) and a payment type imported into the SQUIZZ.com platform that has the payment method set to Credit Card. Once this has be set up and you are administrator of an organisation follow these steps below to assign a payment gateway to a payment type:

1. Login to the SQUIZZ.com platform from the Home page or mobile app.
2. Click on the Organisations menu button in the top header bar.
3. Scroll through your connected organisations and find the organisation you wish to setup a payment gateway for.
4. Click on the Profile button.
5. Within the organisation profile click on the Admin button.
6. Click on the Payment Types button.
7. Click on name of an imported payment type that has its payment method set to Credit Card.
8. In the Payment Type Detail dialog, in the Payment Gateway Code field set the code of payment gateway.
9. Click on the Save button.

The payment gateway will now be assigned to the payment type. Any customer accounts assigned to the payment type will allows the accounts sales orders and invoices to be paid for with the credit card payment method.

Setup A Surcharge For a Credit Card Payment Type

Within the SQUIZZ.com platform there is the ability to assign a surcharge to a credit card payment type, when this occurs the customer paying for selected invoices with a credit card will be charged an additional fee. The surcharge fee can be based on a fixed monetary amount, or based on a percentage fee of the invoice totals being paid. By adding a surcharge to a credit card payment type an organisation can offset the cost of the transaction incurred by the payment gateway or other banking services. To set up a credit card surcharge a surcharge record first needs to be imported by the organisation into the SQUIZZ.com platform. Once a surcharge exists an you are an administrator of the organisation follow these steps to assign a surcharge to a credit card payment type:

1. Login to the SQUIZZ.com platform from the Home page or mobile app.
2. Click on the Organisations menu button in the top header bar.
3. Scroll through your connected organisations and find the organisation you wish to setup a payment gateway for.
4. Click on the Profile button.
5. Within the organisation profile click on the Admin button.
6. Click on the Payment Types button.
7. Click on name of an imported payment type that has its payment method set to Credit Card.
8. In the Payment Type Detail dialog, in the Surcharge Code field set the code of surcharge you wish to apply against the payment type.
9. In the Surcharge Priced As drop down choose the Percentage option if you wish to have the surcharge priced a percentage of the amount being paid. Choose the Fixed Price option if you wish to set a flat fee that the surcharge is applied at.
10. If the Percentage option is chosen in step 9 then in the Surcharge Price Percentage field set percentage number.
11. If the Fixed Price option was chosen in step 9 then in the Surcharge Fixed Price field set a monetary amount that the surcharge will be priced at.
12. Click on the Save button.

The surcharge will be assigned to the payment type, and charged when a credit card payment is made against invoices associated to a customer account that has the payment type assigned to it.

Tip: You may wish to set up multiple payment types and payment gateways, and give customers multiple options to pay for invoices with different payment methods based on different surcharge rates. For example a payment gateway could be set up to only accept Visa credit cards, and incur a %1.5 surcharge, where as a different payment gateway could be set up to only allow Mastercard payments and be assigned to a payment type that has a fixed 50 cents surcharge fee.

Note that some countries may have laws that restrict the total surcharge amount that you are allowed to add on top when paying for invoices.

Also note that some accounting and other business systems may not support applying a surcharge amount directly to an invoice payment. In such sytems it may require a separate invoice to be created that covers solely the surcharge amount.

When an organisation's business system sends a purchase order to a supplier organisation through the SQUIZZ.com API's Procure And Send Purchase Order To Supplier endpoint, there is the ability for administrator people of the supplier organisation to view the logs of the order procurement attempt made by the customer. To do so a person must first be connected to the supplier organisation as an administrator user, then follow these steps to the see the procurement reports:

1. Login to the SQUIZZ.com platform from the Home page or mobile app.
2. Click on the Organisations menu button in the main navigation bar.
3. Scroll through the organisations and find the organisation you wish to view the reports for.
4. Click on the Profile button.
5. In the organisation's profile, click on the Admin button.
6. Under the Reports section click on the Order Procurement By Customers History button.
7. View the list of order procurement attempts, to see the detalis of an attempt click on the date time link for the report.

Within the report's dialog you can be several details about the procurement attempt. If the Result is set to Failure then the purchase order failed to be converted into a sales order for the supplier organisation. This could happen for several reasons, look at the Result Code to determine the reason, based on the following result codes:

• SERVER_SUCCESS
  The purchase orders were successfully procured, converted into sales orders and sent for processing in the supplier organisation.
   
• SERVER_ERROR_ORG_DOES_NOT_EXIST
  The supplier organisation with the given organisation ID could not be found or is not active within the platform. Check with the supplier organisation that their organisation ID issued by the platform is correct.
   
• 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_ORG_CUSTOMER_ACCOUNT_SET
  The supplier organisation has not assigned any customer account to the customer organisation. The supplier organiation needs to import and assign the customer organisation to a customer account.
   
• SERVER_ERROR_NO_ORG_CUSTOMER_ACCOUNT_ASSIGNED
  The supplier organisation has not assigned any customer account to the customer organisation. The supplier organiation needs to import and assign the customer organisation to a customer account.
   
• SERVER_ERROR_CUSTOMER_ACCOUNT_NO_ACCOUNT_PAYMENT_TYPE
  The supplier organisation's customer account assigned to the customer organisation does not have any On Account payment type assigned to it. Because of this the customer organisation cannot pay for the ordered products. The supplier organisatio may need to import an On Account payment type into the platform, and assign the customer account to this payment type if it wishes to allow the customer organisation to purchase.
   
• SERVER_ERROR_ORDER_PRODUCT_NOT_MAPPED
  One or more of the products in the purchase orders received cannot be mapped to the supplier's products, or the supplier's products were found but are out of stock, or the customer orgaqnisation does not have permission to purchase the products (based on the data sharing policy that the customer organisation is assigned to).  See the "Unmapped Lines"  field to determine the lines within the purchase orders that have been unmapped and may require a person to resolve. In the "Unmapped Lines" field the number before the colon is the index of the purchase order (ie. if it is 0, then it indicates the first purchase order sent in the one request), the number after the colon is the index of the purchase order line number that was the problem (ie. if it is 0, then it indicates the first line of purchase order sent in the one request, if it is set to 5 then its the 6th line of the purchase order).
   
• SERVER_ERROR_ORDER_MAPPED_PRODUCT_STOCK_NOT_AVAILABLE
  All of the products in the purchase orders received was able to be matched to the supplier organisation's products, however one or more of the supplier's product was out of stock.  See the "Unstocked Lines"  field to determine the lines within the purchase orders that don't have stock available and may require a person to resolve. In the "Unstocked Lines" field the number before the colon is the index of the purchase order (ie. if it is 0, then it indicates the first purchase order sent in the one request), the number after the colon is the index of the purchase order line number that was the problem (ie. if it's 0, then it indicates the first line of purchase order sent in the one request, if it is set to 5 then its the 6th line of the purchase order).
   
• SERVER_ERROR_ORDER_MAPPED_PRODUCT_PRICE_NOT_FOUND
  One or more of the products in the purchase orders received was matched on a supplier's product, however no pricing could be found for the product(s) based on the customer account assigned to the purchasing organisation. Because of this the platform is unable to price the supplier's product. This would indicate either that the supplier organisation has intentionally not set a price for the customer account, thus not giving permission to sell the product to the customer organisation, or the supplier organisation has not imported pricing for the product(s) into the platform as yet. See the "Unpriced Lines"  field to determine the lines within the purchase orders that have been unpriced and may require a person to resolve. In the "Unpriced Lines" field the number before the colon is the index of the purchase order (ie. if it is 0, then it indicates the first purchase order sent in the one request), the number after the colon is the index of the purchase order line number that was the problem (ie. if it's 0, then it indicates the first line of purchase order sent in the one request, if it is set to 5 then its the 6th line of the purchase order).
   
• SERVER_ERROR_ORG_NOT_ENOUGH_CREDITS
  The supplier organisation does not have enough trading tokens within the platform to allow the sales orders to be created, or if the supplier has designated that the customer organisation must pay for the trading tokens then the customer organisation does not have enough trading tokens. Either the supplier needs to purchase more trading tokens to allow it to sell products and generate sales orders through the platform, otherwise if the customer is paying for the trading tokens then an administrator person of the organisation needs to purchase more trading tokens.
   
• 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.

If the Result Code canoot be found in this list then check to the Procure And Send Purchase Order To Supplier endpoint documentation for a full list of codes.

Note that administrator people of the customer organisation can also see these order procurement attempts by looking at the Order Procurement With Suppliers History Reports within the Admin section of their own organisation.