Warning
WARNING: The TrackAbout MetaWiki has been deprecated and is no longer being updated. Please visit our new TrackAbout Knowledge Base at https://supportkb.trackabout.com for the most-up-to-date documentation on TrackAbout and TrackAbout Mobile.

Proof of Delivery (Paperless Delivery)

From TrackAbout MetaWiki
Revision as of 08:08, 21 September 2020 by Eschurdak (talk | contribs) (→‎Orders Requirements)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


TrackAbout Module
Module Name: Proof of Delivery (Paperless Delivery)
Short Description TrackAbout’s Proof of Delivery module allows drivers and dock workers to record customer deliveries without needing a paper copy of the order.
Supported In: TAMobile 5, TAMobile 6 Rugged, TAMobile 6 Desktop, TAMobile Android, TAMobile iOS
Business Process: Asset Management, Distribution, Supply Chain
← Back to list

<< Back to Module Overviews

The Problem

  • You spend a lot of time and money managing a paper-based delivery process
  • Your drivers have a hard time correctly recording the part number of returned assets

Overview

The Paperless Delivery Module allow drivers and dock worker to record deliveries to customers without starting with a paper copy of the order. After the delivery the data can be sent back into the business system. Below are the high level steps in the process:

  • Order entry done in business system
  • Orders sent to TrackAbout through integration
  • Truck is loaded and counted in TrackAbout
  • Inventory on truck is compared to orders (Using Truck Load Module)
  • DOT truck manifest is created (Using Truck Load Module)
  • Driver makes deliveries with handheld assigned to his route
  • Handheld alerts driver if delivery is not complete
  • Driver prints receipts if needed
  • Truck contents are counted at end of day (Using Truck Load Module)
  • Truck is reconciled (Using Truck Load Module)
  • Updated orders are sent to business system
PaperlessDeliveryFlow.jpg

How does it work?

Proof of Delivery is broken into 4 phases:

  1. Order Entry
  2. Order Management
  3. Deliveries/Returns/Transfers
  4. Delivery Verification and Reconiliation

Phases of Proof of Delivery

Order Entry

Billing Codes

Billing code are needed by some customer to help them bill properly based on asset ownership during paperless deliveries. A Billing Code is a short code that is used in some accounting systems for pricing of products for delivery and also for pricing of cylinder rental. This is not a permanent property of the asset. It is just the code under which the asset was transferred to the customer on a given order. Some gas distributors use the billing code in their accounting system to bill for the same type (e.g. product code/asset type) of asset differently based on whether or not that asset is owned by the target customer. They send TrackAbout this "billing code" via paperless delivery integration because they need it when actually picking which cylinders are going to get left with which customers and they need it to reconcile with their accounting system via invoice comparison later on.

Sample billing codes

  • GD = Gas Distributor (Company name code). Indicates that the customer is to be charged for the gas in the cylinder as well as for rental.

For these next three codes, the customer pays for the gas, but does not pay rent for the cylinder.

  • CO = Customer Owned
  • EX = Exchange
  • NR = Not Returnable

Why have both Ownership and Billing Code?

In an ideal world the Ownership and the Billing Code would be the same thing, but in practice we need two separate fields for this common case: Cylinders flow from the Gas Distributor (GD) to EX Billing Code and back again. A cylinder with an Ownership = "Gas Distributor ACME" could be delivered as either an "EX" or "GD" Billing Code. In either case when that cylinder is returned the Ownership must remain unchanged.

Notes

Billing codes currently are not required to be sent over with the Orders. However, if delivering an asset for which its classification is unknown, you will be required to select a Billing Code from a list when classifying the asset. Therefore, at least one Billing Code needs to be established.

There is a request to make it completely optional across the systems (Ticket 19091 and V1 B-04612).

Billing codes are setup by the TrackAbout support staff. There is currently no tools or API calls to set billing codes.


Screen Shots

Mobile Computer Setup (TAMobile 6)

For a handheld to download and display the orders, the following mobile computer setting (Mobile Device List page) need to match the order entered:

  • Location
  • Load Inventory for this Truck or Branch - select a Branch unless you use the Truck Load module
  • Route/Delivery Route

Paperless MDU.png

Deliveries from the Dock/Branch

It is also possible to use paperless delivery features when making deliveries directly from a branch. These are normally deliveries that take place "on the dock".

