MTAC 138 Group Meeting Notes
January 12, 2011 11:00 AM – 12:00 PM (EST)
Feedback for additional fields we can use to help us determine what barcodes to send to a specific facility. Previous discussions focused on sending barcodes with a finalized postage statement 2 weeks after finalization date to the destination facility. Suggested to feed container information when postage statement is finalized based by locale key. Keep this for some number of days. What kind of burden would that create from a system point of view? Is it possible to narrow down the data or pin down a closer induction date? Possibilities include using:
· Estimated induction date –
o Difficult to estimate, moreso earliest possible induction date for the container.
o How long do we keep data until information keeps on building up?
- Remove container barcodes from the server once they’re used because we can’t afford to have a paid container refused.
· In-home date
o Even though mailer specifies a date, containers maybe inducted prior to it. Requires education for the industry regarding how to treat the in-home date. If they don’t use it correctly, what are the consequences?
o In order to prevent Postal Service from declining paid pallets that arrive too early, maybe create the following rule: Keep the postage statement finalization information for two weeks, unless the in-home date is further out than two weeks in which case the information would remain until the in-home date.
- Notifies that a container is not coming for a while, but would not prevent data from being fed to the correct location.
· Publication date
Once a postage statement is finalized, container information is forwarded to the SV central server and sent to the local SV server. Postage finalization is the trigger and the date will be calculated based on the FPP or the FIN date. FPP are for periodical mailers that use CPP. Container data will be fed by locale key as Exceptions include:
· For continuous mailings, containers can be released before postage statement is finalized. MLOCR mail.
· Origin mail exception: Mailer has until noon the next day after releasing the container to get the physical data into the eDoc and get it finalized
Search within server will be conducted among containers with the same locale key. Sometimes, induction date may not be populated. If the postage statement isn’t finalized, SV will not receive data. What do you do with the pallet. Same as not receiving an 8125. Call someone to ask the status.
Mitigating factors:
· High scan rates = less data retention
· Content association with appointment
o However, you cannot assume that mail is going to be entered as described by the appointment.
o STC: Switch the information using the date/time that the pallet is inducted, not what was on the appointment
o Is the association reliable enough if we didn’t load the associated containers to SV until the appointment? NO because mailers are afraid that if update is not provided, the data will be sent after it the shipment has been delivered.
Additional Capabilities
· eInduction provides opportunity to address redirections and streamline operations so that exceptions can be handled.
· Redirections: During the grace period, containers can be delivered to entry point A or B listed in the MDR. Once the period passes, the containers can only be delivered to the redirected facility (entry facility B).
· During the grace period, containers are fed to the both entry facilities. If it shows up at one facility, delete container information from both entry facilities.
· Should we modify the information in the information so that the container in the entry facility that doesn’t receive the shipment indicates where it the containers have been inducted? Not necessarily, because the systems should be capturing duplicate barcodes already.
Third Party Updates
· Who will develop any cast of characters, if someone says they will build, we will look at functionality.
· MID profiles – someone can go in and authorize another party to be their eDoc submitter, or allow them to feed their own data
· Details to work out – what data do we need to allow to update as a first phase? Long term, we can add more. But the more detail level we go, the more rules and issues of exactly who is updating what and how to report come up.
o Initial thought: phase 1 – look at pallet level/pallet type updates for mail.dat, transportation information, etc. for third party updates. All about shipment, updating shipment information, postage information, all tied together.
o Drive this all based upon MID profiles. Gives clarity as far as legal issues, because you are authorizing people to do this to your data. As long as owner and preparer are indicated, they can update.
o Today’s information is used for data distribution, not necessarily updates, but we can modify this to support third party updates.
o Scope: .csm and mail.dat, containerinfodata block, type information.
· Given current model, when postage is finalized, data is distributed out to facilities IF the customer submits electronic postage.
Action items:
Jeff – Data retention capabilities: Assess the demand on the system and whether the current system can handle it. 14 days/30 days/45 days after postage statement finalization mailing date.
Extend discussion for third party updates and go down a more detailed/complex path and work on it as a separate task/item.