Skip to main content

EDI Documents Report

EDI Documents Report & EDI Forms - How to see which forms have been sent and when

Bryan Mansfield avatar
Written by Bryan Mansfield
Updated this week

Understanding the EDI Documents Report in Luminous

The EDI Documents Report in Luminous provides a detailed and filterable view of all Electronic Data Interchange (EDI) transactions between your ecommerce brand and its trading partners. This guide will walk you through how to interpret the report and gain insight into your EDI activity.

TIP: It's much easier to search for a specific order number if you export the data from the EDI Documents report first. CTRL + F/CMD + F is not always useful within the report itself in Luminous because it will only find an order that is displayed on the current page.

Here are some commonly asked questions from customers regarding EDI:


"My trading partner (Williams Sonoma, Target, Container Store, Scheels, REI, etc.) says they did not receive the 810/856/855"

"Luminous says we sent the order, but my trading partner can't find it. How can I help them find it?"

"When was it sent and to whom?"

This article will help you answer these questions!


Report Structure Overview

The EDI Documents Report is divided into two tables:

1. Top Table – Order Summary View (Called "Purchase Orders")

This section provides a high-level overview of EDI order-related activity across your connected integrations.

Columns

  • Integration – The trading partner or EDI connection (e.g., Target, Walmart, etc.)

  • Order Date – Date when the order was created.

  • order_age_in_days – Number of days since the order was placed.

  • PO Number – Purchase Order identifier.

  • Order – Internal Luminous order reference.

  • Order Ack Date – Date the Order Acknowledgment was sent.

  • Invoice Date – Date the Invoice (EDI 810) was sent.

  • ASN Date – Date the Advance Ship Notice (EDI 856) was sent.

  • Luminous Order Status – Current status within Luminous (e.g., shipped, pending, etc.)

Filters

You can refine the view using the following filters:

  • Missing ASN – Show orders missing an Advance Ship Notice.

  • Missing Invoice – Show orders missing an Invoice.

  • Missing Ack – Show orders missing an Acknowledgment.

  • Order Status – Filter by Luminous status (e.g., only show shipped or pending orders).

  • Integration/Connection Partner – Focus on specific trading partners.

  • Date Range – Filter by order date range.


2. Bottom Table – "All EDI Transactions"

This section displays granular EDI document data for each transaction sent or received

Columns

  • ID – Unique identifier for the EDI document record.

  • edi_type – Type of EDI document (e.g., 850 for Purchase Order, 855 for Acknowledgment, 856 for ASN, 810 for Invoice).

  • created_at – Timestamp for when the EDI document was generated.

  • transaction_response – Response received from the trading partner (if applicable).

  • transaction_status – Current status (e.g., sent, received, acknowledged, failed).

  • order_id – Internal reference to the associated order.

  • json_data – Full payload of the EDI transaction in JSON format, allowing for deep debugging or export.

Filters

The following filters are available in this section:

  • Document Type – View only a specific EDI type (e.g., only 856 ASNs).

  • Incoming/Outgoing – View documents sent to or received from trading partners.

  • Order Number – Quickly locate EDI transactions associated with a specific order.


Reading the JSON Payload

NOTE: This is not usually needed by the customer and should only be used if they want verifiable proof that Luminous sent the

Each row in the bottom table includes the raw json_data, which contains the complete EDI payload transmitted for the transaction. This is useful for:

  • Troubleshooting with support teams

  • Verifying that the correct data was sent (e.g., SKU counts, shipping dates)

  • Providing logs to trading partners

The JSON format is consistent with Luminous's EDI schemas, and you can copy it directly for use with technical teams or validation tools.


Use Cases for the Report

  • Compliance Checking: Use the filters in the top table to identify orders missing critical documents (ASN, Invoice, Ack).

  • Error Investigation: Review transaction_status and transaction_response fields to troubleshoot document failures.

  • Data Validation: Inspect json_data for confirmation of what was sent or received.

  • Partner Accountability: Track delays in acknowledgments or shipping confirmations from your trading partners.


Tips for Effective Use

  • Use combined filters (e.g., Missing ASN + Order Status = "fulfilled") to pinpoint issues quickly.