The handheld computers only have information for assets in a branch's inventory which have been scanned on a record in the last X days ( this is a configurable value with a max of 180 days.) This is done to reduce the number of records that are sent down to the device, the assumption being that assets that have been inactive for so long will probably not be delivered.

A good way to find the assets that will be sent down is to use the "Only show assets that were on a record in the past X days" option in the Current Inventory page

Orders Requirements

NOTE: These are the minimum requirements for POD functionality. These are not the minimum requirements for API integration. The API requirements can be found by going to the API documentation > Help and then going to the Validation section.

  • Order #
  • Customer Id
  • Location
    • Determines which routes can be used
  • Route
    • Determines on which mobile unit the order appears
      • If the config, Location and Route are Optional for Proof of Delivery, is set to True and Proof of Delivery is enabled, every device will use Proof of Delivery whether or not it is assigned to a truck and route.
      • If set to False only devices assigned to a truck and route will use Proof of Delivery; devices which are not assigned will use standard delivery.
  • Trip
    • Puts orders into groups by Trip Number. Can be the entire route or a subset of the route. If only some orders are not populating, check the trip drop-down box at the top of the order list screen.
    • A trip can be in any format, but trip numbers must be unique per day, per truck run.
      • Trip Number Suggestions:
        • Planned delivery date
        • "AM and PM" for morning and afternoon deliveries
        • "1,2,3,..." Groups of deliveries by stops for Universities
        • Geographical area
    • Only available in TAMobile 6 and TAM7
  • Order Date
  • Planned Delivery Date
    • Should not be in the future. Only Planned Delivery date with today's date or older will be downloaded to the mobile devices.
    • Order status displays on the Order Search page and on the Order Detail page. Note that there might be exception to this for customer using Custom Asset Info (CAI) and Custom Info Types (CIT).
  • Order Line Items
  • Billing codes currently are not required to be sent over with the Orders.
    • However, if delivering an asset for which its classification is unknown, you will be required to select a Billing Code from a list when classifying the asset, pending fix of D-02717.
    • Therefore, at least one Billing Code needs to be established.
    • We recommend “X” (Handhelds only show one letter.)

Counter Sales

Some clients sell product/cylinders inside retail shops and not by way of truck deliveries. In this scenario, set up should be as follow:

Pending Orders : Should be sent to TrackAbout without a Truck, but should still include the Trip and Route.

Devices: Should be set with the "Load Inventory for this Truck or Branch" = the branch from which they will be doing counter sales.

Also, be sure to set to the route that matches the orders.

This will allow operators to see the Orders that pertain to their trip/route, but will load assets from the whole branch (that have been active within 90 days) onto the handheld.

Optional

Sequence The sequence number field is an integer with a maximum value of 255.

The sequence number determines the order in which the orders are shown in the mobile app during delivery. If a new order is added, and if the order needs to be shown at the end of the list of trip orders, then the sequence number needs to set higher than the maximum value for the trip. There is not much validation on our end on the sequence number. It is okay to have gaps in the sequence number, as well as to have multiple orders in a trip with the same number.

If no sequence number is provided, the corresponding order appears at the top of the list.

The sequence number can be modified from the web site through the Edit Orders page.

Order Management

Once your orders are in TrackAbout, you may schedule them and update them through the Order Planning page.

This page will allow you to group orders together by trip, truck and route, as well as modify the Planned Delivery Date. Orders must have an assigned Truck/Location and Route to show on a device.

Deliveries/Returns/Transfers

Proof of Delivery Receipt

Sample receipts

Related Features

Sort Trip Load (Picking)

Now that you're already sending Order information to TrackAbout in preparation for deliveries, our Sort Trip Load (Picking) function allows your operators to match up items with orders. Ensure your drivers get out the door with the items they need to fulfill customer deliveries. Even better, do it without having to carry around a ton of paperwork. TrackAbout provides functionality to assist in preparing your orders for delivery.

Difference Reason Codes

Certain actions such as Delivery, Sort Trip Load, and Branch Transfer Send and Receive involve scanning assets to match what was specified on an order. Difference Reason Codes provide a way for handheld users to note why a record was saved with non-matching line items, i.e. when the user did not scan assets to match what was asked for in the order.

For example, when difference reason codes are enabled, if an order indicates that 3 cylinders of Type A should be delivered but the driver only scans 2, he will be required to select a reason code to explain the discrepancy.