Guest Article: MAKING CHANGES TO MAIL.DAT FILES
This is the first of a series of articles which will provide mailers with insight into techniques to manipulate Mail.dat® files to better represent the mailings presented the U.S. Postal Service®. What is described can be performed with commercial post-presort editing products. Readers will need to have some familiarity with the basics of the Mail.dat file specification.
MERGING MAIL.DAT FILES
This article describes why a mailer would merge multiple Mail.dat files to create a single Mail.dat file. Post-presort editing programs have this capability and provide different options to control the content of the merged files.
Why Merge Mail.dat files?
There are four common reasons mailers will merge Mail.dat files:
- Your USPS® Acceptance Clerk wants to do fewer verifications of mail with the similar characteristics and get fewer postage statements
- You want to palletize multiple versions of a job together (Copal). Each version initially has its own Mail.dat file.
- Copalletize mail from multiple jobs (DMU required) using tray-based OCI Copal
- Consolidate data from multiple jobs for reporting or analytical purposes
There are things you should know about how different merge options will impact verification and how your eDocs will look to the USPS. You must never, ever send any of the Mail.dat files you are going to merge to PostalOne!® individually. If so, these jobs have to be canceled before you submit the merged file.
Segmentation
A segment record in Mail.dat can represent a different version of a mail piece, a different production run and/or a different presort qualification. Most Mail.dat files that describe a single version have a single segment. When you merge them together you can create a Mail.dat file with either a single or multiple segments. If your merged file has multiple segments each representing a segment in the original Mail.dat files), PostalOne! will create separate qualification reports for each but a single consolidated statement. This can reduce the amount of time it takes a mail clerk to verify jobs with multiple versions. If your merged file has only one segment, the USPS will see it as a single job with one qualification report and statement. You should discuss this with your mail clerks because the presort will look odd. You may have multiple trays that ordinarily would appear as a single tray in a single presort. All traces of the original presort qualifications on the original jobs will be gone and replaced by single qualification report that reflects the combination of the original jobs but after trays are created.
Copalletization
If you are producing multiple versions of the same job and have the ability to place the resulting tray on the same set of pallets, you can palletize the trays after the Mail.dat files are merged and present the mailing as a single job. This is not the same thing as tray based OCI copal described next, but you can have these pallets verified at Business Mail Entry Unit (BMEU) or a Detached Mail Unit (DMU). Besides the difficulty of producing the trays and combining them onto the same set of pallets, you must be careful that none of the versions is only partially mailed. If the job cannot be mailed in its entirety when the other versions are mailed, you must split out the mailed and unmailed portions into separate Mail.dat files then include only the mailed portion in your merge file.
Tray Based OCI Copalletization (Internal)
It is possible to copalletize the mail from multiple jobs and typically the merge process is used to make this possible. To do this, you must have a Detached Mail Unit (DMU) verifying your mail and you must be approved by the USPS to do this. This is a two step workflow. The first step involves submitting Mail.dat files to PostalOne! for payment as each job is produced. You would not have pallet records in these Mail.dat files and each tray must have the “Included in Other Docs” field set to the value “I” (letter I). Later when you know exactly which jobs were mailed that day, you will merge the files together but the merge program must create or populate an “Original Container Information” (OCI) file in Mail.dat which creates a cross reference between the trays and their original Job ID’s and the trays in this special Mail.dat file. This file would be palletized, placards printed and submitted to PostalOne!. Each of the trays in the original job must be paid for in PostalOne! though payment does not have to be finalized at this point. The timing on this is important because you have to know with 100% certainty which jobs are mailing that day early enough to do your merge so you can palletize and print placards.
Consolidating Data for Reporting Purposes
If you have report that report on the content of a single Mail.dat file, the merge program will allow those reports to reflect the content of multiple mail.dat files. The merging would take place after the original files have been paid for in PostalOne! and the merged files would never be uploaded to PostalOne!. They would just be used for reporting and analytics.
If you like to learn more about making changes to Mail.dat files or about PostalOne! eDocs in general, Window Book has frequent educational webinars on similar topic and also has a newsletter loaded with great tips and other information. Please visit us at www.windowbook.com to get on our e-mail list.
If you’re interested in more information on the latest trends in the postal industry, I invite you to subscribe to our monthly eNewsletter at http://www.windowbook.com/Learning
Lloyd Moss
VP of Premier Client Solutions
Window Book, Inc.
Lloyd Moss has worked for postal software vendors since 1991 and has assisted hundreds of mailers of all types. Lloyd helps clients with all avenues of process efficiency within the post-presort market including investigating their current systems and implementing recommended best practices mailing management solutions.
He also served as a subject matter advisor on U.S. Postal Service eDoc and Intelligent Mail® Full-Service projects for 3 years while at Accenture.
