There is an update available to this documentation. To view the update, please go here: https://docs.orderful.com/docs/orderful-terms

This section provides an overview of core concepts in the Orderful platform and EDI in general. Having a familiarity with these concepts will help you to more effectively utilize the Orderful platform.

Universal EDI concepts

Core Concepts in Orderful

EDI

Electronic Data Interchange (EDI) is the computer-to-computer exchange of business documents in a standard electronic format between business partners. EDI covers a wide range of technologies and standards used by businesses to exchange data. Because EDI documents must be processed by computers rather than humans, a standard format must be used.

There are several EDI standards in use today, including ANSI X12, EDIFACT, TRADACOMS and ebXML. When two businesses decide to exchange EDI documents, they must agree on the specific EDI standard to use.

X12

The most common EDI format in North America is ANSI X12. X12 is an Accredited National Standards Institute ("ANSI") standard.

Transaction types are denoted by a three digit code e.g. 850, 810 etc. Orderful supports a JSON format analogue of the X12 standard.

For reference, the examples below shows the same 810 Invoice, in the standard X12 file format and in Orderful's JSON version.

810 Invoice Example - Standard X12

ISA*00* *00* *ZZ*ODF_SUPPLIER *ZZ*ODF_BUYER *200912*0803*U*00401*001234322*0*T*>~
GS*IN*ODF_SUPPLIER*ODF_BUYER*20200912*0803*1234322*X*004010~
ST*810*0001~
BIG*20200912*INV8793280**PO123456789****00~
N1*RI*ODF SUPPLIER DISTRIBUTION CENTER*1*123456789~
ITD*01*3*****30*****Net 30 days
IT1*1*48*CA*26.25**UP*711719100246~
PID*F****SUNGLASSES VERMILLION (E16249)~
TDS*126000~
CTT*2~
SE*9*0001~
GE*1*1234322~
IEA*1*001234322~

810 Invoice Example - Orderful JSON

{
  "transactionSets": [
    {
      "transactionSetHeader": [
        {
          "transactionSetIdentifierCode": "810",
          "transactionSetControlNumber": "0001"
        }
      ],
      "beginningSegmentForInvoice": [
        {
          "date": "20200912",
          "invoiceNumber": "INV8793280",
          "purchaseOrderNumber": "PO123456789",
          "transactionSetPurposeCode": "00"
        }
      ],
      "N1_loop": [
        {
          "partyIdentification": [
            {
              "entityIdentifierCode": "RI",
              "name": "ODF SUPPLIER DISTRIBUTION CENTER",
              "identificationCodeQualifier": "1",
              "identificationCode": "123456789"
            }
          ]
        }
      ],
      "termsOfSaleDeferredTermsOfSale": [
        {
          "termsTypeCode": "01",
          "termsBasisDateCode": "3",
          "termsNetDays": "30",
          "description": "Net 30 days"
        }
      ],
      "IT1_loop": [
        {
          "baselineItemDataInvoice": [
            {
              "assignedIdentification": "1",
              "quantityInvoiced": "48",
              "unitOrBasisForMeasurementCode": "CA",
              "unitPrice": "26.25",
              "productServiceIDQualifier": "UP",
              "productServiceID": "711719100246"
            }
          ],
          "PID_loop": [
            {
              "productItemDescription": [
                {
                  "itemDescriptionTypeCode": "F",
                  "description": "SUNGLASSES VERMILLION (E16249)"
                }
              ]
            }
          ] 
        }
      ],
      "totalMonetaryValueSummary": [
        {
          "amount": "126000"
        }
      ],
      "transactionTotals": [
        {
          "numberOfLineItems": "1"
        }
      ]
    }
  ]
}

ISA ID

The ISA segment is the first segment in an X12 data transaction. Just like the addresses located on a piece of mail, the ISA segment contains sender and receiver information in the form of their ISA IDs. An ISA ID is a unique qualifier that identifies one party in a business transaction.

At a minimum, an organization needs at least one ISA ID. A single organization can have multiple ISA IDs if they assign a unique ISA ID to different subsidiaries or departments.

EDI transactions must reference an ISA ID of a registered EDI account in order to flow through Orderful. An Orderful organization can have several EDI accounts.

User

A user represents an individual who interacts with Orderful. Users are represented by their e-mail address and belong to one or more organizations. They may have different levels of permissions based on role.

Organization

An Organization is the representation of a trading partner within the Orderful network. An organization typically represents one company. When a relationship is created, an Organization will become either the receiving or the sending party of the relationship.

