The EDI Cable Committee (TECC) is an organization of cable television networks, advertising agencies and vendors whose purpose is to improve the process of buying and selling cable television advertising through the use of Electronic Data Interchange (EDI) and related technologies. This, in turn, will lead to increased profitability for trading partners through lower costs and higher quality transactions. The Cabletelevision Advertising Bureau (CAB) coordinates the Committee and helps publish standards.
The primary purpose of this guide is to document the new version 3.0 TECC standard and to act as a technical reference for users and implementers of this standard. The TECC V3.0 standard is based on ASC X12 Release 4010. However, unlike traditional EDI implementation guides which assume both EDI and industry knowledge, this guide is also intended as a source of information to the many non-technical or casual users of the TECC guidelines, including those new to EDI or cable television advertising. The guide will provide practical information and real-life examples in addition to the formal technical EDI specification. Certain sections of this document have been written specifically for users with the following levels of experience:
Unlike traditional EDI strongholds (e.g. retail, transportation), media companies do not typically have existing EDI departments. In the media industry, many users’ first exposure to EDI is when they became involved with the TECC standards. In fact, few members of the founding TECC initiative had significant EDI experience before their involvement with TECC. X12, the language of EDI, grew out of a pre-Internet, pre-PC world with its own language and syntax. It can be somewhat daunting to new users, especially those who have grown up in a PC-based world. Therefore, one of the major goals of this document is to provide an introduction to EDI to those who have little or no X12 or EDI experience.
The X12 business model for purchasing is based on commerce as it occurs in “traditional” retail industries (i.e. where individual items are chosen from a fixed inventory and price list, ordered via a purchase order, and invoiced after delivery). While the purchase of media advertising shares much in common with this model, it cannot be stressed enough that there are some significant differences that are frequently overlooked or underestimated by those new to the advertising and media industries. This is particularly true of network cable television advertising with its fixed inventory of commercial units, negotiated orders with guaranteed demographics often covering a full year, and multiple changes to the order occurring throughout the year. Brand allocation and traffic instruction transactions also modify attributes of the original order, potentially splitting or combining the ordered units into new units. Therefore a second goal of this guide is to help those new to cable television advertising understand the industry’s terminology and business practices.
Version 3.0 of the TECC specification marks a significant improvement over the earlier versions of the TECC standards. The new standard is fully Y2K compliant and is designed to solve some of the ambiguities of previous standards. This should greatly reduce the number of individual trading partner variations that must be supported. The TECC V3.0 standard provides a single format that can be used by all trading partners, regardless of whether or not they support serialization. This version also benefits from the many years of practical experience that TECC members have gained since the initial implementation of EDI. A very important aspect of the TECC 3.0 standard is the workflow rules section. These rules had only been implied in previous standards and had been implemented differently across trading partners. A third major goal of this document is to highlight the differences between version 3.0 of the TECC specification and previous versions.
As previously mentioned, some sections are tailored for users with specific backgrounds and requirements. Notes on the applicability of the sections are interspersed throughout this guide. Hypertext links allow a user to easily skip over sections of less interest. Those new to EDI should start with the Overview of EDI section. Users who will be implementing the specification should pay special attention to the technical details. Those new to cable television should read the Overview of Cable Television Advertising section first. The section Overview of National Cable EDI will be useful reading for all users new to the TECC standard. Finally, users familiar with the previous versions of the TECC standard will be especially interested in the Migrating to TECC V3.0 section.
The intent of this guide is to provide accurate, up-to-date, practical information to users with varied degrees of experience. This document will act as the reference source for the CAB, and to clarify and resolve differing interpretations of the standard. It is requested that all readers, particularly existing users of X12, review all sections of this document and provide feedback on the value of the information, suggestions for improvement, and especially, any incorrect or ambiguous information. Click here to send feedback.
This section is designed primarily for those new to EDI by providing a general overview of the subject. As a result, cable industry-specific examples and terminology have been minimized. Nevertheless, experienced users should also read this section because it provides some background information that is useful in understanding the cable television industry’s specific implementation. Click here to skip this section.
EDI, like many technical terms in use today, has multiple meanings:
· Some users employ EDI in its generic sense to mean any exchange of data between two computer systems. Under this definition, a file copied to diskette and loaded into another computer would qualify as EDI.
· A more precise definition implies direct computer-to-computer communication of business transactions in a standard context-sensitive format (i.e. each computer understands the “meaning” of each field without requiring additional human interpretation).
· EDI is most commonly used to mean the exchange of information according to the standards defined by the ANSI ASC X12 committee via a commercial Value Added Network (VAN). (These terms will be defined later in this section).
· In the cable television industry, EDI is typically used to mean conformance to the TECC EDI guidelines (i.e. this document).
IMPORTANT NOTE: All of the above definitions are frequently used, so it is important to be aware of these multiple interpretations. When communicating with trading partners, it is important to know which definition is being used.
Electronic Commerce is the latest term used to generically describe electronic business-to-business communications. However, in the Internet world, the term electronic commerce has developed increasingly to mean the purchase of goods electronically. In the cable television industry, the term is used in its generic sense.
EDI benefits an organization through the use of more efficient and higher quality business processes, which in turn, lead to higher profitability. Like any technology, there is a cost to implementing EDI. The level of benefit and period of payback vary depending on the industry and the implementation methodology.
Benefits typically result from the following:
· Reduced Labor Costs of Mailing and Data Entry - In a paper-based world, one computer typically prints a document that is then sent (i.e. via mail, fax) to a trading partner where a human re-enters the information into a second computer system. EDI eliminates the need to re-enter this information and reduces the costs of mailing and receiving documents because there is no longer an envelope to route or a fax machine to load.
· Timeliness of Information - Information is transferred much more quickly from one computer system to another using EDI. The relative importance of this varies depending on the industry, but it will often result in improved cash flow management.
· Higher Quality Information - Typographic errors can have significantly greater consequences than just the labor costs of reviewing and re-typing the data. Some of these costs are easy to quantify while others are less simple (i.e. shipping the wrong item to a customer can incur additional shipping and labor costs from Customer Support required to research and correct the problem. These costs can be easily quantified from bills and timesheets. However, this problem may also lead to a dissatisfied customer, who then either takes their business elsewhere or becomes more price-sensitive in future negotiations). Quantifying such costs is clearly difficult, but nevertheless they are important to recognize.
· Better Communications, Improved Business Processes - EDI also creates feedback systems to ensure that documents are actually delivered and received by the correct party. This can eliminate the need for follow-up phone calls and emergency re-transmissions of documents.
· Standardization - Frequently overlooked are the substantial benefits to an organization stemming from standardization. An organization can use a single business process to communicate with each customer, versus having a separate process for each one. While the costs of individual variations from a standard are often small and easily overlooked, the cumulative effects can be substantial (i.e. the costs incurred if each customer requires a unique printed invoice format. In addition to the one-time costs for MIS to create the new format, there are additional ongoing costs such as the additional time it takes to add a new customer and the amount of additional education and training required for support personnel).
The American National Standards Institute (ANSI) is the recognized coordinator for information on U.S. national EDI standards. The X12 Accredited Standards Committee (ASC X12) is an ANSI-chartered organization that creates EDI standards for submission to ANSI. This body publishes one major release and two subreleases of the X12 standards annually. Version 4010 (version 4, release 1) was published in December 1997 and is the basis of TECC V3.0. The X12 organization currently has 11 subcommittees which meet 3 times a year to recommend changes to the standards based on member requests. The entire membership has then the opportunity to vote on the recommendations of each subcommittee. The Data Interchange Standards Association, Inc., (DISA) is the secretariat for ASC X12. Formed in 1987 and with a current staff of over 25, they coordinate all activities of the ASC X12 body. (A more detailed description of the history and workings of X12 follows at the end of this section).
It is important to understand that the X12 specification is just a rulebook. The standard is voluntary, and trading partners frequently add new rules or modify and ignore existing X12 rules. Trading partners with significant industry power often require conformance to their own variations of the standard. The X12 organization only provides documentation of the standard, it does not provide any implementation software or infrastructure.
The benefits of a standard diminish as more individual trading partners make their own rules. In order to minimize trading partner specific rules, many industry segments have formed trade associations to create and maintain industry-specific versions of the X12 standard. For example, the grocery industry formed the Uniform Communications Standard (UCS), the warehouse industry formed the Warehouse Information Network Standard (WINS) and the chemical industry has the Chemical Industry Data Exchange (CIDX). Each trade association standard typically narrows the X12 rules for individual industry usage (e.g. the grocery industry requires a UPC code to identify each specific grocery item even though this is optional in the general X12 standard). As a result, a transaction that conforms to X12 rules may still not conform to the more restrictive industry rules.
TECC, by representing the cable television advertising industry, is an example of such an industry group. TECC’s specific role is to interpret and narrow the X12 standard for use by the cable television industry.
While the physical definition of a standard is clearly important, the marketplace that supports it is equally important. X12 would be significantly less valuable as a standard if it were not supported by the numerous third-party vendors who provide the tools and infrastructure. X12 users and vendors have a symbiotic relationship; users need vendor competition to ensure lower costs and high quality tools and services; and vendors need a large user base to justify their investment and ensure profitability.
Users new to X12 may find that the standard seems dated and less flexible than newer technologies. While this is generally true, the value of the standard is not just in its technical detail but more importantly, in the marketplace that surrounds it. (As an example, although MS-Windows may not the best operating system from a technical standpoint, it is often the best choice because it has a large user base). X12 is the recognized standard for EDI in the U.S. and has significant support in the marketplace. While other standards, such as XML, look promising, it will be a while before they have a similar infrastructure in place.
Vendors are typically classified as either broadly oriented (i.e. they provide generic products that can be used for all X12 transactions) or narrowly oriented (i.e. products for a specific market segment such as transportation). Broadly oriented products provide the most flexibility but typically require significant customization for an individual industry segment. Narrowly oriented products require less customization and general X12 expertise. However, they are limited to a particular segment and new tools are required when expanding into X12 transactions beyond those in the industry segment. The correct choice usually depends on an individual company’s capabilities and strategy.
The X12 marketplace has 4 key segments:
· Value Added Networks and Communications - An essential component of EDI is the communications infrastructure that allows a file to be transferred from one computer to another. A Value Added Network (VAN) is essentially a large private network that operates like a post office. A user connects to the network (e.g. via a modem) and uploads a piece of X12 mail to be delivered to another user. The user can also check their mailbox and download any mail addressed to them. Most VANs can also send mail to a mailbox belonging to another VAN via an “interconnect.” It is important to note that the VAN model was developed well before the Internet was available as an option. VANs provide some essential value-added services that are not part of current standard Internet e-mail protocols (e.g. security, and delivery tracking and receipts). Finally, VANs can actually validate the contents of the documents for conformance to X12 standards. Some vendors, including some traditional VANs, are beginning to offer their services using the Internet as the communications backbone.
· Translation - Translation is the process for converting internal files to an actual X12 document. This is typically done by generating a “flat-file” from the MIS system and performing a field by field “mapping” of that file to the X12 document. There are many companies offering tools that enable users to perform the mapping. Some tools are designed for non-programmers and provide an easy-to-use interface; others require some programming expertise but allow more customization. Many companies offering mapping software also act as VANs.
· Education and Documentation - There are a significant number of books and publications available on EDI and X12 implementation. Several companies offer EDI courses to train new users, particularly in the area of mapping. Most translation software vendors also offer some training.
· Consultants and Service Providers - Many X12 consultants are available to provide advice on setting up EDI in a company. If necessary, they can act as a “contract employee” to set up translation software and handle the mapping, etc. An organization can also hire an external “service-bureau” to run their EDI operations. More recently, new vendor companies have been formed to provide “turn-key” industry-specific software that consolidates all EDI functionality into a single module.
The only way to communicate via X12 is by using an approved Transaction Set (These replicate an existing paper form). There are over 200 transaction sets in the X12 standard ranging from common forms (e.g. invoices and bills of lading) to specialized industry forms (e.g. application for mortgage insurance benefits). Each has been assigned a 3-digit number that is frequently used instead of its name (e.g. an invoice is called the 810). The standard and design philosophy for transaction sets has evolved over time. In the past, the X12 committees have favored adding new transaction sets for new uses. More recently, they have become reluctant to create any new transaction sets, preferring to modify existing ones. This explains why the cable television industry uses a Purchase Order for the transmission of an order for cable advertising, even though it differs significantly from the “traditional” definition of a purchase order. The cable television industry currently uses only 6 of the X12 transaction sets:
· 850 - Purchase Order
· 855 - Purchase Order Acknowledgment
· 860 - Purchase Order Change Request
· 865 - Purchase Order Change Acknowledgment
· 810 - Invoice
· 997 - Functional Acknowledgment
NOTE: The following sections provide additional historical and technical detail that may be of less interest to the casual or first-time reader. Click here to skip to the next section.
Non-technical readers may want to skip the following technical overview of X12 transactions. Skip here to jump over the technical overview.
Just like its paper form counterpart, a transaction set is composed of multiple fields of information. Fields that make up a logical group (e.g. name, address and telephone number etc.) are called Segments. Each transaction set is composed of multiple segments. Some segments can appear multiple times on a form (e.g. listing all of the items in a catalog), some are optional (e.g. method of shipping on an invoice) and others are mandatory. X12 uniquely identifies each segment with a short 2- or 3-character alphanumeric id. There are over 300 segments in the X12 specification. Some segments are very specific (e.g. the ADV segment for advertising demographic information) while others allow a lot of trading partner variation (e.g. the SI segment which allows for numerous industry-defined name-value pairs). Transaction sets typically consist of three sections, or “tables”. The header section (Table 1) contains the information that might appear at the top of a paper form (e.g. buyer and seller names). The detail section (Table 2) contains the actual details of the transaction (e.g. item numbers and quantities ordered). The summary section (Table 3) contains transaction totals (e.g. the total invoice cost).
Segments are composed of individual fields called Data Elements. Data elements may be optional, mandatory or conditional on other elements (e.g. an area code may be specified only if there is a phone number). Each data element has a data type (e.g. numeric or alphanumeric), a minimum and maximum length, and optionally, a list of allowed values. The X12 standard does not allow an element to appear multiple times within a segment. X12 uniquely identifies each data element by a number. There are over 1500 data elements in the X12 specification.
To send transaction sets from one trading partner to another, they must be organized to ensure proper delivery. Transaction sets designated for a particular partner (i.e. those sets grouped together in an “Interchange Envelope”) begin with an Interchange Control Header (ISA) segment and end with an Interchange Control Trailer (IEA) segment. The header identifies the sender, the recipient, a time and date stamp, and an interchange ID number that can be used for tracking purposes. Related documents, called a Functional Group, begin with a Functional Group Header (GS) segment that contains an additional time and date stamp, and ID number. Functional groups end with a Functional Group Trailer (GE) segment that includes a count of the number of transaction sets. The recipient uses this information to ensure that all of the transaction sets have been received. The interchange envelope ends with an Interchange Control Trailer (IEA) segment that keeps a count of the number of functional groups. Even if a transmission contains only one document, it still must contain a Functional Group Header and Trailer.
Note the following background information will be useful to understand how X12 formed, how it operates and some of its terminology. However, it may be too much detail for some users. Click here to skip this section.
EDI began in the early 1970’s when the transportation industry (i.e. ocean, trucking and rail) formed the Transportation Data Coordinating Committee (TDCC). The first TDCC standard, composed of 45 transaction sets, was published in 1975. ASC X12 was chartered in 1979 and based their standards on those developed by the TDCC. Computer technology was very different at that time; the majority of computers were mainframe computers running proprietary operating systems. There were few standards for communicating between computers built by different manufacturers and even computers manufactured by the same company had difficulty exchanging information. There were numerous modem standards (the common “Hayes-standard” did not exist), and most protocols for transmitting files were vendor specific. Even sending tapes was not easily accomplished because some used the EBCDIC system to store alphanumeric data and some used ASCII. Much of the early EDI standards process was oriented to solving these problems, many of which seem trivial in today’s PC and Internet-enabled world.
X12 standards are technically not official ANSI standards. The ANSI standards process requires an even more rigorous public review process that can take years of elapsed time from submission until adoption as an ANSI standard. As a result, the formal X12 documentation refers to the adopted specification as a “Draft Standard for Trial Use”. While this has no practical implication, it does lead to confusion when viewing documentation and using the term ANSI standard. In the cable television industry, ANSI and X12 are used interchangeably to mean the current X12 standard.
The Data Interchange Standards Association, Inc., (DISA) coordinates all activities of the ASC X12 body. This includes maintaining the numerous X12 rules and regulations, organizing and coordinating the 3 annual meetings of the X12 body, organizing the annual industry EDI conference and trade show, and publishing numerous standards and guidelines. Each year the standard undergoes one major release (published each December) and two minor releases (subreleases - published in February and June). In reality, the only difference between a major release and a minor release is the date of the meeting. However, there can be some practical implications because some third-party suppliers still do not support subreleases. The DISA web site is http://www/disa.org.
The version of the standard is identified by a number of the format xxxyyz where xxx is the version number, yy is the release and z is the subrelease number. Leading zeroes are often dropped so the format is often called xyyz. The current TECC specification is based on Version 4, Release 1, Subrelease 0, which is commonly written as 004010 or 4010 (and pronounced forty-ten). The version number is somewhat arbitrary and changes when there is some “major” change to the specification. The first release of Version 3 was in 1990 while the first release of Version 4 was in 1997.
Industry standards are typically based on a specific version of the X12 standard. Trading partners typically do not upgrade to the newest version of the standard without an important reason to do so. It is not uncommon for some industries to be several generations behind the current standard (e.g. some in the transportation industry are still using version 2040 of the X12 standard from 1989).
In 1986, the United Nations formed a group, UN/EDIFACT, to set international EDI standards. The syntax and structure of EDIFACT transaction sets (called messages) are somewhat different than X12 but the concepts are similar. Users familiar with X12 can easily understand EDIFACT after some review. EDIFACT was organized around regional associations; the U.S. belongs to the Pan-American EDIFACT Board (PAEB) which represents all North America. A recent reorganization has consolidated the regional associations. The goal was to eventually replace the X12 standard with EDIFACT but the bureaucratic nature of standards setting, and in particular, international standards, has delayed this initiative. It is highly unlikely that the cable television industry will be involved with EDIFACT. The current growth of the Internet is likely to create new EDI standards before EDIFACT becomes a worldwide standard.
The X12 body is composed of over 850 member organizations. The steering committee oversees X12 and numerous task groups. Eleven X12 subcommittees handle modifications to the standard. Some X12 subcommittees are industry oriented (e.g. X12N - Insurance) and others are functionally oriented (e.g. X12F - Finance). Modifications to the standard are made by a formal request (called a DM - Data Modification Request) from an X12 member. The Technical Assessment Subcommittee (X12-J or TAS) is responsible for routing the request to the appropriate subcommittee and ensures that overall X12 design rules are followed. Each subcommittee has ownership of particular transaction sets, although multiple subcommittees often review the same DM. Each subcommittee has evolved over time and has developed somewhat different design philosophies and methodologies. As a result, getting DM’s approved is sometimes as much political as it is technical. Disagreements between subcommittees and even between particularly vocal members can delay adoption of DM’s over multiple meetings. The cable television industry has been involved mostly with the Purchasing Subcommittee (X12K) which is responsible for the Purchase Order (850) transaction set.
Rapid technology changes, including the growth of the Internet, are straining the X12 organization. Some member organizations are still using legacy mainframe systems and are reluctant to make significant changes whereas others are pushing forward with new technologies such as object-oriented EDI and XML. These strains were particularly apparent when the X12 body took several years and multiple meetings to finally agree on a standard for adding century information to dates in order to be Y2K compliant.
In order to understand the importance of EDI to the national cable television industry, one must first have a good understanding of how the industry works, industry terminology, and how it differs from other “traditional” industries. The following section is for those readers who are new to the cable television industry. Click here to skip this section.
Modern television began as a broadcast medium. A local television station would broadcast a signal on a VHF or UHF frequency, which could be picked up by those households within the vicinity of the broadcast antenna. The larger local stations were affiliated with one of the national broadcast networks (i.e. ABC, NBC, CBS) who would provide them with the programming they required for broadcast to their local community. The network receives revenue by selling advertising that would air on all of the affiliate stations that carried their programming. This is called national advertising because it is primarily sold to advertisers whose products are sold across the country. In addition to being paid by the network to air its programming, the local station also receives revenue by selling advertising that will only air on the local station. This is called spot advertising. Spot advertising is often sold to local merchants but the station can also sell to larger national advertisers whose commercial will air only in that particular market. The first is called local spot advertising while the latter is called national spot advertising. The distinction is required because they are typically sold by different organizations. National advertising is typically purchased by larger advertising agencies on behalf of the national advertiser; local spot advertising is largely purchased by smaller agencies or directly by the advertiser.
Each half-hour of programming is typically allotted a certain amount of time for commercial messages. Some of these messages are allocated to the network and some are allocated to the station. Commercial time is typically sold in 30-second increments, which are typically called units (for national advertising) or spots (for local advertising). The terms spot and unit are often used interchangeably.
Cable television originally began as a method to deliver broadcast television to communities who were unable to receive a quality broadcast signal. A community would often erect a large antenna to pick up the broadcast signal and pass the signal on to homes connected via a coaxial cable (This was called CATV - community antenna television). This technology also became popular in urban areas to give viewers a higher quality picture from broadcast stations.
CATV grew into cable television, as we know it today. Individual communities would typically award a contract to a single cable system operator who would build the coaxial cable infrastructure to connect homes in the community to their “headend”. The system operator then re-broadcasts a signal via the coaxial cable. The coaxial cable was also capable of carrying additional signals beyond those received via broadcast and the idea of network cable was born. Cable television networks create a schedule of programming that is transmitted to each system (typically via satellite) for re-broadcast by the cable system to homes in its local area. Some cable networks only target a specific region of a country and are called regional networks. Cable networks and system operators negotiate the terms under which the network’s signal can be retransmitted. (The industry term for this is “carriage”). Most individual systems are typically part of a larger company that owns and operates more that one system. Such a company is called a multiple system operators (MSO). Originally, all advertising on a cable television network was sold as national advertising. Recent advances in technology now allow system operators to sell advertising locally and “insert” the commercials into the national network programming.
While they may appear to be the same, the business processes for buying and selling national (network) cable television advertising differ significantly from that used for local television advertising. The reasons for this are varied but among the key factors are that national advertising is seen in more homes, is more expensive, and must therefore be tracked in more detail. The TECC initiative deals only with national network advertising, so this introduction will focus on that process.
As in the case of an airline with its fixed number of seats, a cable network has a fixed inventory of units that they can sell in a given program. Multiple advertisements are typically aired back-to-back during a break. A group of advertisements is called a “pod”. A pod of four 30‑second units (2 minutes) is typical. Some advertisers want to air in a particular “pod position” (typically the first or last position in the pod) or to buy both the opening and ending commercial positions (called a bookend). Just as an airline can not add more seats to a popular flight or get any revenue from an unsold seat, a network must carefully manage its inventory to gain the maximum yield.
Units are priced according to their desirability to advertisers. Most advertisers typically want to reach a target demographic audience, which is a combination of the viewer’s gender and age group (i.e. Men 18-34 or Adults 55+). A viewer watching a program is called an impression. The cost per thousand impressions (CPM) is typically used when discussing advertising costs because it simplifies comparisons between programs.
Example:
A program has 500,000 viewers.
400,000 of the viewers are male, 100,000 are women.
The cost of a 30-second spot is: $5,000
The total CPM is: $5,000/500 = $10.00
The CPM for an advertiser targeting men: $5000/400 = $12.50
The CPM for an advertiser targeting women: $5000/100 = $50.00
Each program appeals to a different audience and a different demographic segment. A network tries to maximize its revenue by selling to advertisers who value the demographic profile of a particular program. Advertisers (via their advertising agencies) try to minimize their costs by finding programs that offer lower CPMs for their target audiences. Clearly, it is difficult to find a perfect fit. As a result, the networks and agencies typically agree to a target total impressions and total costs for the target demographic. Both network and agency work on creating a package of units that will deliver this audience and satisfy each party. The initial broad negotiation is called the Pre-Buy process while the specific programs in which a unit will air (and date of airing) are detailed in the deal. Most deals cover an entire year’s worth of programming and are negotiated many months before the beginning of the new season. This negotiation period is called the upfront. Inventory not sold in the upfront or which becomes available for other reasons, is sold throughout the season and is called scatter. The program and date of airing are important to advertisers so that a commercial reaches the target audience at an appropriate time (e.g. most advertisers would not want all of their annual advertising to occur in a single week).
The new cable season typically begins in late September or early October. The upfront negotiation period varies but usually occurs during the late spring. However, this process is changing as some cable networks are modifying their programming schedules to start a new season at different times of the year.
Scheduling and billing is typically done according to a “broadcast calendar” and “broadcast clock”. The broadcast calendar defines a week as starting on Monday and ending on Sunday. A broadcast month is defined to also always start on a Monday and end on a Sunday so that it only contains full weeks. By convention, the broadcast month begins on the first Monday after the last Sunday in the previous calendar month. The broadcast clock defines a day as starting at 6:00 a.m. and ending at 5:59 a.m. of the following calendar day (e.g. the broadcast month of January 2000 actually begins on December 27, 1999 at 6:00 a.m. This is because December 26th is the last Sunday in the calendar month of December). To accommodate this, many systems use a “30-hour clock”. This means that a unit airing at 5 a.m. (0500 in military time) on December 27th, would be stored as airing at 2900 on December 26th.
One characteristic that makes cable advertising unique is that CPMs are guaranteed. If a deal fails to deliver the total number of impressions required (known as under-delivery), then additional units called ADUs (audience deficiency units) must be added at no additional cost to make up for the shortfall. Refunds are avoided if possible, because the advertiser needs their commercial to be seen in order to generate sales. On the other hand, if a network delivers more impressions (over-delivery) than are stated in the deal, it does not receive any additional money from the advertiser. A deal is based on estimated impressions (i.e. an estimation of how many people will view a particular program in the future). However, the final calculation is based on the actual impressions: the actual number of people in the target demographic who viewed the program. Actual impressions are determined by data collected by the A.C. Nielsen Company and reported in its NTI reports.
Many networks provide added value by associating “billboards” with some units. A billboard is a short (typically 5 second) introduction to a unit, and frequently consists of an audio introduction such as “This program is sponsored by….” accompanied by an on-screen graphic. Billboards are usually offered as value-added features and as such have no costs themselves. A billboard is always associated with a specific unit (i.e. if the unit is moved to a new program or pod, the billboard must also move with it). Billboards are negotiated as part of the overall deal.
Some networks repeat their programming at different parts of the day. When the advertising is also repeated, the units are known as “mirrored”. Similar to billboards, mirrored units are tied to each other and therefore require some special handling.
The pre-buy process focuses on those parameters that affect the overall aspects of the deal (e.g. the total number of units, unit length, specific programs, number of billboards, aggregate impressions and CPM). The agency typically negotiates with various networks to achieve the goals of its media plan. The media plan, agreed upon by both agency and advertiser, serves as the master outline of all advertising purchases. The media plan typically identifies the flight (the period in which an advertising campaign is to run), the budget, and target demographics.
The deal breaks the media plan down into unit specific detail. A deal document is sent from the network to the agency for their approval. This document identifies each unit in the deal by program, air date, time period, associated billboards, unit cost, and the estimated target demographic impressions for the unit upon which the guarantee is based (Note that guarantees are for the deal in aggregate, not for each individual unit).
The agency reviews the document to ensure its accuracy and then typically enters the information into their internal MIS system (Either by keying this information in manually or by using EDI to automatically update their MIS system).
The unit level information in the deal is based on the best information at hand at the time of the deal. However, the reality of the media market is that some changes are inevitable (i.e. the upfront occurs many months before even the first unit airs, means that some units are purchased well over a year before airing). The deal document is essentially just a “snapshot” of the agreement at a particular point in time. Both parties are aware of this and work together to negotiate changes that maintain the spirit of the original deal.
One very important aspect of the process is that no change can be made to the deal without the approval of the other party. While a network can cancel a program without the agency’s approval, it cannot reschedule the unit to a different program without the agency’s approval.
As a unit nears its air time, changes become more frequent. A deal typically undergoes some change at least every week. Daily changes are not uncommon. Networks may cancel or reschedule programs meaning that units have to be moved to new programs. Units are also moved within a program for various reasons; commercials may not air due to special programming (i.e. major news events) or due to technical problems. Such units must be rescheduled or credited. Agencies can also request schedule changes due to changes in advertiser’s schedules or media plans (e.g. a movie is scheduled to be released a month after originally planned).
On occasions, a network may add “zero-cost” units to the deal. These Audience Deficiency Units (ADU) units are added to make up for under-delivery. Recapturable units, commonly called recaps, are included in the deal in case the network under-delivers. This enables the agency to know in advance where the recap will air if it is required. The network can cancel (“recapture”) this unit, after agency notification, if the guarantee can be met without it.Bonus units are sometimes given as “rewards” to an advertiser and do not count toward the guarantee.
All changes initiated by the network must be reviewed with the agency before the change is actually made.
Advertising is usually purchased well before the agency or advertiser has decided on which specific commercials they will air. In addition, large advertisers may pool several different products in a single deal to get better prices and to give them greater flexibility. The individual units are later allocated to specific brands (Brand Allocation) and assigned to individual commercials (Traffic Instructions or Copy Instructions). An advertiser may request to “combine” two 30-second units into a single 60-second unit or “split” a 30-second unit into two 15-second units (or even split a 60 into a 45 and a 15 etc.). A network will try not to air competing commercials in the same pod (and are often contractually obligated to do so), so brand allocations and traffic instructions may require the network to rearrange its scheduling of the units.
The actual ad copy that is scheduled to air is usually identified by an 8-character industry standard “ISCI” code assigned by the American Association of Advertising Agencies (AAAA). This code is physically attached to the actual videotape of the commercial so that a network can identify which commercial to air during a specific time slot. The shipping and tracking of the physical media containing the audio and video is known as “traffic”. The terms “traffic instructions” and “copy instructions” are used synonymously.
When a unit does not air for some reason and is replaced by another unit (or units) the new unit is called a “makegood”. The makegood unit maintains a link to the unit it is making good in order to aid in “stewardship”. Stewardship is the term used to describe the process of monitoring how a deal is doing in terms of meeting its guarantee. Makegoods do not need to be 1 for 1. For example, an unaired unit in a program with a large audience may be made good by 2 units in a less popular program. This would be called a “2 for 1” makegood. Makegoods come in many flavors (e.g. “3 for 2” or “1 for 2”).
After airing, the network sends an invoice to the agency detailing each unit and the time it ran. The invoice serves both as an affidavit and a bill. The distinction is important because it may involve two different departments at an agency. Invoicing is typically done monthly. The agency undertakes a “reconciliation” or “match” to ensure that the unit on the invoice matches what was agreed to in the original deal. If errors were made in entering the numerous changes since the original deal, it may take months of effort to resolve the discrepancy. Typically an agency will not pay an invoice until all discrepancies are resolved. Agencies do not usually get paid by the advertiser until they pay the network so both parties lose money (as well as incur increased labor costs) due to the long reconciliation process.
Post-buy analysis (often called “posting”) sums up the actual impressions that the deal has achieved to date based on the units that have actually aired. After the client schedules have been reconciled to what has actually aired, the agency can then post the actual viewing impressions of the people in their target demographic that have actually viewed the program. The validated sources of measurement are A.C. Nielsen reports or tapes. This analysis allows the agency and network, to track whether the deal is likely to achieve the guarantee as well as anticipate any under-delivery problems (Remember that the deal was based on estimated (vs. actual) impressions). While many agencies do the posting analysis themselves, networks can also provide the agencies with a report of actual delivery, generated by a neutral third party.
Note that while the negotiations between agency and network are based on the deal, the agency’s primary concern is that they achieve the overall media plan.
The prior section was designed to be a “primer” on the major aspects of buying and selling national cable television advertising and to provide a basis for understanding the remainder of this document. It should be apparent that the national cable television business process is complex and goes beyond other “traditional” industries that have benefited from EDI. The next section details the implications of these differences in an X12 implementation. The history section is very important to the understanding of why certain decisions were made and the implications these decisions have upon any EDI implementation.
The TECC initiative covers the process from the initial deal through the invoice (i.e. deals, deal changes and invoices). It does not address the pre-buy or post-buy processes. While discussions have taken place about potentially using EDI for these transactions in the future, it is not addressed in the version 3.0 TECC specification, nor is it expected to be added in the near future.
This section describes how EDI is used to support the national cable television advertising process. It assumes a familiarity with both EDI and the business processes in cable television advertising as described in the previous sections. Those users who have already implemented previous versions of the TECC specification should at least skim this section once. Click here to skip over this section.
Without EDI, the cost to administer a unit (i.e. data entry, stewardship and reconciliation) is relatively fixed; it costs about the same to administer a $1000 unit as it does to administer a unit costing $100,000. However, since agency revenue is typically a percentage of actual media expenditures, the agency’s per unit revenue decreases as unit costs decrease. Variable revenues and fixed costs mean that profit margins are lower for lower cost units. Individual units on cable were traditionally priced lower than broadcast network units because they attracted a smaller audience for a given unit. To continue cable network’s growth and encourage agencies to buy cable, the industry recognized the importance of reducing the cost of administering units and restoring agency profit margins.
Additionally, the growth of cable has meant a larger number of trading partners becoming involved in cable television. Before cable, there were only 3 national television networks and most of their inventory was purchased by only a handful of large advertising agencies. System customizations for specific trading partners could be maintained with relatively low costs. However, new techniques are required to support the larger inventories and greater number of trading partners created by the growth of national cable. There are now over 60 advertising supported national cable television networks and an additional 40 advertising supported regional networks that are members of the CAB. The greater penetration of cable television, larger inventories, lower per unit costs and ability to target audiences, has led many more national advertisers and agencies to buy cable advertising. The number of networks, agencies and advertisers continues to grow each year.
EDI is ideally suited to reducing unit administration costs and keeping costs manageable as more trading partners are added. EDI has been successfully adopted in other industries to address similar needs. The following section provides more specific details of the cost benefits of EDI for the cable television industry.
o Reduced labor costs - The most obvious and easily measured benefit from EDI in cable is in direct labor savings from the following sources:
§ Direct Data Entry - Without EDI, each unit must be hand-entered into the agency’s MIS system at both the deal and invoicing stages. This can be completely eliminated by EDI.
§ Document Tracking - While the costs to receive a fax seem minimal, studies have shown that they add up to substantial expenses, especially when factors such as the time spent waiting for a fax to print and paper jams are considered. In the modern office, these functions may be performed by expensive senior personnel as well as by clerical staff.
§ Error Correction – Data-entry mistakes can take significant time to detect and correct, and often require the involvement of management personnel. The illegibility of some fax transmissions is a major cause of data entry errors.
o Improved Customer Service - In today’s competitive marketplace, finding and keeping good staff is a difficult and expensive challenge. A significant benefit can be gained by freeing up existing staff from repetitive tasks and providing them with more time to focus on improved client service. A secondary benefit is increased motivation gained from more challenging work, leading to better retention of advertising staff. EDI also provides agencies with more accurate and timely information about a media campaign which they can in turn, share with their client. At least one advertising agency has justified their EDI investment on this basis alone.
o Greater Accuracy - Errors in communication can be extremely costly. The network does not get paid for an aired unit that is inconsistent with the deal. The agency also receives no additional revenue from such units and more importantly, risks compromising the media plan. A failed or compromised media plan will certainly reflect negatively on the agency-network relationship. Many advertisers rely on the media plan for promotional and staffing purposes, so incorrect information can negatively affect an advertiser’s profitability. Inaccurate data may also skew the post‑buy analysis reports and cause lost revenues through unnecessary ADUs. While technical difficulties can cause some of these errors, many others are caused by flawed communications (i.e. a misplaced fax, data entry errors or communication delays). One estimate puts the industry losses between 1 and 2% of its total inventory due to such errors. These errors can also reduce the level of confidence between trading partners and may require management time to maintain and restore business relationships.
o Improved Cash Flow - The network and the agency do not typically get paid until the invoice is entered into the agency’s system and fully reconciled. Errors due to data entry or miscommunication can prevent an invoice from being reconciled. Tracking and correcting such errors can cause invoice payment to be delayed by several months. Industry participants have reported that EDI for invoicing alone has accelerated payments by 10 to 20 days.
o More Timely Communication – Faster communication means that misunderstandings can be corrected quicker and therefore have a better chance of being corrected before a unit is aired.
o Standardization - When a new network comes on-line, or a new agency expands into national cable, experienced trading partners typically take on the responsibility of “training” the new entrants in industry practices, including specific trading partner requirements. By having a set standard of industry procedures, the amount of effort required to train the new entrant can be reduced.
TECC was formed with the mission to create the EDI standards necessary to make the buying and selling of national cable television easier. Cable networks, advertising agencies and industry vendors, have all worked together as TECC members since its inception. TECC is composed of multiple committees. The Executive Steering Committee (ESC), with representatives from cable television networks and advertising agencies, sets the general direction of the committee, makes policy decisions and is the ultimate arbiter of disputes. The Design Committee, with representatives from networks, agencies and vendors, is responsible for the actual creation and maintenance of the standard. Recently, the Implementation Committee was formed to help educate those users new to TECC and to share best practices among existing trading partners. The Cabletelevision Advertising Bureau (CAB) helps coordinate all of the TECC activities. Scott Lowe is the contact person for all EDI activities at the CAB and can be reached by telephone at 212-508-1223 or by e-mail at ScottL@cabletvadbureau.com.
X12 was chosen by TECC, primarily for the infrastructure it provides and the number of third party vendors who support it. It was, and remains, extremely important for the industry to adopt a completely open standard that is vendor-neutral.
Similar to the role of other EDI industry trade associations, TECC’s role is to interpret and narrow the X12 standard and to develop guidelines specifically for use by the cable television industry. However, TECC can only provide the rules. It can not prevent trading partners from making deviations from these rules or from interpreting rules differently.
Version 1.0 of the TECC specification (which is still used extensively by the cable industry) stretched the way X12 transactions had commonly been used. This led to some ambiguities in the standard and required customizations to some third-party EDI software. These factors, together with the cable industry being new to EDI, have contributed to the significant number of trading partner variations of the TECC standard.
A significant goal of the Version 3.0 standard is to eliminate or at least to drastically reduce trading partner-specific deviations. This will further reduce implementation costs and pave the way toward support of additional EDI transactions.
Prior to TECC, several other groups had been formed to discuss EDI in the industry. It was the potential for multiple “competing” standards that was the impetus for consolidating these groups into a single body. A vendor-specific file format for transmitting basic contracts via diskette was becoming a de-facto standard. The AAAA’s (American Association of Advertising Agencies) had adopted a “flat-file” format for electronic invoices. While this standard was originally designed for local television and radio, it was used for national television invoices as well.
The TECC Design Committee was given the charter of developing the EDI standards for the electronic transmission of information between networks and agencies. One of the challenges to designing this specification was to create an overall industry “business model” which was not biased toward any specific trading partner or MIS vendor system implementation. A second challenge was to reflect existing non-EDI business processes and minimize EDI’s impact on the way networks and agencies conduct business. This was essential if the standard was to include all trading partners.
Using the X12 standard presented some early challenges. The industry was new to X12 and was not yet represented in the X12 committees that set the standards. As discussed in an earlier section, the industry’s purchasing process is quite complex and does not easily fit into transactions designed for other mainstream purchasing activities. X12 segments were used in creative ways to allow TECC to support industry specific data such as billboards and mirrored units. To support the guarantee and demographic information, which had no parallel in other industries using X12, version 1.0 of the TECC standard used multiple transaction sets to represent a single deal. A single deal was sent as an X12 843 “Response to Request for Quotation” transaction set and multiple 850 “Purchase Order” transaction sets. A second example concerned the handling of the standard broadcast clock. The industry defines the broadcast clock as beginning at 6:00 a.m. and ending at 5:59 a.m. of the next calendar day (A unit shown in the deal as 3:00 a.m. on October 2nd, will actually air at 3:00 a.m. on calendar day October 3rd). To avoid confusion, the industry had become accustomed to using a “30-hour clock” (3:00 a.m. was represented as 27:00). However, the X12 standard would only support times from 0:00 to 23:59.
While the business rules for cable are similar to those for broadcast networks, where each unit is treated individually, most internal MIS implementations were influenced by spot television, where similar units are aggregated together. To distinguish one unit from another, TECC adopted the concept of “serialization.” Simply stated, each unit in a deal is given a unique serial number, which it retains for the life of the deal.
Serialization is essential to the handling of deal changes because of the need to identify each unique unit being changed. Even transmitting all of the identifying information about a unit (i.e. program, date, time) is not sufficient to identify a unique unit because more than one unit can have the same identifying information.
Some significant programming changes are required for most cable network and agency MIS systems to fully support serialization. Although the full benefit of EDI would not be realized until serialization was in place, great benefits could be realized by implementing the invoice and initial deal transactions, which could be sent without serialization. These are called the bookend transactions because they define the start and end of the process. (Note: this is not to be confused with the term “bookend” which is used to mean units airing at the beginning and end of a commercial break).
The first TECC specification, version 1.0, was published in the fall of 1994. This release defined both X12 and flat-file standards for communicating initial deals and invoices. The flat-file standard was included primarily to make mapping easier although some trading partners used it for communications via diskette or modem. The release also included TECC’s progress to date, on defining deal change transactions. As is typical of any new EDI initiative, the initial implementations saw numerous trading partner-specific variations of the standard. This was particularly true of some of the industry’s unique requirements (e.g. some third-party EDI software was unable to handle TECC’s usage of multiple transaction sets for a deal). Other variations were due to software limitations, ambiguities in the initial specification and the industry’s modest experience with X12. The 30-hour clock and other similar “extensions” to the X12 standard led to most trading partners turning off the X12 validation, a significant value-added component of X12. Despite these minor problems, the initiative was very successful, especially for invoices, which provided the greatest initial benefit.
The Design Committee continued its work and published version 1.1 of the TECC specification in the winter of 1995. In addition to documenting the committee’s progress on change transactions, the new specification attempted to clean up and resolve many of the problems and issues found with the version 1.0 standard. However, because most trading partners had already found workarounds to these issues, version 1.1 was not widely used and version 1.0 remained the de-facto standard.
Version 2.0 was published in March 1997, and was the first release that defined all of the change transactions. By this time, the cable industry had gained more X12 expertise and had become active within the ASC X12 committee. As a result, some significant changes were made to the X12 specification for purchase orders, which reduced the complexity of mapping initial deals to X12. The entire deal could now be transmitted in a single transaction set (i.e. it required only one 850 transaction set instead of the 843 and multiple 850 sets). The transmission of demographic information was also much clearer due to the inclusion of a new X12 segment designed specifically for that task.
However, the version 2.0 standard fully supported deal changes and required serialization. While some agencies and networks were now capable of handling serialized units, many others were not. Trading partners were reluctant to invest in the new standard because they would still need to support the old standard for trading partners who were unable to support serialization. In addition, Y2K issues in other areas were taking precedence over EDI enhancements for many trading partners.
At the same time, new trading partners were beginning to implement EDI and were often confused as to which version was the current standard. Existing trading partners had to spend much more time than expected helping these new trading partners get up to speed. This reduced the amount of time they had available to work on serialization. Because version 1.0 remained the de-facto standard, trading partner variations continued to proliferate, further delaying serialization.
To address the issues above, version 3.0 (also referred to as “Scaleable EDI”), was created with the goal of providing a single standard for all trading partners, regardless of their support for serialization. This standard can be used without serialization for new deals and invoices, allowing all trading partners to take advantage of the cable industry sponsored changes to the X12 specification. An entire deal can be transmitted in a single transaction set using a new segment for transmitting demographic information. In addition, the specification clarifies the ambiguities that caused so many trading partner variations to the 1.0 standard.
New trading partners can now be assured of a single, fully documented specification that they can implement without the extensive time commitment from existing trading partners for prototyping and training. All trading partners should benefit from this unified specification, which will minimize trading partner variations. This specification is also fully Y2K compliant.
The development of this web-based TECC document versus a print-based version is also significant. It is inevitable in any undertaking of this magnitude, that there will be differing interpretations and potentially even some minor errors in the specification (This is especially true of the largely untested section on deal changes). By having this document available on-line, problems can quickly be identified and documented, and new trading partners can benefit from the practical experience of the existing trading partners.
The terms “deal” and “contract” have been a cause of some confusion during the implementation of EDI. Local television uses the term “contract” to define an advertising agreement between a station and agency. In addition, most cable MIS systems are extensions of systems originally defined by spot television, with the result that the term contract is often used instead of deal. Due to local television being purchased typically a quarter at a time, it is common for MIS systems to break a deal into multiple “contracts”, each representing a quarter’s worth of information for a single network. The original version 1.0 specification also broke deals up into contracts. Unfortunately, the definition of contract (and assignment of units to a contract) is trading partner specific, so it is very difficult to standardize.
To clarify these definitions, TECC introduced the term “Master Order” in version 2.0 for use instead of “deal”. This term was based on the traditional purchasing model where a deal is roughly equivalent to an “order”. However, Master Order never gained widespread use and TECC has decided to return to using the term “deal”.
One advantage of EDI is that it allows trading partners to maintain their own internal representation of the data. Each trading partner can design and maintain their database as best fits the needs of their organization. However, this also means that the same data exists in two separate databases, one at the network and one at the agency. The two databases must be kept “synchronized” (or “in-synch”) to ensure that they both reflect the same key deal information. There will still be periods when the two databases reflect different information (i.e. the time between a change being made on the network system and the time this information is approved and loaded into the agency system). The goal is to provide a process to control periods when the databases are out-of-synch and to provide processes for getting them back in-synch.
The Executive Steering Committee (ESC) oversees all TECC committees and is responsible for setting the overall direction and goals of the TECC committees. The committee consists of senior executives from cable networks and advertising agencies. It meets two to three times a year to set direction and to address any difficulties related to electronic commerce.
Click here to view the current ESC membership list
The EDI Task Force works in conjunction with the Design Committee and the ESC, to identify and provide recommendations for resolving problems associated with electronic trading. The EDI Task Force is comprised of representatives from cable networks and advertising agencies.
Click here to view the current EDI Task Force membership list
The Design Committee's mission is to provide technical and operational support to the cable industry's electronic commerce efforts and to develop implementation guidelines and strategies in support of business solutions as defined by the Executive Steering Committee. The committee consists of representatives from cable networks, advertising agencies, and vendors.
The committee's charter guides it to:
· Support ongoing efforts of the ESC by designing solutions and developing standards based on the electronic commerce requirements of the cable industry.
· Maintain and disseminate current and new versions of the TECC specifications.
· Obtain industry and ASC X12 approval of specifications for cable EDI.
· Resolve issues arising from the TECC Implementation Committee and EDI Task Force, and incorporate resolutions into the TECC standards.
Click here to view the current Design Committee membership list
The Implementation Committee's mission is to provide a forum in which all issues, concerns and ideas can be freely presented and discussed by those users interested in conducting electronic commerce in the national cable industry. Activities include education, advice, support, pilot experience feedback and a technology review forum. The Implementation Committee consists of representatives from cable networks, advertising agencies, vendors and service bureaus, and anyone else interested in implementing EDI in the national cable industry.
Click here to view the current Implementation Committee membership list
The most recent survey found that there are more than 45 cable networks and 25 advertising agencies, currently trading deals or invoices via the TECC X12 standard. 80% of these are trading both invoices and contracts while the other 20% are using X12 for invoices only. The number of trading partners using X12 is expected to grow by 10 to 15% per year.
Some of the networks to first implement EDI and actively add agency trading partners, are reporting that well over 50% of their deals and invoices are being sent via the TECC standard. Networks newer to EDI as well as those that have not actively sought out agency trading partners, are reporting that 5% to 30% of their deals and invoices are being sent via EDI.
Agencies that are EDI-capable have been doing an even higher percentage of their volume via EDI. Most report that between 70% and 95% of their volume is via EDI. Some agencies require that networks be EDI-capable (or at least have an EDI implementation plan) as a prerequisite to doing business.
Agencies and networks that wish to trade should register their contact information with the CAB. This information will allow trading partners to contact the appropriate person in the organization when problems and issues arise, and when new trading partners wish to begin prototyping.
Click here to view Agency Participants
Click here to view Network Participants
Click here to register or change information
EDI has been used extensively for the “bookend” transactions: initial deals and invoices. While this provides significant advantages, the full benefit will only be achieved when EDI is used for deal changes. The first and most important step for trading partners will be to convert to the version 3.0 standard. Unfortunately, trading partners can not abandon support for the older standards until everyone has moved to the new standard. More importantly, new entrants to EDI will only support the new standard. Energy expended on support for older standards serves only to dilute the effort to implement deal changes.
A key component will be a commitment to eliminate trading partner-specific variations in the implementation of the version 3.0 specification. It is inevitable that some situations such as a system limitation or unforeseen occurrence will arise in which a change to the specification is requested. At this point, it will be important to resist the temptation of an immediate workaround but rather to escalate the issue to the appropriate TECC committee so that an industry-wide solution can be agreed to and, most importantly, so that it can be documented. The impact of trading partner variations will be greatly magnified during the implementation of deal changes.
While serialization is not required to implement the version 3.0 specification, it is needed to take advantage of deal change transactions. It is important for the remaining trading partners to make the required changes to their internal MIS systems for handling serialized units.
Once the conversion to the version 3.0 specification is completed, trading partners can begin prototyping for deal change transactions. The ability to produce a snapshot of the current deal with serial numbers, at any time, will be very important for implementing and testing deal changes. Both agencies and networks should have this capability.
This section also includes is a planning guide to help new users get started with EDI. This section may also be useful to those who are already trading via EDI and who are now re-evaluating their EDI strategy for TECC version 3.0.
The business processes for national cable television advertising have been continuously evolving since the inception of cable television. Few were formally documented, most of these conventions were passed from trading partner to trading partner. Anyone new to the industry would often learn by trial and error.
In the same way, the rules and processes for X12 have evolved as well. While X12 is highly documented, there are still some processes that are commonly assumed and which have not always made it into implementation guides.
A major goal of this guide is to identify and document as many of these rules as possible. The intent is to make EDI easier to implement for new trading partners and help to minimize “unwritten rules.”
The technical rules regarding the EDI transmission of a document are detailed in Section 4 of this document. Rules outside of the scope of the formal specification and generic in nature (i.e. not specific to EDI) and rules that need additional emphasis or clarification are also defined here. In the past, these rules were often referred to as the Rules of the Road. In version 3.0, they are now called the Business Process Standards. While Section 4 is written primarily for technical personnel, the rules are intended primarily for those responsible for the business implications of EDI implementation.
The TECC Rules of the Road were created to set the framework for future EDI transactions and to help solve some of the ambiguities discovered in early trading. They were also designed to record existing standard business processes that had never been formally documented. However, the Rules of the Road included some rules that many trading partners could not implement due to technological limitations and as a result, they were treated as goals rather than rules. It became unclear which rules were requirements and which were merely guidelines. To address this problem, TECC recently revised and updated these rules. It now clearly identifies the rules that are mandatory for all trading partners, the rules that are goals (i.e. best practices), and the rules which are highly desirable but may not yet be achievable due to technology limitations.
These rules represent industry standards or rules constituting current cable buying and selling business practices. As such, they apply to all transactions, not just to transactions via EDI.
· Rotation is defined as equitable distribution both horizontally and vertically within agreed time parameters and program (s).
· Changes to rotation/ROS day, date and timeparameters, but not specific spot airings within these rotations,require deal/contract change.
· The salesperson will be responsible for monitoring adherence to the agreed upon schedule.
· Run of schedule (ROS) must conform to day, date and time parameters without regard to equitable distribution.
· For networks not utilizing a standardized broadcast clock, units will require conversion of time and date to correspond to the AC Nielsen clock, defined as 6:00 – 29:59 Eastern time.
· Sell patterns cannot cross broadcast days.
· A broadcast month will end on the final Sunday of a calendar month.
· A broadcast quarter will end on the final Sunday of a calendar quarter (final Sunday of March, June, September and December).
· The broadcast calendar as defined applies to proposals, contracts and stewardship.
· Inventory will be removed from sale by the network upon agency hold notification.
· Changes to holds or orders need to be approved and confirmed by both sides.
· Conflict resolution must occur prior to airing.
· Network and agency must be in-synch prior to brand allocation. Prior to air, as long as total commercial time remains constant, the agency can split/combine units during brand allocation without violating the in-synch rule. The number of splits/combines, if any, is to be negotiated at time of deal. Exceptions and conflicts can be dealt with on a case-by-case basis. NOTE: This implies that the cable network will be required to fully accept the electronic transmission of the brand allocation "as is" every time, including splits/combines per agreement with deal.
· Deal changes via brand allocations cannot be guaranteed.
· Requests for brand allocation changes cannot be guaranteed.
· Agency and network schedules must be in-synch at point of issue.
· Traffic instructions are not a means to make order changes.
· Conflict notification and resolution are required prior to air.
· The methodology for audience analysis will be agreed upon by buyer and seller at time of negotiation.
· Demographics must be specified by the agency in time for thetransmission of the deal.
· Any changes outside of original agreement parameters require buyer notification and approval, specifically number of units by time frame, rotation parameters, programming elements and unit length.
· Changes, via hard copy or electronic transmission, are communicated by unit and do not require dealrevision unless these changes are to elements that define the deal such as guaranteed CPMs, total number of units and total expenditures.
Best practices are goals that can be complied with today from a technological standpoint but that are not always practical or possible in the real world of cable buying and selling. Adherence to these goals improves the cable selling and buying process regardless of technical issues associated with EDI. These goals should be followed whenever possible.
· Network will notify agency of any errors by next business day after air.
· Certified post-air schedule notification will be derived from reconciled log.
· Agency may request the current status of a rotation at any time. Status requests are a snapshot of rotation at a given time and cannot be used by agencies to request changes or to update agency databases prior to actual airings.
· Network will confirm clearance of inventory to agency within two business days.
· Agency will respond with hold-to order confirmation within agreed upon length of time (i.e., order letter confirmation).
· Audience information for guaranteed demographics will tie back to guaranteed CPM in deal header on initial transmission of the deal and all contracts. Deals should not be rejected due to differences in rounding.
· In order for agencies to incorporate the most up-to-date version of a deal capturing all changes made thus far, quarterly information will be electronically transmitted to the agencies one (1) month prior to the quarter start date. Initial electronic transmission of the whole deal is optional based upon client or agency requirements. Quarterly information will replace the initial deal information.
· The receiver is responsible for the translation of data into their own system (s).
· All brand allocations will be delivered to the network (s) a minimum of ten (10) business days prior to the first affected air date. This implies that the agency, not the network, is providing the brand allocation.
· Networks can perform brand allocations based upon agency specifications, however, the Best Practice is for the agencies to perform the allocations.
· Initial instructions for the networks to perform the brand allocations will be delivered to the network (s) 15 business days prior to the quarter or first air date.
· Network (s) will provide initial confirmation of brand allocation and conflict information seven (7) days prior to airing.
· Once v3.0 change transactions and brand allocations are implemented, networks will send only unallocated versions of initial contracts and deals. Agencies will allocate these and send brand allocations (via ANSI 860 documents) to the networks.
· At a minimum, network will receive approved copy instructions five business days prior to air.
· Material should arrive prior to receipt of traffic instructions. It is the joint responsibility of the brand and buying agencies to ensure material arrives prior to receipt of traffic instructions when the two organizations are different.
· Demographics should be specified by the agency at the time of submission of the order.
· Invoices will be received by agency within five business days after end of network’s billing month.
· Agency will complete invoice matching in one to two business days.
· Identification and notification to network of discrepancies will be performed by the agency within five business days.
· The Invoice Clearance goal is resolution of discrepancies within 30 days.
These are goals that can not be adhered to today for technological reasons but that should be followed in the future to improve and expand the EDI process. These are mandatory for communicating deal changes via EDI.
· Units require serialization.
· Each unit within a deal must be associated with a unique identifier.
· Verbal and last minute changes must be followed up by a corresponding electronic transmission.
· There is no implied information in the unit serial number.
· Agency and network must stay in-synch through the life of the deal.
· When an agency and network determine that they are not in-synch, they should stop the electronic trading process and verbally resolve the problem. Electronic trading should recommence once they have mutually agreed to changes necessary to be in-synch.
· Agency must review deals and contracts and accept or reject them within a specified period of time.
· All change requests made for units in a particular contract must be reviewed as a set and approved in totality prior to implementing the revision. Disagreements require verbal resolution and resubmission of agreed upon changes in totality.
· Electronic agency confirmation of receipt and agreement to (or rejection of) deals, contracts and changes is required.
· Electronic changes must be content accepted within 24 hours of receipt, provided the changes are received prior to an agreed upon cut-off time.
· The cable television industry agrees to a cut-off time of 2:00 PM Eastern Time for change requests expected to be responded to within 24 hours.
· Agency will communicate with network electronically using data elements and codes at the serialized level – agency must assign copy to individual units.
The following “rules” have driven the design of the TECC specification and are useful in understanding the responsibilities and expectations of each trading partner.
· Vendor Neutrality – In designing the specification, the TECC Design Committee members were very cognizant of making this an open specification that does not favor one trading partner or MIS vendor over another. Where system limitations have created de-facto industry standards (i.e. program names limited to 25 characters), these have been considered in setting the standard.
· Standard Code Lists – In cases where de-facto standard codes exist, the TECC specification will identify the allowable values for a given field (e.g. demographic codes and network call letters are standardized according to the A.C. Nielsen standard). However, in cases where trading partners have traditionally maintained their own internal code lists (e.g. brand codes, advertiser names), the TECC specification allows continued use of them. It is the responsibility of the recipient to maintain the translation tables required for converting them to the appropriate internal codes.
· Structure – This version of the TECC specification was designed with the concept that each unit is an independent stand-alone entity. (Prior versions of the specification grouped similar units together in a “line”). This fits well with the structure of the X12 transaction sets for deals and invoices. The X12 structure may or may not have a structure similar to a trading partner’s internal database. Each trading partner must take responsibility for mapping from/to the X12 structure and to/from their internal database. In past versions of the TECC specification, some recipients have asked senders to modify the X12 transaction to make the recipient’s mapping easier. This is bad practice because it creates multiple flavors of the TECC specification and must to be avoided.
Conformance to the TECC rules and standards is voluntary. TECC has no authority to enforce conformance; this is left to the discretion of the trading partners. To achieve the goal of a single standard benefiting everyone, trading partners must maintain some self-discipline and avoid the temptation to deviate from the standard. In the past, variations occurred primarily due to different interpretations of the specification and to appease trading partner requests to make mapping easier.
The following are some vendor-specific issues that have affected EDI in past implementations of the TECC specification:
“Package Headers” – The initial TECC transaction is the transmission of the deal from network to agency. However, some agencies have traditionally preceded this transmission by sending a “package header” to the network. This document is typically faxed or mailed and there is no equivalent EDI transaction. The package header is used by the agency to specify the agency’s internal codes. The network is then expected to use these codes in all transmissions concerning the deal. There are typically multiple package headers for a given deal. In addition, there is often a separate package header for each network and each quarter’s worth of information but this can vary depending on how the agency sets up the deal in their internal system. While it would be more consistent with the TECC design philosophy for the agencies to maintain this information, it is possible that networks will be asked to continue to support this procedure. It is expected that as agencies update their EDI systems, the communication of package header information will no longer be necessary.
Invoicing by Brand – The TECC specification allows for an invoice to include units from multiple brands in a single invoice. However, in the past, some agencies have required that a separate invoice be generated for each brand.
This section describes the components of a successful EDI implementation. Those users who are migrating from a previous version of the TECC specification may want to skip this section.
Click here to skip to Migrating From Previous Versions of the TECC specification.
Users new to EDI, need to weigh the “make versus buy” decisions that are typical when implementing a new project. There are many X12 vendors who sell tools and services that are designed to handle X12 transactions and which can then be customized for a particular user’s needs. In addition, there are vendors who provide solutions tailored specifically for the cable television industry. Often these vendors work closely with or are the same vendors that develop internal MIS systems. There are also vendors who offer outsourcing of the entire EDI operation. EDI consultants are also available to help evaluate and implement a chosen solution. An existing MIS system vendor may offer an EDI solution or recommend vendors that interface with their system. If a service bureau is being used as a MIS system, it is likely that they will provide an EDI solution as well.
Each solution has its own strengths and weaknesses, and any choice depends upon a company’s strategy, internal resources and technical expertise. As a general rule, in‑house development costs more, but can provide a greater amount of control, and develops internal expertise that can often benefit other projects. Larger companies that expect to use EDI for many aspects of their business tend to have in-house capabilities. Smaller companies and those that expect to used EDI for cable television advertising only, tend to outsource as much as possible.
As is the case of most technology decisions, the best first step is to talk with other organizations with similar backgrounds, to get their recommendations. It is important to understand their strategy toward EDI, to ensure compatibility of objectives. Often the best choice for one organization, is the wrong choice for another. Finally, always keep in mind that the way EDI is used by the national cable television industry differs significantly from traditional EDI industries. Cable organizations should be cautious when making comparisons with other industries.
An EDI system consists of the following components:
· Interface to your internal MIS system
· Translation
· Validation
· Communications
· Value Added Network (VAN)
· Audit / Tracking
Implementing EDI is not a one-step process. The translator must be able to interface with the internal MIS system to communicate data between trading partners. The translator must also be programmed to correctly map all fields according to the industry standard and must be configured to use the industry-defined communication standards. Validation is one key component of the process that is often overlooked; it ensures that the data being transmitted is technically and semantically correct. Much of the value of EDI is lost if humans are relied upon for validation instead of using the computer’s natural talents. Lastly, a company must put into place, procedures that can efficiently and effectively solve any problems arising from the transmission. It is important to remember that EDI is still in its infancy in the cable television industry and there will likely be additional minor problems to be solved.
While the above list details 6 distinct component processes, some vendors offer several of them. Many VANs also offer translators, and most translators have some built-in validation. Some vendors will offer the entire service but still allow you to choose among several supported VANs. Companies that use service bureaus for their MIS system, will have most of these choices made for them by the service bureau. They can still benefit from understanding the various EDI components.
A key area of any EDI implementation is the interface between the internal MIS system and the EDI component. Most EDI systems do not interface directly with the MIS system, but rather via an intermediate “flat-file” which is understandable by both systems. This modular approach makes systems much easier to maintain and allows different hardware platforms to be used for each system.
Networks are responsible for creating the deal and invoice, and transmitting them to the advertising agency. They need to generate a flat-file version of the deal and invoice in a format that can easily used by the translation software. Flat-files are simply a convenient mechanism for interfacing between the database and the translator. Their format can vary from implementation to implementation. While some early implementations allowed direct communication of flat-files, this is not allowed under the TECC version 3.0 standard. All communications must be via X12. Most traffic system vendors have the capability to create a flat-file description of an invoice according to the standard AAAA’s flat-file invoice format. This file type is commonly used as the input to the translator. The TECC version 1.0 standard also defined a flat-file format for deals that many trading partners have used as the basis for their own flat-files. However, version 3.0 has a somewhat different structure that will require some flat-file modifications. Some networks have written their own customized interfaces to their MIS database to create the necessary flat files. It makes no difference which format is used so long as it contains all the appropriate information. One key issue is determining who in the organization will be responsible for creating these files and updating the translation component as to where to send the files. It is also important to have a feedback mechanism so that a user can track the progress of a document: when it was sent, and when it was received and accepted.
Agencies receive the X12 deals and invoices from the network and typically translate them into flat-files that are used to populate their internal databases. This is much more complicated than the network scenario because the data is actually modifying an internal database. It is vital that the files be pre-validated to avoid database corruption. One key issue is deciding whether a user should preview the information before or after it is entered into the database. While previewing it first provides the maximum control, this often requires some significant MIS enhancements and adds complexity to the overall process. A more common approach is to enter the data automatically into the database with a “hold status” and have a buyer review it at a later time.
For deals and invoices, the majority of the traffic is one way: from network to agency. The only communications from agency to network are the acknowledgments that the data has been received and accepted (or rejected). However, once deal changes are implemented, there will be a significant amount of agency-originated traffic as well.
Most MIS vendors already have the capability to generate (or load) flat-files, compatible with the TECC standard. Some vendors will charge extra for this component, others include it as part of their package cost. If a user needs to write their own interface or modify the one provided by the vendor, then the cost will depend on the ease of database access and the level of expertise available to implement the modifications.
The translator converts the flat-file to the X12 format file. It essentially creates a computer program to read a file, process it and write a second file. While a generalized programming language can be used, X12 translator vendors have created their own programming languages and visual programming environments to make this task easier. Most of these environments allow users to graphically identify fields in the input file and “map” them to the appropriate X12 transaction set, segment and data element. As a result, translation is often called mapping.
There are two major components in translation: the environment used to create, test, and debug the code: and the actual execution of the code. Most translators are interpreted and require that the code be executed within the framework of the translator.
While most vendors have created an easy-to-use interface for mapping to X12, users should pay special attention to the macro language that handles exceptions, and the debugging environment. With total control of the MIS system interface and therefore the structure of the flat-file, mapping would be a straightforward process with little need for exception handling. However, in most cases the output file is based on an internal database structure or an industry standard format (e.g. the AAAA’s invoice) and is not necessarily designed with the goal of making mapping as easy as possible. In such cases, a user will need to employ the translator’s macro language (a custom programming language that is tailored to the specific application, in this case the translator itself). While some macro languages are designed so that a non-programmer can use them, they are still programming languages and require some programming skills.
The person undertaking the mapping is usually the best placed to evaluate the translator. Ideally they will have some programming experience to assess the robustness of the macro language and the ease of use of the debugger. They should also be familiar with X12, the flat-files being used, and the TECC specification, to judge whether the macro language can handle the particular set of needs. Special attention should be paid to the debugging environment, which can greatly affect the amount of time and effort needed to create the mapping process. In general, mapping languages do not have the same robust debugging capabilities as general purpose programming languages. Before purchasing a translator, it is important to speak with other experienced users involved in similar transactions, and to evaluate the vendor’s customer support policies, customer support expertise, and cost and availability of training.
The TECC version 3.0 specification allows senders to use their own internal values for fields such as the program name. Most recipients will translate these values into an internal code (e.g. program code) before loading it into their MIS system. A translator should have this capability as well as a user-friendly interface for maintenance of these tables.
In factoring costs, both the cost of the translator and the cost of labor for the mapping need to be considered. While it is easy to calculate the former, the latter is more difficult. Vendors selling the translation software can significantly underestimate the effort needed to perform (and maintain) the mapping. Translators can cost from $1,000 to tens of thousands of dollars. The cost to implement the mapping will be many times that amount. A significant factor in the cost of a translator is the platform on which it will run on (i.e. translators running on PCs are cheaper than those that run on minicomputers or mainframes). In the past, PCs did not have the power to run high volume EDI operations but now they are commonly used. Key issues in choosing a platform are security and multi-user capabilities. If a single user is running the EDI system, then a personal computer is likely to be adequate. However, if the EDI system is used for multiple purposes or has a large number of users interfacing with it, then a workstation or minicomputer may be more appropriate. In either case, the machine running EDI needs to be professionally managed (i.e. regular backups, redundancy, and multiple communications paths, etc.).
Maintenance and support costs must also be factored in. Some translators have an additional charge for each version of the X12 specification supported while others do not offer support for minor releases of the X12 specification. Version 3.0 is based on the major release 4010 but TECC has used minor releases for previous versions.
Another important factor is the “robustness” of the EDI implementation. A basic mapping with little error-handling capability will be significantly cheaper to implement initially than a system with fail-safe protections, robust handling of errors and an easy-to-use user interface. However, the more robust system will usually be cheaper in the long run. (Please read the next section on validation for a more thorough discussion of error handling.)
The choice of a translator should be made in concert with the selection of a VAN and communication software. Many VANs also sell translation tools, some of which are more tightly integrated than others. Some companies significantly discount their translators to get customers for their VAN, so users should be aware of this when comparing prices (See the section on VANs for more information).
For users outsourcing EDI or using a service bureau, the vendor will have chosen a translator and in many cases, will not itemize translation costs. However, the user will still most likely be responsible for communications costs.
Validation is often bundled with translation since most commercial translators offer integrated X12 validation as part of the translator functionality. It is an extremely important function and one that is an essential part of the TECC 3.0 specification. While the rules of X12 and TECC are key, how the rules are enforced and what happens when a violation occurs are of special importance. When choosing a translator, a user should determine how validation errors are reported. Some translators give specific information about the error, others may give cryptic reports which require additional investigation and significant X12 expertise to determine the cause of the validation error.
There are 5 levels of validation for a transaction:
· Communications Syntax – Ensures that a transaction set is properly enveloped and addressed. Of key importance here is validation of the control number, which helps identify missing or duplicated transactions. Most translators have the capability to generate and maintain control numbers (See the Control Structure section of the TECC V3.0 Reference, section 4 of this document, for detailed implementation information). Some VANs also can be configured to do the appropriate validation
· X12 Transaction Set Syntax – Ensures that a transaction follows all rules imposed by the X12 standard (i.e. all required fields are present and field values have the proper type and size). Most translators have the capability to automatically validate for X12 syntax. In the past, TECC was not able to use the X12 transaction set syntax feature because the broadcast clock violated X12 rules and most transactions would not pass X12 validation. However, the version 3.0 TECC specification allows full X12 validation.
· TECC Syntax – Ensures that a transaction follows the TECC-defined rules that impose additional limitations on the X12 rules (e.g. the X12 specification allows an alphanumeric serial number from 1 to 20 characters. However the TECC specification requires a 12-digit numeric serial number). While most translators have the capability to support such added validations, they are not automatic, as are the X12 validations. The addition of the TECC validations often requires some significant programming effort. In the past, many trading partners did not bother to add them. Some of the TECC rules are significantly more complicated than just checking field lengths (e.g. validating that the number of units in the deal matches the deal header).
· TECC Process Standards – These are the rules defined in the previous section. Enforcing these rules is outside the scope of many translators and therefore validation may require additional changes to a MIS system and some human intervention.
· Context Validation – There are some rules that a computer simply cannot validate. Human review is necessary to determine validity. While this is an anathema to X12 purists, it is an essential part of the EDI process in cable television where the ultimate decision on acceptance or rejection rests with a person. Only a buyer can tell whether a proposed schedule change is acceptable to the advertiser. This decision-making process is too complex to be automated. Any system must therefore have mechanisms in place to allow a user to accept or reject a document based on context issues.
The costs of validation are primarily labor costs for programming and testing. Using a vendor who has already implemented validation can be a way of lowering costs. When comparing costs, a user must ensure that the comparison is for the same level of validation. Some vendors provide only validate X12 transaction set syntax, while others may include validation of the TECC process standards as well. Some VANs can undertake X12 level validation, but they do not typically have the TECC-specific validation capability.
While technically, the sender is responsible for ensuring that a transaction set passes validation, it is good practice for the receiver to implement validation as well. This not only prevents unexpected data from being entered into the system, but also helps both trading partners find and eliminate system bugs. All transactions should be validated, not just test transactions. Some situations may arise in production that never occurred during test transactions due to the unique nature of each deal and invoice. It is also good practice to validate all fields, not just those that are commonly used.
In an EDI outsourcing or service bureau arrangement, that organization is responsible for performing validation. Nevertheless, it is useful for each cable company or agency to understand the level of validation being performed.
For those users outsourcing or using a service bureau, the choice of VANs is limited to those supported by the vendor. For other organizations, the choice of VAN is typically driven by a combination of factors, including the following:
· VAN Compatibility with Translation Software.
· Trading Partner’s VANs
· VAN Value-Added Services
· VAN Reliability
· VAN Cost
A VAN is essentially a private network that allows easy communications among its customers. While VANs do have the capability of interfacing with other VANs (via an interchange) some of the value-added information they provide is lost. Most VANs can indicate when a trading partner downloaded a transaction. However, if the trading partner uses a different VAN, only the information as to when the transaction was communicated to the other VAN is available.
In the past, TECC designated a preferred VAN with the objective that this would provide better cost efficiencies and support. However, this strategy was dropped largely because trading partners wanted to be able to choose their own VAN. Advertising agencies did not want to be forced to use a VAN that might be a competitor of a client and trading partners wanted to select translation software based on its merits, not based on a VAN. In addition, service, support, and technical sophistication can vary greatly among VANs. VAN costs have dropped significantly, so several VANs now offer rates competitive with the rates originally negotiated by TECC.
VANs typically charge startup and monthly maintenance fees (or minimums) plus charges based on volume (the number of transactions and the size of the transactions). Both the sender and receiver incur a charge. Volume discounts are common. Many VANs impose a surcharge for communications to another VAN via an interconnect. Some translation software has the capability to take advantage of a VAN’s pricing structure (i.e. by bundling or sending transactions at night), but recent price changes have made this largely unnecessary. In general, the cost of a VAN should not be a significant factor in getting started with EDI because initial volumes will be low. A more important factor is ensuring that a user can easily switch VANs at a later date (do not simply rely on the vendor’s word for it, especially if they are allied with a particular VAN).
As their name implies, VANs typically offer value-added services above general mail delivery (Many of these services incur additional costs; always check the price list). These services vary in importance depending on each individual implementation. The most important added service a VAN provides is summary reporting and status information on transactions. These reports provide an audit trail that indicates when a transaction was sent and when the recipient picked it up. They can also identify misaddressed transactions. When evaluating VANs, the format, timeliness, and ease of use of these reports are important. Most VANs can provide electronic versions of these reports, enabling customization to best fit a company’s needs. An additional important service is the ability to store transactions so that they can be retransmitted if an error occurs in the delivery process. This can save considerable time especially if the translation software does not have a retransmit transaction capability.
Support, security, and reliability of a VAN are key factors. It is important that a VAN has mechanisms in place to ensure that they are up 24 hours a day, and has processes to guarantee that transactions do not get lost. Support should be available during your standard business hours. It is also important to evaluate the sophistication of the support staff; some VANs are knowledgeable about the TECC specification, others are not. Depending on the level of expertise within a company, this may or may not be important. If communication with the VAN is via phone lines, as is typically the case, it is important to investigate the size and reliability of their modem pool. If the VAN does not have local access or toll-free numbers (caution: some charge extra for toll-free service), some additional local telephone charges will be incurred. The speed of the modem lines is also important (e.g. some VANs are unable to support modem speeds over 9600 baud). VAN communication issues are discussed in more detail in the next section.
Many VANs sell translation software in addition to communication services. Advantages of VAN-supplied translation software include tighter integration between the two areas, a single point of contact for customer support, and typically, improved testing and exception handling. The major disadvantage is that the translation software does not provide the same level of support for other VANs.
It is recommended that users have accounts with more than one VAN, and that the translator is set up to easily switch between them. This allows a second path in case a VAN has any outages or problems, and enables a company to switch between VANs (to take advantage of new rates, services, etc.).
Like validation, communications is often bundled with translation, although it is important enough to be evaluated separately. Communications connects the translator with the VAN. When creating transaction sets, most translators create an X12 file on a local disk drive. The communications software is then responsible for bundling the transaction sets into an X12 “Interchange”, assigning appropriate control numbers, and transmitting this file to the VAN according to a specific protocol. The communications software is also responsible for downloading incoming X12 files and reports.
There are no universal communications protocols for interfacing with VANs, so each VAN requires customized scripts, protocols, and/or hardware. As a result, translators often have favored VANs with which they have been predominately tested. Many translators require a specific third-party communication package (e.g. Term, Procomm).
The protocols familiar to experienced PC users may not be available on all VANs. The use of personal computers for interfacing with VANs is a relatively new phenomenon and VANs have been generally slow to react to PC-driven technology changes. Some VANs work best with bisynchronous modems not commonly found on PCs (which typically support the “Hayes-standard” asynchronous modem). Other VANs do not support modern communications protocols such as XModem, which can limit the access speeds and affect reliability. The trend among VANs is to use TCP/IP protocols for communications instead of enhancing direct modem connectivity. This is the same technology that is used to connect to the Internet. The VAN is in essence, creating a “private Internet” for its customers. While this provides excellent connectivity, it may create additional configuration and support issues if a computer is already connected to the Internet or a local TCP/IP network. In some cases, a company’s IS policy may not allow a secondary TCP/IP connection for security reasons, so traditional dial-up may still be necessary. Several VANs are developing file transmission to them via the public Internet, however, this option is still in its infancy. Also, some VANs may only offer this to their Internet Service Provider (ISP) customers.
In general, the cost of the modem and communication software is relatively minor when compared with the cost of translation. However, there are hidden support costs when choosing a technology which is not routinely supported at a company, or which limits the choices of tools. It is therefore important to involve the IS department in any software decisions to ensure that a selection is compatible with the company’s internal policies.
Staffing levels will depend on decisions made regarding an EDI implementation. Even if a service bureau is used or the EDI is outsourced, there still needs to be a contact person familiar with the operation, to handle requests from new trading partners and to solve any problems that occur. The main EDI contact person is normally known as the EDI Coordinator. If consultants are used to implement EDI, there is still a need for someone knowledgeable in EDI to manage them and ensure that the implementation fits the company’s expectations. It is also important to have a second person who understands the process and who can fill in when the primary person is unavailable (i.e. on vacation). This person can assume the primary role if the primary contact moves to another job, etc.
The EDI personnel should understand both the technical aspects of the EDI implementation and also the internal EDI business processes. One person can fill both roles if they have experience, but typically they will come from different departments within the organization.
If EDI is being implemented internally, additional technical and support staff will be required. Once the initial mapping is completed, at least one technical person and one support person for every 15 to 25 trading partners is needed (as well as backup personnel).
While the industry goal is to minimize the impact of EDI on current business processes, some impact is inevitable. The major impact is that all communications must ultimately be made in a computer readable form and be funneled through EDI software. Before EDI, documents were printed out on paper and mailed or faxed to the trading partner. In many cases, agreements were made via telephone with or without paper backup. It is expected that trading partners will continue to negotiate changes via telephone before the formal electronic communication. However, it is essential that all agreements ultimately be communicated electronically via EDI to ensure that the MIS systems have the same information that has been communicated verbally.
As a result, the EDI Coordinators become an important “middleman” in all communications. They are responsible for communicating with the buyers and sellers within an organization, ensuring that documents are transmitted correctly and on time, and most importantly, are in charge of tracking problems such as missed communications or content errors in the documents themselves. It is unreasonable for all buyers and sellers to be versed in X12, so the EDI Coordinator is responsible for “translating” the language of X12 into the language of cable media. As an example, most EDI systems track documents by their internal control number, whereas most buyers and sellers recognize a deal by the agency/advertiser or deal number. Generic EDI systems rely on an EDI Coordinator with expertise in X12 to make the translation. EDI systems written specifically for the cable TV industry will do much of the translation for the user so the EDI Coordinator needs less specific X12 expertise.
After completing the mapping and internal testing, a company will want to identify several trading partners for initial tests. It is recommended that testing be done one transaction set at a time. Ideally, this is with a trading partner with whom the company has a good relationship, does substantial business, and that is experienced in EDI and in production with other trading partners. It is very important to have good personal relations with that partner because they will be expending energy to help debug your EDI system. It is therefore good EDI etiquette to thoroughly test the system and understand the specification before beginning the prototype. Some of the most experienced trading partners are wary about being selected for initial prototyping because they have had, in some cases, to essentially train another company’s personnel in the TECC specification through repeated rounds of test transactions. While some errors are inevitable, most problems should be corrected within 3 or 4 test transactions.
As trading partners are added, it is customary (and prudent) to prototype with them before beginning live trading. Once the first prototypes are completed, the rest should proceed without errors. A first step is to know your trading partner’s EDI ID and qualifier, as well as which VAN they are using. The VAN is important because many VANs require a configuration step to allow transmissions between trading partners. It is also helpful to know which vendor the trading partners uses. Adding a new trading partner who has the same system as an existing trading partner will be smoother than with one using a different vendor/MIS system.
The TECC Implementation Committee is a good place to share experiences and to identify potential trading partners.
This section is intended for those responsible for implementing and supporting EDI and who will be interfacing with the company’s legal staff. It is important for all those involved in EDI to understand the business reasons for each transaction and common industry business practices so that legal contracts can be structured appropriately.
The deal is a legal contract between the advertising agency and the cable television network. Networks are obligated to provide the appropriate units and demographics, and agencies are obligated to pay the price stated in the deal. Terms governing these contracts are usually included as “boilerplates” on the pre-printed forms used to communicate deals and invoices. All trading partners have an interest in maintaining good long-term business relationships with each other. As the common industry practices have evolved over the years, most industry disagreements have been able to be resolved without lawyer involvement. The pre-printed legal language is seldom enforced to the letter, but rather is used as protection if a dispute should ever escalate to the courtroom. With EDI, these pre-printed paper forms are no longer used. EDI does not lend itself to the communication of legal terms; those terms should be detailed in a separate “Trading Partner Agreement”. Besides serving as a legal document, the trading partner agreement should also detail the business expectations of each party to help avoid disagreements.
It can be difficult and time-consuming to create a legally binding trading partner agreement. EDI documents are viewed by the courts as roughly equivalent to paper documents. However, there are some subtle differences and it is difficult to forecast precisely how courts will rule since the case law surrounding EDI is still evolving. It is therefore not uncommon for trading partners to conduct business without a formal trading partner agreement in place. Although this may at first seem risky, the reality is that most disputes are resolved from a business perspective through day-to-day business and not through the courts (where the nuances of the legal language will be important). A second approach, currently used by many in the cable television industry, is to continue to backup all EDI communications with paper documents and use the paper as the legal documentation. This is not a good policy since it obviously limits the benefits of EDI.
In the non-EDI environment, both paper and verbal communications are common, as well as communications that are implied via convention (e.g. agreement is assumed unless the intended recipient says they don’t agree). Because all of these communications must ultimately be entered into the computer system, they must all be communicated via EDI even if it is merely a confirmation of a verbal agreement. In practice, most communications are discussed verbally before EDI transmission. Some trading partners have been reluctant to use all of the TECC transactions written documents have more legal weight than verbal or implied commitments. This is unfortunate because it makes the process less efficient and makes the goal of eliminating paper much more difficult. A key objective of this section is to provide a description of industry-standard usage for each TECC transaction so that these descriptions can be used as the basis for more formal trading partner agreements.
DISCLAIMER: This should by no means be viewed as legal advice. The author is not a lawyer. This section is designed to merely identify some of the issues that should be considered when drafting a trading partner agreement.
All TECC transactions have an equivalent in the non-EDI world although many are communicated informally. Some of these informal communications are merely implied, so that some users may not even realize that information is being exchanged. EDI makes all of these transactions explicit. Therefore it is important that all parties agree on the meaning of these transactions in the EDI world.
The deal is a contract between the cable network and the advertising agency that is transmitted from the network to the agency via X12 using an 850 (Purchase Order) transaction set. As discussed earlier, the deal undergoes continuous change, so the deal transmission is actually a snapshot of the units in a deal at a given point in time. More accurately, it is a snapshot of what is in the network’s computer system at the time of transmission. Networks have a responsibility to act in good faith and ensure that their information is up to date and that inventory exists for units included in the deal. However, the business reality is that there are cases where the data reflected in the deal is not the most current (e.g. the programming department may announce the cancellation of a show before it makes its way through the network’s computer system). In this case, the network can still send a deal with units scheduled in the cancelled program. Ideally, the network would wait until the database is current before sending the deal but there are certain cases where it is more important to send an imperfect deal and correct it later via deal change transactions. This would be the case if the cancelled units are many months away but other unchanged units are airing soon.
Identifying these obligations in a legal document is difficult. A network should not knowingly include incorrect information in a deal, but as in the example above, there can be exceptions. As in the case of most business agreements, the process can only work if both parties act in good faith; no amount of legal language can substitute for good business practices.
In most industries, it is standard EDI practice to acknowledge receipt of an X12 message using a 997 (Functional Acknowledgment, abbreviated as FA). The FA is used only to acknowledge that the message was received and was in the proper format (e.g. all mandatory fields were there). It is not used to imply acceptance of the contents of the message (i.e. it is not used to indicate agreement by the agency with the content of the deal). The FA is the equivalent of someone signing for an overnight package delivery: the person is just acknowledging that they received the package, not that they agree with its content. This is the standard interpretation of the 997 as identified in the X12 standard. The Functional Acknowledgment is a very important component of the X12 standard and it is essential that trading partners use it to provide a proper audit trail. Unfortunately, some trading partners have been reluctant to send 997’s because they are concerned that this would be legally construed as accepting the deal. If legal departments are concerned with this issue, it should be explicitly stated in the trading partner agreement.
In the non-EDI world, receipt was either communicated verbally via phone or it was implied if no complaint was received.
The TECC standard uses the X12 855 (Purchase Order Acknowledgment) transaction set to communicate acceptance of the content of the actual deal transmission. In most industries, this is the equivalent to a signature that indicates that the recipient is legally bound to uphold the details of the contract. However, this is not the appropriate definition for use in the cable television industry where deals are constantly in flux and standard industry practice allows both parties to make changes to the deal over time.
In the non-EDI world, an agency would review the overall deal, paying special attention to the guarantee and to the units that would be airing in the initial quarter. The acceptance was either implied (no complaints) or a verbal partial acceptance (e.g. “looks good except for these two units” or “everything in the first quarter looks good”), but there was never a formal signature. Due to the nature of the process, the TECC specification does not allow partial acceptance (It would be an administrative nightmare to implement partial acceptance). The 855 must either accept the deal or reject it in total. This has caused concern from some agencies that are concerned that by accepting the deal via an EDI transaction, it can be construed as a legally binding acceptance. As a result, they will either not send 855’s or they will reject the deal until every item is 100% correct. Both of these alternatives are impractical and have the potential to undermine the EDI process.
It is imperative that the 855 is not construed as a legally binding acceptance, but rather as a general agreement between the parties that the contents of the deal represent the spirit of their negotiations and that it will be the basis for ongoing changes and negotiation. If an agency finds problems with specific units in the deal, but it is otherwise correct, they should accept the deal and use the deal change process to invoke the necessary changes. Rejection should only be used when the deal could not be processed (i.e. it violates the TECC standard) or it had serious discrepancies with the initial agreement (e.g. incorrect guarantee information).
While some lawyers have a difficult time with this interpretation, it has worked well as the standard business practice evolved over many years in the industry. Implementation of the 855 is an important transaction for EDI in the cable industry and is essential for enabling deal changes via EDI and for the elimination of the need for paper documents.
Theoretically, the deal should be sent once and all subsequent communication should be via deal change transactions. However, there will be times that a “snapshot” of the deal as it currently exists will be retransmitted using an X12 850 (Purchase Order) transaction set. As mentioned previously, many agencies process a single quarter’s worth of information at a time and prefer a fresh snapshot instead of reconstructing the snapshot from the original transmission and numerous changes. This is especially important in the near term, where most trading partners are not communicating deal changes electronically. The deal retransmission is simply a snapshot of the current state of an already agreed upon deal, and therefore acceptance merely means that the agency has received the transmission and it reflects the general state of the current deal.
Rejection should only occur in extreme cases (e.g. it violates the TECC standard or the network sent the wrong deal).
The invoice is a legal document between the network and agency. Invoices are sent via X12 using the 810 (Invoice) transaction set. The invoice serves as an affidavit as well as a bill. The network states that the units on the invoice ran in the appropriate time period and the appropriate copy was aired. Some invoices will also identify missed units (with a zero cost) for informational purposes. There are rare cases where mistakes exist on an invoice and corrections must be made. The TECC standard does not allow invoice changes so in such cases the entire invoice must be revised and retransmitted.
Invoices are typically sent at the end of each broadcast month, although certain advertisers prefer a different schedule that can be agreed to via a trading partner agreement.
From a legal perspective, the cable television invoicing process is similar to other industries so there should not be a need for any industry-specific legal language.
As in the case of deals, the X12 997 (Functional Acknowledgment) should be sent by the agency to the network to acknowledge receipt of the invoice. This does not imply the acceptance of the invoice, only that the invoice was received in the proper TECC format.
There is no separate transaction for invoice acceptance. In both the EDI and non-EDI environments, payment is the transaction that indicates acceptance. The agency reconciles the invoice with what they have ordered. If any discrepancies are noted, they typically hold the entire payment until the discrepancy has been reconciled.
Deal changes are sent from the network to the agency via X12 using an 860 (Purchase Order Change Request) transaction set. In the majority of the cases, the change will have already been discussed verbally between network and agency. As in the case of the deal, the deal change reflects the current state of the network’s computer system. Changes to multiple units will likely appear in a single deal change transaction.
In the non-EDI world, changes were communicated verbally and/or via paper documents.
An X12 997 (Functional Acknowledgment) should be sent to acknowledge receipt of the deal change transaction. It does not imply acceptance of the changes.
The X12 865 (Purchase Order Change Acknowledgment) is sent from the agency to the network to accept the deal change. As in the case of the deal acceptance, the deal change acceptance should be construed as a general agreement to work with the data sent as the basis for further discussion, not as an absolute agreement to accept the changes sent by the network. Like deals, the deal change transaction can only be accepted or rejected in total. Rejection should be reserved for major problems such as data not conforming to the TECC specification. For most discrepancies, the agency should accept the deal change and the network should make the correction in a subsequent deal
Brand allocations and traffic instructions use the same X12 860 (Purchase Order Change Request) transaction set that is used for deal changes. However, this transaction is sent from the agency to the network.
The network should send an X12 997 (Functional Acknowledgment) to acknowledge receipt of the brand allocation or traffic instruction transaction. As with all functional acknowledgments, it does not imply acceptance, it merely indicates that the transaction was received.
The network should send an X12 865 (Purchase Order Change) acknowledgment to the agency. As in the case of all deal changes, the 865 must either accept or reject the entire transmission. The only reason that the network should reject this transaction is if it is unable to process it (e.g. the agency has sent changes for a unit with an unrecognized serial number). Otherwise the network should always accept the 865, even if the network is unable to accommodate the agency’s request. If the network can not accommodate the request, it should send a deal change back to restore the original values.
From a legal standpoint, acceptance should not be construed as absolute acceptance of the request, but rather indicates that the network has received and processed the request.
The X12 standard provides a mechanism for uniquely identifying each transaction with a control number. This is extremely important for auditing purposes and will be discussed further in the following section. The use or non-use of control numbers is a business issue and should not have any legal implications. Trading partners may wish to include the meaning of the control numbers in their trading partner agreements for informational purposes.
Many networks print their deals and invoices on forms pre-printed with the terms and legal language governing this contract. The question has arisen as to whether this language should be included in the EDI transmission. The X12 transaction sets are not intended for the communication of long textual passages such as legal contractual language. Even if sent via EDI, it is possible that a court might not accept the “boilerplate” language because the software that receives it is not designed to process it. Therefore any terms or boilerplate language that is not specifically identified in the TECC standard should be included in a separate trading partner agreement, and not included in the actual X12 transmission.
The need for maintaining an audit trail will be discussed in detail in the next section. However, it is important to note that maintaining a reliable audit trail is also important for legal reasons so that it can be used as evidence in a legal dispute. The existence of evidence is a key factor in the resolution of any legal disputes between trading partners.
Trading partners who are concerned with the legal implications of EDI should have a trading partner agreement with each of their trading partners. It is vital that users familiar with standard cable television industry practices and business issues be involved in the drafting of such agreements so as not to negatively impact the use of EDI. It is very important that functional and content acknowledgments are included, so each trading partner should take care that the language does not limit their use.
Auditors are primarily concerned with risks, controls and the maintenance of records. Risks are those issues that can adversely affect a business. Controls are procedures that are put in place to minimize these risks. To eliminate the need for paper backup of EDI transactions and maximize the value of EDI, auditors must be assured that there are adequate controls in place to guarantee the integrity of the operation, and to satisfy legal and tax audit trail requirements. The IRS requires the retention of all records that have tax relevance, including EDI transactions. Records are also important as evidence if a dispute is to be settled by arbitration or trial and can be used by auditors as a basis for their annual audits to ensure that proper controls are in place and working correctly. A good audit trail can also be used as a business tool to reconstruct transactions in the case of missing data, and inconsistencies between network and agency computer systems. There are both business and legal reasons for maintaining reliable records.
While some trading partners have assumed that merely implementing X12 will eliminate the need for paper, this is not the case. Trading partners must follow rules and develop procedures for maintaining electronic documents, just as they do with paper. While this section is not meant to be an exhaustive discussion of auditing with regard to EDI, it will identify some of the key issues for the industry and make some specific recommendations to satisfy auditors. The following sections will discuss specific risks to the industry from EDI, and recommend controls and procedures for maintaining records. Some of these controls and risks have analogies in the non-EDI world; others are unique to the EDI process.
The move from paper-based transactions to electronic transactions typically introduces some added risks; it is much more difficult to detect tampering of an electronic document than it is on a paper document. Fortunately, the nature of the EDI process in buying and selling cable is such that the added risks are relatively low compared to many other industries using EDI (e.g. banking). This is largely because the process of buying and selling cable television via EDI still requires manual human intervention and inspection at multiple stages of the process. The risk from the intentional tampering of data by insiders or third parties is quite low because it would be difficult for an individual to manipulate records for financial gain. Risks are more likely to result from the increased possibility of computer error or human errors due to the newness of the EDI process. The following section will identify the typical risks associated with EDI. A later section will recommend controls that can be put in place to mitigate these risks.
While computerization has clear benefits, it also introduces the potential for bugs that can have unintended consequences. The EDI process adds additional software to the process (flat-file generation, translation and transmission) and therefore introduces the potential for additional bugs that can corrupt the data to be transmitted. Because the data is no longer printed and the format of an electronic transmission is difficult for a human to interpret, the electronic document does not typically undergo human review before transmission. New releases of software, computer upgrades and database changes mean that the environment will routinely undergo change and each change has the potential to introduce new bugs.
The impact of EDI system problems is less when compared to other industries. Most problems will be detected before they have financial impact. However, system problems can still cause a loss of revenue if errors are not detected before a unit is scheduled to air. More likely, these problems will result in a loss of trading partner confidence, and the potential loss of future business, especially if the problems are frequent.
The additional reliance on computers and phone lines for transmission increases the impact of “disasters” such as fires, power failures, disk crashes, and phone outages. Any disruption at the VAN can also cause a similar impact on a company’s system.
There are ongoing “non-disaster” risks to a company’s operations as well. These include additional charges that occur when using a VAN or service bureau and are typically billed monthly and based on transaction volumes. This billing can be confusing, as it is often difficult to reconcile the charges. The risk of a VAN or service bureau overcharging in this type of environment is introduced. The use of EDI also increases a computer’s usage and the increased volume has the potential to affect overall system performance. Likewise the additional reliance on computerization means that the MIS department becomes more strategic in that its performance has a greater impact on the core business.
These risks are similar to any additional computerization and are not specific to EDI. The impacts are primarily in the area of invoking unforeseen costs and a potential loss of business from MIS failures.
An electronic document has the potential to be corrupted during the transmission process. Data can be incomplete, garbled, lost, or even sent to the wrong trading partner. Most of these problems are correctible if identified in a timely manner. However, if they occur frequently, a loss in trading partner confidence can adversely affect the business relationship. Failure to identify problems can cause loss of revenue if they are not corrected before the air-date. In addition, the transmission of a document to the wrong trading partner can give away proprietary information since pricing is negotiated and may differ between clients.
Transmission risks are not specific to EDI. Similar risks can occur due to lost or damaged mail, smeared faxes, or mailing pages to the wrong customer. EDI can provide significant improvements over paper, if the proper controls are put in place.
These risks come from unauthorized alteration or destruction of information, unauthorized access to data, or unauthorized use of the VAN. EDI introduces additional places where the electronic data is held and where it has the potential to be viewed or tampered with. Although paper documents are not tamper-resistant (e.g. the use of white-out), it is much more difficult to detect tampering of an electronic document. In the non-EDI world, reports are typically generated directly from the database. Tampering can only occur in 3 places: in the database itself, in the code that generates the report, or by altering the written document. With EDI, there are additional places where the document can be tampered with: in the database, in the code that generates the flat-file, by direct editing of the flat-file, in the translation from flat-file to X12, and in the X12 file itself (either by the sender, the VAN, or the recipient). VAN and service bureau personnel, as well as the EDI personnel, can all potentially access the data.
Fortunately, in the cable television advertising industry, malicious tampering is not a serious security problem. It is very difficult to tamper with an EDI document for personal gain, and therefore the incentive for tampering is minimized. However, if a “hacker” does manage to intercept a traffic instruction transaction, they could conceivably change the ISCI code of a commercial that is to be run in a particular program.
A more likely situation is the “authorized” intentional modification of an electronic file. Such modifications are not done for fraudulent reasons, but rather they are undertaken done to circumvent MIS system limitations or to accommodate customer requests. This is not unique to electronic documents, paper documents can also be modified using white-out or handwritten addenda. One example is the inclusion of an agency’s internal estimate number on a document, where this information is not stored in the network’s traffic and billing system.
An additional risk comes from the increase in the number of people who have access to the data. Networks and agencies consider pricing information to be confidential and keep this information from their competitors. Floppy disks and e-mail make it easier to copy electronic documents than their paper equivalents. Fortunately, the impact from unauthorized access is still rather low compared to many industries. The information has limited financial value, the data loses its value over time, and aggregate information is often shared anyway. The actual impact of such a violation is likely to be a loss of negotiating leverage in future negotiations and a deterioration of the relationship with your trading partner (since they also have an interest in maintaining confidentiality).
It is important to ensure that a document was actually sent by the trading partner and that a trading partner can not deny that a document was sent to them. It is hard to imagine a scenario in the cable television industry where this could be used for fraudulent purposes and go undetected, because all documents are reviewed manually and normally discussed ahead of time.
A more likely situation would be a system bug or human error that would cause a trading partner to overlook a particular transaction. This could negatively impact credibility with a trading partner and also has the potential to cause units to air incorrectly.
Many controls and procedures that auditors have traditionally employed are based on a paper audit trail. These procedures no longer work for electronic documents. It is important to develop new procedures for retaining and archiving electronic documents that can satisfy the auditors and provide a reliable mechanism for an audit trail. When properly implemented, EDI can provide more accurate data than the paper version because human error (e.g. misfiled or lost documents) is minimized. However, human error in the EDI world has the potential to cause very serious damage (e.g. lost CD-Rom or tape).
The risks from not having paper are mostly due to the consequences from lost, incomplete, unreliable, or inaccessible archived transactions. The time-honored procedures used to ensure the completeness, accuracy and authorization of paper documents do not work as well in a paperless environment. For example, it may become second nature to file a copy of a deal at the time it is sent. When invoices are filed, the user may also check the file to ensure that a deal document is in the folder. In the world of EDI, the archiving function happens behind the scenes and the files are typically not reviewed unless needed to handle a special situation. Most EDI translation software has the ability to enable/disable the archive function (it is typically disabled for test transactions) so inadvertently setting the switch incorrectly can undermine all of the other archiving procedures in place.
An additional risk occurs because the electronic data is more difficult to visually inspect and therefore existing standard audit processes will require change. Bugs in the process are also less likely to be discovered “casually” (e.g. a secretary would notice if sections of the printed document were blank, but such a problem would not likely be discovered with electronic documents).
The impacts of these problems are varied and hard to predict. Some of them may prove inconsequential, others may make it extremely difficult to conduct the financial or operational audit.
A well-designed EDI program will have controls in place to minimize and mitigate the impact of the risks identified above. The following section recommends some specific controls that can be put in place to address these risks. Many of these controls apply to all software and EDI implementations, however the discussion will be tailored to the cable television industry. Where the recommended controls address multiple risks, they will be grouped with the most significant risk category.
The following list is not meant to be an exhaustive list of controls. Each trading partner will need to develop its own set of controls which best address the company’s strategy and internal operations. An audit plan should be developed to document these controls. This plan should be developed jointly by auditors, managers, and users for maximum benefit.
The evolution of software engineering has produced many techniques to control and minimize system risks. The following are some recommended procedures, most of which are applicable to all types of computerized software.
Machine Segregation – The computer(s) running the EDI software should, where possible, be used exclusively for EDI. This is especially true if the EDI software runs on a PC. No software runs in isolation; it is dependent on other system components (e.g. operating system, modem, other software running/installed on the machine, etc.) By limiting the machine to this single use, the chances of other software affecting the operations of the EDI software are minimized. While this was cost-prohibitive in the past, the fall in the prices of personal computers now makes this a viable option. Machine segregation also helps protect information security since it is much easier to limit access to a machine used for a single purpose.
Release Controls – Upgrades and modifications to the EDI computer (e.g. new releases of the software) should be made in a controlled fashion. They should be scheduled for times of low EDI activity (e.g. avoid the end-of-the-month invoicing period) to minimize the impact of any problems. Standard tests should be run to ensure that the existing EDI applications continue to run smoothly. It is always important to have the capability to restore the previous state of the machine if the upgrade causes unforeseen problems. It is also important to keep a detailed log of any changes to the system.
Software Testing – It is wise to have a test plan and test data available when software upgrades or changes are made. It is important to remember that EDI maps are the equivalent of computer programs, and any changes to the maps should be thoroughly tested. Wherever possible, these tests should be automated so that they can be run on a regular basis without requiring human intervention.
Validation – The X12 specification and the TECC specification have numerous checks and balances as part of their structure (e.g. record counts). Many system bugs can be detected by performing thorough validation checks of the X12 files (e.g. an invalid date format). While it does take increased initial effort to implement these validations, the effort will produce dividends over the long run. Validation can easily be automated and performed on every transaction going in or out of the system to provide the maximum level of protection.
In the cable television industry, most disasters can be handled in the short run through common sense and manual procedures. Communication between trading partners is key; time critical information can still be communicated verbally, via e-mail or by fax. Once the crisis has passed, the information should be transmitted via EDI to confirm decisions that were communicated manually. The following controls are also important in order to be able to restore normal operations as soon as possible.
Backup Plan – All software data that is needed to duplicate the EDI environment should be backed up on a regular basis. Ideally all data should be backed up both locally and on the network file server (which should be backed up as a matter of course). It is important to test that all data is being backed up properly by completely restoring the EDI setup to a test machine from time to time. If possible, a duplicate version of the EDI software should be maintained on a second machine that could be used in the case of hardware failure.
Disaster Plan – Most organizations will have a enterprise-wide plan in place to handle the case of a disaster which incapacitates the computer system. This typically includes storage of software backups off-site and the ability to set up computer operations at a third-party site. It is important to ensure that the EDI system is included in the corporate disaster plan and backup plan.
Phone outages – Most trading partners connect to their VAN via phone lines. A phone outage can make it impossible to receive or transmit data. Some VANs allow a connection via the Internet so this may be an alternative if the phone lines are out of service. This assumes that the company’s Internet connection is not part of the affected phone network.
Multiple VAN Accounts – The VAN is an important third party in the communications between network and agency. They are susceptible to the same outages and disasters as any company. While most VANs are prepared to deal with such outages, it is good practice to have an account with a secondary VAN that can be used as a backup. The connection with the second VAN should be tested on a regular basis to ensure that the switch can take place easily.
Involve MIS in Business Discussions and Planning – In most businesses, computer systems have evolved from a support role to a key strategic component. Software or hardware failures can affect a company’s ability to do business. It is very helpful to involve MIS personnel in business discussions relating to the implementation of EDI. They may be able to offer suggestions and techniques that can reduce system and operational risks.
Control numbers – The EDI process should be configured to require and enforce the use of control numbers. It is standard EDI practice to assign a sequential control number to each transaction sent to a particular trading partner. By enforcing this practice, it simplifies the detection of missed or duplicate transmissions. This procedure should be automated so that the EDI Coordinator is notified when these problems occur.
Validation - Validation of files for conformance to X12 and TECC rules can also identify transmission errors (e.g. dropped segments). This validation should be performed by the recipient of the document. If the validation finds errors, the recipient should contact the sender to have the document retransmitted. In some cases, the VAN will be able to retransmit the document. However this will only be useful if the error was introduced between the VAN and the receiver. It is also important for the sender to perform a validation to ensure that the error was indeed a transmission error and not an internal system error (in which case the document should never have been sent).
“Envelope” Validations – As is the case in the non-EDI world, the address on an EDI envelope is independent of the contents of the envelope. An invoice for agency A could be accidentally inserted into the envelope for agency B. Therefore it is recommended that an additional validation step be included which compares the address on the “envelope” to the address on the internal transaction. Any discrepancies should be flagged so that they can be reviewed before transmission. (Note: This may require access to the translation software database.)
Physical Security of Systems – One obvious way to protect the information is to keep the computer in a limited access area. While effective, this is typically overkill because of the inconvenience caused to the EDI Coordinator. In most environments, other security measures are sufficient without requiring the machine to be locked.
User Access Control – The system administrator should set up a security system that limits access to the information to those with a “need to know”. Standard password level protection to the programs and files is usually sufficient to limit access to the data.
Segregation of Duties – Segregating duties is a common practice used to help prevent unauthorized tampering with data. As previously discussed, it is unlikely that anyone would commit fraud by intentionally tampering with EDI files. Nevertheless, if the files are ever to be used as evidence, segregation will be considered important in considering their reliability. Therefore it is important to have a second person responsible for archiving the data, who is not the person operating the EDI software. Ideally the process should make it impossible to alter data once it has been transmitted. Having the data archived by a third party (e.g. a VAN or service bureau) will make collusion even more unlikely.
Audit Trail of “Manual” Changes – As discussed in the risks section, on rare occasions X12 files are intentionally modified for legitimate business reasons. The best way to eliminate or at least minimize these changes is to provide a preferred alternate means to achieve the same goal. This may require enhancements to the existing traffic and billing systems or the addition of an editor to modify the file and create an audit trail entry that documents the change. The editor should be configurable to only allow certain changes and to provide some validation to ensure that the change did not cause unintended consequences.
Archiving – Archiving of transmissions can serve as evidence of altered documents and should help deter those who might try to alter documents. Data should be archived in a write-only format so that it cannot easily be tampered with once written. CD-ROM is thus an excellent low-cost medium for archiving. The archives should be made on a regular basis (weekly or monthly) and stored in a secure area, preferably off site. Both the original flat-files and the actual EDI transmissions should be archived. This will make it easier to identify problems caused by system errors. There are significant benefits to maintaining good archives beyond the minimization of information security risks, so it is worth the effort to maintain good archives. These will be discussed further in the section on maintenance of records.
Validation – Validation can be used to identify unauthorized tampering. For example, by validating traffic instructions to ensure that each ISCI is a correct ISCI code for the brands associated with the deal, the unlikely situation where a hacker has changed an ISCI code can be detected.
Control Numbers – The use of control numbers makes it possible to easily detect fraudulent transactions. Because each transaction is assigned a sequential control number, the fraudulent transaction would have to either have the same number as a legitimate transaction, or have a control number that was out of sequence. In either case, it would be apparent to the recipient that there was a problem and a discussion with the authorized sender would identify which was the bad transaction. Likewise a third party could not intercept and “delete” a transaction because the recipient would notice a missing control number when the next transmission was received from the trading partner. There is still one scenario that control numbers can not identify: the case of a third party intercepting a transaction and substituting a fraudulent transaction with the same control number as the one they intercepted.
Acknowledgements – Acknowledgements can be used as proof that a recipient did receive the document that was sent.
Reconciliation Processes – It is current standard industry practice to review and reconcile all incoming transactions. Some of these reconciliations are automated while others require manual inspection. These processes are extremely effective in detecting any authenticity problems and no further controls should be needed.
Most of the risks associated with going paperless can be addressed by implementing automated audit trail procedures. This has the potential to provide a better audit trail than with paper because there are no errors due to filing mistakes or deals made with scribbles on the backs of napkins. The section on the maintenance of records will identify in more detail the data that should be maintained in the audit trail. This section will discuss controls to ensure that the audit trail is being correctly maintained.
Testing – Audit trail procedures do not typically receive the scrutiny and testing that are expended on the actual business transactions, since the audit trail is primarily used as backup and is not referenced on a day-to-day basis. Unfortunately this means that significant bugs can go undetected. Most EDI software must be configured to produce the audit trail logs. Because archiving is frequently disabled for prototyping and testing, a common mistake is simply to forget to turn it back on. The majority of these problems can be avoided merely by making maintenance of the audit trail a high priority. Testing of the audit trail features should be a key element of any test plan that is run whenever the software is upgraded or other changes are made to the system. The archive files should be inspected on a monthly basis to ensure that they are being generated correctly. While offsite storage is important for security reasons, the archived files should also be left on the local hard drive so that they can be accessed by the EDI coordinator for problem solving and to answer requests (e.g. to determine on what date was a particular deal sent?).
Human Readable Formats – The flat-files and X12 files were designed to be read by computers, not by people. Even a trained X12 user may not be able to glance at an invoice and notice that a billing address was missing, even though this would be apparent to most users by looking at a printed invoice. Thus, if the audit trail is to be useful, it needs to have an interface that is tailored for people, not for computers. Users should be able to view the audit trail in an organized format and “translate” the X12 file into a format that mirrors the printed version of the document. The same code could be used to generate paper backup when required. It is important that the X12 file be used as the source to ensure data integrity.
Migration to Paperless – Due to the evolution of EDI and system architectures, the X12 files and their paper documents can differ. In some cases the two are generated from different databases but most differences are simply due to the files being generated by different programs. While many differences are trivial (e.g. spelling of a customer name or program name truncation), they can be problematic for auditors. Therefore, it is wise to develop new procedures so that printed documents are based on their EDI equivalents and it is always good practice to routinely compare printed reports to the X12 files to detect system bugs.
EDI Policies and Procedures – Each trading partner should document and maintain a list of polices and procedures for EDI. This document can be used as part of the annual audit to ensure that the appropriate controls are being followed.
Training and Education –The more that personnel understand about the EDI process and the controls that are in place, the more likely they will adhere to them and make recommendations for improvement. It is essential that the personnel involved with enforcing the controls understand and agree with their purpose.
The previous section has discussed the merits of keeping good records and maintaining an audit trail. This section discusses the various documents that can be kept.
X12 Transactions – All X12 transactions should be kept as part of the audit trail. These are the most important to auditors and the ones most likely to be used for evidence. It is also important that adequate controls are in place to ensure their reliability. The 850, 810 and 860 are the key transactions. As already discussed, the industry policy is to use the 997, 855, and 865 transactions for informational purposes only, with no legal meaning. As a result, they have limited value as evidence, so there is less need to archive these transactions.
Flat-Files – The audit trail is useful for debugging to determine the cause of particular errors. Minor errors embedded in a deal may not be detected for awhile, so the X12 transaction archives can be used to help identify where they occurred. If the error does not appear in the database, the archived flat-file can identify whether the error was introduced in the creation of the flat-file or in the translation to/from the X12 transaction set. In some situations, the recipient may request that the error be corrected and retransmitted. In such cases, manually modifying the old flat-file or X12 file for retransmission may be the best option (since the database has likely changed since the transmission in question).
Paper Documents – Paper documents should continue to be stored until the auditors and trading partners no longer require them. Even in this case, it may be beneficial to continue the storage of paper documents that can be used by non-EDI experts in reviewing the audit trail. In this case it would be best to generate the paper documents directly from the X12 files to avoid potential discrepancies.
Deal and Invoice Numbers – Buyers and sellers identify deals and invoices by the advertiser and date ranges and/or by the deal and invoice numbers. X12 is organized by control numbers, and information such as the deal number is embedded within the document. As a result, it can be difficult to locate the appropriate X12 transaction for a given deal. It is therefore quite useful to maintain a file that identifies each X12 transaction and the corresponding deal/invoice number. Ideally this should be maintained electronically (e.g. in a spreadsheet) so that it can be searched easily.
Log Files – Most EDI software generates log files describing the date and time of various transactions. These log files can be quite useful in reconstructing an audit trail of past events.
Translation Tables – There are typically many “translation tables” in the EDI process. These tables are used to convert data to/from a format that is used in the internal database from/to a format that is used by a trading partner or mandated in the TECC specification. Because these tables often undergo changes, having these tables available can be useful in tracking down errors that are discovered late in the process (and after the tables have been modified).
Translation Maps – It may be useful to save the maps that are used for each trading partner. These maps can be helpful when reconstructing the cause of an error later in the process.
The Legal and Business Controls Workgroup of DISA has developed a set of guidelines for evaluating EDI control issues. It is entitled “A Model EDI Audit Program” and is available from DISA. They also publish a guide for auditors managers and users entitled “EDI: Risks, Controls and Auditing” written by William J. Powers of BDO Seidman, LLP. The Electronic Messaging Services Task Force Subcommittee on Electronic Commercial Practices of the UCC has developed a “Model Form of EDI Trading Partner Agreement and Commentary” which is published by the American Bar Association.
This section is intended for users who have already implemented earlier versions of the TECC standard. For those who will be implementing TECC version 3.0 for the first time, click here to skip this section.
The major change to the TECC standard is that the entire deal is now sent in a single 850 transaction set, the 843 transaction set is no longer used. This was achieved by some modifications to the structure of the X12 850 to accommodate cable industry specific needs and some restructuring in the way that the data is transmitted.
The specification should now be much easier to read and follow. The initial mappings were undertaken based on existing limitations of the X12 specification and as a result, much of the TECC information was “forced” into segments that did not necessarily reflect the meaning of the transmitted data. Following multiple Data Maintenance requests submitted to X12 subcommittees by TECC, the industry transactions now have a more logical flow. The addition of new codes to the X12 specification means that the use of “ZZ” codes has virtually been eliminated. Demographic information is now transmitted via the TECC designed ADV segment, instead of forcing it into other “generic” segments.
Version 3.0 conforms to all ASC X12 rules so X12 validation can now be turned on in the translator and/or at the VAN. Most implementations of version 1.0 had turned off validation due to the 30-hour broadcast clock and other trading partner specific variations that violated some X12 rules. It is highly recommended that each transmission be validated for conformance to X12 rules.
TECC version 3.0 uses X12 release 4010, so there may be a need to update the translator with the appropriate tables. Earlier versions of the X12 specification had multiple date formats for dealing with century information. In version 4010, most dates are now of the form “YYYYMMDD”.
The deal header information is now included in the heading section of the 850. Contract headers have been eliminated. An optional field in each unit allows the unit to be assigned to a specific contract number. However, this is the only place where contracts appear. Guarantee guidelines and cancellation instructions are now based on date range and network instead of by contract.
In earlier versions of the TECC standard, the non-guaranteed demographics were listed in the header and their values were identified by position in the detail section. In version 3.0, non-guaranteed demographics are no longer listed in the header section, but are instead identified by name in the ADV segment for each unit. This means that a user can no longer rely on the impressions being listed in the same order for each unit. In addition, “Homes” is no longer required for all transmissions. If Homes is requested, they must be included in the ADV demographic list.
Addresses now use the N4 segment for transmitting city, state and zip code information. Previous versions had allowed this information to be aggregated in an N3 segment.
Version 3.0 now has a greater emphasis on units as standalone entities. Billboards and mirrored units can now have their own independent serial numbers. Prior versions required serial numbers to be assigned according to a set “algorithm”. Each serial number must now be transmitted as a separate SLN loop. Previous versions allowed sequentially assigned serial numbers to be aggregated in a single SLN loop. This means that file sizes may be larger than in previous TECC versions. Some additional fields have also been included in the standard (e.g. broadcast network and episode information).
Times are now sent according to a 24-hour clock. However, the times from 00:00 to 05:59 by convention actually air after midnight of the day specified. If trading partners use a 30 hour broadcast clock internally, then they must convert to/from a 24 hour clock. This is easily accomplished in the EDI translation according to the following algorithm:
For networks: Before transmission, subtract 2400 from any time that is greater or equal to 2400.
For agencies: Upon receipt, add 2400 to any time that is less than 0600.
The first draft of the version 3.0 invoice was streamlined to remove non-essential fields and repeated information. This was based on the assumption that all trading would be serialized. Now that version 3.0 supports both serialized and non-serialized transactions, the essential fields have been added back. However, some fields that were part of the earlier standards are no longer transmitted in version 3.0.
Multiple trading partner variations evolved in earlier versions of the TECC specification for a variety of reasons. Supporting these variations placed a heavy burden on EDI coordinators when adding new trading partners. It is hoped that version 3.0 will eliminate or at least drastically reduce trading partner variations. Therefore it is important that any requests for variations be brought to TECC for discussion and resolution. Conformance to a single TECC standard is essential for the successful implementation of deal changes.
This section is the formal TECC Version 3.0 EDI standard. It assumes the reader has a solid understanding of the EDI process and network cable television industry business practices. This formal specification is written in the technical language of X12 and therefore requires a technical familiarity with ASC X12.
The first section describes the process flow of EDI documents. The second section describes the format of each transaction set. A link is provided to the formal X12 documentation for each transaction set. This document includes additional information about key fields.
The following section describes the flow of electronic documents between network and agency both with and without unit serialization. The primary difference is that without unit serialization, only deals and invoices can be communicated electronically (i.e. deal changes cannot be transmitted electronically).
Initial Deal
· The cable network sends a Deal (850) to the advertising agency.
· The advertising agency sends a Functional Acknowledgment (997) to the cable network to acknowledge receipt.
· The advertising agency sends a Deal Content Acknowledgment (855) to the cable network to acknowledge that there are no major problems with the deal and that it will be used as the basis for further communications. Typically this acknowledges that the agency has loaded this information into their computer system. If the 855 is used to reject the deal, the process begins again with another initial deal transmission from the cable network.
Deal Changes
· Deal changes (including traffic instructions) are communicated via traditional non-EDI methods (e.g. via paper documents). Each trading partner is responsible for manually entering this information into their computer system.
· Because no further electronic transmissions can take place regarding changes, the advertising agency may ask that a snapshot of the deal be retransmitted to ensure that the two systems are in-synch. Typically this will happen at the beginning of a broadcast quarter. The network would then send another Deal (850) to the advertising agency. The advertising agency would then send a Functional Acknowledgment (997) and Content Acknowledgment (855). Such transmissions are for informational purposes only, and therefore the 855 cannot be used to reject the document unless it violates a TECC rule.
Invoices
· The cable network transmits an Invoice (810) to the advertising agency on an agreed upon schedule (typically at the end of the broadcast month).
· The advertising agency sends a Functional Acknowledgment (997) to the cable network to acknowledge receipt.
· The advertising agency sends payment to the network via traditional non-EDI methods.
Initial Deal
· The cable network sends a Deal (850) to the advertising agency. Each unit is required to have a serial number.
· The advertising agency sends a Functional Acknowledgment (997) to the cable network to acknowledge receipt.
· The advertising agency sends a Deal Content Acceptance (855) to the cable network to acknowledge that there are no major problems with the deal and that it will be used as the basis for further communications. Typically this acknowledges that the agency has loaded this information into their computer system.
Deal Changes
· All changes to the deal must first be discussed before they are transmitted electronically. With the exception of traffic instructions (described below), all changes are transmitted from the cable network to the agency via a Deal Change (860). Even changes that are requested by the advertising agency are transmitted from network to advertising agency.
· The advertising agency sends a Functional Acknowledgment (997) to the cable network to acknowledge receipt.
· The advertising agency sends a Deal Change Content Acknowledgment (865) to the cable network to acknowledge that the changes were received and processed. Only in extreme circumstances should the 865 be used to reject the deal change. Rejection can make it very difficult to keep the two systems in-synch. The preferred method for “rejection” is to acknowledge the change via an 865 and request that the network make the necessary corrections and have them send another deal change reflecting these changes. If the deal change is rejected, all subsequent changes must be held until the deal change is corrected and acknowledged. Acceptance should occur as soon as is possible.
· Deal changes should not be transmitted until all previous changes have been acknowledged.
· Despite the best efforts, it is possible that the cable network and advertising agency computer systems become out of synch. The actual solution to this problem will depend on the individual circumstances. However, it may be necessary to “re-synch” the systems by having the network send a snapshot of the deal via another Deal (850) transmission.
Traffic Instructions
· Brand allocations and traffic instructions are sent from the advertising agency to the network via a Deal Change (860). Most of these transmissions will simply be specifying a unit serial number, a brand code and/or ISCI code associated with that unit. The notable exceptions are brand allocation splits and combines which involve deleting or creating new units.
· The cable network sends a Functional Acknowledgment (997) to the advertising agency to acknowledge receipt.
· The cable network sends a Deal Change Content Acknowledgment (865) to the advertising agency to acknowledge that the traffic instructions were received and processed. Only in extreme circumstances should the 865 be used to reject the traffic instructions. If the network cannot accommodate the agency’s request to split and/or combine certain units, it should still accept the 860 and verbally communicate the problem to the advertising agency by sending a subsequent deal change transaction that restores the original units.
· If an agency has split a unit as part of brand allocation, they will have assigned a temporary serial number to the unit. The network should then send back a deal change transaction that assigns permanent serial numbers to these units.
· A problem can occur if the agency sends traffic instructions at the same time that the network is sending deal changes. Ideally, agencies should notify networks when they plan to send brand allocations and the network should hold their changes until the brand allocations are received and acknowledged. If a case occurs where the transactions do cross, the industry convention is that the network’s transmission takes precedence.
Invoices
· The cable network transmits an Invoice (810) to the advertising agency on an agreed upon schedule (typically at the end of the broadcast month). Each unit is required to have a serial number.
· The advertising agency sends a Functional Acknowledgment (997) to the cable network to acknowledge receipt.
· The advertising agency sends payment to the network via traditional non-EDI methods.
This section describes the actual X12 transaction sets and the TECC rules for their usage. Each transaction set will include a brief description of the transaction set structure, a link to the formal X12 specification for the transaction set, and a description of key fields and their usage. Fields are listed separately here to provide additional context information and to provide examples of usage. Consult the formal specification for the comprehensive list of all fields.
The format used for describing the TECC transaction sets is utilized by most industry groups who employ the X12 standard for EDI. Those users with prior X12 experience will find the format familiar and can skip this section. Users who have never seen an X12 standard may find this information helpful. If the standards are being viewed for the first time, it may be helpful to first review the X12 Transaction Sets section before proceeding. It is important to remember the distinction between X12 rules (which apply across industries to all users of the X12 standard) and TECC rules (which apply only to the cable television industry).
The formal rules for this format are described in documents X12.6 and X12.59, which are part of the X12 standard and are included at the front of the printed X12 specifications available from DISA. However, the following summary should be adequate for most readers.
Each transaction set is created as a separate document. The transaction set name and number are listed at the top. Formal boilerplate language included and a very brief description of the generic use of the transaction set is also included. All segments that can appear in the transaction set are then listed. Loops allow a related group of segments to be repeated. Those segments that are not allowed as part of the TECC standard are marked with an X in the first column. Additional columns describe how the segment is used:
Pos – The numeric position number assigned to this instance of a segment in the transaction set.
Segment Id – The X12 identifier for this segment. This is the abbreviated name that is commonly used when referring to segments.
Segment Name – The full X12 segment name.
Required – Mandatory or Optional.
Max Use – The maximum number of segments of this type that can occur at this position in the transaction set. >1 is used if there is no limit.
Repeat – Applies to loops. The maximum number of times this group of segments may repeat. >1 is used if there is no limit.
Notes – If there is a note associated with this segment, a note id is included in this column. The actual notes are listed at the end of the transaction set.
Following the transaction set description, each segment is described. Only those segments that are allowed in the TECC standard are listed. Each segment begins with a header describing its name, id and position in the transaction set. The element summary lists all of the X12 elements that are allowed in this segment. Elements that are not allowed as part of the TECC standard are marked with an asterisk (*) in the first column. Additional columns describe how the element is used:
Ref – The reference identifier for this instance of the element in the segment. The first characters are the segment id and the last two digits identify the element’s position in the segment. (For example, BEGO3 is the third element in the BEG segment).
Element Id – The X12 identifier for this data element.
Element Name – The X12 element name for this data element.
Required – Mandatory, Optional, or Conditional. Conditional means that it depends on whether other data elements are used. The conditions for each element are described at the end of the element summary.
Type – The type of data allowed in this data element. The current list of X12 types:
AN – Alphanumeric data. A left justified alphanumeric string with at least one non-space character. Any leading spaces are assumed to be significant. Trailing spaces should be suppressed.
B – Binary data. Not used in the TECC standard.
DT – A date of the format YYYYMMDD where YYYY is the Year, MM is the numeric month and DD is the day. (Note that in earlier versions of the X12 specification, only a 2‑digit year was transmitted).
ID – A value from the pre-defined list of values maintained by ASC X12. In most cases, the TECC standard only allows a subset of these values and these will be identified in the code list section (described below).
Nx – (Where x is a number from 0 to 9). A number with an implied decimal point. There are x digits to the right of a fixed, implied decimal point. Thus, N0 (N-zero) implies an integer. The decimal point should never be transmitted. Leading zeroes should be suppressed unless necessary to satisfy minimum length requirements.
R – Decimal number. This is used to transmit data that may have a decimal point. In most cases in the TECC standard, the decimal point is implied and therefore a decimal point should not be transmitted.
TM – Time in the format HHMM where HH is hours and MM is minutes. (Note that the X12 specification allows for the inclusion of seconds and partial seconds, however the TECC standard only allows HHMM).
Comp – A composite element. Composite elements consist of multiple data elements separated by a subelement separator.
Min/Max – The minimum and maximum number of character positions for the value of this data element.
Usage – Similar to the Required column, this column describes how this element is used in the TECC standard. (Note that the required column only relates to the X12 standard). Values are Must use, Used, or Not used.
Description – The X12 description for this data element.
User – The TECC description for this data element. This will be shaded in gray to make the standard easier to read.
Code List – For data elements of type ID, the list of allowed TECC standard values are included here. The list of values is typically much smaller than the range of values allowed in the full X12 standard. Only those values listed in the standard are considered to be legal for TECC compliance. The code and name are both listed.
The following appear after the completion of the element summary.
Syntax - Syntax notes (listed after the element summary) describe rules that must be followed for X12 conformance. Typically they define the conditions for conditional fields.
Semantics – Semantic notes give information to clarify the relationship that exists between elements.
User – These notes give TECC specific information about the usage of the segment,
All X12 transmissions must begin with an ISA (Interchange Control Header) segment and end with an IEA (Interchange Control Trailer) segment. This acts as an “envelope” around the entire transmission. The ISA contains the EDI address of both sender and recipient. This is the address that VANs use to route messages between trading partners so it is imperative to have the correct address.
Transaction sets within an ISA envelope are enveloped between a GS (Functional Group Header) and a GE (Functional Group Trailer) segment. These allow related transaction sets to be grouped together. In the cable television industry, the GS and GE segments have little purpose, but they must nevertheless still be included.
Element Separator – The ISA segment is the only X12 segment with a fixed length. Non‑used fields must be blank or zero filled. This is because the element separators are defined by position. The 4th character in the ISA defines the element separator to be used for the entire transaction. To make examples easier for humans to read, the separator is typically an asterisk. However, because asterisks are legal alphanumeric values (and are sometimes part of the program name), it is suggested that a non-asterisk character be used. A non-printable character is often used to avoid potential conflicts. The choice of the element separator is entirely up to the sender, and it is the sender’s responsibility to choose a character that does not appear in any alphanumeric strings in the transaction.
Subelement Separator (ISA15) – The last character in the ISA is the subelement separator. The components of X12 composite elements are separated by the subelement separator. It is important to choose a character that does not appear anywhere in the data to be transmitted.
Authorization Information – The TECC specification does not use authorization information, therefore the Authorization Information Qualifier (ISA01) should always be “00” and Authorization Information (ISA02) should always be blank filled.
Security Information – The TECC specification does not use security information, so the Security Information Qualifier (ISA03) should always be “00” and Security Information (ISA04) should always be blank filled.
Interchange ID – Each trading partner chooses a unique ID to identify themselves to their trading partners. The ID defines the mailbox, so different ID’s are needed for each VAN account. The company’s Dun & Bradstreet number is often used in the cable television industry. (The Interchange ID Qualifier is “01” for Dun & Bradstreet numbers.) Each ISA contains the Qualifier and ID for both the sender and recipient, so trading partners must first manually exchange ID’s before trading can begin.
Interchange Control Version Number (ISA12)– TECC Version 3.0 is based on X12 version 4010, so the Interchange Control Version Number should always be “00401”.
Acknowledgment Requested (ISA14)– TECC Version 3.0 calls for acknowledgments for all transactions, therefore this field should always be “1”.
Test Indicator (ISA15) – This is a very useful flag for sending test transactions. A value of “T” indicates that this is a test transmission only and is not production data. A value of “P” should be used for all “normal” transmissions. (Note that your trading partner may not have implemented a separate procedure for handling test transmissions, therefore it is always wise to notify your trading partner before sending test transmissions).
The heading section of the 850 is used to convey general information about the overall deal. This includes network and agency identification information as well guarantee information. The network assigns a unique deal number that will be referenced by all subsequent EDI transactions pertaining to the deal (e.g. deal changes, invoices).
The detail section provides information about each unit in the deal. The primary PO1 loop describes the program and the range of dates and times where the unit may air. This section also gives information about how units are to be distributed within the given dates and times, and any exceptions that are allowed. The SLN (subline) loop within the PO1 gives additional details about each unit.
The summary section is used to give transmission totals and is primarily intended as a check to ensure that no errors occurred in producing the transaction or in transmission.
Click here to view the version 3.0 TECC 850 specification
Note: This is a large document and may take awhile to download.
Deal Number - The deal number is defined by the sending trading partner (i.e. the cable network) and must be unique within their system. The sender can never send separate deals with the same deal number. However, the recipient (i.e. the advertising agency) may receive deals with duplicate deal numbers since they do business with multiple networks. The agency must look at both the trading partner id and the deal number to uniquely identify a deal. The network code should not be used for this purpose, because a cable company often broadcasts multiple networks. Note that this method is not perfect, since a cable network organization may have multiple trading partner ids (e.g. if they have accounts with multiple VANs or if they change VANs). The deal number is also important because it links subsequent transactions (e.g. deal changes, invoices, deal retransmissions) to the original deal.
Revision Number – The release number is used to uniquely identify deal retransmissions. A release number of 0 is used for the initial transmission. Each time the cable network sends a new snapshot of the deal, the release number should be incremented. However, if the same exact 850 is being retransmitted (e.g. because of transmission difficulties with the original), the release number should not be incremented.
Advertiser Name – A network provided description of the advertiser. There is no standard industry code list.
Advertiser Code – A code which will uniquely identify the advertiser. There is no standard industry code list.
Calendar Type – Most deals are organized and invoiced according to a standard broadcast calendar. However, it is possible to have deals organized according to a standard calendar or a custom trading partner specific calendar.
Revenue Sources – Defines how the units are paid for.
Cash – The standard method of payment.
Barter – A scenario where units are traded for other units on another network. This is rare in cable network television, but one scenario is for cross-promotion where cable networks may exchange units to allow each to promote their programming on the other’s network.
Per Inquiry – A scenario where the network is paid based on the number of calls that the advertiser receives from the airing of the advertisement. If Per Inquiry is used, the amount per call is sent in the Per Inquiry Payout field.
Direct Response – Similar to Per Inquiry, Direct Response means that payment is based on the response to a particular advertisement. When the price is more complicated than a single fee per phone call, Direct Response is chosen as the revenue source instead of Per Inquiry.
Trade – The units are given to the agency in exchange for other services or products. If trade is used, the Trade Agreement Number (which references a non-EDI document) is transmitted. Trade deals are not invoiced electronically.
Deal Type
Upfront – A deal made during the standard upfront period.
Opportunistic – A deal made for remaining unsold inventory, typically near the broadcast date.
Scatter – A deal made for specific inventory, but after the upfront period. Scatter deals are typically for a shorter period of time than upfront deals.
Network Code – A unique code for each network that appears in the deal. The cable network defines these codes, however it is common (and preferred) practice to use the standard network codes defined by A.C. Nielsen.
Equivalence Indicator – Indicates whether the demographic impressions are based on unit lengths or on the number of units (independent of their length). This is important because it affects how the guarantee CPM is calculated.
Example: A program is viewed by 250,000 adults. An advertiser purchases a 15 second unit and a 30 second unit in this program. If impressions are equivalenced, the impression for the 15 second unit is calculated to be 125,000 adults. If impressions are not equivalenced, then both units will have an impression of 250,000 adults.
Cancellation Option – Some deals are negotiated to give the advertiser the ability to cancel a portion of the deal without penalty. Cancellation options can be specified to apply to a specific quarter and/or network. Multiple cancellation options can be specified for the deal, however multiple cancellation options cannot cover the same network/quarter combination. Cancellation options must indicate the percentage of dollars that can be cancelled without penalty. (If all, 100% is specified). Optionally, a due date may be included. This is the date by which the advertiser must exercise their option to cancel.
Sender Date / Time – This is the date that the transaction was created by the sender’s system. This can either be the time that the information was extracted from the MIS system (e.g. when the flat-file was generated), or the time that the information was processed by the EDI system. While both are allowed, the former is preferred because that will be more useful for resolving synchronization conflicts.
Deal Start / End Date – The start and end date for units in the deal. No unit in the deal should air outside of the date ranges specified by deal start and end. These dates must be the start and end of a week. The start date must be a Monday and the end date must be a Sunday.
Brand Code – The code used to identify the brand if the entire deal is for a single brand. The brand code is typically assigned by the agency during brand allocation and therefore does not usually appear on the initial deal. However, in cases where the entire deal is for a single brand, this may be filled in.
Total Deal Dollars – This is the total dollars for the entire deal. Ideally this will be the sum of the costs of all of the units in the transmission. However, if only a portion of the deal is being transmitted (not recommended), then this is the total cost of the entire deal, not just what is being transmitted. The summary section of the 850 will have totals for the transmission.
Total Units - This is the total number of non-billboard units in the deal. Mirrors count as a unit. Ideally this should be a count of all of the units in the transmission. However, if only a portion of the deal is being transmitted (not recommended), then this is the total number of units for the entire deal, not just what is being transmitted. The summary section of the 850 will have totals for the transmission.
Comments – Deal level comments are allowed. However, these should be used sparingly if at all and certainly should never be used to transmit meaningful computer processable information. Legal language and terms should be handled via a trading partner agreement, not via the 850.
Agency Code – Typically the agency code assigned by the AAAA is used. However, some agencies are not members of the AAAA and do not have a AAAA-assigned code. In such cases, networks usually assign an internal code to the agency.
Guarantee Information – The ADV loop is used in the heading section to specify guarantee and guarantee guideline information. All guaranteed deals must have at least one ADV segment to specify the guaranteed demographic and its CPM. There can be a maximum of one guaranteed demographic per deal. For the initial deal, the total cost divided by the sum of the impressions of all units in the deal should equal the CPM. (Note that there may be a slight difference due to rounding issues.) All purchased (i.e. units with an associated cost) and No Charge units count toward the guarantee total. Bonus, ADU, and recapturable units do not count toward the guarantee total. A seldom used alternative is to guarantee the total number of impressions or rating for the deal instead of CPM information. No date (DTM) records should be associated with the guarantee.
Guarantee Guidelines – Guarantee guidelines provide more detailed guidelines that can measure how a deal is doing compared to the guarantee. Guidelines can be provided by time period (typically quarterly) as well as by network. The guarantee guideline looks similar to the guarantee, however the time period and network are specified using the optional DTM and MTX segments.
Guarantee Example – The following is for a deal with a $9.50 guaranteed CPM for Men between 18 and 34. Quarterly guidelines are provided to show that the bulk of the impressions are to be aired in the first two quarter. (1 million total impressions: 350,000 to air in each of the 1st two quarters, and the last two quarters with 150,000 each). For this example, the asterisk (*) will be used as the element separator.
ADV*AE*MA*18*34*NTI*GC*950
ADV*AE*MA*18*34*NTI*LI*3500
DTM*196*19991027
DTM*197*19991226
ADV*AE*MA*18*34*NTI*LI*3500
DTM*196*19991227
DTM*197*20000326
ADV*AE*MA*18*34*NTI*LI*1500
DTM*196*20000327
DTM*197*20000625
ADV*AE*MA*18*34*NTI*LI*1500
DTM*196*20000626
DTM*197*20000924
Program Name – The network assigned name for this program. Note that program names sometimes contain “non-typical” characters (e.g. “ * ” or “ – “ ). Be sure to choose an element separator that will not conflict with such data. Some agency mainframe systems have difficulty with some of these codes, so agency EDI systems may need to filter out these characters when they receive the initial transmission.
Program Code – A network assigned code for this program. There are no industry standard program codes, the agency is responsible for mapping these to program codes within their system.
Mobility Code – If set, the unit may be moved outside of the parameters of the program without prior approval.
Event Code – The event code is set if a program is tied to a specific event (e.g. the Academy Awards). The implication is that if the event is moved to a different day and/or time, the unit should also be moved.
Conclusion Code – Some programs do not have a fixed end time (e.g. a baseball game which may go into extra innings). If this is the case, then the Conclusion Code is set. This implies that the unit may air after the scheduled end-time.
Rotation / ROS Code – When there are multiple units for a given program, this describes how the units are to be distributed.
Fixed – The distribution is according to a fixed schedule agreed upon by the cable network and agency. In such cases, the schedule date is the actual day that has been agreed upon.
Rotation – Units are to be equitably distributed across days and across times. If trading partners have concerns about the meaning of “equitable”, the agreed upon definition should be written into the trading partner agreement.
Run of Schedule – No equitable distribution requirements. The units may air anytime within the program parameters.
Program / Time Buy – Determines whether program or time are the key factors in the purchase.
Program – Units are to move with the program should the program be moved to a different time period.
Time – Units remain in the specified time period, even if the program moves to a different time period.
Non-Paid Status – For zero cost units.
Audience Deficiency Units – These no-cost units are added to the deal to make up for a prior under-delivery. ADU units do not typically appear in the initial transmission of a deal. If the Non-Paid Status is set to ADU, then the quarter that the under-delivery occurred may be specified in a subsequent segment. The estimated impressions for ADU units should not be used for CPM calculations because the original estimated demographics are not adjusted.
Bonus Units – Bonus units are given to the agency by the cable network with no obligation. Impressions are in addition to any guarantee, and should not be used in CPM calculations.
No Charge Units – These units have no charge, but do count toward CPM calculations.
Recapturable Units – Recapturable units are included to define the program and/or time where units will air if necessary to make up for under-delivery. As such, they do not count toward CPM calculations.
Sales Type – Some programs can air in multiple date/time slots. If these are non-contiguous date/time slots, the sales type is set. It serves primarily as a mechanism to aid in mapping to alert the EDI programmer to expect multiple dates and times in multiple DTM segments. An example would be an all day live event that will be interrupted at fixed times for news reports.
Exclusivity Indicator – This is set if the network is guaranteeing that the advertiser will be the only advertiser in its product category in the program where this unit will be aired.
National / Local Indicator –
National – (Default) The units will air on the program nationally.
Regional – The units will only appear in certain regions of the country.
Local – The units will only appear locally.
TBD Indicator –This code is set to allow a unit to be purchased before the actual date and time of a unit are determined. For example, the exact date and time for sports playoffs are typically not set until the teams are decided.
Selling Network / Broadcast Network – These fields allow units to be sold by one network, yet air on another network. This typically occurs when one company controls multiple networks and events may be switched between networks based on popularity and schedule conflicts.
Preemptable – This is set if the unit may be preempted without a need for a makegood. This is typically used for Direct Response units where units are only aired if they are not otherwise sold.
Bookend – This is set if the unit is to be aired as part of a bookend.
Contract Number – Some agency systems are contract based and require the network to identify the agency specified contract number to which each unit belongs. The preferred method is for the agency to assign the contract number as part of their EDI mapping process since the contract number has no meaning to the network. This is used for the initial transmission of the deal only (i.e. not used for deal retransmissions and deal changes).
Daypart Code – The network’s daypart code for the time of day that the unit airs. There is no industry standard list of daypart codes.
Estimate Code – Some agency systems are estimate based and require the network to identify the agency specified estimate code to which each unit belongs. The preferred method is for the agency to assign the estimate code as part of their EDI mapping process since the estimate code has no meaning to the network.
Package Code – Some agency systems are package based and require the network to identify the agency specified package code to which each unit belongs. The preferred method is for the agency to assign the package code as part of their EDI mapping process since the package code has no meaning to the network.
Program Start / End Time – There can be multiple DTM program start and end times for a program with non-contiguous time slots. If a program is mirrored, the start and end times of the mirror are reflected. Times are sent according to a standard clock, it is the agency’s responsibility to convert these to the “30-hour” clock if needed. For example a unit identified as airing at 5 a.m. (0500) on December 10th, actually airs the morning of December 11th. According to the standard 30 hour broadcast clock, this is actually 2900 on December 10th.
Example : An hour-long program airs at 10 p.m. and is mirrored at 7 a.m.
DTM*196**2200
DTM*197**2300
DTM*154**0700
DTM*155**0800
ADU Period – If the units are ADU units, a date may be included to indicate the quarter to which these ADU units apply.
Incumbency Period – If present, indicates that the agency has until the specified date to retain the rights for the same program in the following year.
Comment – Line level comments are allowed but their use is discouraged. In no case should the comment field be used to convey machine processable information.
Serial Number – The serial number is required to transmit deal changes for the deal. It is optional, but still highly recommended if deal changes are not going to be transmitted electronically.
Brand Codes – The brand code is typically assigned by the agency during brand allocation and does not usually appear on the initial deal. However, in some cases, this may be filled in by the network. The brand code will also appear on deal retransmissions after brand allocation has begun. In cases where multiple brands are piggybacked, each brand is listed along with the number of seconds that this brand occupies.
Secondary Serial Number – The SI segment is used for billboards and mirrors. In the serialized world, each billboard and mirror should have its own serial number. There is a SI segment within the SLN loop for each mirror and billboard, up to a maximum of 3 (if the unit has a billboard, mirrored unit and mirrored billboard).
Episode Title – The network can optionally send additional episode specific information in this alphanumeric field.
Demographics – The ADV segment is used to send specific estimated demographics for each unit. These are the estimated demographics used to calculate the initial deal CPM. Naturally, estimates will change as the air-date gets closer, however, the network will not send new estimated demographics. Ideally, the deal retransmission will maintain the original estimates, and added units will have demographics roughly equivalent to those they are replacing. However, they should not be expected to be an exact match. There will be a separate ADV segment for each demographic being reported. The guaranteed demographic must always be reported. Each unit in the deal must report the same demographics.
Schedule Date – The currently scheduled date that this unit is scheduled to run. This is typically the date of the Monday of the week that the unit is scheduled to run. In some cases it may be the actual run date.
Total Units, Billboards, Dollars – These are the transmission totals used for verifying that there were no transmission or system errors. In most cases, these will match the total number of units reported in the heading section of the 850. However, if the 850 is being used for sending a partial deal, these totals will differ from those in the heading section.
The deal acknowledgment is a simple transaction. It is used to accept or reject an 850 that has been previously transmitted. Only a few segments and elements in the header section are used in the TECC specification. The Detail and Summary sections of the 855 are not used at all. The header identifies the deal that the deal acknowledgment is responding to and indicates acceptance or rejection.
Click here to view the version 3.0 TECC 855 specification
Deal Number – This is the network assigned deal number for the deal that is being acknowledged.
Sender Date / Time – This is the sender date and time that was included in the deal that is being acknowledged. This will identify the specific deal transmission in the rare case where the network sent a deal retransmission before the agency has acknowledged the original transmission.
Transaction Set Purpose - Approval or Rejection
Comments – If the deal is rejected, the reason for the rejection can optionally be included in a comment.
The heading section of the 810 is used to convey information about the buyer and seller and also to indicate the deal that this invoice represents. A unique, network assigned invoice number is used to distinguish this invoice from other invoices.
The detail section gives information about each unit aired during the invoice period. The invoice must contain enough unit level detail to uniquely identify each unit because the invoice must be able to handle non-serialized as well as serialized units. The invoice also serves as an affidavit, so additional information is included on the invoice that would not typically be found on invoices in other industries. For example, no cost and pre-empted units are typically still listed on the invoice, even though they have no financial impact.
The summary section is used to give transmission totals and is primarily intended as a check to ensure that no errors occurred in producing the transaction or in transmission.
Click here to view the version 3.0 TECC 810 specification
Note: This is a large document and may take awhile to download.
Deal Number – This optional field is required if using unit serialization. Even if serial numbers are not being used, the deal number is extremely valuable because it identifies the deal to which this invoice belongs. Without it, manual intervention is required to link the invoice to the appropriate deal.
Revision Number, Purpose Code – The release number and purpose code are used for re-issuing invoices. If an invoice must be changed after the initial transmission (this should be very rare), then the original invoice must be deleted and a new invoice re-issued. The release number identifies the version number of the invoice. Release numbers begin with 0. To delete an invoice, an empty 810 is sent with the invoice number and release number of the original and the purpose code set to delete. For example, the following three 810s would be used to send an invoice and to replace it with a re-issued version:
|
Invoice Number |
Release Number |
Purpose Code |
Comment |
|
1234 |
0 |
00 – Original |
Original invoice |
|
1234 |
0 |
03 – Delete |
Delete the original invoice |
|
1234 |
1 |
00 – Original |
Reissue the invoice |
Invoice Comments and Warranty Statements – The 810 invoice includes a place for comments. However, comments should be used sparingly if at all and should never be used to transmit meaningful computer processable information about the invoice. Legal language and terms should be handled via a trading partner agreement, not via the 810 invoice.
Network Code – A unique code for the selling network. The cable network defines these codes, however it is common (and preferred) practice to use the standard network codes defined by A.C. Nielsen.
Invoice Period Start / End Dates – All units included in the invoice should have dates within the invoice period start and end dates.
Serial Number – This is a required field if unit serialization is being used. Its use is recommended for any network capable of generating serialized units, even if deal changes are not being transmitted electronically.
Unit Price – This is the cost invoiced for the specified unit. Note that some zero cost units may be included on the invoice.
Call Sign for Broadcasting Network – Units sold by a particular network, may, in some cases actually air on a different network. In this case, this field contains the network where the unit actually airs.
Air Date / Time – This identifies the date and time that a unit actually airs. This serves as an affidavit that the unit was aired.
ISCI Code – This identifies the ISCI code for the copy that aired for this unit. This serves as an affidavit that this was the actual copy that was aired.
Total Gross Dollars – This is the sum of the unit prices for each unit on the invoice.
The 860 transaction set is very similar to the 850 used for the original deal. With the exception of mandatory information and some basic information used to identify the deal to which this change relates, only the data being changed is transmitted as part of the 860. If a segment contains multiple optional fields, only those fields for which values are supplied are considered to be changed. If a field is mandatory, then a value must be assigned. If no changes to the mandatory field are desired, then the original value must be retransmitted.
The 860 is used for all changes as well as for brand allocations and traffic instructions. This section includes a note on the usage differences for brand allocations and traffic instructions.
The heading section is used to change information corresponding to the overall parameters of the deal and to change contact information. The deal identification fields (deal number, revision number, sender date, sender time) are filled in for all 860’s to identify the deal to which these changes apply. All other fields should be filled only if they are reflecting a change.
The detail section is used to make changes to individual units. All units must be identified by serial number. The Change Type Code determines the type of change. All other fields should only be filled in if they are reflecting a change.
The summary section contains summary information about the number of changes being transmitted and is primarily used as a check to ensure that no errors occurred in producing the transaction or in transmission.
Click here to view the version 3.0 TECC 860 specification
Note: This is a large document and may take awhile to download.
Deal Number, Revision Number – These required fields identify the 850 that is the basis for these modifications. Note that there is no place to indicate whether or not previous 860’s have been applied to the original 850.
Sender Date / Time – This is the date that the transaction was created by the sender’s system. This can either be the time that the information was extracted from the MIS system (e.g. when the flat-file was generated), or the time that the information was processed by the EDI system. While both are allowed, the former is preferred because that will be more useful for resolving synchronization conflicts. This field is essential because it is used to distinguish one 860 from another.
Serial Number – Identifies the unit to which the changes are being made. In the case of a unit being added, this should be a new unique serial number. For all other changes, the serial number is essential to identify the unit being changed.
Change Type Code – Specifies the type of change for this unit.
QI : Quantity Increase – Indicates that this is a new unit with a new serial number. All of the detail for this unit must be provided in subsequent segments. In this case all of the rules for the 850 apply to the data being supplied for this new unit (i.e. all fields that are mandatory in the 850 must be specified).
CA : Changes To Line Items – The serial number identifies an existing unit. Any data specified in the subsequent segments implies a change in value for this unit. (For example, to change an air-date, the new air-date is specified). All fields that are not specified will retain their original values. The SLN segment has an element which can be used to change a unit’s serial number.
QD : Quantity Decrease – This indicates that the unit identified by the serial number is deleted. A PO3 segment can be included to give reasons for the deletion. Otherwise, no other segments should occur in this instance of the POC loop. No further reference should be made to this serial number and it should never be re-used within the deal.
AI : Add Items – Adds a new linked unit to an existing serial number. In this case, an SI element with a new serial number is specified within the SLN loop.
DI : Delete Items – Deletes a linked unit from an existing serial number. In this case, an SI segment is included with the serial number of the linked unit to be deleted.
TI : Transfer Item – Transfers a linked unit from one serial number to another. In this case, the following data will look very similar to an AI transaction – adding a new linked unit. However, the serial number of the linked unit will be that of an already existing linked unit.
Example :
1. Change the start time of the unit with serial number 55 to 8 p.m.
2. Delete the unit with serial number 56.
3. Add a 5 second billboard with serial number 97 to the unit with serial number 57.
4. Delete billboard number 98 from unit number 58.
5. Move billboard 99 from unit number 59 to unit 60. (Note that serial number 59 is not transmitted, it can be assumed by the recipient from previous transmissions).
6. Change agency assigned serial number 900000000010 to serial number 101.
(1) POC*000000000055*CA
DTM*196**2000
(2) POC*000000000056*QD
(3) POC*000000000057*AI
SLN*000000000057**S
SI*AS*SE*BB*SN*000000000097
SAC*C**AS*BB*****03*05
POC*000000000058*DI
(4) SLN*000000000058**S
SI*AS*SE*BB*SN*000000000098
(5) POC*000000000060*TI
SLN*000000000060**S
SI*AS*SE*BB*SN*000000000099
(6) POC*900000000010*CA
SLN*900000000010*000000000101*S
Demographic Information (ADV segment) – Demographic information should only be transmitted for units being added. The demographics transmitted during the initial deal are the estimates on which the guarantee was based and therefore the original estimates should be retained.
NOTE ON TRAFFIC INSTRUCTIONS AND BRAND ALLOCATIONS
For traffic instructions and brand allocations without splits or combines, the only segments transmitted are the ST, BCH (Beginning Segment which identifies the deal), a POC segment for each unit for which traffic instructions or brand allocations are being transmitted (to identify the unit), and an SLN which provides the brand allocation and/or ISCI codes for the unit.
For brand allocation splits and combines, new units are created and the old units are deleted. If the total number of units is changed, this must also be specified in the header. For units being created (and thus replacing original units), all of the fields that were specified in the original unit should be transmitted with the new unit. For new units the agency must provide a temporary serial number (beginning with 9 in the most significant position to avoid a conflict with network assigned serial numbers). This number must be unique within the deal. It is good practice for an agency to never re-use a temporary serial number within the same deal.
The deal change acknowledgment is a simple transaction. It is used to accept or reject an 860 that has been previously transmitted. Only a few segments and elements in the header section are used in the TECC specification. The Detail and Summary sections of the 865 are not used at all. The header identifies the deal change to which it relates and indicates acceptance or rejection.
Click here to view the version 3.0 TECC 865 specification
Deal Number – This is the network assigned deal number for the 860 being acknowledged.
Sender Date / Time – This is the sender date and time that was included in the 860 being acknowledged. The sender date and time uniquely identifies the 860. This is the only way of knowing which 860 is being referenced.
Transaction Set Purpose - Approval / Rejection
Comments – If the deal is rejected, the reason for the rejection can optionally be included in a comment.
Functional acknowledgments are sent to acknowledge that a particular transaction set has been received. 997 transaction sets are never acknowledged to avoid an endless loop.
AAAA (American Association of Advertising
Agencies)
A national trade association for the advertising agency industry and a
participant in TECC standard development.
AAAA Code
An ID code assigned by the AAAA’s to its member adverting agencies that
uniquely identifies the agency.
Acceptance
An EDI or other transmission to inform the sender that a transaction conforms
to expectations and that it will be used as a basis for further transmissions.
Acknowledgment
An EDI transmission to inform the sender that a transaction has been received
without errors.
ADV Segment
An X12 segment designed by TECC specifically for the transmission of
demographic information.
Affidavit
A statement that verifies that commercials were aired on a cable network.
American Association
of Advertising Agencies (AAAA)
See AAAA
ASC X12
The national standard for the transmission of documents via EDI. See also DISA.
Also commonly referred to simply as X12.
The term is used to describe both the committee responsible for the
development of the standards, and the standards themselves.
Audience Deficiency
Unit (ADU)
A no-cost unit that is added to a deal to make up for under-delivery. The impressions are counted in guarantee
calculations.
Barter
An industry practice where advertising is exchanged for the right to sell or
use advertising on another network or medium.
This is not as common in network cable television advertising as it is
in other advertising media.
Billboard
A brief opening or closing sponsor identification announcement that is
associated with a unit. An example is:
“This program is brought to you by …..”.
Billboards must always be associated with a standard unit.
Bonus Unit
A no-cost unit that is part of a deal provided as a “bonus” to the
advertiser. The impressions are not
counted in guarantee calculations.
Bookend
The first and last position in the same commercial pod. This term is also used by TECC to describe
the Deal and Invoice transactions because they are the first and last
transactions in the flow of documents between network and agency.
Brand Allocation
The process where specific products are assigned to individual units within a
deal.
Broadcast Calendar
A technique that divides the typical calendar into months which always begin on
an Monday and end on a Sunday. A
broadcast month begins on the Monday before the first Sunday in the calendar
month. It ends on the last Sunday in
the month. (e.g. the broadcast month of
June 2000 begins on May 29th and ends on June 25th).
Broadcast Clock
A technique that defines the broadcast day as beginning at 6 a.m. and ending at
5:59 a.m. of the following calendar day.
This conforms to how viewers typically perceive programming. For example, late night programming that
begins after midnight is typically perceived as a continuation of the previous
calendar day’s schedule.
Broadcast Network
Defines the network on which a program will air.
Business Process
Standards
These are the business guidelines and rules that trading partners should adhere
to in order to trade according to the TECC standard. These were formerly known as the Rules of the Road.
Cabletelevision
Advertising Bureau (CAB)
A national trade association for the cable television industry. CAB has been a sponsor of the TECC
initiative.
Call Sign
An abbreviation that uniquely identifies a cable network (e.g. TBS).
Cancellation Rights
The rights to cancel units within a deal without penalty. Cancellation rights must be negotiated and
usually must be exercised by a specified date.
CPM
Cost Per Thousand. A method for
evaluating advertising schedules based on how much it costs to reach 1,000
people in the target demographic. CPM =
Cost / Impressions.
Combine
The process of combining two or more units into fewer units while maintaining
the same overall unit length. For
example, four 15-second units may be combined into two 30‑second
units. See also: Split.
Contract
Generically this describes any business agreement, thus a deal is a
contract. However, contract is also
used by some industry computer systems to describe a specific division of a
deal.
Copy
The industry term used to describe the actual commercial (e.g. the videotape)
that is aired.
Copy Instructions
See Traffic Instructions.
Data Element
An X12 term used to describe the atomic level items that are used to build a
segment. Data elements are analogous to
“fields” which are combined make up individual “records” (segments in X12
terminology). A sample data element is
“area code”.
Daypart
A standard time period for which advertising is sold. For example, the Prime-Time daypart may be defined as 8 to 11
p.m. weekdays. There is no single industry standard for dayparts, therefore the
daypart names and corresponding times may vary among trading partners.
Deal
The formal agreement between advertising agency and cable network for
advertising on the network for a given period of time and for a given
advertiser. The deal may not extend
beyond one year.
Deal Number
A number that uniquely identifies a deal within a network. A network should never re‑use a deal
number.
Demographic
The classification of an audience by social and economic characteristics. The categories defined by the A.C. Nielsen
company are those allowed as part of the TECC standard. Demographics are also called “demos” by
those within the industry.
Direct Response (DR)
Units where the station is paid based on how many sales are generated by the
advertisement.
DISA
– Data Interchange Standards Association
The non-profit organization responsible for administering and organizing the
ASC X12 standard.
Discrepancy
A difference between the deal and the actual airing of a given unit. Discrepancies typically occur due to
miscommunication, human error, or computer error.
DUNS Number
A unique identification code assigned by Dun & Bradstreet to uniquely
identify a company. This number is used
within the TECC standard to uniquely identify a trading partner.
EDI Coordinator
Describes the person responsible for managing the EDI implementation. This person must be familiar with both the
technical requirements of EDI and cable industry business rules and
processes. They are the point person to
contact in the case of any problems or questions regarding the EDI
implementation.
EDIFACT
A United Nations sponsored committee that is the international equivalent of
ASC X12. The EDIFACT standard is
supposed to eventually replace ASC X12, however it has been progressing at such
a slow rate that this now seems unlikely.
Electronic Commerce
(EC)
A term used to describe the generic exchange of business documents
electronically. Distinguished from EDI
in that EC is not tied to a particular technology (e.g. X12).
Electronic Data
Interchange (EDI)
The term used to describe the exchange of business documents
electronically. In most cases EDI
refers to the exchange of documents according to the ASC X12 standard.
Episode
Identifies a particular “episode” of a program. For example, the Dolphins vs. Patriots may be an episode of the
program “Sunday Night Football”.
Equivalenced
Impressions
A technique used to allocate impressions to units based on the length of a
commercial. Impressions are normalized
to a 30-second length. For example, if Nielsen reports that a
program receives 300,000 viewers, a 15 second unit in this program will be
treated as having 150,000 viewers, and a 60-second unit will be treated as
having 600,000 viewers. This is an important technique to keep guarantees
consistent when units are split and combined.
Estimate
An industry term used by some MIS systems to describe a specific group of units
within a deal.
Exclusivity
The situation where an advertiser is the only one in its product category
allowed to appear in a particular program or time period.
Event
A program that is based on a specific event that may not yet have a specific
day-time or the day-time subject to change.
(e.g. Game 4 of the World Series).
Flat-File
Describes a data format where all of the data is stored in a text file as
opposed to in a database. Flat-files
are commonly used in EDI as an intermediate step between an internal database
and the X12 format files. Most EDI
translators use flat-files as input and generate flat-files as output. In the past, some flat-file formats were
passed between trading partners instead of X12 files and the term flat-file was
also used to describe these transmissions.
The TECC 1.0 standard defined an industry standard format for such
files. In the TECC 3.0 standard,
flat-files are for internal use only to aid the translation process and these
should never be used for transmission to other trading partners.
Flight
An industry term used to describe the range of dates in a deal.
Functional
Acknowledgment
The X12 transaction set (997) used to acknowledge all other transaction sets.
Guarantee
A requirement that the cable network deliver a specific CPM or total number of
impressions for a given deal.
Guarantee Guidelines
A break-out of the guarantee by date range, network, etc. These are used as guidelines in the
post-buy process to determine how well a network is doing in terms of meeting
the guarantee.
Impressions
An industry term used to describe the total number of viewers in a particular
demographic category who view a particular program. Impressions are often expressed in thousands (e.g. 300,000
viewers may be described as an impression of 300).
Incumbency
An industry term used to describe the rights to purchase advertising in a
particular program in the future.
Incumbency rights must be negotiated in advance and usually must be
exercised within a certain time period.
Interconnect
An EDI term used to describe the capability of a VAN to exchange EDI documents
with another VAN.
Invoice
The document used to bill an advertising agency for advertising that has aired
on its behalf. In the cable television
industry, invoices also serve as an affidavit and often provide additional
information about scheduled units that did not air. Invoices are typically generated for each broadcast month.
ISCI Code
An industry standard code used to uniquely identify the copy that will air in a
specific unit. ISCI code standards are
maintained by the American Association of Advertising Agencies (AAAA). The ISCI code uniquely identifies the
advertiser and the product as well as the specific commercial.
Log Files
Files generated by EDI application software detailing transmissions and
internal transactions. These are used
for debugging and to verify and audit the proper performance of the software.
Makegood
A unit (or group of units) that is added to a deal specifically to make up for
another unit (or group of units) that will not air.
Mapping
The X12 term used to describe the process of programming the translation
software to convert an internal flat file to / from an X12 transaction set.
Media Plan
The “master plan” made between an advertising agency and its advertiser client
in order to best achieve the advertiser’s goal. The media plan may cover all media (i.e. not just network cable
advertising) and will often include more than one cable network.
Mirrored Unit
A unit that airs with the same copy and pod position in a program that is repeated
in a different time period on the same broadcast day.
MIS System
A term used to describe the computer system that a trading partner uses to
manage its business. The MIS system for
a cable television network is often referred to as a Traffic and Billing
System.
NAD (Nielsen
Audience Demographic) Categories
Demographic categories that segment an audience beyond traditional age/gender
categories (e.g. income).
NTI (Nielsen
Television Index)
The A.C. Nielsen Company’s network and cable television ratings report. This report is used as the basis for all
guaranteed deals.
Opportunistic
A term used to describe deals that are not made during the upfront and that
typically concern unsold or returned inventory. See also Upfront, Scatter.
Orbit
A program that airs in non-contiguous time periods.
Over-Delivery
The industry term used to describe the situation where a deal is delivering
more impressions than originally estimated in the original deal. Cable networks try to avoid over-delivery
since they receive no additional revenue for the impressions that could have
otherwise been sold to other advertisers.
Package
An industry term used by some MIS systems to describe a specific group of units
within a deal.
Paperless
Describes the EDI process where paper documentation is no longer generated or
stored as back-up to the electronic communications.
Per Inquiry (PI)
Units where the station is paid a fee based on the number of inquiries or
purchases made in response to a specific airing of an advertisement.
Piggyback
Two different commercials that air within the same unit. See also: Tripleback.
Pod
An industry term for the cluster of units aired during a program break.
Post-Buy
The process of evaluating how a deal is performing in terms of meeting its
guarantee by evaluating actual impressions for units that have already aired.
Preemption
A unit that does not air within the parameters laid out in the original deal.
Program
A cable television show. Advertisers
typically buy advertising on a particular program in order to reach a specific
demographic.
Prototyping
An EDI term used to describe the process of sending test transactions before
proceeding with live data. Prototyping
should be done whenever a new trading partner or transaction set is added, or
whenever significant changes are made to the EDI infrastructure.
Purchase Order
The X12 Purchase Order transaction set is used for the transmission of cable
television deals. Some trading partners
may thus refer to a deal as a Purchase Order.
Rating
A method of expressing impressions as a percentage of the total television
viewing population. Although ratings
are allowed in the TECC standard, ratings are seldom used in cable television
advertising.
Recapturable Units
(Recaps)
Inventory scheduled for potential under-delivery that can be recovered by the
cable network if the under-delivery does not occur. (Recapture requires the consent of both parties).
Rotation
The equitable distribution of units across day and time parameters as agreed to
by trading partners.
Rules of the Road
An old TECC term for the industry Business Process Standards. These are the business rules (as opposed to
technical rules) that must be followed in order to do business according to the
TECC standards.
Run of Schedule
(ROS)
A distribution of units which conforms to the parameters of the unit, but which
otherwise has no requirement of equitable distribution across day and time
parameters.
Scaleable EDI
A TECC term used to describe the concept of having the same standard support
both serialized and non-serialized trading.
Scatter
A term used to describe units purchased at other times than during the upfront
season. These buys are usually made for
a shorter period of time than upfront buys.
See also: Upfront, Opportunistic
Segment
An X12 term used to define a “record” in the X12 transaction set. The segment consists of related data
elements. Multiple segments are
concatenated to make a full transaction set.
A sample segment is “geographic location”.
Selling Network
The network responsible for selling the specific unit. In some cases, a network may sell units that
will ultimately air on another network.
Serialization
The assignment of a unique serial number to each unit. It is used to uniquely identify the unit
within the deal throughout the life of the buy. Serial numbers must be unique within the deal.
Split
The process of transforming one unit into two or more units while maintaining
the same overall unit length. For
example, one 30-second unit may be split into two 15-second units. See also: Combine.
Stewardship
The process of managing a deal once units have begun to air.
Synchronization
The process where the internal computer systems of the agency and cable network
reflect the same information about the units and parameters that comprise a
deal.
TECC – The
Electronic Commerce Cable Committee
The group of cable networks. advertising agencies and vendors responsible for
the development and maintenance of the industry EDI standards.
30-hour Clock
A method often used to avoid ambiguities and aid computer processing of the
broadcast clock. This method uses the
familiar military time format, but adds 24 to the time periods between midnight
and 6 a.m. Thus, 2 a.m. is written as 2600
according to the 30-hour clock (instead of 0200 as in military time). The X12 standard does not support the
30-hour clock. Trading partners who use
the 30-hour clock internally must convert it to standard military time in order
to trade via the TECC standard.
Trade Deal
Describes a deal where units are given to an agency in exchange for other
services or products in lieu of cash.
Traffic
The industry term used to describe the process of scheduling and administering
the airing of commercials.
Traffic and Billing
System
The industry term often used to describe a cable network’s MIS system.
Traffic Instructions
The document that assigns specific commercial copy (i.e. an ISCI code) to a
particular unit. Also called Copy
Instructions.
Transaction Set
The X12 term describing related data that is the equivalent of a paper document
(e.g. an Invoice or Purchase Order).
Translation
The EDI term used to describe the conversion of data to / from an internal
representation from / to an X12 document.
Translation Tables
The EDI term used to describe the data tables that are often used by EDI translators
to convert a flat file to / from an X12 transaction set.
Tripleback
Three different commercials that air within the same unit. See also: Piggyback.
Under-Delivery
The industry term used to describe the situation where a deal is not delivering
as many impressions as estimated in the original deal. In such cases, cable networks must generally
provide ADU units to bring the impressions in line with the guarantee.
Upfront
The period in which most deals are agreed upon. Upfront deals typically cover an entire broadcast year. See also: Scatter, Opportunistic.
Unit
An industry term describing a placeholder for a commercial that is used as the
basic unit of trade for network cable television deals.
Validation
The process of ensuring that an EDI transmission conforms to all TECC and X12
rules. Thorough validation minimizes
the risks of errors getting into one’s internal computer system and helps the
industry police itself to ensure that variations to the standard do not
proliferate.
VAN – Value Added
Network
A company that provides the communication infrastructure to send and receive
X12 transactions to / from other trading partners.
VPVH – Viewers per
Viewing Household
A method to define impressions based on the number of households capable of
receiving the program. Although part of
the TECC standard, VPVH’s are rarely used.
This is often abbreviated as VPH.
X12
The national standard for the transmission of documents via EDI. See also DISA. Also more formally referred to as ASC X12. The term is used to describe both the
committee responsible for the development of the standards, and the standards
themselves.
Implementation Committee Members
For your reference, a list of vendors has been included here. Inclusion here does not constitute an endorsement by TECC.
Cabletelevision Advertising Bureau
This document was written by Evan Schapiro of Meerkat Technology on behalf of the Cabletelevision Advertising Bureau. It was made possible by the numerous hours of hard work that TECC committee members have volunteered over the years. This Implementation Guide would not have been possible without Scott Lowe’s dedication and guidance.
All current and past members of the TECC Design Committee and other TECC committees have contributed to the creation and continued improvement of the TECC standard. As co-chairs of the TECC Design Committee during the core work of creating the version 3.0 standard, Helene Sperling and Elizabeth Hobby deserve special recognition.
Helen Tocheff provided valuable input that greatly improved the business process section of this document.