EDI and Web Policies

• Weekly reporting: Inventory and point-of-sale reports must be received by Adobe each Monday for the previous week's inventory and sales activities.
• Reporting accuracy: All reporting files submitted to Adobe must be in accordance with Adobe's specifications, as provided on this website. Files with structural inaccuracies or data errors will be rejected and must be resubmitted with corrections.
• Ordering worldwide: Purchase orders are received 24 hours a day, 7 days a week, excluding regular testing and data backup periods scheduled each Friday from 8pm to 1:30am, Pacific Standard Time. Orders are loaded into Adobe's sales database hourly from 7am to 6pm, Pacific Standard Time, Monday through Friday. Web orders are subject to review.

Standard EDI Policies

• EDI transmissions and documents: Adobe and distributor/reseller, each at their own expense, will acquire the equipment, software, service, testing, and training for systems use and facilities for sending and receiving information to each other by means of EDI transmissions.
• Service providers: Each party shall transmit documents using the services of any third-party service bureau ("Service Provider") it designates for the delivery and receipt of any EDI message.
• Functional acknowledgements: Each time a document is sent, it is the responsibility of the receiving party to send a functional acknowledgement of that transmission.
• Document changes: Any change requested for a transmitted document must be mutually acceptable to both the sender and the receiver of the transaction.

Purpose of EDI Policies

The purpose of Adobe's EDI policies is to set forth the standards and contract terms for all of Adobe's EDI-based transactions with Adobe's reseller and distribution channel partners.

EDI Document Standards

Adobe requires adherence to ANSI X.12 or EDIFACT standards for all partners that wish to complete any EDI transactions with Adobe.

ANSI X. 12 or EDIFACT?

Adobe will accept either ANSI X.12 or EDIFACT reporting standards from its trading partners, regardless of their geographic location. Typically, partners in North America select ANSI X.12 as their standard, while international partners trade using EDIFACT. New partners may want to consider local support issues before choosing between standards. If a partner in North America trades mostly with international partners, they may find EDIFACT more practical to implement than ANSI X.12. Should a partner decide to change standards, they will need to follow Adobe's procedure for new trading partner implementation.

All trading partners agree to comply with the following:

• Completion of EDI implementation steps, including full testing
• Acceptance of full financial responsibility for implementation and maintenance of EDI
• Transmission of data via a service provider such as a value-added network (VAN)
• Adherence to either ANSI X.12 or EDIFACT standards, as specified in Adobe's implementation guides
• Consistent, accurate, timely reporting in accordance with Adobe's processing schedule
  

EDI Requirements

Security

The Parties to a distribution agreement undertake to implement and maintain security procedures and measures to ensure the protection of EDI messages against the risks of unauthorized access, alteration, delay, destruction, or loss.

Security procedures and measures include verification of origin, verification of integrity, nonrepudiation of origin and receipt, and confidentiality of EDI messages.

Security procedures and measures for verification of origin and integrity to identify the sender of any EDI message and to ascertain that any EDI message received is complete and has not been corrupted are mandatory for any EDI message. Where required, additional security procedures and measures may be agreed upon between the Parties.

If the use of security procedures and measures results in the rejection or detection of an error in an EDI message, the receiver shall inform the sender thereof, within one business day.

The receiver of an EDI message that has been rejected or that contains an error shall not act upon the EDI message before receiving instructions from the sender. When a rejected or erroneous EDI message is retransmitted by the sender, the EDI message should clearly state that it is a corrected EDI message.

Confidentiality and the Protection of Personal Data

The Parties shall ensure that EDI messages containing information specified to be confidential by the sender or agreed mutually to be confidential between the Parties are maintained in confidence and are not disclosed or transmitted to any unauthorized persons nor used for any purposes other than those intended by the Parties.

When authorized, further transmission of such confidential information shall be subject to the same degree of confidentiality.

EDI messages shall not be regarded as containing confidential information to the extent that such information is in the public domain.

The parties may agree to use a specific form of protection for certain messages such as a method of encryption to the extent permitted by law in either of their respective countries.

Where EDI messages or other data transmitted to the other Party include personal data, such data shall be received, processed, and stored in accordance with the terms of the distribution agreement between the Parties, and the receiving Party agrees to comply with same for its processing of the data. EDI messages with personal data originating in the European Economic Area (EEA) and transmitted to the receiving Party outside the EEA shall be processed by the receiving Party in accordance with a "safe harbour" arrangement or by adhering to the terms of a separate model data transfer agreement (as published by the European Commission).

Recording and Storage of EDI Messages

A complete and chronological record of all EDI messages exchanged by the Parties in the course of a trade transaction shall be stored by each Party, unaltered and securely, in accordance with the time limits and specifications prescribed by the legislative requirements of its own national law, and, in any event, for a minimum of seven (7) years following completion of the transaction.

EDI messages shall be stored by the sender in the transmitted format and by the receiver in the format in which they are received.

Parties shall ensure that electronic or computer records of the EDI messages shall be readily accessible and are capable of being reproduced in a human-readable form and of being printed, if required. Any operational equipment required in this connection shall be retained.

