PostalOne!® Mail dat Technical Guide Version 19 0 March 2009 preface

Key Technical Requirements

1. Internet Connection

2. Formatted Mailing Files

4. Methods of Transferring Files (Manual and Batch)

1. 
   Manual mode. In Manual mode, customers log on, select the files they want to send, and then upload them. This mode is called Manual because a person must actively use the PostalOne! system and be present while the file is transferred. The information presented in this chapter assumes you will make Manual mode file transfers to the system.
   
2. 
   Batch mode. Batch mode allows customers to schedule file transfers to take place automatically, for example at 2 a.m. Once Batch mode is set up, no one needs to be present when the file transfer takes place. This capability requires additional infrastructure and configuration work. If you plan to send files in Batch mode, see Chapter 3, Batch Processing.
   

2. Technical/Operational Prerequisites

This section provides details on all of the technical and operational prerequisites necessary to successfully send mailing data files to the system. Topical areas include:

1. 
   Hardware prerequisites. The base requirements for the hardware elements of the computer system that will access and send mailing data files to the PostalOne! system such as the recommended physical memory amounts. For more information on hardware prerequisites, see Section 2.2.1, Hardware.
   

3. 
   Software prerequisites. The base requirements for the software elements of the computer system that will access and send mailing data files to the PostalOne! system, such as browser software versions. For more information on software prerequisites, see Section 2.2.2, Software.
   
4. 
   Networking prerequisites. The base requirements for the networking elements of the computer system that will access and send mailing data files to the system, such as firewall settings. For more information on network prerequisites, see Section 2.2.3, Network.
   
5. 
   Mail.dat prerequisites. The base requirements for the actual files sent. The PostalOne! system complies with the Mail.dat File Specification. As a result, mailing files must comply with this specification and the exceptions noted in this guide. This document notes any instances where the PostalOne! system differs from the Mail.dat specification, and supersedes the specification in all such instances.. We strongly recommend that you obtain and read the specification. For more information, see Section 2.2.5, Information/Manuals.
   
6. 
   User License Code (ULC) prerequisites. To use Mail.dat, your company must have a ULC, also called a Provider Code. Business mailers using Mail.dat should already have a ULC; if not, they need to get one before continuing. For more information, see Section 2.2.6, User License Code.
   
7. 
   Optional digital certificate prerequisites. To send mailing files in Batch mode, your company must obtain and install a digital security certificate. For digital certificate requirements, see Section 2.2.7, Security Certificates and Chapter 3, Batch Processing.
   

1. Hardware

Table 3‑1. RAM Requirements Based on Net Job Size

For Mail.dat jobs with a large total file size, file transmission may result in an “Out of Memory” error. To resolve this issue, modify the Java™ Virtual Machine (JVM) memory arguments, then retry the transmission. For more information on how to modify the JVM memory settings, see Section 2.4.3 for manual mode, or Section 3.1.8 for batch mode.

2. Software

• 
  A text editor or third-party Mail.dat viewer. This software is necessary to analyze the contents of your Mail.dat files and resolve any file format or content problems reported by the PostalOne! system.
  
