1. Support arrow-right
  2. What is the difference between a transaction and an order?

What is the difference between a transaction and an order?

Orders

An order is a request for a material to be moved from one location to another or counted. Orders can be created in PowerPick or through the ItemPath API. These are the different "directions" an order can take.

Direction Types

1 = Put
2 = Pick
3 = Return
4 = Transport
5 = Count
7 = Production

Orders contain one or more order lines. Each order line contains a material and a quantity. When each line of an order is fully processed, the order is considered complete.

Transactions

A transaction is a record of an action that has been taken. These records are stored in PowerPick's history table.

ItemPath uses these records in History-themed Reports, and they can be accessed through the ItemPath API using the /api/transactions endpoint. For users of ItemPath's Data Push app, these transactions are what's exported from PowerPick to ERP software.

Transactions Guide

Whenever any part of an order line is processed (a material is picked, put, counted, moved, etc., even partially, or something is adjusted) and the action is confirmed in PowerPick, a transaction is recorded. There are many "types" of transactions, and this list describes what the type values mean in PowerPick.

History/Transaction Types

0 = NotSet
1 = ManualPut
2 = ManualPick
3 = OrderPut
4 = OrderPick
5 = Transfer
6 = OrderCount
7 = ContextCount
8 = MaterialRename
9 = ManualCorrection
10 = ContextCorrection
11 = CancelRequest
12 = Purge
13 = Production
15 = KitRename

There are many cases where a transaction isn't simply a completed order line. As you'll see in the types listed above, a record is made when an order is cancelled or corrected. There are also situations where an order line isn't completed, such as in the case of a shortage, or a partial put away because a location became full.

In these cases, a "Motive Type" can be recorded to explain why the order wasn't fully processed. Those motives are listed below.

Motive Types

0 = NotSet
1 = StockUnavailable
2 = Shortage
3 = SpaceUnavailable
4 = SpaceFull
5 = Deleted
6 = Canceled
7 = RoundUpOverstock
8 = ResolveMissingQty
9 = Trim
10 = CancelError

In cases of deviated quantities or cancellations, PowerPick may give the option to enter a "Reason Code." A reason code is an optional free-text field that only appears when the confirmed quantity is less than what was requested, and there is no default motive set.

As an example, let's look at a partial pick. Here's how the order looks in the API, including the order line.

{
    "orders": [
        {
            "recipient": null,
            "status": "processed",
            "id": "77C870B5-F986-4D17-AD75-E0FFB22BEF0C",
            "order_lines": [
                {
                    "id": "E6E1BFC0-89CF-462E-A5F0-585E0A0E8349",
                    "serialNumber": null,
                    "Info1": null,
                    "Info3": null,
                    "Info4": null,
                    "materialName": "1109",
                    "costCenterName": null,
                    "quantity": 3.0,
                    "lot": null,
                    "Info5": null,
                    "Info2": null,
                    "number": 1
                }
            ],
            "unit": null,
            "Info1": null,
            "priority": 2,
            "Info3": null,
            "Info4": null,
            "warehouseName": "Warehouse",
            "owner": "sys",
            "handlingUnit": null,
            "directionType": 2,
            "type": 1,
            "name": "S-12045",
            "hasStock": false,
            "Info5": null,
            "modifiedDate": "2022-10-30T17:04:09.760000",
            "deadline": null,
            "Info2": null
        }
    ]
}

We can already see a warning sign—when an order is created, ItemPath checks to see if there is enough stock to fulfill the order. If there isn't, the "hasStock" field is marked false. Let's check one of the transactions from the order to see what happened.

{
    "orderName": "S-12045",
    "id": "3B9005B5-7292-4963-AA06-68DAEECC5C98",
    "qualification": null,
    "shelfName": "01",
    "userName": "Admin",
    "quantityConfirmed": 2.0,
    "locationName": "VLM-01-001/01-04/04",
    "serialNumber": null,
    "reasonCode": null,
    "batchName": "S-12045",
    "motiveType": 9,
    "carrierName": "001",
    "productionDate": null,
    "taskNumber": 132,
    "expiryDate": null,
    "binName": "08x08x04",
    "handlingUnit": null,
    "warehouseName": "Warehouse",
    "quantityRequested": 3.0,
    "creationDate": "2022-10-30T17:04:09.760000",
    "materialName": "1109",
    "directionType": 2,
    "type": 4,
    "xStep": 4,
    "yStep": 4,
    "lot": null,
    "storageUnitName": "VLM-01",
    "exportStateType": 4,
    "quantityDeviated": 1.0,
    "orderId": "77C870B5-F986-4D17-AD75-E0FFB22BEF0C",
    "orderLineId": "E6E1BFC0-89CF-462E-A5F0-585E0A0E8349",
    "releaseDate": null,
    "number": 1,
    "uploadDate": "2021-05-21T09:26:12.423000"
}

You can see from the quantities here that the order line was only partially picked. The "quantityRequested" was 3, but the "quantityConfirmed" was only 2. That leaves us with a "quantityDeviated" of 1.

The "motiveType" field is set to 9, or trim, which means the users confirmed a different (lower) quantity. The "reasonCode" field is null, which means the user didn't enter a reason code. That could be the end of the story, and the order wasn't completely fulfilled, but we'd need to check for other transactions from this order to make sure.

When using the ItemPath API to get these records, you can get all the history of an order using the order name or ID.

You can also track what records have been sent using the "Export State Type" in ItemPath. This is what the Data Push app uses, looking for new records (type 2) and updating them as exported (type 4) once they're sent. All these values are described below.

Export State Types

0 = NotSet 
1 = Cannot yet be exported
2 = Ready to export
3 = Currently exporting or export canceled
4 = Successfully exported
5 = Export failed
6 = Not to be exported

As an example, if you wanted to get all the transactions that had an error with exporting, you could use the following API call:

curl -L
    -X PUT '[Your IP]/api/transactions'
    -H 'Content-Type: application/json'
    -H 'Authorization: Bearer [Your JWT Access Token]'
    --data-raw '{"exportStateType": "5"}'

It's important to keep in mind that a transaction doesn't equate to an order line. There are quite a few types of transactions beyond picking and putting, and many reasons why picks and puts don't happen all at once. While we work with the software, we consider the people at the other end—moving from place to place, doing multiple things at once, changing their minds, getting interrupted—and make sure we account for those cases.