Product Documentation
Home » Rover ERP Overview » Rover Hub Overview » Integrations » Rover POS

# Rover POS

Read Time: 6 minute(s)

This article describes how to integrate your back end to various Rover POS features.

# Table of Contents

# Validation Codes

These validation codes are used to determine which section of POS triggered an API call to validate the current sales order.

Code Description
CUSTOMER_SELECTED Selecting a customer to create a new order.
ORDER_INFO_SELECTED Navigating to the order information section
EDIT_ORDER Selecting an order to edit.
PARTS_SELECTED Navigating to the parts sections.
DRAFT_ORDER Selecting a draft order to edit.
LIS_ITEM Add/Edit/Remove a part from the cart.
SHIP_SEQ Selecting a new shipping address

Additionally, support for specific fields in the Order Information section can trigger a validation if the field has a defined FDICT and has web_validate flag enabled.

# Validation Prompts

To enable a prompt to display after an error or confirmation. Add this information to the response from the validation API. A modal will appear and once a selection is made a subsequent validation API call will be made with the selection chosen.

Sample of the validation response

{
    "errorDisplay": {
        "cancelButtonLabel": "Cancel Custom",
        "confirmButtonLabel": "Confirm Custom",
        "confirmValidate": true,
        "dialog": false,
        "errors": [
            "Item xxx can only be sold in qty of yyy, do you wish to override?"
        ],
        "warning": false
    },
    "record": { /* record information goes here */},
    "recordId": "",
    "status": "error"
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Sample of the validation request override confirmation/dismiss

{
    "metaData": {
        "validate_override": "Y" // or "N" on Cancel
    }
}
1
2
3
4
5

# Partial Ship Fields

MRK.CONTROL response JSON format to show additional fields in the POS Partial Ship section.

{
    "pos_partial_ship_field_items": [
        {
            "pos_partial_ship_field": "46" // Ship Quantity
        },
        {
            "pos_partial_ship_field": "101" // Vendor
        },
                {
            "pos_partial_ship_field": "103" // PO Number
        },
        {
            "pos_partial_ship_field": "80" // Custom field 1
        }
    ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# Show Orders Tab

MRK.CONTROL response JSON format to show the orders tab in the customers selection within POS.

{
    "pos_show_orders_tab": "Y"
}
1
2
3

Requires SO.E or PSO.Eto be defined in the user commands. If command rights are enabled, view must be set to true.

# Show Quotes Tab

MRK.CONTROL response JSON format to enable the quotes tab in both the main tab as well as the customers selection within POS.

{
    "show_soquote_tab": "Y"
}
1
2
3

Requires SOQUOTE.E to be defined in the user commands. If command rights are enabled, view must be set to true.

# Show Opportunities Tab

MRK.CONTROL response JSON format to show the opportunities tab in the customers selection within POS.

Requires SALEOPP.E to be defined in the user commands.

{
   "pos_show_opp_tab": "Y"
}
1
2
3

# Calc Price

calc_price is a field that replaces the POS price calculation based on std_price_items and code_items. This allows the host to calculate the price and skip any price calculation on the client side.

The PRICE FDICT should include the correlative CALC with the following format:

{
 "fdict_items": [
  {
   "file_name": "PRICE",
   "correl_field_no_items": [
    {
     "correl_field_no": "0",
     "correl_desc": "Calc.Price",
     "correl_conv": "MD4",
     "correl_dict_id": "CALC.PRICE",
    }
   ]
  }
 ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

The PRICE API response will allow need to include calc_price with parts returned.

{
    "price_items": [
        {
            "part_number": "93",
            "calc_price": "6.0000"
        },
        {
            "part_number": "94",
            "calc_price": "7.0000"
        }
    ]
}
1
2
3
4
5
6
7
8
9
10
11
12

# Lookups

POS supports the use of database lookups to drive searches and tabular data in various sections. Generally speaking, the value expected for these lookup properties follows the format of FILE*LOOKUP.NAME i.e. "INV*LASTPRICE".

Those values are used in conjunction with API calls to the doLookup endpoint which is used to dynamically interact with the back end to process lookups. An example request is shown below:

{
    "lookupName": "LASTPRICE",
    "id": "10",
    "file": "INV",
    "parameters": {
        "coCode": "1",
        "custId": "71",
        "parts": "10"
    },
    "filters": {},
    "fullRecords": false
}
1
2
3
4
5
6
7
8
9
10
11
12

Your response should include an array called data to contain the data and an array called fDicts to contained the data schema. An example response is shown below:

{
    "data": [
        {
            "date": "03/30/22",
            "invoice": "4966869",
            "qtysold": "1",
            "price": "113.090",
            "branch": "1 Rochester",
            "writer": "Tester",
            "shiptoname": "Zumasys",
            "customer": "123"
        }
    ],
    "fDicts": [
        { 
            "conv": "D",
            "dict_name": "date"
        },
        { 
            "conv": "",
            "dict_name": "invoice"
        },
        { 
            "conv": "",
            "dict_name": "qtysold"
        },
        { 
            "conv": "MR3",
            "dict_name": "price"
        },
        { 
            "conv": "",
            "dict_name": "branch"
        },
        { 
            "conv": "",
            "dict_name": "writer"
        },
        { 
            "conv": "",
            "dict_name": "shiptoname"
        },
        { 
            "conv": "",
            "dict_name": "customer"
        },
    ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

# Customer Lookup

To add an alternative Customer Lookup, your MRK.CONTROL response needs to include a property called pos_customer_lookup. Omit or set as empty string to keep the original customer lookup table.

{
    "pos_customer_lookup": "CUST*POS.LOOKUP"
}
1
2
3

# Inventory Lookup

To enable Inventory Lookups, your MRK.CONTROL response needs to include an array called pos_inv_lookups_items. This array is optional and you are free to omit if you do not want to add inventory lookups. As this section allows for an array of lookups, the inv_lookup_desc property is used to present a user friendly description to select from for display purposes.

{
    "pos_inv_lookups_items": [
        {
            "pos_inv_lookups": "INV*LASTPRICE", "inv_lookup_desc": "Last Price Paid",
            "pos_inv_lookups": "INV*ALLOCATION", "inv_lookup_desc": "Order Allocation"
        }
    ]
}
1
2
3
4
5
6
7
8

# Order Lookup

To add an alternative Order Lookup, your MRK.CONTROL response needs to include a property called pos_search_orders_lookup for the search and pos_customer_orders_lookup for the customer tab. Omit or set as empty string to keep the original order lookup table.

{
    "pos_search_orders_lookup": "SO*POS.LOOKUP",
    "pos_customer_orders_lookup": "SO*POS.CUST.LOOKUP"
}
1
2
3
4

# Quote Lookup

The lookup for quotes is required to be set in the MRK.CONTROL response. Add pos_soquote_lookup and pos_cust_soquote_lookup to your response to view in POS for both the main and customer tabs.

{
    "pos_soquote_lookup": "SOQUOTE*POS.LOOKUP",
    "pos_cust_soquote_lookup": "SOQUOTE*POS.CUST.LOOKUP"
}
1
2
3
4

# Categories and Filters

You can provide custom categories to your users to select from with the CAT.CONTROL API. Each category object within can contain an array called subcategories containing more categories allowing you to create as many levels of depth as your system requires. An example JSON response is shown below:

[
    {
        "control_id": "CAT",
        "category_items": [
            {
                "category": "plumbing",
                "description": "Plumbing",
                "subcategories": [
                    {
                        "category": "plumbing-plumbing-specialties",
                        "description": "Plumbing Specialties",
                        "subcategories": [
                            {
                                "category": "plumbing-plumbing-specialties-vacuum-breakers",
                                "description": "Vacuum Breakers"
                            }
                        ]
                    }
                ]
            }
        ]
    }
]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Filters present an additional level of power as they allow you to display different dropdown filters at the header of the parts table and those filters can be made dynamic based on the search results you are returning with your prices endpoint response. To do this, make sure your prices response includes a control_items array, top level next to your current price_items array. An example is shown below:

"control_items": [
        {
            "control_id": "WEB",
            "web_category_items": [
                {
                    "web_category": "Brand",
                    "web_category_title": "Brand",
                    "web_category_description": "Brand"
                },
                {
                    "web_category": "3M",
                    "parent_category": "Brand",
                    "web_category_title": "3M",
                    "web_category_description": "Brand"
                }
            ]
        }
]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

In this example, "Brand" serves as the top level filter and "3M" is an option within. Do not be confused by the use of the term category here even though we're describing filter functionality.