FAQ's

We are asked this frequently. Many believe that EDI is limited to exchanging X12 documents. We consider EDI to be broader and encompass the exchange of electronic documents between companies. Also, we consider APIs to be part of EDI and not opposed to EDI.

Examples include:

• Sending purchase orders to vendors as Excel spreadsheets,
• Receiving orders from customers in Excel spreadsheets or formatted text files,
• Receiving XML replenishment orders from vending machines,
• Sending price catalogs to an API in an eCommerce system,
• Picking up orders from Amazon,
• Sending invoices as cXML files to another company.

To accommodate our customers, we have built all the connection types in our EDI System: FTP, SFTP, AS2, API and VAN. We also support any and all data formats to import data: Excel, XML, CSV, JSON, and text (with the exception of PDF).

Banks use their own formats for ACH and EFT transactions and we have implemented several of them. We can send and receive these transactions to/from vendors and customers. The X12 standard for these transactions is an 820, which we support.

Yes, we have several Amazon integrations in place which are based on your specific relationship with Amazon. Our latest update for Amazon is our integration of the Amazon Selling Partner API in our EDI system. We also support encrypting address information to comply with Amazon’s PII requirements.

Yes, for example, we can take an 846 inventory inquiry, export it to Excel and then email it to you. We can do the same thing with an 867 Product Transfer and Inquiry report.

We can connect with trading partners electronically and bypass web portals, which defeats the purpose of EDI. This way orders, invoices and other electronic documents can be exchanged without manual intervention.

Our EDI system is monitoring our clients for technical issues 24x7x365. In so doing, we are able to detect, and fix, issues such as connectivity problems, data format errors, business rule conflicts or items with your Trading Partners. This allows us to address issues before they create problems for our customers.

We have over 5,000 Trading Partners connected through our EDI system and over 600 distinct maps integrated for distributors and manufacturers. You benefit from existing maps, and any new or revised maps, for new/existing trading partners.

Yes, we can help you integrate with 3PLs as it is much like integrating with any other Trading Partner. EDI with 3PLs is different in that the process starts by sending pick tickets to the 3PL. The 3PL then ships the items and sends back ship confirmations, which are imported into the ERP. The pick tickets are marked as shipped and will generate an invoice.

Yes, we have a full cXML integration in our EDI System that allows us to receive orders based on the cXML standard (see cxml.org) as well as sending cXML invoices and other documents. Mappings for cXML are also integrated (the ability to auto-attach documents and custom fields with additional data).

We will try to make orders importable with all lines by any means possible. This includes applying your business requirements, substitutions, mappings, etc. Should there be an error during import, we will notify you about the error so you can make adjustments accordingly.

We utilize the Play database for testing as it allows us to create test data, documents and scenarios without affecting your Live system. This helps avoid scenarios like accidentally shipping out a test order by mistake. Using Play helps keep your Live data clean.

Prices from orders can be handled in one of two ways:
1. We always use the price in your accounting or ERP system, regardless of the price on the order. This is the default method.
2. We use the price from the order, regardless of the price defined in accounting or ERP system. This can be done on a customer-by-customer basis.

We also store the original unit price from the order and reference it on outbound documents like order confirmations, ASNs or invoices, so we can identify discrepancies on documents going to customers.

Yes, you can import the data as orders into your system provided the Excel spreadsheets adhere to a basic format, so we see the data in the same location. We need to be able to clearly identify ship-to information, item data, quantities, etc.

Yes, this recent modification allows FULL import of scheduled releases (e.g. from 830s) into P21. We automatically create new orders, order changes, or releases against existing orders based on the data received.

Yes. We have a number of integrated connectivity methods that allow us to push and pull inventory and pricing information between Trading Partners. We also have an API that allows authorized Trading Partners to remotely query inventory and pricing.

We are continuously adding new Maps (we have well over 5,000).

Yes, we currently have a number of Buying Groups integrated for our clients. Setting up Buying Groups for EDI is a similar process as setting up any Trading Partner.

Yes, our EDI provides a full 360 integration. When you send a PO our software is listening for a functional acknowledgement (997) from your Vendor within 24 hours. If we don’t receive the 997 we will send you an email notifying you of this so you can contact the vendor. We do this for any situation where there should be a 997, like outbound ASNs and invoices to Customers.

