Documentation
Order Routing
Orders can be routed from external systems.
Back to Order Status and Lifespan
Routed Orders Originate in External Systems
In Order Routing, Orders originate on another system, and are passed to HaggleDigital for matching. The Order can store information identifying the external customer, such as their ID or login name, together with an external sales reference or unique order identifier. This information is propagated into the Fills during execution. When Fills are downloaded, an Owner of a Market will be able to see the customer and sales reference data that originated on their own system, and relate those Fills back to the activity on their own system for settlement and fulfilment.
When an Order is sent to the system via the API, there are two free-text fields available that the caller can use to store their own information, OnBehalfOf and ClOrdID. These fields ride along with the Order throughout the Order lifespan, and are recorded on the Fills when an execution occurs.
When Order Routing is used, you only need one actual login on HaggleDigital. As far as the system is concerned, the single User is just placing Orders on both sides of their own Markets and trading against themselves. The "real" data about who is trading is contained in the OnBehalfOf and ClOrdID fields. System usage is charged to the single HaggleDigital User, so there is just one invoice for this service.
Customer ID Data: OnBehalfOf
The OnBehalfOf field is a free-text field that allows the caller to add data identifying the customer who placed the Order. This might also be used to identify the employee (or process ID) for Orders that are placed to match against customer Orders.
External Reference Data: ClOrdID
The ClOrdID field is also a free-text field that the caller can populate with their own data, such as an internal Order ID, or sales reference code. The idea is that when Fills are downloaded, the price agreements can be related back to the customer's interaction data.
An Order Routing Scenario: JustDoIt Shoes
A company, JustDoIt, sells sports shoes. Some shoes become fashion items and sell out quickly; other models fall out of favour and build up in the warehouses. Supply and demand are affected by sporting, seasonal and fashion trends, so JustDoIt would like to use price negotiation to take full control of sales and maximise profits.
The JustDoIt website has a "Make a Bid!" button added near the checkout button for each product page. The customer can check out with the fixed price as normal, or they can hit "Make a Bid!" and put in the price they would be happy to pay for that shoe.
JustDoIt have set up a Market for each shoe model, and have an employee, Alice, who will be selling shoes in these Markets. Alice will have a brief for how many shoes to sell, how over- or under-stocked each model is, and how low she can go with each model. Alice might be an AI. Who can say.
When the JustDoIt customers make a bid, their username is recorded in each Order's OnBehalfOf field, and a unique sales reference is recorded in the ClOrdID field. The Orders are sent to this system's API to go into the relevant shoe model Markets. Alice sees the Buy Orders and places Sell Orders to match against the best of them.
Each time there is an execution, Fill records are created. These Fill records hold the customer (OnBehalfOf) and originating sales reference (ClOrdID) that was stamped into the JustDoIt Order when the customer hit "Make a Bid!". The JustDoIt techies have a system that polls the Markets for Fills, and finds the agreements that Alice and the customers have created. The current JustDoIt fulfilment process now continues as normal, with the only difference being that the price each customer is charged is tailored to that customer.
Depending on their sales strategy, JustDoIt might choose to show customers the current Price data, including Alice's offers, before they click "Make a Bid!". How much Price data is shown to customers, and how and when that data is presented, is controlled by JustDoIt.
This gives JustDoIt the ability to offer short-lived, customer-specific discounts at the moment a customer is considering a purchase. This could reduce the need for flash sales to clear stock backlogs, and for the promotional campaigns that accompany those sales.
JustDoIt for the Win!
JustDoIt shoes get the following out of this:
- Control of Supply and Demand: JustDoIt can adjust prices in real time and choose which customer bids to accept, thereby maximising profit on hot lines and stimulating sales of slow-moving models.
- Minimum Technical Impact: The Market is accessible via API, so web-development is limited to making API calls.
- Minimum Investment: The electronic Market can be inserted into the price agreement stage while the rest of the fulfilment process, payment and delivery, are unchanged.
- Price Privacy: Prices agreed with customers are one-to-one, and competitors have no idea what discounts or premiums JustDoIt are using.
- Only One Login: JustDoIt have one system login and one HaggleDigital invoice, but route multiple Orders from both customers and employees through that login.
Average Limit Orders
LIMIT Orders adhere to their price limit at every execution. Average Limit Orders can take advantage of price improvements to increase the quantity that can be executed while respecting the price restriction.