You are on page 1of 4

Interface Errors, Why Should I Fix Them and How

This document contains an overview of the best techniques and approaches to use when you are resolving interface
errors, how to locate specific solutions on the support site to help you, and dispels common misconceptions about
interface errors.
Interface errors that are not corrected can lead to missing data, inaccurate or outdated data, and slower daily processing.
When you are correcting errors, you should first do research in the host system and see if you can fix a process, program,
or bad data there to prevent errors going forward. In the Direct Tech system, you can correct errors in the Interface Errors
window and you can also adjust various parameter settings to prevent future errors.
When you are researching interface errors, it is best to sort the errors different ways. Try to determine if there are any
patterns that are occurring. You might see the same item, offer, or vendor erroring many times.
By finding a pattern, you may be able to eliminate many errors at once. Look for the error with highest count and then
review the details of that error. Try to determine what is causing the error and the meaning of the error message. You
can locate the specific meaning of many error messages on the Direct Tech support site. There are hundreds of different
messages and adding specific information about each one to the support site is an ongoing process. Therefore, there is
not a solution on the support site for every possible message, but the support site is still the best place to begin when
you are researching error messages. You should conduct a search of the error message solutions and see if there is
information to help you.

Locating Solutions
To locate the error message solutions in the support site, do the following:
1. Login to the support site.
2. Click on the Find Solution tab.
3. Click on the How To Documentation category.
4. Under the Data Transfer and Loading sub-category, click on the Interface Errors link

Figure 1: Direct Tech Support Site

AllChannel Suite v14.0.0


2015

Direct Tech, Inc.

Interface Errors, Why Should I Fix Them and How

Best Approach
The best approach to resolving interfaces errors is to consider the dependency order of the errors. Always correct Item
Product (IP) errors first since the other files are dependent on the IP file.

Figure 2: Interface Errors Dependency Order

The following graphic shows an example of how one Invalid Default Vendor error in the Item Master (IM) record can
create many errors in the dependent records.

Figure 3: Item Master Error Example

Another example of the importance of dependency order can be seen using the Order Transactions (OT) file. Consider
the life cycle of an order, when a customer orders it generates Demand (DMND). After the demand is generated, the order
can be shipped, become a backorder, or be cancelled. The Order Detail records post in this order. The BACK, CNCL, and
SHIP records are dependent on the DMND record posting so if there is an error, the DMND record should be corrected first.

Figure 4: Life Cycle of an Order

AllChannel Suite v14.0.0


2015

Direct Tech, Inc.

Interface Errors, Why Should I Fix Them and How

Misconceptions
The error resolution process can be technical, multi-faceted, and often the solution may not be readily apparent. Since
it can be a complex process, many users have misconceptions about the errors and the resolution process. These
misconceptions often lead to additional errors and complications. It is important to understand why these common
misconceptions are not true and their implications when you are developing good techniques to handle you interface
errors.

Figure 5: Interface Error Misconceptions

Errors Can Be Deleted


Because IP is a full snapshot, you might conclude that you could just delete current errors because any missing or
erroneous records will load again tomorrow. This is incorrect because only new or changed records from your host are
ultimately processed into the database. Refer to the Alternate Processing section of the Interface File Layouts Reference
Manual for additional explanation about why this is the case.
Please do not delete errors on your own. If you feel deleting is necessary, please contact Direct Tech support before you
proceed.
If you deleted errors without contacting support first, it is important to let them know you deleted errors when you are
submitting a case related to the issues and problems that deleting creates.
Errors Can Be Recycled
The data will not get loaded and this will create further confusion.
Errors Will Go Away In Time
Errors recycle and process every day until they are corrected. They can cause correct records to not post. Errors that
are not corrected will most likely cause additional errors.

AllChannel Suite v14.0.0


2015

Direct Tech, Inc.

Interface Errors, Why Should I Fix Them and How

Parameters that affect Interface Errors


There a number of system parameters that can make errors MUCH easier to correct and produce fewer errors going
forward. It is important to review the values of these parameters with Direct Tech to help your overall interface errors.
The parameters highlighted below are not all of those which affect interface errors, however, they are some of the most
important.
Interface Error Handling
The FINT_ERROR_HANDLING parameter controls how interface errors are handled. Traditionally, when we received an
error, it persisted until it was corrected and posted. This still happens if the value of this parameter is set to STANDARD.
This method can result in accumulated errors if they are not monitored and corrected. Therefore, it is important to set
the value of interface error handling parameter to ENHANCED.
When the value of this parameter is set to ENHANCED, the assumption is made that the last record we received for an
item is the ultimate end result. For example, if we receive a CHANGE record today, we want that record to post (create
the production entry if it doesn't exist, or update it if it already exists) regardless of any other error record that occurred
previously. In addition, we want to remove any previously erroneous records, so they don't interfere with the action we
are taking with today's record.
Treat DMND Add Records as Changes
The FINT_OT_TREAT_ADD_AS_CHANGE parameter controls how we handle changes to order detail. The default method
is to erase the previous demand by manually sending a DMND delete record. If you cannot send DMND delete records
via the OT interface, this parameter allows you to send add records only.
When the value of this parameter is TRUE, it does not require DMND delete records to be sent to change Order Transaction
(OT) data. If an order line is already posted, the new DMND Add record is sent and the previous data is automatically
deleted. When the value of this parameter is TRUE, it can prevent Add Record/Already in Marketing order Detail errors.
Product Mismatch on Supplementary Records
The MATCH_DMD_ACROSS_RECS parameter controls whether supplementary demand types (ships, cancellations,
returns, etc.) are forced to match the DMND order number/order line record. The fields that are verified/updated are SKU,
PRODUCT_ID and DESCRIPTORS 1, 2, & 3. When the value of this parameter is TRUE, it helps eliminate errors by making
assumptions that the DMND record is correct and any future updates to the record are for the same item. It prevents
subordinate Record with Mismatching Product/SKU in Order Detail errors.
Extended Cost Check
The FINT_OT_CHECK_EXTENDED_PRICE, controls the whether the extended price field is compared to the extended cost
field during the order transaction error checking process. This is a reasonableness check, as cost should be less than price
in most cases. The demand, shipments, returns, and cancels records use this parameter. When the value of this parameter
is T (true), the absolute value of the extended price is compared to the absolute value of the extended cost. The
FINT_OT_CHECK_EXTENDED_PRICE_FACTOR and FINT_OT_CHECK_EXTENDED_PRICE_OFFSET parameters provide
additional control for the formula used in this check. When these parameters are set in alignment with your business
practices they can prevent the Extended Cost error check failed error.

Summary
The best approach to dealing with interface errors is to monitor and correct them daily. They can quickly build to a point
that becomes unmanageable and discouraging. Taking the time to correct the errors will help to to ensure you have
complete, accurate, current data, and optimized daily processing.

AllChannel Suite v14.0.0


2015

Direct Tech, Inc.

You might also like