We have all major eCommerce systems integrated in our EDI System (Shopify, Magento, BigCommerce, WooCommerce and several others). To set up a connection we typically need credentials for that site along with API keys or access keys, depending on the individual system.

We retrieve orders from eCommerce systems and dependent on the eCommerce system’s capabilities, we send inventory information, order status updates, shipment status updates and invoices.

Our EDI software that establishes the link between your accounting or ERP system and the rest of the world, as far as electronic communications goes, typically resides on a small VM where it can see your accounting or ERP instance(s). 

Yes, our EDI system reads and stores any data even if there are no dedicated fields in P21. This includes things like GL codes, original order line numbers, original item prices and quantities. We use this data for outbound documents so we can reference the original GL codes in invoices to customers.

Yes we can. We can utilize all available pricing methodologies, e.g. price libraries/books/pages, contracts or standard pricing and more. We can send full catalogs as well as partial catalogs with only items that have been changed.

Yes, we can receive price updates in various formats. They typically do not import directly into P21 but we can present those price updates in Excel spreadsheets, custom import files or write to custom databases or tables as needed.

Yes, we have done both. In fact, we are using the voucher imports for carrier invoices that do not have matching POs against them.

Punchout technology enables the seamless integration of an external electronic catalog into a buyer’s procurement system, creating a unified shopping experience. It allows buyers to access a vendor’s online catalog directly from their own procurement system, select items, and then seamlessly transfer these items back to their procurement system for purchase processing. This process involves the exchange of cXML documents for order information. Punchout is a specialized facet of EDI, focusing on the catalog and order aspect. Comparatio EDI not only supports but excels in integrating these punchout systems, ensuring a smooth transaction flow from catalog browsing to order placement.

APIs and EDI both serve to enable data exchange, but they operate differently. EDI refers to a set of standards for structured data exchange, while APIs are tools that link different software for data sharing. At Comparatio, we integrate APIs into our EDI services to offer real-time data interchange and support a variety of platforms and eCommerce systems like Shopify, BigCommerce, Magento, and Amazon Selling Partner APIs. This blend of APIs and EDI allows us to provide flexible and secure data exchange solutions to our clients.

Yes. Our customers find this to be helpful. We point to your play and live P21 databases at the same time, so testing can be done in play. This allows us to test orders, transactions, and invoices in play, thus avoiding any incidents in your live system. It also allows us to test all necessary scenarios.

X12 180 transactions are RMAs. We can send them from P21 through our EDI system to customers or receive them from customers.

Yes, the vendor sends an ASN which we import as a vessel receipt into P21, instead of an ASN. The vendor can send the ASN in formats such as: X12 856, EDIFact, Excel and CSV.

816s are organizational transaction sets to indicate the structure of a company. The 816 shows locations and relationships for plants, warehouses, distribution centers, branches or facilities that have been opened or changed. These could serve as templates to set up customers or ship-to accounts in P21.

Yes, we recently developed a solution that will allow you to comply with Amazon and process orders without manual intervention. Any import files that have address information in them will be archived after 30 days.

Yes, we recently integrated our EDI system with WorkWave and can now import Proof Of Delivery (POD) transactions into P21.

When vendors submit invoices there can be cases where line numbers don’t match PO line numbers, missing line numbers or invalid item IDs. We can reduce, or eliminate, the need for manual intervention and correct errors such as:

• Incorrect unit of measure,
• Incorrect or transposed item IDs or customer part numbers,
• Incorrect or missing address information,
• Invalid pricing.

We do the same thing for order confirmations and vendor ASNs.

Yes, you can do EDI processing in a hosted or on-premise scenario. We need read-only access to the database, which is easily set-up in either arrangement.

Our EDI web portal allows users to do it themselves. We offer training in order for each user to understand this process.

We need a few rules set up in your company’s firewall in order to allow traffic, while our software handles the rest.

A PO Confirmation (850) lets your trading partner know you have accepted their order, including any changes made to the order. A Functional Acknowledgement (997) is one system telling another system an EDI file has hit our system.

We send a document that gives us all the information we need to set up a new trading partner.

