Receiving Technical Specification

Article Contents

Overview

Purchase Receiving Process Flow

XML Format Examples

JSON Format Examples

General Processing Conventions

ESM Purchase Receiving Receipt Transaction Data Elements

Additional Receive Settings

Overview

This article details the process flow of ESM Purchase Receiving as well as technical specifications.

 

Purchase Receiving Process Flow

The below diagram gives a high-level overview of the ESM Purchase Receiving process:

Purchase_Receiving_Process_Flow.jpg

 

XML Format Examples

Requests

Receipt (RI) Transaction Example

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<Transaction>

                <TransactionID>AABDF1D5-EE70-45AE-A467-ABC1E2802333</TransactionID>

                <TransactionType>ReceiptInsert</TransactionType>

                <TransactionDateTime>2005-02-25 16:23:45.334</TransactionDateTime>

                <PurchaseOrderID>0591109C-3425-4F99-8164-4A3FFE805692</PurchaseOrderID>

                <PurchaseOrderNumber>123</PurchaseOrderNumber>

                <ReceiptDate>2005-02-24</ReceiptDate>

                <ESMItemID>33334455-7765-223E-B234-AABBCCEEFF66</ESMItemID>

                <LineNumber>1</LineNumber>

                <Quantity>12</Quantity>

                <Value>0.000000</Value>

                <ClosedFlag>true</ClosedFlag>

                <ESMItemReceiptID>2502</ESMItemReceiptID>

</Transaction>

 

Responses

Success Response for Transaction Example

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<Response>

                <TransactionID>AABDF1D5-EE70-45AE-A467-ABC1E2802333</TransactionID>

                <TransactionType>ReceiptInsert</TransactionType>

                <TransactionStatus>Success</TransactionStatus>

</Response>

 

Error Response for Transaction Example

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<Response>

                <TransactionID>AABDF1D5-EE70-45AE-A467-ABC1E2802333</TransactionID>

                <TransactionType>ReceiptInsert</TransactionType>

                <TransactionStatus>Error</TransactionStatus>

                <Message>Error message 1</Message>

                <Message>Error message 2</Message>

</Response>

 

JSON Format Examples

Requests

Sample Banner Ethos request and response with packing slip number (Pkg slip is only specific to Banner Ethos customers where they can opt in or out)

Receipt (RI) Transaction Example

{

  "id": "00000000-0000-0000-0000-000000000000",

  "purchaseOrder": {

    "id": "32037fd2-ec9f-6239-85d0-977898f6f1ce"

},

  "packingSlipNumber": "1250",

  "lineItems": [

    {

      "lineItemNumber": "1",

      "received": {

        "quantity": -1

      }

    }

  ],

  "receivedOn": "2021-12-14",

  "receivedBy": {

    "id": "b69c09ef-411c-4bac-89f2-263c45f39da9"

  }

}

 

Responses

{

  "id": "2cafd4f1-7e13-4dee-a93f-1a4680a06ad7",

  "lineItems": [

    {

      "lineItemNumber": "1",

      "received": {

        "quantity": 150

      }

    }

  ],

  "packingSlipNumber": "1234",

  "purchaseOrder": {

    "id": "c0692023-a6a0-440c-a86f-07502dae92e5"

  },

"receiptNumber": "Y0000018",

  "receivedBy": {

    "id": "a70f09ef-411f-4bac-91f2-623c45f39ca1"

},

  "receivedOn": "2022-12-09"

}

 

General Processing Conventions

Notes on XML

It is highly recommended that all parties support some general rules of flexibility when processing XML from a foreign system.

Order of elements is not guaranteed.  Either party is free to alter the order of the elements in any document, so long as that reordering does not break the agreed-upon hierarchical structure of the document. The processing system must assume no pre-defined order of elements.

Either party is free to include additional elements in an XML document, which are irrelevant to the processing system, so long as these additions do not constitute a duplication of an existing element and do not alter the agreed-upon hierarchical structure of the document.  The receiving system must ignore these extra values.

Notes on Transaction Consistency and Fault Tolerance

It is highly recommended that all parties strive to support as much fault tolerance as possible when handling transactions of all types.

Each transaction must be processed independently of all other transactions.

Each transaction must succeed or fail in its entirety.  No partial processing of a transaction can be allowed.

ESM Purchase Receiving Receipt Transaction Data Elements

Receipt ESM Transaction Data Elements
Transaction Header Data (one per transaction)

TransactionID

GUID

Required

Unique Identifier for transaction

TransactionType

Text

Required

“ReceiptInsert”

TransactionDateTime

YYYY-MM-DD HH:MM:SS.sss

Required

Date and time the transaction was created

PurchaseOrderNumber

Text(20)

Required

ESM’s purchase order number

PurchaseOrderID

GUID

Required

ESM’s unique identifier for the purchase order

ReceiptDate

YYYY-MM-DD

Required

Date of the receipt

ESMItemID

GUID

Required

ESM’s unique identifier for the PO line item

LineNumber

Integer

Required

Position of item within an order.

Quantity

Integer

Required

Quantity received

Value

Decimal

Required

Monetary value received (to two decimal places)

ClosedFlag

Bool

Required

“true” or “false”

ESMItemReceiptID

Integer

Required

Identifier for the receipt line

 

Receipt GL Response Data Elements
Response Header Data (one per transaction)

TransactionID

GUID

Required

Unique Identifier for transaction

TransactionType

Text

Required

“ReceiptInsert”

TransactionStatus

Text

Required

“Success” or “Error” – Success or error indicator

Message

Text(500)

Optional

Receipt error message – Multiple instances of this tag may be returned if multiple error messages exist

ESMItemID

GUID

Required

From item ID sent by ESM

 

Additional Receive Settings

Settings

Line Receipts – Receipt Insert request sent for 1 line at a time
Group Receipts – Multiple line receipts sent as single request
Entity Level (Value/Qty/Both) – Entity setting to receive by only Qty, Value or both
User level (Qty/Value) – User level setting to receive by only Qty or/and Value
Entity Prevent Self Receipt – Setting to allow/disallow a user from receiving the transactions created by them
Allow Overreceipts – When enabled entity can over-receive
Allow Negative Receipts - When enabled negative receipts can be made
Close Receipts – Ability to close receiving for an order
Reopen Receipts – Ability to re-open closed receipts
Allow Receipt of S&H
Allow Receipt of Taxes
Entity Wide Receiving – Receiving can be made for any transaction from the entity
User Specific Receiving – Receiving can be made to only transactions created by that user

 

ESM Integrations that have Receiving Touchpoint

Colleague Ethos
Banner Ethos
Colleague
Munis (Qty and Value Receipts)
Sungard BusinessPlus (Qty and Value Receipts)
USL (Qty and Value Receipts)
eFinancePlus
Generic (No customers are configured for this in Production)

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.

Articles in this section