If local country legislation requires or allows for the exchange of summary statement invoices, each Party shall be responsible for providing such summary statements to the other Party in accordance with such legislation.

Optional Requirements for EDI

The parties undertake to implement and maintain the operational environment to operate EDI according to these terms and conditions, which include but are not limited to the following.

Operational equipment

The Parties shall provide and maintain the equipment, software, and services necessary to transmit, receive, translate, record, and store EDI messages.

Means of communication

The Parties shall determine the means of communication to be used, including the telecommunication protocols and, if required, the choice of third-party service providers.

EDI message standards

All EDI messages shall be transmitted in accordance with the UN/EDIFACT standards, recommendations, and procedures (UN/EDIFACT Syntax Rules ISO 9735 - EN 29735, UN/EDIFACT TDED ISO 7372 - EN 27372, the UNTDID [United Nations trade data interchange directory] including the UN/EDIFACT message design guidelines, syntax implementation guidelines, data elements directory, code list, composite data elements directory, standard segments directory, UNSMs directory, and UNCID) as approved by the United Nations Economic Commission for Europe (UN/ECE-NP 4) and with European Union standards and legislation.

Codes

Data element code lists referred to in EDI messages shall include UN/EDIFACT-maintained code lists, international code lists issued as ISO international standards, and UN/ECE or other officially published code lists.Where such code lists are not available, preference shall be given to the use of code lists published, maintained, and ensuring correspondence with other coding systems.

Technical specifications and requirements

Either Party shall be responsible for defining in writing the technical, organizational, and procedural specifications and requirements to conduct their respective EDI transmissions according to these terms and conditions, which should include the following:

• Operational requirements for EDI, as referred to above including operational equipment, means of communication, and EDI message standards and codes
• Processing and acknowledgement of EDI messages
• Security of EDI messages
• Recording and storage of EDI messages
• Time limits
• Procedures for tests and trials to establish and monitor the adequacy of the technical specifications and requirements

Upon request from either Party, the other Party shall provide the requesting Party a copy of its written technical specifications and requirements as defined above.

Without prejudice to the above-stated obligations, the Parties may establish joint technical specifications and requirements, which shall be in writing and become an integral part of this Agreement.

Electronic reporting must be in compliance with posted Adobe electronic reporting policies, including submission by the partner of a quarterly statement of reporting compliance.

Quarterly Reporting Declaration (PDF, 27K)

1. What is a Quarterly Reporting Declaration?

A Quarterly Reporting Declaration is a document confirming a partner's compliance with Adobe's policies as set forth on the Adobe Electronic Interchange website. It should be signed by an officer of the company and submitted the last fiscal week of each Adobe quarter end.

2. When do I need to start reporting point-of-sale (POS) and inventory data?

Distributors and Resellers that stock and distribute Adobe media and boxed products (shrinkwrapped) are required to start reporting POS and inventory data to Adobe within 30 days of signing their contract.

3. What products should be included in the inventory and POS files? 

You should report only media and box product information in your files. Do not send inventory or POS information for licenses.

4. When should the weekly reporting files be submitted to Adobe? 

Files must be received by Monday for the previous week's inventory and sales activities. Inventory data is a snapshot in time, and it should reflect the ending inventory as of Friday of the previous week. If your files are not received on time, your rebate may be affected.

5. What if the Channel Partner's company is closed for the holidays? 

If you know ahead of time that your company will be closed for the holidays, send an email message to reporting@adobe.com informing Adobe of the days that you will be closed. You should send your files as soon as you return from your holidays. Iif you do not have any sales to report, you should still send an inventory file for each week your company was closed for the holidays. Make sure you change the "Reporting Date" to correspond to the reporting week.

6. What information is required on Channel Reporting web files?

Required columns must have data. Refer to row 2 of either the POS or inventory template. On the template, each field is labeled as either required (Channel Partner must provide data) or requested. It is recommended that you provide data for all fields; however, requested fields can be left blank. The information must be entered as specified on the instruction template; otherwise, the file(s) will be rejected by our system.

7. Can Channel Reporting Partners use their own header columns on the web templates?

You can use your own language or choice of description in headers for each of the columns in the template. The actual data reported in each column should be mapped exactly as requested in the templates.

8. Can Channel Reporting Partners enter their own description for products in the Product Description field?

The Product Description field can contain your own description of Adobe's product. The field is used by Adobe Channel Reporting for troubleshooting problems with the SKU number field.

9. What sales date should be entered in the Sales Date field of the POS file?

Use the date of when the product was physically shipped. The format of the dates should be YYYYMMDD (for example, 20070807 for August 7, 2007). The product is left off the POS report until it is physically shipped from you to the end customer. If there is a minimal timing difference between shipments and invoicing in your systems, use the invoice date in the Sales Date field to indicate a sale in the POS file.

10. What if I do not have any sales activity to report?

Our systems check for receipt of both an Inventory and POS file from our Channel Partners every week. If you do not have sales activity to report, enter the comment "No Sales to Report" when you upload your inventory file. There is no need to submit a blank file.

