Seamlessly integrate with Tractor Supply using cost-effective AS2 and EDI connections. Streamline your workflow and cut costs with our easy guide. Read Now.

If you are in the agricultural or heavy machinery business where Tractor Supply (TSC) is a primary vendor, having AS2 and EDI connectivity with them is a must. Here let’s discuss the related requirements, process, and common pitfalls.

Connect with Tractor Supply

Image by TrinkK - Own work, CC BY-SA 4.0, Link

AS2 and EDI connectivity

TSC requires suppliers to use AS2, the secure B2B protocol, for all EDI transactions. Hence, a TSC connection is made up of two “layers”:

AS2 (Applicability Statement 2): exchange of securely enveloped files (potentially of any type) and receipts (MDNs)
EDI (Electronic Data Interchange): actual sequences of business-level documents (POs, invoices, shipping notices, functional ACK, etc.)

Similarly in the on-boarding phase, these two are set up and verified in that order. However due to the nature of EDI infrastructure at TSC side, these two are intertwined to some extent; and it is required to transmit a valid EDI file during AS2 connectivity phase as well.

Let’s go through the process, with MFT Gateway (MFTG) SaaS by Aayu Technologies as the AS2 communications provider:

1. Create your trading identities (stations).

You can create a station on your MFTG account, by either generating a new certificate - or uploading an existing key pair (as a key store), if you are migrating from an existing system. If you are new to TSC, make sure to use an AS2 identifier and certificate common name (CN) that represents your organization/business name.

TSC expects you to maintain two connections, with their test and production environments. Therefore, you can create two such stations on your account; the test station could typically use an AS2 ID with a “T”, “TST” or “TEST” suffix, with its own certificate.

2. Exchange your AS2 configuration with TSC.

Note: if you already have a TSC connection through another software or provider, you would instead be directed to submit a “SNOW” task through TSC’s vendor portal - in order to migrate it to the new provider and perform required re-testing.

The process typically starts with opening a support ticket through the TSC vendor portal. TSC support is generally highly responsive, and will request you to submit a set of on-boarding documents (which typically depends on the nature of your business; e.g. drop-shipping (direct-to-consumer or D2C), vs 3PL or store/DC), along with a more generic “Vendor AS2 Specifications” form - where you can fill in the details from step 1:

Contact Information: {yours}
Production Support email: {yours}
Vendor Company Name: {yours}
3rd party AS2 provider: Aayu Technologies MFT Gateway
3rd party AS2 contact: {MFT Gateway support email address}
Two separate sets of configurations, for test (“non-production”) and production AS2 connectivity:
- AS2 ID: the AS2 identifier of your relevant station
- Encryption Algorithm: 3DES (triple-DES, DES-EDE3-CBC)
- Hashing Algorithm: SHA-1
- Receipt Type: request signed receipt
- Receipt Algorithm: SHA-1
- PKI -S/MIME encrypted/signed: encrypted and signed
- Source IP address(s): IP address allocated for you, under the station’s partner view
- AS2 URL: shown in above partner view
- AS2 Software: Aayu Technologies MFT Gateway

TSC support will also provide their AS2 configurations and certificates with you, typically as .cer files zipped and embedded in a MS-Word document. You can then use this information to create separate AS2 partners on your MFTG account, representing their test and production endpoints.

Note: Please check the expiry date before importing the certs, because sometimes TSC may mistakenly share their “previous-year” certs which may already be expired or expiring very soon. (TSC typically uses certs with 1-year validity.)

TSC may take up to 5 days to configure the AS2 connection and whitelist your IP address on their end. When they confirm back, it is time for the next phase: testing.

Note: If you have a non-US IP address, the whitelisting may incur an extra charge, possibly borne by you. MFTG always uses US-based IP addresses, and is exempt from this concern.

3. Make test AS2 transmissions, both ways.

TSC usually allocates two weeks of testing time, for both test and production connections. A common practice is that TSC sends a test EDI file, and you respond back with a functional acknowledgment (FA, 997).

Testing traffic from TSC is rather straightforward; if everything is set up properly, MFTG will accept the incoming file, save it into your account’s inbox, and automatically send back an AS2-level ack (MDN receipt). If anything goes wrong, general troubleshooting should help in pointing out the issue.

As mentioned earlier, when testing traffic to TSC, the file/attachment must be a valid EDI file:

X12 4010 standard
containing correct ISA/GS identifiers and qualifiers; TSC usually expects you to use DUNS numbers, with qualifier 01
indicating correct test/production flag (T vs P) on the ISA header (ISA15)
with a Content-Type (MIME type) of application/edi-x12; in MFTG side, you can use .x12 file extension to achieve this, or specify the MIME type directly if you are using other means such as the REST API

If above are not met, TSC’s infrastructure may produce somewhat obscure errors such as the following:

expected “EDIdata” or “ediintdata”, but received a “payload”
received incorrect content type “application/pkcs7-mime” (available on the top-level AS2 envelope)
XML parsing errors (in the absence of EDI/X12 MIME type, their system may fall back to process the file as an XML)

If TSC reverts back with any of the above, please revise data and configurations of your sent file; you can always reach out to MFTG Support for further assistance as well.

4. Perform EDI transaction-level testing.

This process may vary significantly, based on your use case; for example, for drop-shipping (direct-to-consumer or D2C, by TSC’s terminology), TSC’s D2C and EDI teams will coordinate to get the following documents and labels tested:

purchase order (PO, 850)
functional acknowledgment (FA, 997)
inventory advice (846)
purchase order ack (855)
advanced ship notice (ASN, 856)
invoice (810)
purchase order change (860)
return authorization notification (180)
label (UPS)
branded packing slip (TSC)
bill of lading (LTL)

Aayu’s EDI Generator product is capable of handling most of these, out of the box.

5. Proceed to production traffic.

When all testing is successfully concluded, TSC will send you a production approved email notification. In addition to basic conditions like the use of production connection and ISA/GS IDs, be mindful of additional EDI guidelines imposed by TSC; such as sending 846 (inventory) updates once a day, the “all orders shipped” policy, and sending 997s within 48 hours for all TSC-originated documents.

In conclusion

Setting up EDI and AS2 connectivity with TSC is straightforward, when you know the process and potential delays/pitfalls along the way. Whether you are starting off as a new TSC client or migrating an existing TSC AS2/EDI connection to a cheaper and more versatile solution, Aayu’s AS2 and EDI solutions can fulfill your needs with a proven track record of scalability, reliability and support, and at a fraction of the cost.