In Attendance:

Phil Antonson (@media), Gloria Arias (DDB), Mary Ann Avery (Fox Family), Elizabeth Carr (MTV), Warren Chin (CJDS), Judith Cruz-Lancaon (Fox Family), Anthony D’Arrigo (A&E), Jim Diederich (Grey), Wendy Eagle (Discovery), Hal Engelke (CJDS), Jennifer Franchere (ESPN), Pat George (DDS), Sara Ghasletwala (E!/STYLE.), Larry Gilbert (DDS), Elizabeth Hobby (Discovery), Erhan Hosca (Turner), Karen Kaplan (TN Media), Steve Kaye (DDS), Ron Levy (Datatech), Scott Lowe (CAB), David Miller (Comedy Central), Kumar Natesan (MTV), Evan Schapiro (Meerkat), Bobby Shapiro (E!/STYLE.), Helene Sperling via phone (Carat),

Unable to Attend:

Bart Brassil (Donovan), Ed Hausser (Starcom), Dan Hawks (ESPN), Mona Kay (A&E), Trish Lemley (Turner), Sunny Singh (Edifecs), Jim Thompson (MediaVest) and Patricia Watson (DMB&B)

Upcoming Meetings:

TBD

Agenda:

At the beginning of the meeting, it was announced that Jim Diederich has taken on the role of Design Committee co-chair from Helene Sperling.

Version 3.0 Mapping Issues

The entire meeting was devoted to addressing the issues raised by Warren Lamb in a letter to Jim Diederich dated September 22, 1999 (attached). Each of his issues along with Design Committee responses/resolutions to these issues are listed below:

We assume the new description codes for Guarantee CPM (GC), Guideline Rating (GR) and other values can be derived from the data elements placement in the TECC v1 contract flat file format. For instance, the code for Estimated Impressions (EI), describes the impression values found in the LA record in TECC v1 flat file. Is this assumption correct for all new codes (i.e., GC, GI, GR, LC, LI, LR, EI, ER, EV)?

We did not deal with this issue but agreed that we should have another meeting to discuss 850 issues.

Map unmapped field, "Number of Spots", in ISS01

Since the ISS segment has a looping structure, it was suggested that there be a separate loop for each unit type. In this case ISS02 would be BB for billboards, UN for units, FE for features (using the codes in IT109) and ISS01 would be the count for that particular type of unit. The CAB will revise the ISS segment (ISS02) to include BB for billboards and FE for features. The user notes for ISS01 will also be changed from "Number of serial numbers included on this invoice." to "Number of serial numbers for billboards, features, or units included on this invoice."

Reconciliation Remarks not mapped in TECC v3

The committee felt that this item, along with several other informational data items, were not needed in an electronic document. This issue generated a great deal of philosophic discussion but most committee members agreed that only data essential for processing an invoice should be sent electronically.

Billboard Information in Record 51 now separated out in TECC v3. This will require additional system programming to produce new flat file records.

Unlike v1.0, the v3.0 mapping is not cognizant of a flat file. It is the responsibility of the receiving parties to reconfigure the data into their applications.

Map unmapped field, "Agency Commission", in TDS02 (pg.39)

No, see # 2 above.

Map unmapped field, "Agency Estimate Code", like in TECC v1 (p141)

No, see # 2 above.

Create new REF segment to contain the following fields: "Product Name" (p169), "Agency Product Code" (p171), "Network Product Code" (p170).

For Agency Product Code and Network Product Code, see # 2 above. However, it was agreed that the Product Name could be sent, but at the unit level since invoicing may be done by single product or for multiple products. Obviously if an invoice has the same product for every unit it must be a "brand" invoice, but again, it is the responsibility of the receiving party to determine this.

Rather than using a new REF segment as suggested in Warren Lamb’s letter, we propose using the IT1 segment (IT111 and IT112) to identify the Product Name. Any comments? The CAB will revise the IT1 segment for inclusion of the Product Name by unit assuming that committee members do not have a problem with this.

Assume field, "Station Name" is the same as "Network Description" in TECC v3 (p8).

Yes, this is correct.

 

The following fields are not mapped in TECC v3: "Contract Number", "Station Order Name", and all personnel contact names (buyer, station, etc.).

Yes, they are not mapped. See #2 above.

Recommend giving TECC v1 option in TECC v3 for addresses. In other words, do not need to use the N4 segment.

