EDI Import Form

Outbound

Inbound

Outbound

Outbound

Opens file defined in sample file box for viewing.

Imports any saved EDI Layout template.

Saves EDI layout as a template.

Name of the EDI Import, which must be unique. If a user enters a name that has already been used and clicks the "Import" button, the system will prompt the user that the name must be unique.

• Beginning in version 16.00.108, Tthe system will use the name in this field as the file name when clicking "Export" button above. If this field is blank, the system will use "EXPORT" as the file name. The following special characters would be replaced with either a + / _ character. For example, a file named " <>:"/\|?*" will have an output of "+_________.xml"
  • < (less than)
  • > (greater than)
  • : (colon)
  • " (double quote)
  • / (forward slash)
  • \ (backslash)
  • | (vertical bar or pipe)
  • ? (question mark)
  • * (asterisk)

Location of the data files to be imported on the local server.

• Files are placed here before processing. After successful processing, they are put in the Success Path location.
• Use network paths with the UNC (server) name rather than mapped drives.

Location where data files that pass the EDI parameters will be sent on the local server and removed from the Source Path folder.

• Use network paths with the UNC (server) name rather than mapped drives.

Location where data files that fail the EDI parameters will be sent.

• If, for example, the data file contains part ID’s that are not found in the Deacom system the program will send the file to the location in the Failure Path. A record for the failure will be logged in the EDI import history table.
• Note that the system will add the header and footer information to the files (successful or failed) if the file does not contain them.
• Use network paths with the UNC (server) name rather than mapped drives.

Determines if the EDI Import will be for Purchase Orders, Sales Orders, or Inventory (Adjustments).

• When processing an EDI import with a type of Inventory, all processes that occur when an inventory adjustment is made in the main application will occur. Inventory transactions occur as of the date the EDI profile is run, or with a custom date (fi_date). To accomplish this, the fi_prid (part number ID), fi_waid (facility), and fi_quant (quantity being adjusted in or out) must be populated as a result of the EDI Import. If fi_quant is negative, inventory is adjusted out, if fi_quant is positive, inventory is adjusted in. To adjust for lot controlled items, fi_lotnum (system lot number), fi_userlot (user lot number), and fi_loid (lot number ID) must be populated as well as a result of the EDI Import.

Pick list used to define the Order Type to be created by the Import. The options available depend on the Transaction Type selected above.

None

• Automatically selected and grayed out when selecting a Transaction Type of Inventory.

Purchase Order Type

• Purchase Order - Can be received as imported, no manual review required.
• Requisition - Cannot be received as imported, requires manual review and conversion to a Purchase Order.
• Purchase orders can be received automatically via EDI.

Sales Order Type

• Block Order - Cannot be shipped as imported, requires manual review. Note: Block Orders are no longer available beginning in version 17.02.006.
• Forecast - Cannot be shipped, either as imported or with manual review. Used to represent future sales demand before actual orders are received from customers.
• Inter-company Transfer
• Internet Sale - Cannot be shipped as imported, requires manual review. During import of the EDI file, an order may be saved as an internet order. At this point, the user will have to manually change the order to a Sales Order to allow the order to be shipped.
• Master Order
• Sales Order -
  • Can be shipped as imported, no manual review required or set to to ship automatically. To set the automatic shipment process, the Transaction Type needs to be set to Sales Order, and the following fields, at a minimum, need to be populated as a result of the EDI Import: to_ordnum(order number), to_shipped (shipped date), fi_quant (quantity be shipped), and fi_prid (part number ID). If shipping with lot controlled items, fi_lotnum (system lot number), fi_userlot (user lot number), and fi_loid (lot number ID) must be populated as well as a result of the EDI Import.
  • Inventory already reserved to an order can be used when shipping sales orders via EDI. To accomplish this, a parsing rule for both to_ordnum and to_shipped must be created on the EDI Import routine.
  • Sales orders that have already been shipped can be invoiced via EDI. To accomplish this, a parsing rule for both to_ordnum and to_invdate must be created on the EDI Import routine.
  • Inventory can be reserved to a sales order via EDI, even if the order is not being immediately shipped. In order to reserve via EDI, the EDI Import must contain a parsing rule for to_ordnum, fi_prid, fi_quant, fi_date and at least one of [fi_attrib1, fi_attrib2, fi_attrib3 or fi_masterlot]. Note that fi_date will be used as the reserve date and fi_quant will be used as the reserve quantity, rather than a filter on which lots to reserve. Similar to fi_quant, fi_attrib1-3 and fi_masterlot. These fields indicate values that will be set after the lots are reserved, not values that will be filter on when selecting lots to reserve. All other dtfifo lots (fi_lotnum, fi_serial, fi_catchwgt, etc.) will be used as filters on which lots to select for reserving.
  • to_shipped and to_invdate rules can exist in the same EDI profile (map). If the shipment action results in a failure for any reason, the system will not attempt to invoice. (Note: The existing functionality where these actions can exist in separate profiles (maps) is still retained.)

  • NET1 payments can be applied to sales orders if the Terms specify a credit card process and the processor to be used is NET1.

Location of sample file, for reference.

Allow the user to store various notes that will remain post import/export.

Frequency to run import, if running automatically. The use of this field requires that the Deacom automation service or console is running. 

• Note: Most versions of MS Windows have automatic service restarting capabilities to ensure that if a service is stopped it can be restarted by MS Windows. If users wish to setup some type of alert service, a piece of service management software that would send out email and other alerts when a specific service is not running would need to be installed.

Address/location of FTP server. If set up, EDI import will retrieve information from Source Path on the FTP server. If a secure FTP connection is desired, set the prefix to be "FTPS://".

Port number used for clients who use the Secure File Transfer Protocol. This field will only be used for SFTP and only when it is set to a port number. (greater than 0)

