Steven,

Worksheets are cheap. Put your footer on a new sheet all by itself. Format the sheets columns exactly like the sheet the footer gets pasted to, hidden and widths.

Do not use "Merge Cells. Use Webdings Font, lower case "c" for checkboxes.

Starting in cell "A1", design your footer as you like, include any empty border rows/columns all around.

Including "A1", select the entire footer with empty border cells. On the Excel Menu, Insert >> Name >> Define, Name the Selected Range "DocFooter." If you think you may ever want another footer, append a numeral to the name. Don't use "footer" as the name without 'pre-' or 'suf-' fixing something to it.

The code snippet above now becomes[VBA]Range("DocFooter").Copy Sheet1.Cells(dr + 1, 1) [/VBA]




Fortunately you have a working App "Live," so you can take some time to think about what you really need to do do make it a good one.

Structured Code Requires Structured Data.
Or; Someday You'll Want SQL.

Data Is For Code and Reports Are For People.
Or; Keep It Separate, Smarty.

Data is Forever, But Reports Are Kiss and Tell
Or; Intransient vs Transient.

Reports are forms and forms are reports. I use "Reports" for both except when talking about UserForms. for me, Form always means a (VBA) MS UserForm.

I'm going to refer to this Post: http://www.vbaexpress.com/forum/show...php?t=46847And this App:UserForm App.xls from that post.

The Post is to someone else who is designing their first App and the Download is an (incomplete) App I was making for someone. It contains in one book, a Report sheet, (transient data,) a Report Database, (permanent new data storage,) two value look up sheets, a Locations Sheet, (fixed data,) and a Data Entry Form definition sheet. The data structure and data retrieval code in it will be of interest to you.

Some Definitions for you:
Database = A group of Columns and Rows
Field Name = Column Label or column Range Name.
Field = A Column in a DB
Record = A Row in a DB
Record Field = One cell in a Record
Keys, primary and secondary = Unique values that identify unique records
Index = Key

From what you have said about your operation, it's a pretty good sized business. I would suggest that you consider putting Customer information in one DB with an Index number in Column A. The Index, or Primary Key is used to look up relevant records in other DBs. You can also have DB's for employees, product codes, locations, (by product code Index,) and Destinations. Any data that can be (semi-) permanently listed.

I realize that this post in Intense 'n Dense, so I'll check back in a few days.