Not mapping the N4 segment in v1.0 was a mistake and it was felt that a mistake shouldn’t be perpetuated so the N4 segment should remain in v3.0.

Map unmapped field, "Broadcast Month", in DTM segment as in TECC v1.

The Broadcast Month can be determined from the period start and end dates of the invoice. See DTM code 186 (Invoice Period Start) and DTM code 187 (Invoice Period End).

Recommend moving field, "Due Date", to ITD segment in TECC v3.

Since ITD06 is described as "Net Due Date" it was felt that this is where the due date should remain mapped.

Need confirmation and reason that record 41 in the DDS invoice station format is not mapped in TECC v3.

Again, the feeling is that it is not the responsibility of the v3.0 mapping to accommodate a specific flat file format since the ultimate goal of v3.0 is to be a unit-based, not a line-based implementation. The application can group individual unit items into a line item record but that is the responsibility of the receiving party.

IT1 segment in TECC v3 needs a makegood Id.

The consensus of the committee is that an invoiced unit’s status as a makegood is irrelevant as long as the unit matches the agencies buy file. Administering makegoods is not in the purview of an invoice.

A new field for TECC v3, "ISCI Media Type", is mapped to a mandatory X12 data element. Many traffic systems do not carry this information and many cable networks assume that advertising agencies will be able to determine or derive the media type from their own ISCI codes that are carried in the invoice. We recommend defining a default value (like, "V", for video) that can be used or mapping this field to an optional X12 data element.

It was suggested that an additional code of ‘U’ be used for undefined media types. The CAB will add Unknown (code U) as an ISCI type to SLN01.

What is a warranty number in TECC v3 (p24)? Usually these are standard comments only available in the invoice paper form, not available on many traffic systems. Currently, assume the N9 segment in TECC v3 (p24) contains warranty information from record 25 in the DDS flat file station format.

The warranty number is meaningless. It is merely in this segment so the conditional MSG segment that follows can be used. It can contain any number but the suggestion is that it always be a 1. The CAB will indicate that 1 should be used for the warranty number in the user notes for the N902

Need a glossary or term definitions for new data element names used in TECC v3 standards.

This will be put on the CAB website by the end of 1999 as part of the v3.0 Startup Guide for EDI Implementation (SAGE).

Even though the use of 24 hour military time for a 30 hour Nielsen Broadcast Clock will work with pre- and post-processing of time calculations, the EDI transactions will no longer truly represent the order and invoice carried within the buyer and seller’s business systems. This may cause discrepancies where previously none ever existed in the industry.

We will continue using an X12 "time" field for this data. To use an untraditional clock would mean mapping to some other type of field. The receiving party’s application should convert this data to the proper Nielsen clock format.

TECC v3 requires serial numbers with spot and billboard information. Most cable network systems do not export these numbers, do not support the TECC definition or do not have them. To meet this mandatory requirement in TECC v3, serial number information will be arbitrarily defined by the EDI process at a cable network. These serial numbers are not reflected in the cable network’s traffic or proposal systems. Therefore, they cannot be used by an advertising agency in any communication back to the network whether in electronic or hardcopy/paper form. As with the 30 hour clock problem mentioned above, the use of mandatory serial numbers in EDI means that these transactions do not reflect internal traffic/proposal system information. This may cause discrepancies.

If the data being sent using v3.0 is not serialized, fill the serial number fields with zeros. In this case, although the serial number is "mandatory" in v3.0, it does not have to be "meaningful". The CAB will indicate this in the IT101 user notes.

Scaleable EDI & the v3.0 810

During the discussion of Warren Lamb’s issues, there was considerable contention regarding moving forward with the v3.0 810 or allowing either the use of v1.0 for those who cannot serialize yet or revising v3.0 to include a lot of the information contained on v1.0. It was agreed that we should move forward with the v3.0 invoice without including information that is not needed for electronic processing. There are advantages for the industry as a whole in adopting one standard that will allow you to receive the benefits of serialization when you are ready to do so. This is in conformance with the concept of Scaleable EDI.

Also Noted

Design Committee members were asked to look over the EDI FAQ’s on the CAB website and advise the CAB of any comments or suggestions. Revised FAQ’s will be included in the Startup Guide for EDI Implementation (SAGE) to be posted on the CAB website around the end of the year.

Version 3.0 Update

Due to time constraints, we did not get a chance to discuss agency and network v3.0 implementation progress.