• Article Type: General
• Product: Aleph
• Product Version: 17.01

Description:
We have been sending EDI orders without a problem. Yesterday, we had an order for which we did not get a confirmation on the vendor's ftp server. The outgoing edi message was missing the information immediately following UNB+UNOC:3+ although it had been present in the past.

Our solution was to re-enter their password to the vendor's ftp server on tab5.EDI Address, line 3 of the corresponding vendor record. After re-entering the password and updating the record, the order was transmitted without a problem. The information showed up correctly in the outgoing message after UNB+UNOC:3+ and they received a confirmation on the vendor's ftp server. What caused Aleph to stop recognizing this password?

Resolution:
The XML that was generated by the two order sends ("before" and "after") they updated the vendor record are different. The difference is in the presence of sub-library-edi-code and sub-library-edi-code-type tags in the "after" order that are not present in the "before" XML:

<sub-library-edi-code>987654C</sub-library-edi-code>
<sub-library-edi-code-type>31B</sub-library-edi-code-type>

These tags are generated based on what is found in tab35. The check for a matching line in tab35 could be thrown off by several things. If the sub-library code that was currently selected was not ABCSL, the test for a matching line in tab35 could fail. Selecting order unit instead of sub-library is another way to change the selection criteria. It then doesn't look at the sublibrary in tab35 and would miss inclusion of the sublibrary information in the XML. Of course, tab35 could be altered between the two orders, but I don't see any evidence of that in this case.

Editing the vendor record and retyping the address was not the real solution to this problem. It just meant that when you tried again, your standard context had been re-established and the order went through normally.

• Article last edited: 10/8/2013