Meridian Awards 2012

Ceridian has touched on all five of the core criteria that exemplify this category of technical achievement. The core criteria are, extending the use of Pitney Bowes Softwares technology beyond the standard feature sets, creating a highly scalable and/or highly available application, pushing the limits of the Pitney Bowes Softwares technology to create an optimal user experience, implementing a technically innovative solution and Integrating seamlessly with other products. This paper will get into the details of how we did this at Ceridian after noting how we addressed each of the core criteria.

When Ceridian originally started using the Pitney Bowes Streamweaver product, in conjunction with the MaiiStream Plus and Finalist products, it only had a couple of applications. These applications were basic documents that always had one page, a mailing envelope and maybe a return envelope. This meant that the weight of each mail piece was always less than one ounce at the first class postage rate. As the use of Streamweaver expanded the complexity of the applications increased. One of the challenges that arose was the ability to have multi page documents which would lead to mail pieces exceeding the one ounce threshold. At first Ceridian handled this by setting the Pitney Bowes inserting equipment to the maximum weight for each of our three envelope sizes (#10, 6x9, and 9x12) and running all the pieces through at that rate, as you may imagine this lead to an unnecessary increase in postage. It was tasked to me to come up with a solution from the Streamweaver software side.

The solution I designed was to take a static weight table and give it dynamic lookup capabilities. This is how the use of the Pitney Bowes Softwares technology was extended beyond the standard feature set. This paper will explain this further by going through the details of the table and its interaction with the Streamweaver applications that use it.

Since the program uses a table, if data changes, say a different type of paper is used and the weight changes, then the appropriate entry can be modified in the table. This creates a highly scalable and/or highly available application. The use of the weight table is transparent to the end user which creates an optimal user experience. By making the weight table dynamic the process is implementing a technically innovative solution. The calling programs just need to add the calls to the weight table program and then check the values returned making the integration seamless with other products. The rest of this document explains the technological details of the process.

There are certain things that are checked for each of the applications when using the weight table. The first check is if a return envelope is being sent in the mail piece. The program is expecting every application to have a return envelope entry in the weight table but if a return envelope is not used for that application then it will return zero for the weight. This means the postage would not be affected. The second program check is if there are any inserts to be included in the mail piece. Our mail inserters can handle up to 5 inserts along with the return envelope so I designed the program to handle inserts 2 through 6 as insert 1 would be the return envelope. Whereas the return envelope is always required to be passed to the program the inserts are not required. The last of the application specific checks in the weight table is more for future use. The program has code that loops through what I call addl records. For example, this could be an additional return envelope with a different address then the original return envelope for a new insert being mailed back to Ceridian. The calling program will then sum up the various weights found and then adds this to the weights covered in the next section. This completes the application specific values for the weight table; the next section describes the way the weight table program handles the calculation of the mail piece weights by number of pages within a mail piece.

When an address from a mail piece is passed to Pitney Bowes address lookup tool, Finalist, called via Streamweaver, it will verify if the address is valid compared to the addresses used by the United States Post Office. These addresses are stored in a database that Finalist uses. For Ceridian this means there are three valid types of addresses, addresses for the #10, the 6x9 and the 9x12 envelope sizes. Along with that there would be three invalid types of addresses for the above mentioned envelope types. What this means to the program is that #10 envelopes with valid addresses will be assigned a code of 1, invalid addresses will be assigned 2, 6x9 envelopes with valid addresses are 3, invalid addresses are 4, 9x12 envelopes with valid addresses are 5, invalid addresses are 6. Within the program this is referred to as the splitcode. This numbering scheme could be continued if another envelope size was ever introduced. The new envelope splitcodes would be 7, valid address, and 8, invalid address.

The United States Post Office charges first class mail by the ounce, so the main purpose of this program is to figure out how many ounces each mail piece weighs. The splitcode mentioned above is used at this point as part of the key into the weight table to lookup a particular record in the table. The other part of the lookup key is the total number of pages for the mail piece. The items found on the record containing the key are the weight of an individual piece of paper, weight of the mailing envelope and a weight code that is used later. Of note here is the fact that the program uses 1000 to symbolize 1 ounce. The reason for this is to make the calculations easier for fractions of an ounce. For example, the paper that Ceridian uses weights 0.2 ounces so this would translate to 200 in the weight table, 1000 x 0.2 = 200. Once the record is found in the weight table using the key discussed above the weight of the mail piece can be found by multiplying the number ofpages of paper times the weight of the paper. Then add the weight of the mailing envelope to this. This would be the weight of the mail piece. An example could be 2 (pages) x 200 (weight of each page) = 400 + 200 (weight of mailing envelope) = 600. Next compare this to 1000 (symbolizes one ounce in the calculation) to determine that the weight code is 1 (which would actually be 1 ounce). This is the power of the program because the weight code, 1 ounce in our example, is dynamic - if the weight of the paper or the mailing envelope ever changed then the weight code would be calculated appropriately. This is what is meant by the static table becoming dynamic, because every time the program runs it updates the weight codes within the weight table.

Another dynamic aspect of the weight table and the program that uses it is that the maximum number of pages a particular envelope uses can be changed and then reflected within the program. This can be better explained by showing what we do at Ceridian. Currently for #10 envelopes the maximum number of pages is 6 but that could be changed to 7 by simply inserting a row into the weight table with 1 (the splitcode) as the first part of the key and 7 (number of pages) as the second part of the key. (An entry should also be entered in for the invalid splitcode.) One last thing about this process is the ability to round the weight code up to the next number if the calculated weight of a mail piece goes over a particular ounce weight. Again, this is better explained by an example. Take 5 pages of paper times 200 (0.2 ounces) = 1000 (1 ounce) and then add the envelope weight of 200 for a total of 1200 which is over 1000, or 1 ounce. This means the weight code would end up being 2 for 2 ounces. If the calculation ends up being exactly 1 ounce or 2 ounces, etc, rounding the weight code is not performed. This explains how the weight table and weight table program work. Now to explain how each application would use this program.

The Streamweaver program calling the weight table does so at several places during processing. Each piece uses the table for a different purpose. The first call is in the start section where all of the initial calculations and assigning of variables to be used later is done. Next, within the main part of the calling program, the total number of pages for each mailing piece is compared to the maximum number of pages, found in the start up, for each type of envelope. Based on which envelope type is selected for the mail piecethesplitcode is assigned. This assignment is also based on a valid or invalid address. Once the record is found in the weight table the splitcode, along with the found weight code, can be used to sort the mail pieces within the file. If an auxiliary item is to be included, such as a return envelope, insert(s) or any additional items besides the paper and mailing envelope, add this to the documents total weight. Now compare this to the multiples of 1000 to determine the weight code. 1000 or less is weight code 1 (= 1 ounce), 1001 to 2000 is weight code 2 (= 2 ounces), etc. This way, within each envelope type, all of the particular ounce weights can be grouped together and a banner page can be inserted into the mail run to separate them out. In this case, all of the # 10 envelopes at 1 ounce can be loaded onto the inserter and the meter can be set at 1 ounce. This solves the problem of having to set the meter at the highest ounce weight for that envelope type and saves mailing costs.

Since this new weight table was implemented the cost savings has been approximately $250,000. The good news about this is that the cost savings will only continue to grow as more mail is sent out and the difference between the ounce weight postage will only increase year by year.