11. How do I report returned products from my customer?

When a product is returned by a customer and has been physically received in your warehouse, you should: 

a. Inventory file: Enter receipt of these units in your inventory file as a positive number. The units should be reported in the Quantity on Hand or the Returns Quantity field, depending on whether the product is resalable. Do not report the returned product in the Quantity on Hand and Returns Quantity columns.

b. POS file: Enter receipt of these units in your POS file as a negative number in the Quantity Shipped or Returned field. Also provide a credit memo number (or any unique identification number) in the Invoice Number field. Please note: Returns should be entered on a separate line than shipped products. (For example, if you sold ten units of a product and had two of them returned, we would expect you to report positive ten units and negative two units rather than a net figure of eight.)

12. How do I report returned products to Adobe?

If you have inventory that needs to be returned to Adobe (stock rotation, defective, obsolete):

a. Inventory file: Report the product quantity in the Returns Quantity field until you physically ship the product back to Adobe. Do not double report the returned product in the On Hand Quantity and Returns Quantity columns.

b. POS file: Returns being sent back to Adobe should not have an impact on your sales file.

13. Where can I find the table of country code values to be used in the Sold to Country and Ship to Country fields?

Look up the two-character code for a particular country on this website.

14. Who should I contact if I have any questions?

a. Questions regarding your inventory and POS files should be sent to reporting@adobe.com.

b. If you have system issues where you can’t log in to upload your files, send email to channelorders@adobe.com.

Updated EDI Guidelines - June 21, 2010

• Example :
  • N1~DU~RESELLER
  • N2~Reseller NameII
  • N3~123 MAIN STREET
  • N4~CEDAR RAPIDS~IA~524032140
  • REF~DP~DP~DEPARTMENT 100
  • REF~7I~ResellerAuth

• Example :
  • NAD+SU+++RESELLER TO+MAIN ST.9TH FLOOR.2400 PARK+LONDON++WV11+GB'
  • RFF+ACF:Department 100'
  • RFF+AKO:ResellerAuthID'
    

EDI and Web Policies

Benefits of EDI

Selecting Translator Service Providers

Profile Forms

Profile forms are provided for the mutual benefit of Adobe and its trading partners. Adobe's EDI Profile form contains the information necessary for setting up trading relationships. The Trading Partner Profile form is for use by our partners in providing Adobe with their EDI profile information.

EDI/WEB Form (PDF, 33K )

Adobe's EDI Profile Form (PDF, 5.2K)

Trading Partner EDI Profile Form (PDF, 7.3K)

EDI Organization

Organization that supports and promotes standards for business-to-business data exchange — an extremely useful site for new trading partners, regardless of location

Computing Technology Industry Association (CompTIA)
Organization responsible for the growth and direction of EDI

New Trading Partner Guidance

Implementation Guidelines

EDI Purchase Order Processing

Updated EDI Specifications - Effective November 4, 2009

850 V 4010 Purchase Order for Shrinkwrapped Orders — Updated: Sep 29, 2015
850 V 4010 Purchase Order for TLP Orders — Updated: Jun 21, 2010
850 V 4010 Purchase Order for CLP Orders — Updated: Jun 21, 2010
850 V 4010 Purchase Order for VIP Orders — Updated: Aug 31, 2015

Implementation Guides

The guides provided on this site represent Adobe's EDI specifications. Adobe's requirements are based on industry standards, following the guidelines set forth by the Computing Technology Industry Association (CompTIA). The specifications included in these guides are taken from document sets created by the United Nations Directories for Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT).

INVRPT D.93A Inventory

SLSRPT D.93A Point of Sale

EDI Purchase Order Processing

Adobe does not accept any preprinted terms in a purchase order. All pricing, payment, delivery, and freight terms are derived from the trading partner's customer master record in Adobe's sales database. A purchase order is solely a request for a specified product quantity and delivery date. Receipt of a purchase order does not guarantee acceptance into Adobe's sales database. Purchase orders failing to pass through Adobe's EDI translator will generate a failed transmission reply.

Adobe now accepts EDI purchase orders for regular retail and licensing products. Retail product orders received and processed through the translator, but not accepted into the sales database, must be reviewed by an Adobe sales representative. Licensing product orders received and processed through the translator, but not accepted into the sales database, will be routed to Adobe's licensing website for correction by the ordering party and can be found by accessing the Saved Orders link on the site.

Updated EDIFACT Specifications — Effective November 4, 2009

ORDERS D.97A Purchase Order for Shrink-Wrap Orders — Updated: Sep 30, 2015
ORDERS D.97A Purchase Order for TLP Orders — Updated: Jun 21, 2010
ORDERS D.97A Purchase Order for CLP Orders — Updated: Jun 21, 2010
CONTRL Message Syntax and Service Report — Updated: Apr 2008
INVOIC D.97A EDIFACT Invoice — Updated: Jun 22, 2009
ORDERS D.97A Purchase Order for VIP Orders — Updated: Aug 31, 2015