EDIRobot

    EDIRobot is for suppliers to the major retailers that need an automatic and seamless flow of data between their
    legacy system, MRP system or accounting system, and their EDI customers.

    EDIRobot does the following:

    1. Turns an inbound EDI file (X12) from your customers into either:
             -  a CSV file or
             -  an XML file

    The inbound EDI file can come from any of your EDI trading partners and can contain one or more documents
    like purchase orders, acknowledgments, remittance advice, etc.

    The CSV file will go to your legacy system, which in turn will pick it up and update its database.  For example, if
    the CSV file contains a purchase order, your legacy system will create sales orders from it.

    The XML file will directly update your MRP or accounting system.  Of course these systems must have a COM
    object with the necessary interface to process the XML file with updating instructions created by EDIRobot. 
    This updating is done automatically by the COM object interface.  One of these systems is JobBOSS, for
    instance.

    2. Generates an outbound EDI file (X12) from a CSV file coming from your legacy system.

    The outbound X12 file can be for any of your EDI trading partners (customers) and can contain one or more
    documents like invoices, advance shipping notices (ASN), etc.

    Because the X12 file can differ from customer to customer, EDIRobot has to know what each customer’s EDI
    requirements are.  For this it has what we call “trading partner modules” or TP for short, which are like tiny
    programs or maps that EDIRobot calls as needed.  There is a TP module for Home Depot, for instance, another
    one for Wal-Mart, etc.  These TP modules are used to interpret the X12 file coming in and to know how to
    structure an outgoing EDI (X12) file.

    Note, however, that the record layout of a CSV file (both inbound and outbound) is independent of the trading
    partner.  The record layout of a purchase order CSV file is different from the record layout of an invoice CSV file
    but all the purchase order CSV files have the same record layout, same for the invoice CSV’s, the ASN CSV’s,
    etc. This is important because it means that the legacy system doesn’t have to worry about individual customer
    X12 mapping requirements which, by the way, can change at any time; when there is a new customer, the
    layout of the CSV file remains the same.

    EDIRobot can move data between your computer and your customer FTP site but it cannot move data between
    a VAN (Value Added Network) and your computer.  Therefore, if all your customers can use FTP, you don’t need
    a VAN.

    If your customer prefers to use a VAN for EDI, you need a separate communication program to move the data
    between the VAN and your computer.  This also means that you need to have an EDI mailbox at a VAN, which
    doesn’t have to be the same as your customer’s.  This separate communication program would move the data
    between your computer and your EDI mailbox at your VAN and then your VAN will look after moving the data
    between your mailbox and your customer’s mailbox.

    EDIRobot is a modular system consisting of a core, or basic module, and one or more TP modules. It grows with
    your business because you add TP modules as you need them. For example: you need to go on EDI with Sears,
    you get EDIRobot with the Sears module. Later on, when you start selling to Target and Home Depot, you add
    the Target and the Home Depot TP modules.