Unique name of user for accessing FTP server.

Unique password of user for accessing FTP server.

If checked, indicates that system will accept invalid SSL certificates. This functionality is off by default (denying access to hosts with invalid SSL certificates).

If checked, Binary mode is used to transfer files. If unchecked, ASCII mode is used to transfer files.

Pick list used to choose the delimiter that is used between fields. Options are:

• ASCII - Used in situations where special non-printable/viewable characters will be used as field delimiters and line separators. An example would be a Field Delimiter that is a "@" and the line delimiter that is a "~" that would be inside a .txt file. When setting the ASCII values in the EDI form the user would enter the following values: Field: 064, Line: 152.
• Comma
• Other
• Pipe
• Space
• Tab

Specific field delimiter when the “Other” option is used.

Pick list used to choose the delimiter that is used between lines. Options are:

• ASCII
• New Line
• Other

Specific line delimiter when the “Other” option is used.

Memo field to define when to create a new order.

Pick list used in connection with the "New Order Condition" field. Options are:

• Order Condition Changes - A new order will be created each time the new order condition changes in the import file.
• Order Condition is True - A new order will be created each time the new order condition is true in the import file.

Memo field to define a new sales order line.

Memo field to define when to skip a line.

Memo field to define when to delete a line.

• An example of an EDI Import that uses the Delete Line Condition is available via the Configuring Inbound EDI Transactions page.

If checked, Sales/Purchase Order header information pulled via the EDI Import may be applied to multiple Sales/Purchase Orders. The process is: 

1. When the New Order condition succeeds while parsing an EDI file and the flag has been checked on the EDI setup, copy the order header information from the current order to the new order.
2. Made the current order's line count available to the new order condition expression so that it can be determined if any lines have been added to the current order or not. The field name is "linecount" and is only available to the New Order condition. An example using this feature is available on the Configuring Inbound EDI Transactions page.

Template data is used to copy and create actual EDI imports, and is not intended to be run.

Pick list used to define the Deacom field name to which data is being imported. The fields available in the list depend on the Transaction Type selected on the EDI Import form.

• EDI imports can set the Tax Region to a sales order or newly created ship-to or bill-to company. Complete information on this process is available here: Setting Tax Regions on Sales Orders and Customers. The business case for this change is situations where dropship (B2C) orders from a service like Shopify requires creating new Ship-To Customers using the "Lookup or Create" functionality.  Due to this, the Ship-To doesn't exist and therefore unable to pull in the Tax Region from the Ship-To.
• Users can set GL Overrides, during EDI Imports, on newly created Bill-Tos and Ship-Tos by adding all GL Override fields (all fields in the dmover table) to the dropdown in this field. These fields are only available when the "Transaction Type" field on the EDI Import form is set to "Sales Order" and only when using the Lookup or Create option on Bill-To/Ship-To records.
• Bill-To and Ship-To User Defined Fields (beginning in version 17.02.106) are available for selection in this field.

Memo field to define when to import into the selected field.

Pick list used to select the method to define data. Options are:

• Lookup - Look up data in Deacom Lookup Table, using Lookup Expression.
• Lookup or Create - Only available when selecting the Sales Order Bill-to Company" (to_biid) or "Sales Order Ship-to Company" (to_shid) in the "Field" field on the Edit Parsing Rule form.
• Expression - Use parsing expression to define field data.

Notes:

1. The Parsing Rule form was enhanced so that when creating a new Ship To Company using the "Lookup or Create" type, and a Bill-To Company is being created as well during the EDI Import, and a Ship-To Company is not specified in the "Create Same As" field, the system will use the values from the new Bill-To Company to set the defaults on the newly created Ship-To Company. See the list below regarding parsing rule exceptions when creating Ship-To Companies via "Lookup or Create" in version 16.06.046 and above.
   1. If the import profile has a specific parsing rule for any dmship fields, the system will use those instead of copying from the Bill-To Company.
   2. If a parsing rule exists to override a value on a Bill-To, that overridden value will not propagate to the newly-created Ship-To or to the Order.  Similarly, if a parsing rule overrides a value on a Ship-To, that overridden value will not propagate to the Order.  For example, if the intent is to override a value on the Bill-To and have it flow to the Ship-To and Order, a parsing rule must exist for each override (one for the Bill-To, one for the Ship-To, and one for the Order).
2. Version 16.06.078 further enhanced the Parsing Rule form so that Wwhen using the "Create Same-As" button to create a Bill-To or Ship-To via EDI Import the system will prevent the following fields from being imported: Name, Contact, Phone, Ext, DBA, Streets, City, State, Zip, Country, County, Fax, Email, Dear, Salutation, Notes. The code was also changed to add an empty string to the specified fields above so that they are not imported unless explicitly done so by using a parsing rule. This was done to ensure that a Bill-To or Ship-To that is created via EDI Import will NEVER have its address or contact fields populated from the "source" Bill-To or Ship-To.
3. Bill-To and Ship-To User Defined Fields are available to EDI Imports when Lookup or Create.

Pick list used to select the Deacom table to look up data in, when using a "Type" of "Lookup".

Expression to define the table lookup. The expression will usually contain the name of the Deacom field stored in the table indicated in the "Lookup Table" field above. 

• Note: This field uses TSQL code and not the traditional SQL code documented in the "Functions & Operators" library.

Used in connection with the importing or creation of bill-to and ship-to customers through EDI. This field will only be available when selecting "Lookup Or Create" in the type field above. When this field is enabled, users may select a bill-to or ship-to customer (depending on which one was chosen in the field "Field" at the top of the form) that represents the record that will be copied and used to create the new customer record if the lookup fails. Additional information is available in the "Import & Creation Of Customers" section further down on this page.