Welcome
Login  Sign up

April 2022

Planned release to production in May 10, 2022

Expanded Barcode and Alternate Type 2 Handling 

As we are seeing more and more retailers adopting the newer GS1 barcode standards, ShopperKit is now introducing our way of supporting these expanded, multi-part barcodes. Rather than taking a pre-defined or fix-format approach, we are allowing retailers to define the exact schemas that they will be using in their operations. Ultimately, when using these types of barcodes, ShopperKit is going to need to understand how to validate the product and parse out any weight or price values.  The way these barcodes work is that in the barcode there are key values that indicates attribute type and the characters immediately following the key value will make up the attribute value.

An example is a user could scan a 17 character barcode where the scanned value of 01028042520300243203004555

In this particular example the UPC value is represented in GTIN format as 02804252030024

and this also contains a weight value of 4.555. As such in this barcode the first key is GTIN and the value is 01 with a position of 0. The second key is Weight with a value of 3203. Following that is 004555 and weight here has an implied precision of 3. This of course is a just a single example and there could be multiple formats.

To accommodate these various barcodes, we have introduce a new ExpandedBarcode JSON based attribute using schema below. This object will allow users to define multiple expanded barcodes and will instruct ShopperKit how to parse these barcodes to understand the product identifier, price and weight values when scanning items with matching barcode lengths.

When scanning product barcodes in shopping flow, ShopperKit tests the length of the scanned value. We will expect that expanded barcode values will be greater than in length than UPC-A or EAN-13 barcodes. When the scanned barcode is 14 characters or more, we will look to see if the scanned length matches any of the defined expanded lengths. The assumption here is that we will only have one unique definition per length. Based on the length, we will then select the Expanded barcode format and using the definition data, interpret the barcode.

Expanded Barcode Schema

{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"title": "ExpandedBarcode Schema",
"properties": {
  "ExpandedBarcode": {
    "type": "arrary",
    "items": [{
      "type": "object",
      "properties": {
        "name": {
          "description": "friendly name for expanded barcode format definition",
          "type": "string"
        },
        "barcodeLength": {
          "description": "character length of format",
          "type": "number"
        },
        "attributes": {
          "type": "arrary",
          "items": [{
            "type": "object",
            "properties": {
              "attributeType": {
                "description": "Indicates the type of attribute for the value. ShopperKit only cares about product, price and weight. other must be defined but will not be used",
                "enum": [
                  "product",
                  "price",
                  "weight",
                  "other"
                ],
                "type": "string"
              },
              "position": {
                "description": "indicates the starting position in the barcode that the attribute appears starting from 0",
                "type": "number"
              },
              "keyValue": {
                "description": "indicates the character value of the attribute key value",
                "type": "string"
              },
              "attributeLength": {
                "description": "indicates the length of the attribute value immediately following the defined key value",
                "type": "number"
              }
            }
          }]
        }
      }
    }]
  }
  }
}

Expanded Barcode example definition

{
  "ExpandedBarcode": [
    {
      "name": "weight embedded",
      "barcodeLength": 17,
      "attributes": [
        {
          "attributeType": "product",
          "position": 0,
          "keyValue": "01",
          "attributeLength": 14
        },
        {
          "attributeType": "weight",
          "position": 16,
          "keyValue": "3203",
          "attributeLength": 6
        }
      ]
    },
    {
      "name": "price embedded",
      "barcodeLength": 26,
      "attributes": [
        {
          "attributeType": "product",
          "position": 0,
          "keyValue": "01",
          "attributeLength": 14
        },
        {
          "attributeType": "price",
          "position": 16,
          "keyValue": "1234",
          "attributeLength": 6
        }
      ]
    }
  ]
}

In addition to the above, we have also introduced some alternate handling for traditional Type 2 UPCs. While most retailers continue to use price embedded Type 2, we have introduced the Type2WeightOverride attribute to allow ShopperKit to read the embedded value as weight. When this attribute is set, ShopperKit will use the embedded value as the literal weight value vs. attempting to calculate the weight based on the embedded price.