We have implemented: 180, 210, 214, 240, 754, 810, 812, 816, 820, 824, 830, 832, 846, 850, 852, 855, 856, 860, 861, 862, 864, 865, 867, 875, 945, 997 and other less common documents. We will add other X12 documents as needed.

We have integrations with Clippership, ShipLinx, RateLinx, StarShip and Latitude.

Yes, there are standard transactions for this type of information that can be sent to distributors or vendors. The data format typically varies between different trading partners, but as long as customers can receive these transactions electronically this is very doable and part of our system.

Differences in units of measure between sales orders and what is in P21 are resolved through individual mappings. We directly map units of measure between systems or we find the default value (along with the conversion factors) stored in P21. We save the original unit of measure from the orders so we can reference them back in outbound documents like order confirmations, ASNs or invoices.

Yes, we have transactions going in-and-out to pick-up orders, update order status and send back shipment and tracking information.

We currently integrate with Amazon, BigCommerce, Channel Advisor, eBay, Magento, SellerActive, SellerCloud, Zentail and others

A 240 is a package status transaction, typically used by carriers like UPS to send the shipment status of individual packages. Comparatio can handle and process 240s.

An 894 is a delivery/return record that is sometimes used in place of an 810 or 880 invoice.

Yes, we can connect to Ariba through regular EDI channels as well as cXML integrations for punchout functionality.

Yes, provided you have corresponding GL and SAC codes maintained in P21, we can import tariffs, taxes, freight charges, and other items from vendor invoices into P21.

We support any data format to send or receive documents. We also integrate with remote APIs to submit or pull data as required.

Yes, we can import invoice data from Excel files, CSV files, X12 transactions (210), EDIFACT and others.

ASNs and invoices are typically based on existing, unpaid invoices. These transactions get sent as soon as they have been created and marked as done. We can also combine multiple ASNs into a single transaction in case customers require to send a single ASN either per shipment or per day.

Yes, but we recommend implementing the mapping directly into the system. The benefit in having our team handle this is we can add custom business processes, translations and other procedures that go beyond simple field mapping or basic rules. Dynamic order routing or geographic mapping are good examples.

All transactions in our EDI system are logged to ensure that any report requested can be generated. Reports can be sent automatically, on a schedule and/or with specific event triggers. Such a report might show all purchase orders which have not been acknowledged or confirmed yet, when ASNs or invoices came in and whether they were processed correctly.

Any form of electronic data exchange between companies can be considered EDI. Whether the data is sent as an Excel spreadsheet, X12 transaction, CSV file, or unique proprietary format, it’s all EDI. The only exceptions are PDF files or images.

Yes, that is possible. We can treat individual companies in the same P21 database as each other’s customer or vendor, and send the full spectrum of transactions back and forth that would typically occur in such a relationship. Company #1’s purchase orders will be imported into company #2’s system as sales orders. Order confirmations, ASNs and invoices will flow back the opposite way.

Yes do we support that, and we can import and export from them for outbound transactions.

Yes, we can import transfers. ASNs from vendors that indicate ship dates, arrival dates, etc., will be imported into P21.

Our system reviews all transactions to ensure that they are fully processed. We also verify that orders are imported correctly, no warnings or errors have occurred and provide summary transaction reports when requested. Each step of the process is checked and logged so we can be certain of what happens to each transaction.

We tag outbound transactions with support acknowledgements to confirm the acknowledgements are received. If acknowledgements have not been received within a reasonable timeframe, the system sends a notification.This is critical when sending a large number of purchase orders to vendors, or many invoices to customers.

Most eCommerce systems utilize APIs to interface with other systems. We connect to these APIs to easily transfer data like shipping and payment information back-and-forth. APIs for new systems will be implemented as they become available.

Yes, this will import into P21 and update a PO, provided the vendor is sending the data. Keep in mind, order confirmations may or may not have pricing, dates, or line item information at all. This depends on what each vendor is capable of sending. Ship dates are updated via ASNs from vendors.

We can connect with trading partners electronically and bypass web portals. So orders, invoices and other documents can be exchanged without manual intervention.

If trading partners cannot support direct, electronic file transfer, also offer a Customer and Supplier Web Portal option.