• 
  Microsoft Internet Explorer® 5.0 or later with the Java Virtual Machine (JVM) plug-in or Netscape® Communicator 6.0 or later with JVM plug-in. The JVM should be version 1.4.2 (see the next bullet). In the Internet Options dialog box, the Use Java x.x for check box must be selected on the Advanced tab.
  
  
  Because newer Microsoft operating systems (such as Windows® XP) no longer support some Java software, users with new installations of Microsoft operating systems must now install Sun Microsystems® Java Virtual Machine 1.4.2 or greater on their browsers. If you do not do this, the PostalOne! functions for file validation and manual file transfer will not work. The Batch Processor has a different requirement.
  
  To install the JVM, ensure you have administrator rights on your computer, then click the links on the Sun Microsystems site at: http://www.java.com/. If a security warning dialog box opens, click Yes to install, and follow any directions. If you do not have administrator rights, contact your system administrator. Once installed, the JVM automatically runs whenever necessary.

  For information about batch mode requirements, see Chapter 3, Batch Processing.

  
  

  3. Network

  
  The File Transfer software (Manual mode) uses http/https protocol to communicate through port 443. If firewall settings prevent http/https communication through port 443, reconfigure the firewall to allow this traffic. Port 443 is the standard port for https communication.

  The Batch Processor software uses the http/https protocol to communicate through port 444. If firewall settings prevent http/https communication through port 444, reconfigure the firewall to allow this traffic. See Chapter 3, Batch Processing.

  
  

  4. Infrastructure

  
  Because the PostalOne! system is Web-based, no infrastructure requirements exist other than the hardware and software previously discussed.
  

  5. Information/Manuals

  
  To ensure that you accurately configure your Mail.dat files, use this guide and the Mail.dat File Specification, Version 08-2. While the PostalOne! system also supports version 07-1 (history files only) and 08-1, the latest version is recommended. The Mail.dat File Specification is a key document from IDEAlliance. As a nonprofit organization, IDEAlliance charges a nominal fee for the file specification. The fee covers the costs of changes, updates, printing, and notifications to customers. If you do not have a current copy of the specification, contact IDEAlliance at (703) 837-1088 or download it online at http://www.idealliance.org/maildat/.

  IDEAlliance

  100 Daingerfield Rd., Fourth Floor

  Alexandria, VA 22314

  For technical support, contact the PostalOne! Customer Support team. See Section 4, Customer Support, for contact information.
  

  6. User License Code

  
  To participate in the PostalOne! program, obtain a valid User License Code (ULC) from IDEAlliance, who assigns a ULC to each Mail.dat user. The ULC uniquely identifies you to the Postal Service. Customers who generate, update, or pass along Mail.dat files for subsequent use must have a ULC.
  

  7. Security Certificates

  
  The PostalOne! system uses Secure Sockets Layer (SSL) Version 3.0 to transfer files safely over the Internet. SSL is a secure enhancement to the standard Transmission Control Protocol/Internet Protocol (TCP/IP). It uses a combination of cryptographic processes to authenticate the host computers, and to encrypt and decrypt data transferred between them.

  If you use the Manual mode file transfer process, the pre-installed VeriSign® client SSL certificate (included with the web browser) secures the file transmissions. No user setup is required for this process other than using the required web browser.

  If you use the Batch mode file transfer process, your company must have a SSL certificate installed and set up. For information about security certificates, see Section 3.1.6, Digital Certificates/Security.
  

  8. Collaboration

  
  For unresolved issues with Mail.dat files, the IDEAlliance Mail.dat Work Group collaborates with the Postal Service to find solutions for future releases. All Mail.dat licensees may participate in the Mail.dat Discussion Forum on the IDEAlliance collaborative Web site (http://pmstage.freecom.at/pmstage/). Topics of interest include:
  

  • 
    Handling for Periodical container charges
    
  • 
    Firm bundles and non-incidental enclosures
    
  • 
    Virtual bundles – from USPS
    
  • 
    Mail Piece Unit ID – Definition in Segments
    
  • 
    Files, Fields, values to be deleted (applies to all mail classes)
    
  • 
    Mail.dat specification 09-1 (work in progress)
    

  3. Configuring Mailing Files for Processing

  
  This section provides details about the Mail.dat File Specification as they relate to data elements used by the PostalOne! system. Specifically, it covers required files and fields, typical problems, sending job updates, and file processing. We strongly recommend that you acquire the Mail.dat File Specification from IDEAlliance. For more information about obtaining the specification, see Section 2.2.5, Information/Manuals.
  

  1. Required Files and Fields

  
  A Mail.dat job sent to the PostalOne! system consists of, at most, twenty-one files. Each file in the set sent for a job consists of a different record type. Key fields within the records provide linkage from one file to another, thus creating a hierarchical relationship between the files. The PostalOne! system uses the Mail.dat standards as specified within the Mail.dat specification, with a few exceptions. This guide includes any exceptions and rules specific to USPS and/or the PostalOne! system. In any instance where this guide differs from the Mail.dat specification, this guide’s rules take precedence.

  For a listing of the files available in Mail.dat, see Appendix A. Mail.dat File Definitions. To review the validation performed by the PostalOne! system, see Appendix B. Mail.dat Field Validation. Appendix B also notes any fields required by the PostalOne! system, but not marked in the Mail.dat specification.

  
  

  2. Postage Statement Generation, Rejection, and Conflict Resolution

  
  This section discusses the key fields used to indicate a new postage statement within a job, the issues that can cause rejection of a segment of a Mail.dat job, and conflict resolution for redundant values in Periodicals mailings.
  

  1. Key Fields

  
  This section discusses the key fields used to indicate a new postage statement within a job, based on the Mail.dat 08-2 specification and the PostalOne! system. One job may contain multiple postage statements. The PostalOne! system generates a new postage statement each time a unique set of information is found in the following fields:

  Table 3‑2. Key Postage Statement Generation Fields

  
  

  Field	Record(s)	Position(s)	Notes
  Job ID	(Multiple files)		Must be identical for all files in the job.
  Mailing Facility	(Multiple files)		Must be identical for all files in the job.
  Provider Code	(Multiple files)		Must be identical for all files in the job.
  Periodicals Issue Number	Component (CPT)	157-162	Periodicals only.
  Periodicals Volume Number	Component (CPT)	152-156	Periodicals only.
  Container Ship Date	Container Summary (CSM)	101-108
  Container Status	Container Summary (CSM)	198
  Entry Point for Entry Discount Postal Code	Container Summary (CSM)	43-48	Periodicals only.
  Postage Grouping ID	Container Summary (CSM)	233-240
  CAPS Reference Number	Mailer Postage Account (MPA)	100-139
  Federal Agency Cost Code	Mailer Postage Account (MPA)	171-175	Non-Periodicals only.
  Permit Number	Mailer Postage Account (MPA)	58-65	Pending Periodicals and non-Periodicals, including enclosures
  Permit ZIP Code + 4	Mailer Postage Account (MPA)	81-89
  Postage Payment Method	Mailer Postage Account (MPA)	140
  Publication Number	Mailer Postage Account (MPA)	49-57	Periodicals only.
  Rate Type	Mailpiece Unit (MPU)	94
  Mail Piece Unit (MPU) ID	Mailpiece Unit (MPU)	13-17	Periodicals only.
  Mail Piece Unit Weight	Mailpiece Unit (MPU)	60-65	Periodicals only.
  Mail Piece Unit Name	Mailpiece Unit (MPU)	18-29	Periodicals only.
  Periodicals Advertising Percentage	Mailpiece Unit (MPU) or Component (CPT)*	87-91 74-78	Periodicals only.
  Periodicals Frequency	Component (CPT)	171-173	Periodicals only.
  Periodicals Issue Date	Component (CPT)	163-170	Periodicals only.
  Processing Category	Mailpiece Unit (MPU) or Component (CPT)*	95-96 82-83
  Mail Piece Unit - Class Component Class	Mailpiece Unit (MPU) or Component (CPT)*	93 80
  Automation Coding Date	Segment (SEG)	167-174	Periodicals only.
  Carrier Route Coding Date	Segment (SEG)	175-182	Periodicals only.
  Carrier Route Sequencing Date	Segment (SEG)	183-190	Periodicals only.
  Sacking Criteria	Segment (SEG)	76-81	Non-Periodicals only.
  Packaging Services Packaging Criteria	Segment (SEG)	165-166	Non-Periodicals only.
  Container and Bundle Charge Method	Segment (SEG)	249	Periodicals only.
  MPA ID for Container and Bundle Charge Method	Segment (SEG)	250-259	Periodicals only.

  
  * When both MPU and CPT values are listed, the CPT values are used for enclosures.

  ** Only used if the same MPU ID appears multiple times within

  Once postage statements have been created, the PostalOne! system reviews the new statements to see if consolidation is necessary. A new consolidated statement is generated for each unique set of the listed fields within a job.

  Table 3‑3. Key Consolidation Fields

  
  

  Field	Record(s)	Position(s)
  Job ID	(Multiple files)
  Mailing Facility	(Multiple files)
  Periodicals Issue Date	Component (CPT)	163-170
  Periodicals Issue Number	Component (CPT)	157-162
  Periodicals Volume Number	Component (CPT)	152-156
  Container Status	Container Summary (CSM)	198
  CAPS Reference Number	Mailer Postage Account (MPA)	100-139
  Federal Agency Cost Code	Mailer Postage Account (MPA)	171-175
  Mail Owner’s Lcl Permit Ref Num / Int’l Bill Num	Mailer Postage Account (MPA)	90-97
  Mail Owner’s Lcl Permit Ref Num / Int’l Bill Num - Type	Mailer Postage Account (MPA)	98
  Permit ZIP Code + 4	Mailer Postage Account (MPA)	81-89
  Postage Payment Method	Mailer Postage Account (MPA)	140
  USPS Publication Number	Mailer Postage Account (MPA)	49-57
  Rate Type	Mailpiece Unit (MPU)	94
  Mail Piece Unit Class Component Class	Mailpiece Unit (MPU) or Component (CPT)	93 80
  Processing Category	Mailpiece Unit (MPU) or Component (CPT)	95-96 82-83
  Container and Bundle Charge Method	Segment (SEG)	249

  2. Segment Rejection

  
  Segment rejection occurs when a particular segment of a Mail.dat job fails validation. The PostalOne! system processes the entire Mail.dat job, and generates qualification reports, postage statements, etc. based on the information in the file, but skips any rejected segments and data specifically associated with those segments. Data associated with rejected segments include MPU and MPU/C Relationship Records associated only with the segment ID, as well as container IDs associated with the segment ID. Additionally, all CQT Database IDs associated only with the rejected container IDS and their records in the Package Quantity Record are also ignored during file generation. The segment rejection error message includes a description of the error(s) and the segment ID(s) of the rejected segment(s) so errors can be resolved.

  The following conditions can cause segment rejection:

  
  

  • 
    In a Periodicals mailing, the weight of a single ride-along piece exceeds 3.3 ounces (0.20625 lbs) and/or the weight per copy for the issue, as declared in the Component Weight field of the Component (CPT) record.
    
  • 
    A Periodicals mailing or an enclosure in a Periodicals mailing claims an unauthorized rate category, such as Nonprofit, Classroom, or Science of Agriculture. Special rates only apply to Outside County postage. The Mailing ZIP Code in the MPA record must be the finance unit granting an active permit authorization for the rate. The authorized permit must be used in the mailing.
    
  • 
    The Class Defining Preparation field in the SEG file does not match values 1 (First-Class Mail), 2 (Periodicals), 3 (Standard Mail®), or 4 (Package Services).
    

  
  When segment rejection occurs, other segments in the Mail.dat file are not affected. However, if all segments in a Mail.dat file fail, the entire job fails validation. Segment validation occurs during processing of "Ready to Pay" Mail.dat jobs. Any subsequent updates must be sent without the segment or with the segment still rejected and the associated containers removed. To resend the rejected segments, first correct the validation issues, then send a new or updated job with those segments. To prevent additional validation errors, do not include any segments that previously passed validation in the new or updated job.
  

  3. Issue Date Validation

  
  If the required field Issue Date is missing from the CPT record for a Periodicals mailing, the file is rejected with the following error message: “For Periodical Statement # [#] Issue Date is required for 3541.” If Issue Frequency is missing, the PostalOne! system treats the field as blank and continues processing.
  

  4. Periodicals Rate Calculations

  
  The following items impact rate calculations:
  

  1. 
     Flats Machinability. The Flat Machinability field (position 118) in the MPU file accepts the value “Y” for flats machinable under DMM 301.1.3 and the value “U” for flats machinable under 707.26. The MPU Flats Machinability field (position 118) cannot be blank if Mail Piece Unit – Processing Category (positions 95-96) is “FL”.
     
  2. 
     Outside County for bundles and containers.
     

  • 
    The rates for the Outside County Bundles depend on the Package Level (.pqt position 33) and the Container Level (.csm position 41-42).
    
  • 
    The rates for the Outside County Containers depend on the Container Type (.csm position 13), the Entry Point for Entry Discount – Facility Type (.csm position 49), and the Container Level (.csm position 41-42).
    

  
  For specific mappings, see Appendix B.
  

  3. 
     Outside County payment method. In the required field Container and Bundle Charge Method (.seg position 249):
     

  • 
    If the mailing does not include any Periodicals, this required field must be filled with a “0” (zero).
    
  • 
    If this field is set to the value “1” or “2”, the Segment field MPA ID for Container and Bundle Charge Method (positions 250-259) becomes required.
    
  • 
    If the value is set to “3”, the MPA ID for Container and Bundle Charge Method field is not required.
    
  • 
    Validation uses the first Container and Bundle Charge Method for the entire job. This differs from the Mail.dat specification.
    

  4. 
     Unsupported mail preparations.
     

  5. Bound Printed Matter Validation Issues

  
  The following list includes Bound Printed Matter (BPM) mailing combinations that result in file failure or incorrect postage statements when submitted using Mail.dat files. Incorrect validation issues affect the following BPM mailing combinations:
  

  • 
    Mailings that include bundles with a piece weight of less than one pound. These mailings fail validation with the error message "ORA-20001: EXITING WWS Data Submission Package - Invalid MPU weight." This file failure is due to a weight validation defect that will be corrected in a future release.
    
  • 
    Mailings that include bundles with the number of copies higher than the number of pieces result in an incorrect postage statement. To submit a BPM mailing that includes bundles, the Number of Pieces field (positions 58-61) must match the Number of Copies in the .pqt file.
    

  6. Unsupported Mailing Cases

  
  The following mailing cases are not currently supported using Mail.dat files:
  

  • 
    Mailings with multiple mail classes.
    
  • 
    Co-palletized mailings where a segment contains only mother containers.
    
  • 
    International mail.
    
  • 
    Pending Periodicals in combined mailings, with parcel rates, or that include firm bundles.
    
  • 
    Mailings with firm bundles that include non-incidental enclosures
    
  • 
    Move Update method updates.
    
  • 
    Per the DMM 707 section, Periodicals with:
    

  • 
    Exception to Sacking (DMM section 23.4.2). Sacking is not required for bundles prepared for and entered at a DDU when the mailer unloads bundles under (DMM section) 28.4.6. Mail presented under this exception is not subject to the container charge (but is still subject to the bundle charges).
    
  • 
    Bundle rates do not apply to barcoded letter-size mail prepared in full letter trays or to flat-size mail prepared in flat trays under the optional tray preparation in DMM sections 22.7 and 25.5.
    
  • 
    Periodicals parcels that are not bundled. If Periodicals parcels are not bundled, even irregular parcels, validation rejects the Mail.dat file. To submit Periodicals parcels that are not bundled per DMM section 23.4, submit the mailing with the alternative standardized documentation and postage statements.
    

  • 
    For MLOCR mailings, postage statements cannot claim the “Single Piece” rate category.
    
  • 
    Combined Periodicals mailings submitted using Mail.dat 07-1 files that include a Limited Circulation Discount (LCD). A mailing may either be a combined mailing or claim the LCD discount, not both.
    

  
  The above list is not exhaustive; the Mail.dat specification may support additional cases that are not supported by the PostalOne! system.
  

  3. Postage Payment

  
  This section discusses how to list the parties involved in a postage statement, including designating the permit(s) to be used for payment.
  

  1. Permit Roles

  
  Postage statement permits can fill one or more of three primary roles:
  

  1. 
     Permit Holder. This is the permit charged for the postage statement. This is represented in the MPA file as Permit Number (positions 58-65) or USPS Publication Number (positions 49-57). The Postage Payment Method (positions 140), identifies the permit type of the listed Permit Number in the Mail.dat file.
     
  2. 
     Mailing Agent (Preparer). This identifies the organization that prepared the mailing and/or delivered it to the postal service for mailing. This information is linked to the preparers login account, and is not represented in the Mail.dat file.
     
  3. 
     Org for Mailing is Prepared (Owner): This identifies the organization who owns the mail being sent. This is represented in the Mail Owner’s Lcl Permit Num (position 90-97). If this field is left blank, then the default in the postage statement is the same as the permit holder. The permit type for this permit number is Mail Owner’s Lcl Permit Ref Type (field 98) in the Mail.dat file. For example, if a ghost permit is listed in Mail Owner’s Lcl Permit Num, then position 98 will be listed as “V” = Virtual.
     

  
  For an example of these fields on a postage statement, see Figure 3 -2. Postage Payment Roles.
  
  

  Figure 3‑2. Postage Payment Roles

  
  

  2. Additional Postage

  
  When postage affixed (precanceled stamp or meter) is used, the file must include a separate MPA record. This separate MPA record MUST be linked to a Permit Imprint account; Postage Payment Method (position 140) must be a “P”.
  
  NOTE: An MLOCR mailing with Postage Payment Method (.mpa position 140) values “G” (Government), “S” (Precanceled stamps), “C” (Metered - Correct), “L” (Metered – Lowest), or “M” (Metered – Neither) must have one Additional Postage MPA ID (positions 37-46) in the MPU / C Relationship (.mcr) record. Only one account is currently allowed for additional postage payment for this type of mailing, even if the mailing includes multiple statements. The first record must be a Metered or Precanceled Stamp permit, and is used to authorize the mailing. All subsequent MPA records must be Permit Imprint or ADDPOS (Additional Postage) permits, and are used to charge any additional postage due.
  

  Presort & MLOCR Regular (2-pass) Files:

  
  The MCR file links to the MPA record. The Primary MPA ID (positions 27-36) of the MCR record maps to the MPA Unique Sequence ID (positions 9-18) of the primary permit(s) in the MPA record. When there is additional postage, then the Additional Postage MPA ID (positions 37-46) of the MCR record maps to the MPA Unique Sequence ID/Grouping ID (field 9-18) of the Permit Imprint in the MPA record set for additional postage in the Mail.dat file.
  
  NOTE: An MLOCR mailing with Postage Payment Method (.mpa position 140) values “G” (Government), “S” (Precanceled stamps), “C” (Metered - Correct), “L” (Metered – Lowest), or “M” (Metered – Neither) must have one Additional Postage MPA ID (positions 37-46) in the MPU / C Relationship (.mcr) record. Only one account is currently allowed for additional postage payment for this type of mailing, even if the mailing includes multiple statements. The first record must be a Metered or Precanceled Stamp permit, and is used to authorize the mailing. All subsequent MPA records must be Permit Imprint or ADDPOS (Additional Postage) permits, and are used to charge any additional postage due.

  Table 3‑4. Presort and MLOCR Regular ID Requirements

  
  

  To Pay	MCR Record 1	MPA Record 1	MPA Record 2
  Postage Statement Charges	Primary MPA ID (positions 27-34)	MPA Unique Sequence/Grouping ID (positions 9-18)
  Additional Postage Charges	Additional Postage MPA ID (positions 37-46)		MPA Unique Sequence/Grouping ID (positions 9-18)

  
  
  

  MLOCR One-Pass Files:

  
  The Primary MPA ID (positions 27-36) maps to the MPA Unique Sequence ID (positions 9-18) of the primary permit(s) in the MPA record. When there is additional postage, then the Additional Postage MPA ID (positions 37-46) maps to the MPA Unique Sequence ID (positions 9-18) of the Permit Imprint in the MPA record set for additional postage in the Mail.dat file. In addition, the Postage Adjustment MPA ID (positions 56-65) must be the same as the Additional Postage MPA ID (positions 37-46).

  Table 3‑5. MLOCR One-Pass ID Requirements

  
  

  To Pay	MCR Record 1	MPA Record 1	MPA Record 2
  Postage Statement Charges	Primary MPA ID (positions 27-34)	MPA Unique Sequence/Grouping ID (positions 9-18)
  Additional Postage Charges	Additional Postage MPA ID (positions 37-46) Postage Adjustment MPA ID (positions 56-65)		MPA Unique Sequence/Grouping ID (positions 9-18)

  4. Typical File Formatting Problems

  
  As more customers begin to utilize the PostalOne! system, we have been able to identify several common errors made in formatting fields. For details on field validation, see Appendix B. Mail.dat Field Validation. The more common errors are:
  

  1. 
     The optional date fields defined in the Mail.dat File Specification are often filled with zeros. The system validates all optional fields containing information and does not consider zeros to be acceptable date values.
     

  8. 
     The file/record level status flags are not used consistently. The system requires that all file/record level flags be consistent and does not allow any mixed Mail.dat transactions. For example, for an original Mail.dat transaction, all file level status flags should be set to "O".
     
  9. 
     You attempt to transfer a file but it fails because of an "Invalid Facility ZIP+4" in the segment (.seg) record. When looking at the actual data, the file shows all of the data in the correct positions according to the Mail.dat File Specification. However, the software being used has written a blank record in the CR/LF pair causing the data in the Segment file to be off by two characters.

     Solution: Delete the blank record and resave the file; the data will be in the proper positions in the file.

     
     
  10. 
      I/O Errors "Unable to connect to server." You can access the Internet and validate files, but when trying to transfer a file, you receive an I/O exception error.

      There are a few situations that could cause this. Your inter-company network may allow read-only access to files. If you have your Mail.dat files saved on a network drive, the Transfer Applet is not being permitted to get the files and transmit those due to company firewall settings, inter-company network access, etc.

      Solution: Create a folder on your local machine's hard drive, called "Mail.dat" for example, and save in that folder any Mail.dat files to be transferred to the PostalOne! system. Use the Transfer Applet and get the files from the new folder. This way, the Applet does not contend with the network firewall.
      

  11. 
      I/O Errors "Unable to connect to server." You are transferring Mail.dat files from a folder on the local machine's hard drive (i.e., no network involvement, as described in the previous item) and still get an I/O exception error. Reasons:
      

  1. 
     You may have lost connectivity to the Internet during the process.
     
  2. 
     The PostalOne! database could be temporarily offline.
     
  3. 
     It may be software related (an old browser or the user answered "No" to the security warning when trying to use the Transfer Applet).
     

  12. 
      "Trying to Reinsert an Original File." You have sent a specific Mail.dat job and it transferred successfully; however, when you try to resend the file, the PostalOne! database fails the transfer because the file has already been transmitted under that specific Job ID.
      

  
  When transferring Mail.dat files to the PostalOne! database, remember that once an original Mail.dat was transferred successfully, you can only send subsequent updates to that job, unless the job is deleted, then resent. For details about updates, see Section 2.3.5, Sending Job Updates.

  To send an update to an existing Job in the system, make sure that all File Status flags in each file being transmitted reflect a "U" for update. All subsequent files included in the transfer of an update should include a “U” in the File Status flag field. For example:

  
  

  1. 
     The Segment File SEG Record Status Flag (position 164) should contain a “U” for an update.
     
  2. 
     The Mail Piece Unit File MPU Record Status Flag (position 117) should contain a “U” for an update.
     

  
  Alternately, to resend an original file, first delete the job, then resend the job. The same Job ID can be used if the first attempt to submit the file is deleted prior to the second attempt. For more information on deleting files, see Section 2.3.5.3, Commands.
  

  13. 
      If the files were validated and transferred, but not accepted by the database and you receive "Internal System Error," a file may have null characters. The database will not accept a file with null characters. To spot the null characters, open the Mail.dat files using the Textpad utility. The null characters appear as black squares. Delete the black squares, then resubmit the files.
      
  14. 
      If files cannot be transferred due to an issue with the ZIP Code +4 or a permit, verify that you have a permit, even a ghost permit, at the same finance number (ZIP Code) as the permit(s) used to pay for the postage statements in the job. The finance number ZIP Code is available in the Mailer Postage Account record.
      

  5. Sending Job Updates

  
  Large mailing jobs are often split into smaller production units, then produced and presented for acceptance incrementally (along with supporting documentation) over several days or even weeks. Specific details of a mailing job may change. For example, a piece weight may have changed or an initial estimated weight becomes finalized when the mail is produced. Also, in-process mailing jobs may be canceled in whole or in part for a variety of reasons. The PostalOne! system, via the Mail.dat File Specification, accommodates these and other tasks and provides business mailers the means to communicate them to the Postal Service.

  The scenarios such as those described above are handled as updates to the original Mail.dat file initially sent to the system. The list below includes the general guidelines for sending updated Mail.dat files:

  
  

  • 
    The system must receive an original Mail.dat file before any update can be received and processed.
    
  • 
    Mailers can send multiple updates to a mailing job, as long as they observe the rules established by the Mail.dat File Specification and those of the system.
    
  • 
    For mailers with an Optional Procedure (OP) mailing system, 100% of the containers in a mailing job must eventually be accounted for when a job is updated.
    

  
  The table below lists the files a mailer would commonly include in original and update transfers.

  Table 3‑6. Files Included in Original and Update Transfers

  
  

  Original Mail.dat File	Update
  *Header	*Header
  *Segment	*Segment
  *Mailpiece Unit	Mailpiece Unit
  *MPU/C Relationship	Component
  *Mailer Postage Account	Container Summary
  *Component	Container Quantity
  *Container Summary
  *Container Quantity
  *Package Quantity

  
  *Required files

  Following is a common update scenario to an original Mail.dat file: The mailer creates an ORIGINAL Mail.dat mailing data file after presort processing a large job and sends that file to the PostalOne! system. For each portion of the job, the mailer produces the incremental portion, presents it for acceptance, and sends an UPDATE to the Mail.dat file. For the portion of the mail that is presented for acceptance that it is “ready to pay,” a postage statement is created. This scenario is illustrated in Figure 3-2 below.

  
  

  	Presort done on ENTIRE job		Mail.dat files sent to PostalOne!
  1	Mailing Job		Original Mail.dat file sent to PostalOne!
  First portion of Mailing Job	Mail produced day X, presented for acceptance.		Updated Mail.dat file sent to PostalOne! for first portion
  Mail produced day Y, presented for acceptance.	Second portion of Mailing Job		UPDATED Mail.dat file sent to PostalOne! for second portion
  	Mail produced day Z, presented for acceptance.	Last portion of Mailing Job	UPDATED Mail.dat file sent to PostalOne! for final portion

  
  Figure 3‑3. Sending Job Updates to the PostalOne! System
  
  NOTE: Mailers can indicate that a portion or entire mailing job is ready for payment in an Original mailing file. If an entire job or portion of a job is ready to pay and will be presented for acceptance, an Update is not necessary.
  

  1. File/Record Level Status

  
  To use the PostalOne! system, mailers must use file/record level status flags for all Mail.dat files. The table below lists the file/record level status flags allowed by the system.

  Table 3‑7. File and Record Level Status Values

  
  

  Mail.dat Transaction Type	File Level Status	Record Level Status	Required Files (Minimum)
  “O”riginal	All flags must be set to “O”.	All flags must be set to “O”.	HDR, SEG, MPU, MCR, MPA, CPT, CSM, CQT, PQT
  “D”elete	All flags must be set to “D”.	All flags must be set to “D”.	HDR, SEG
  “R”eplace	Not supported by the PostalOne! system.	Not supported by the PostalOne! system.	Not supported by the PostalOne! system.
  “C”hange	All flags must be set to “C”.	All flags must be set to either “I” or “U”.	HDR, SEG
  “U”pdate	All flags must be set to “U”.	All flags must be set to “U”.	HDR, SEG

  2. Rules for Sending Updates

  
  When sending an update transmission, mailers participating in the PostalOne! program must follow these rules and requirements:
  

  1. 
     The Header file must contain a "U" in the appropriate status field.
     
  2. 
     The PostalOne! system validates all container status updates and fails transactions that violate the rules in the following table, which contains the valid container status values to which a given container can be changed. If updating the Container Summary Record, position 198 must reflect the appropriate status and have one of the following allowable values:
     

  
  Table 3‑8. Allowable Container Status Values
  

  Container Status	Allowable Changes	Notes
  C	D, P, R, or X
  D		No changes allowed.
  O	D, P, R, X, or C
  P	D, P, R or C
  R	D, X, T, or C
  T	D, X, T, or C
  X	T

  15. 
      File transfers that include one or more containers with status “D” result in the cancellation of the entire postage statement and impact the reconciliation report accordingly.
      
  16. 
      Original file transfers can have a "P" value. A preliminary or estimated postage statement will be generated with the Qualification Report. This postage statement will have the stage “EST” displayed on the Dashboard.
      
  17. 
      File transfers with the container status “R” generate postage statements with a stage “UPD” (USPS Processing Due) displayed on the Dashboard. Postal clerks can only finalize (bill) UPD postage statements.
      
  18. 
      The "R" value can only be resent if a container is cancelled (set to "C") prior to the second "R" being sent. The file fails if a second "R" is sent without canceling the container first.
      
  19. 
      To update transportation information, use the "T" value to update the reservation number and container barcode information in a file set to “R” or “X”. The only way to update a file marked “X” is with a “T”. A "T" value is accepted only after an "R" or “X” has been sent because no transportation update is necessary until the indication of payment. You can update transportation information only after it has been marked Ready to pay ("R") or Paid and Closed (“X”). Original file transfers fail if a "T" is sent.
      
  20. 
      Updates to weight are reflected only in a postage statement with a "P" or an "R" value. If an update to weight is received within any other update, it is logged, but no recalculation of the postage statement occurs until a "P" or an "R" value is received.
      
  21. 
      Only one estimate of postage is generated for an entire mailing job, unless more than one actual postage statement is required for the mailing or the same containers are sent multiple times with status “P”. Original job files generate preliminary statements, and group containers by date; to perform these functions, the container status associated with the original submission must be “P”. A separate update is not required.
      
  22. 
      Individual postage statements are generated for each unique Permit/USPS Pub number and each distinct Mailing Date populated in the Ship Date column in the .CSM file. The PostalOne! system consolidates postage statements across segments for an entire Mail.dat file. This applies to all files within a job that contain the same values for a postage statement: class, payment method, rate type, processing category, CAPS reference number, container ship date, sacking basis, packaging basis, entry point, and permit holder. Additionally, the PostalOne! system generates a new postage statement for each unique occurrence of the CAPS Customer Reference ID for the subset of the mailing identified by that ID. See Section 2.3.2 for key fields used in postage statement generation.
      

  3. Commands

  
  The Delete Transaction

  You can close a mailing job (i.e., containers canceled) by sending a "delete" file. This signals that the product, for whatever reason, is no longer going to mail.

  A delete file is composed of a header file and a segment file. The segment file specifies the individual facilities (using the Verification Facility ZIP+4 field) affected. When the Verification Facility ZIP+4 is available, the job can be closed at a specific facility (if this job spans more than one facility). Verification Facility ZIP+4 is contained in the segment file.
  
  The Change Transaction

  If the File Status fields in the header file for a Mail.dat job are set to "C", the job is considered a "Change" job. Per the Mail.dat File Specification, available change actions are “I”nsert and “U”pdate, based on the values contained in the record level status flags. Although the specification includes support for the “D”elete flag, the PostalOne! system supports only the "I", "O" and "U" flags. Support for the "D" flag at the record level is pending.

  
  
  Replace Transactions

  A Mail.dat job may be replaced by sending a “delete” transaction (see above) then resubmitting the same job.

  
  

  6. File Processing Overview

  
  When users select and send files manually, the PostalOne! system processes the files in the order the user selected them. When selecting multiple update files for transfer, users must select only those update files for which an original file has already been sent.

  The batch file transfer module processes jobs in first-in-first-out (FIFO) order based on the date-time stamp on the Mail.dat files. However, this does not guarantee that the system completes jobs with different Job IDs in the original transfer order. For example, when a large job is transferred first and then followed by a smaller job with a different Job ID, the smaller job usually finishes first. This is because the file transfer module can process several jobs at a time, and the larger job takes longer to process.

  
  
  The PostalOne! system Electronic Data Exchange process is detailed and illustrated in Figure 3-3 below.
  

  1. 
     The customer transfers Mail.dat files to the PostalOne! system in one of two ways:
     

  • 
    The Transfer Applet client, available on the PostalOne! website, manually transfers Mail.dat files to the PostalOne! File Upload Server.
    
  • 
    The Batch Processor application, when scheduled, automatically transfers Mail.dat files to the PostalOne! File Upload Server using password protection and Secure Socket Layer (SSL) encryption. The File Upload Server then returns a Receipt file to the client machine.
    

  23. 
      The File Upload Server inserts the Mail.dat files into the PostalOne! database.
      
  24. 
      Various reports (including the postage statements) are made available from the PostalOne! web server.
      

  
  NOTE: Postage statements for Mail.dat files larger than 30MB may not be immediately available as those files take longer to process.
  
  

  Figure 3‑4. Mail.dat File Transfer Process

  
  
  
  
  Download 6.32 Mb.