Notifications User Level Opt Out

Since rolling out our Arrival Notification features, a somewhat common request has been to provide a way to suppress these notifications from automatically going out to all users. With this release, we have introduced a new user level permission that will allow you to disable arrival notifications for specific users. From the user management screen in the client portal, you will now notice a new Receive Arrival Notification permission. By default, this permission is enabled for all users. By toggling this option off, ShopperKit will stop sending notifications to devices that the user is logged into.

Appliance Mode Label Reprint

In certain situations retailers may not want to configure label printers to connect to devices using the traditional Wifi or Bluetooth connections and instead use the label printer in appliance mode (appliance mode implies a stand alone label printer with an attached scanner). In this mode, instead of sending the ZPL to the printer, ShopperKit will generate an onscreen QR code that contains the ZPL instructions for the label being reprinted. From here you may scan the QR at the label printer to print the label. To enable this mode, you will need to enable the EnableReprintContainerLabelQR attribute and configure the device for No Printer.


Improved Support for Concurrent Printing

In certain extreme circumstance, when multiple users are attempting to print label batches to Wifi connected printers at the same time, we have seen instances of labels getting mixed up between batches. To better support these concurrent printing scenarios, we have introduced a new method of printing label batches over wifi that is enabled by setting the BatchWiFiZPL attribute to True. With this attribute set, ShopperKit will send the entire label batch to the printer as a single ZPL file, thus eliminating the opportunity for labels to get mixed up across batches.

Zone Picking Order List

As zone picking is intended to be action oriented with a focus on picking efficiencies, there is no value in showing staged orders in the zone picking list. With this release, the Zone order list will only show orders that have pending picks to be completed. Once an order has been picked and staged it will drop from the Zone order list. This will allow associates to focus only on those orders still needing to be picked. The All orders view will continue to show staged orders however.

Additional POS Integration Support

ShopperKit has recently added integration support for NCR Emerald and ECRS Catapult.

Defects

  • Fixed issue that would intermittently cause label printing media settings to revert to ZPL-Black Bar when gap media had been defined for the device.
  • Fixed issue that was causing expired carryout notifications from being broadcast to devices.
  • Fixed intermittent issue that prevented picking an item due to failure to create a container.
  • Corrected issue that was preventing Rules Management - Lead Time Rules from properly triggering application notifications
  • Fixed the regression issue that would occasionally leave substituted or added items displaying a Ready status despite actually being picked.
  • Fixed the issue that prevented Store Managers from being able to see all users for stores they have permissions to.
  • Fixed communication issue with Onfleet integration
  • Order Summary report will now correctly respect the store level time zone settings.
  • Fixed issue preventing the Smart Sub badging feature from working properly.
  • Fixed issue preventing the Same Day Order option in Rules Management from triggering as expected.
  • Fixed the issue that prevented users from being able to cancel orders when accessing the order details through the menu order search function.
  • Fixed issue in Cartonization that would allow single unit items to be assigned multiple labels when that item exceeds container volume.
  • Fixed issue in Cartonization that would generate multiple labels for an item when the item volume was zero.
  • Fixed issue in Client Portal that prevented the lead time value on the FST from being edited. 
  • Fixed issue that prevented the order status from moving to In Progress when the first item actioned in the pick list was Shorted.
  • Fixed issue with the location upload process handling large files.
  • Corrected the Client Portal User management pages to enforce same password length requirement when adding and editing users.
  • Corrected the Recall barcode on the order summary report to ensure it uses same symbology as the POS recall screen in the mobile application.
  • Fixed issue in staging workflow that kept the focus on the storage screen instead of moving back to cart screen when there were still more containers to stage.
  • Fixed issue specific to Zebra TC52 running android 11 that prevented the camera in the chat client from launching as expected.