This entry is rather wonkish. There are no funny stories. I just wanted to record the details while I could still remember them.

I gave our system the name “GrandAd”, but I doubt that anyone ever called it that. We were lucky if the users called it “TSI” rather than “Mike’s system” or “Sue’s system”. The original programs were designed to be run on a Datamaster with an external hard drive (described here). A few years later the system was converted to run on a System/36 (described here). We also converted it to run on an AS/400 (described here).

In the early eighties, administrative software systems generally fell into two categories: BICARSA (Billing, Inventory Control, Accounts Receivable, Sales Analysis) and GLAPPR (General Ledger, Accounts Payable, Payroll). Accounts Receivable was abbreviated as A/R. The GLAPPR modules were abbreviated as G/L, A/P, and P/R)..

GrandAd contained versions of all of these modules except payroll. I don’t remember even one of our agency clients using TSI’s payroll system. From an accounting perspective the distinctive features were that the GrandAd system had two separate methods of billing—media and other—that fed a rather standard accounts receivable system and a unique “media liability” module. The accounts payable system likewise had two separate sets of data entry programs, one for media vendors and one for others. If a bill from a media vendor included production charges, it could be entered in the media payables program after the media portion was completed.

None of the operating systems used by our customers distinguished between tables and data files, but our documentation usually did. In our parlance a table was maintainable by the users through simple editing. Data files could only be maintained through transactions that always created auditable detail records. Transactions were also usually entered in batches that updated the data files all at once. Changes made to items in tables took place immediately. Some important tables contained a few fields that could not be edited by the users. For example the G/L master file contained thirteen fields for the amounts for each month and adjustments. These fields could only be updated by transactions.

Every table had a unique key. The open item files for A/R, A/P, and media liability also had unique keys, as did the file with job costs by category and the media detail table. Detail files for transactions either had no key or keys that were not unique.

There was also one record-oriented specs table that TSI did not tell users about. We maintained this ourselves. It contained things like the agency’s name and address and a large number of “switches”, mostly binary Y/N designations that indicated whether the agency used optional features or the manner in which it used them.

Here were the principal tables, at least as I remember them:

• Client: The key was a three-digit number. There was a field on this table for an “associated” client number to handle those cases where one company owned several semi-independent entities. Client #10 was usually used for in-house jobs and #11 for one-shot projects.
• Job Type: The key was a two-digit number.
• Job: The key was the client number plus a three digit-job number. The numbers could be assigned by the system. A few agencies had their own job numbering system. We kept this number as a twenty-character reference number. In general, 90000 was used for media billings. Every job was assigned a job type.
• Job Cost Categories: The cost categories also had three digit keys. The categories were of three principal types: time, agency-owned materials, and vendor costs. The entries in the time categories consisted of hours worked on a job. The entries in the materials categories were dollar amounts. The vendor costs came from the accounts payable system.
• Employee: The key was a three-character code. Initials were usually used here.
• Rate: The key consisted of the employee code and the category number. It might also have had a date to allow rates to keep up with inflation.
• Vendor: Vendors were keyed by a five character code and a two-digit location number. Checks were always cut to the name and address on location #0.
• Media Type: A two digit code identified types of media—radio, television, magazine, newspaper, mailing house, yellow pages, etc.
• Pub: Like the vendors, pubs were identified by a five character code and a two-digit number (usually 0). Every pub was associated with one vendor and had one media type. A vendor could have any number of pubs associated with it. Although the name “pub” was derived from “publication”, this table was also used for other media entities.
• Media Ad: The key was the client number, a five-digit ad number, and a one-character version code (usually blank). The ad number was usually the production job number, but it could be something else.
• Media Schedule: The key was the media ad key plus the pub key plus the date in the form YYMMDD and a two-digit number to preserve uniqueness. The last field was necessary because the same ad could be run more than once on the same day in the same publication or station. Three costs were stored on each record: net (the amount the agency paid the vendor), gross (net plus agency commission), and charge (the amount the client would pay).

The system provided for the following types of transactions:

• Menus specific to each type of transaction allowed for recording of new items, editing or (at least deleting) of items entered but not updated, printouts of the contents of the batch, and updating of data files.
  • Production and fee billing. Invoices could be printed on special multi-part forms or just recorded. The update program created records on the A/R detail file. Summary records on the job file were updated and entries were created in the batch file for the G/L system.
  • Media billing: Detail was selected from the media schedule. The update program created records on the A/R detail file, media liability records, and G/L batch entries. Summary records on the job file were updated.
  • Media payables: The update filled in the amount relieved on media liability records and created A/P Detail records and G/L batch entries. YTD spending on the vendor table was updated.
  • Other payables: The update created G/L batch entries. YTD spending on the vendor table was updated. For production costs job cost detail records were written and the job-to-date costs on the job file and job cost summary file were updated.
  • Checks: Invoices from vendors could be selected for payment in various ways. The update program wrote A/P detail records and entries for the G/L batch.
  • General ledger: Entries were generated by other modules, but they could also be entered one at a time. The update program wrote out journal entries and updated the monthly totals by account.
• Live entries:
  • Cash receipts: The program to record cash received from clients updated paid amounts on open A/R items, and cash received month-to-date and year-to-date on the client table. It also wrote out A/R detail records and batch entries for the general ledger.
  • Individual disbursements: This program was used for partial payments, write-offs, and other A/P issues that were difficult to handle. It could also print checks, but that feature was seldom used by agencies.

The best thing about AdDept and also the worst thing was the month end reconciliation process. That is, it was the invaluable process that underscored the reliability of the data, but its vigor was still dreaded at the end of each month.

We provided the customers with checklists for what needed to be in agreement with what at the end of the month. For example, the total for the list of items in A/P must be the same as the balance in the A/P account in the G/L. If there were discrepancies, I showed the users the reporting tools to use to find the discrepancy and how to fix it. This could easily consume an entire day, and I often had to help them for two or three months before they understood what was causing the errors and how to fix them.

An account at one installation showed a discrepancy of only ten cents that we discovered was the result of three different errors, each of which was for more than $1,000.

I mostly dealt with the manager of the business office. However, I almost always sat down with one of the principals to go over the cost accounting report by client at least once. This report had columns for each source of income (media commissions, fees, billings for production jobs) and both direct and allocated expenses. A primary purpose of the reconciliation process was to insure that the total profit by client was the same as the total profit on the general ledger¹. I tried to make it clear that the allocation of indirect expenses was only as accurate as the timesheets. If some employees (media buyers, for example) were not reporting their time accurately, the accuracy would suffer.

I have no doubt that our competitors did a lot less for their customers. Some tried to support their clients without any on-site visits. Some partnered with locals to provide hand-holding. I feel sure that they must have had some unhappy customers.

We actually used parts of this same process in TSI’s office. An unintended benefit of this rigorous approach was that it was rather easy to catch embezzlers.

The system was not sexy. The screens were green, and the output was columnar. The first few months were frustrating and difficult for almost all users. However, in the end it always saved a lot of time and produced valuable information.

---

One of our agency clients told us that they used a PC-based system called Media Management Plus² to purchase broadcast commercials from radio and television stations and to evaluate the performance of the spots. We contacted Glenn DeKraker at the company in New Jersey. He told us that the software had several forms of files that it could produce to feed billing and accounting systems. We chose one of them, and wrote software on the System/36 (it would have been very difficult to do it on a Datamaster) to create records on the ads file in GrandAd’s media system from the records uploaded from the PC.

It worked smoothly from the beginning. We did not need to make any adjustments to our files at all. The users just needed to follow a simple convention when it came to naming the pubs. They had to use the call letters and a one-character code: A for AM, F for FM, and T for television.

This project taught us not to fear building interfaces with other software companies.

---

The original design of GrandAd was surprisingly stable, especially when the constraints under which we operated are considered. The screens supported nothing but text and had only 78 usable columns and 24 rows. The reports were limited to 132 characters on each line. The amount that could be stored on the hard drives was quite limited. If a customer ran out of room, the options were poor.

It was, thank goodness, never necessary to increase the size of any fields, although we had to pass on requests for proposals from two agencies. One was a New York agency that specialized in theatrical productions, each of which was a separate client, and a separate agency that specialized in want ads. Our biggest problem was in handling the version of the system that was used by TSI. When we started selling the AxN system to newspapers, The 999 clients allowed by the three-digit client number might not be sufficient. Besides, we did not want to intermingle the newspapers with our other clients. We decided to allow alphabetic characters in the client number field.

In retrospect we obviously should have used eight-digit dates from the beginning. We devoted countless hours in the late nineties to fixing this oversight.

---

1. Occasionally some G/L accounts, such as investment income, were excluded for this purpose.

2. In 2021 the company is now known as CoreMedia Systems. Its website is here.