Reading and Using the JSON Payload

Each row in the bottom table of the EDI Documents Report includes a json_data column. This contains the full raw EDI payload that was transmitted for the selected transaction. This payload is extremely valuable for technical users, support troubleshooting, and retailer communication.

How to Copy and Beautify the JSON (if needed)

The raw JSON may initially appear dense and difficult to read. Here’s how you can turn it into a more readable format:

  1. Copy the JSON Payload:

    • Locate the row you’re interested in from the bottom table.

    • Click into the json_data field (you may need to expand the row or use a scrollable panel, depending on your interface).

    • Select all the text in the field and copy it (Cmd + C on Mac or Ctrl + C on Windows).

  2. Paste into an Online Beautifier:

    • Go to a free JSON beautifier tool, such as:

    • Paste your copied JSON into the text box and click Beautify or Format.

  3. Review the Output:

    • The tool will reformat the data with proper indentation and line breaks.

    • This makes it significantly easier to read nested elements such as line items, ship-to addresses, and fulfillment data.

Why the JSON Payload Is Helpful and When to Use it

Understanding the JSON payload can provide clarity into exactly what was sent to or received from your retail partner, including:

  • Data Accuracy: Verify that SKUs, quantities, prices, and shipping information were included and correct.

  • Troubleshooting: When a trading partner rejects or fails to process an EDI file, the JSON can be shared with your Luminous support contact or the partner’s EDI team for diagnosis.

  • Audit Trail: It serves as a source of truth for what was transmitted at the time—useful for resolving disputes or delivery issues.

  • Developer Support: Technical users on your team can reference the JSON when building custom workflows or integrations.

This level of transparency ensures you always have a complete, inspectable record of your EDI activity at your fingertips.

Example:

Let's say the customer asks one of the following questions:

  1. "Did Luminous actually send the ASN?"

  2. "Was the data in the ASN accurate and complete?"

You can see all of this data on the EDI Documents report. The customer likely does not need to see the entire payload, but if they press for details or proof, we may need to send the payload to someone on the trading partner's team or the customer's team to confirm that they received it.

Occasionally it can happen that Luminous properly sent the EDI forms, but the trading partner still did not receive it. This could be due to the trading partner receiving the file in the wrong folder. Read on to troubleshoot:

What Is SFTP and Why Does It Matter for EDI?

SFTP stands for Secure File Transfer Protocol. It’s a secure digital pipeline used to send files from one system (like Luminous) to another (like your retailer’s EDI system).

Think of it like a locked, private mailbox:

  • Luminous places the EDI file (like an ASN, invoice, or PO acknowledgment) into the box.

  • The trading partner (e.g., Target, Nordstrom) is responsible for checking that mailbox and picking up the file.

This method is commonly used in EDI because it's secure, standardized, and doesn't require direct system integration between companies.


Why Can Files “Go Missing”?

Sometimes, even when Luminous successfully sends the file to the SFTP mailbox, the trading partner might not receive it properly. Here's why that might happen:

  • Wrong folder: The file may have landed in the wrong "pickup" folder on the trading partner's side.

  • File naming mismatch: The partner may be expecting a specific file naming pattern or format, and if the name doesn't match exactly, their system might ignore or fail to process the file.

  • Pickup delay: The partner's system may not check the SFTP frequently, or it may have encountered a temporary error during its scheduled pickup.

  • Processing errors: The partner may have received the file, but their internal EDI system couldn't interpret or process the data due to validation issues.


How the JSON and EDI Documents Report Help

Even if your trading partner claims they didn’t get the file:

  • Luminous can confirm that the file was created and sent (via transaction_status).

  • The json_data can prove what data was in the file.

  • Luminous support can use internal logs to verify the SFTP upload, including timestamp, file name, and delivery status.


In Summary

  • SFTP is just the method we use to safely deliver EDI files.

  • Luminous drops the file into a secure digital mailbox.

  • It’s then up to the partner’s system to retrieve and process the file correctly.

  • Just because the partner doesn’t “see” the file, doesn’t mean it wasn’t sent — and the EDI Documents Report + JSON payload are your tools to verify that.

Did this answer your question?