250 Appointment Letters: Mail Merge, Lost Leading Zeros and a Page Overflow
A ministerial constable in a Delhi Police district office must dispatch 250 appointment letters before 5:00 p.m.; it is 2:45 p.m. and the section printer, which prints 12 pages per minute, is free. The letter body is a one-page Word document and the names and addresses sit in an Excel workbook named DATA.xlsx with the columns Code, Name, House and Pincode. Two problems appear during the trial merge: every Code that begins with zeros shows as a plain number (0007 becomes 7; 0042 becomes 42), and 12 rows have an empty Pincode. In the first trial print of 10 letters, two of the longer addresses pushed the last two lines onto a second page, although the template was designed to fit one page. Eight letters also need a manually typed remark that cannot come from the Excel data. The inspector wants the merge corrected rather than the letters typed one by one, and wants a realistic time check before the full run is released.
1. Calculate whether the dispatch is achievable, and state the latest time the full 250-page run may start if 20 minutes must be kept for sorting and dispatch and each of the 8 special letters needs 3 minutes of manual work after printing.
Read the worked answer
Step 1 - printing time: 250 pages ÷ 12 pages per minute = 20.83 min ≈ 21 minutes. Step 2 - manual work: 8 letters × 3 min = 24 minutes. Step 3 - sorting and dispatch: 20 minutes. Total from the release of the run = 21 + 24 + 20 = 65 minutes. Latest start = 5:00 p.m. − 65 min = 3:55 p.m.
At 2:45 p.m. there are 70 minutes of slack, so the deadline is achievable - but only just. The decisive point is not the arithmetic but the cost of a mistake: a failed trial discovered after the full run costs another 21 minutes of printing plus re-sorting, which eats almost the whole 70-minute cushion. Therefore the data errors (codes, blank pincodes, page overflow) must all be fixed and re-previewed before the run is released, not corrected letter by letter afterwards. Printing first and repairing later would still technically fit if nothing else went wrong, but it leaves no margin for a paper jam or a toner change.
2. Why do the Codes lose their leading zeros, and what is the safest way to make 0007 and 0042 print correctly? How would you verify the fix before the full run?
Read the worked answer
Cause. In Excel, a cell in General format treats 0007 as a number, so the stored value is 7 and the leading zeros are not part of the data. If a custom number format such as 0000 is applied later, only the display changes; the underlying value stays 7, and a merge field may take the underlying value, which is why letters print 7 and 42.
Fixes, in order of safety:
- Helper column with TEXT - in a new column put =TEXT(A2,"0000") and merge that column. The zeros become part of the text itself, so no downstream setting can strip them. This is the safest option because it does not depend on how Word connects to Excel.
- Text-formatted column, re-entered - Format Cells → Text before typing or pasting the codes, then re-enter or re-paste. Merely changing the format of existing cells does not bring back lost zeros.
- Apostrophe prefix - typing '0007 stores text and hides the apostrophe. Fine for a few manual corrections, slow for 250 rows, and easily broken by a later copy-paste. When importing from CSV, set the Code column type to Text at the import step so the zeros never fall off in the first place.
Verification. Use Mailings → Preview Results and step to a record whose code is 0042 and to the last record; open Edit Recipient List and confirm no code appears with fewer than four digits; print a 2–3 page trial and read the codes, not just the names. A quick count check - the number of 4-digit codes in the helper column should equal the number of rows - catches a silent partial failure.
3. Diagnose why the longer addresses spill onto a second page, and explain how to stop the 12 blank pincodes from producing a misleading address line - without typing any letter manually.
Read the worked answer
Page overflow. The template is one page only for a short address. The usual cause is layout built with repeated Enter keystrokes - empty paragraphs at the end of the address block or after the closing - so when a record adds one more address line (or a longer house description), everything below is pushed past the bottom margin. Turn on Show/Hide ¶ and look for empty paragraph marks, then:
- delete the empty paragraphs and control spacing with Paragraph → Space Before/After instead of blank lines;
- reduce line spacing marginally (for example 1.15 → 1.0) or trim the top and bottom margins by 0.2 cm;
- apply Keep Lines Together to the address block so it never splits, and Keep With Next to the closing line so the signature does not sit alone;
- re-preview the longest record, not the first record, and check Print Preview page count = 1 before releasing the run. Physical page breaks (Ctrl+Enter) must not be inserted inside a merge template; they will cut every letter at the same point.
Blank pincodes. Do not merge a blank field into a line that reads 'PIN: .' - the letter then looks incomplete or, worse, mis-sorted. Fix it in the data rather than in Word: in Excel add a helper column =IF(C2="","PIN not available",C2) and merge that column, or filter the Pincode column for blanks to spot the 12 rows and obtain the correct pincodes. If the correction must happen inside Word, a rule (Mailings → Rules → If...Then...Else) can print a placeholder when the field is empty, but field-syntax errors are common and silent, so the Excel helper column is the more dependable route for a 250-record run under time pressure.