EDI Account

An EDI account is a unique set of EDI X12 data that is required for an organization to trade data with trading partners. Prior to sending or receiving transactions, an Organization must register at least one EDI Account under Organization Settings.

Transaction

A transaction is information that your organization exchanges with your trading partner for a business purposes. Examples of transactions include a purchase order, invoice, shipment notification, load tender, etc. Transaction types are denoted by their three digit code (e.g. 850 for a purchase order). You can view all of your individual EDI transactions, both inbound (transaction you receive from your trading partner) and outbound (transaction you send to your trading partner) within the Transactions tab in the Orderful U/I.

You can filter transactions based on date, status, stream, direction, transaction type, trading partner or business number. You are also able to view real-time metrics on number of transactions and status of valid vs. invalid transactions.

Business Number

A Business Number is a value associated with a transaction. The Business Number acts as an identifier for each transaction posted in Orderful and is displayed in the Transactions tab. The location of the Business Number in the data payload is different by transaction type and is governed by X12 standards.For example:
On a purchase order (850 transaction), the Business Number is the “Purchase Order Number”, found in the element (BEG03) in an X12 transaction. On an invoice (810 transaction), the Business Number is the “Invoice Number”, found in the element (BIG02) in an X12 transaction.

Trading Partner

A trading partner is any organization that sends or receives transactions from you. For example, if you sell your product to Amazon, Amazon is one of your trading partners.

Relationship

A relationship is unique transaction type per trading partner. For example, if you trade a purchase order and an invoice with Trading Partner A, you see two relationships in your relationships dashboard, one for the purchase order and one for the invoice associated with Trading Partner A. There are three core components of each relationship:

Direction: Indicates the direction of the transaction.
In = You receive the transaction
Out = You send the transaction
Transaction Type: Indicates the type of business transaction
Trading Partner: Trading partner the transaction is being sent to (outbound transaction) or being received from (inbound transaction)

Trade Request

A trade request is a feature that allows you to request a new trading partner be added to your network in order to establish relationships with that trading partner and begin trading with them. The Trade Request feature is located on the left navigation bar within the Orderful U/I.

Guidelines

Guidelines define the type, structure and information required to be included in the transactions that you will be trading. Each transaction requires a guideline. For example, if you have a relationship with Trading Partner A where Trading Partner A sends you a purchase order and you send back an invoice you will need to have a guideline for both the purchase order and invoice. Within the guideline you will set all the necessary fields your system of record needs to process the transaction. Creating guidelines ensure that the data you transmit to and receive from trading partners is consistent and standardized. Guidelines help you to avoid invalid transactions and reduce charge backs. You will need to create guidelines for both inbound and outbound transactions.

Scenarios

An Orderful scenario describes the back-and-forth exchange of one or more transactions, including their expected contents, that you and your trading partner must successfully complete before you begin to exchange production data.

For example, if you are a seller and your trading partner is a buyer, a typical scenario might look like this:

my trading partner sends an 850 Purchase Order
my organization responds with an 855 Purchase Order Acknowledgment
my organization sends an 856 Ship Notice/Manifest
my organization sends an 810 Invoice

Communication Channels

A communication channel is a connectivity method that connects your trading partners to the Orderful platform to enable your trading partners to send and receive transactions. Orderful supports several communication channels including AS2, SFTP/FTP, HTTP, POLLER and VAN. Please reference Communication Channels for more information.

Integration

The Integration tab in the Orderful U/I contains a mapping assistance tool that helps you determine the correct fields in your system of record to map to Orderful's API.

Schema

An Orderful schema is a JSON template listing all the fields that can be used for a particular transaction type

Stream

A stream is a flag applied on a transaction to identify the transaction as live or test. A transaction in a Live stream flows without interruption from/to your organization to/from your trading partner organization (except if the transaction has a guideline error(s)). A transaction in a Test stream will have stop its flow before leaving an organization for implementation configuration and checks.

Leader Vs Follower

In any EDI Partnership, there is a "Leader" and a "Follower".
As a user of Orderful's platform, you have the ability to be either of these designations.

Note: The Leader and Follower is determined by you and your partner at the time of your partnership agreement. Orderful cannot decide this on your behalf.

A Leader is defined as the partner that is providing X12 specifications and Testing Scenarios that need to followed or adhered to.
a Follower is defined as the partner that is receiving X12 specifications and Testing Scenarios and will be adhering or following them.