4

Click here to load reader

Interface Errors, Why Should I Fix Them and How

Embed Size (px)

DESCRIPTION

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.

Citation preview

  • 2015 Direct Tech, Inc.AllChannel Suite v14.0.0 1

    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

  • Interface Errors, Why Should I Fix Them and How 2

    2015 Direct Tech, Inc.AllChannel Suite v14.0.0 2

    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

  • Interface Errors, Why Should I Fix Them and How 3

    2015 Direct Tech, Inc.AllChannel Suite v14.0.0 3

    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.

  • Interface Errors, Why Should I Fix Them and How 4

    2015 Direct Tech, Inc.AllChannel Suite v14.0.0 4

    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.