Issue Date Change
This utility changes the frequency and/or issue dates for a product. When assigning a product an issue date table, or defining dates on an issue date table, they only change with this utility. The utility changes the products issue date table and the dates on the orders attached to the product. Follow the systematic process for successful completion. When in doubt do not hesitate to call Datasystem Solutions, Inc.
Changes can only occur for future issue dates beginning at a point AFTER the products current issue date. Dates equal to or less than the current issue of the product may not be changed. The user does not need to wait until right before the change occurs. Issues date tables can be created in advance. The user can then run the utility as desired.
Instructions for Product Issue Date Change
- Create a new Issue Date table, mirroring the product’s issue date table up through the product’s current issue. Make a new control code for all years back in time with the issue dates mirroring the product’s current control file. This should include the product’s current issues as stated on the product code. After this date, table dates for the rest of the year and all years going forward should reflect the new issue dates.
- Post labels, all paid transactions and cancellations for the product. Also verify that all campaign statements for this product have been posted (or understand that in some cases, expire dates will move, moving the subscriber to a different campaign, and creating a new statement record, forever leaving the other in the csdtl -campaign detail statement – file.). If the product is a multiple issue product, the final mailing must be sorted and posted before proceeding with running the Issue Date Change program.
- Use product lock out to set the product status to LOCKED.
- Run a Backup.
- Run the Issue Date Change Program for “Report Only”= yes. The program will display the product’s current issue and current number of annual issues. Enter the new Issue date table (as created in step 4) and the new number of annual issues to serve. Print out this “pre-report”, and check the proposed changes to the orders, especially the first and ending issue dates being changed. Answer the ‘ASCII detail’ question as yes to create a file showing EVERY order for the product, original first issue and expire dates and suggested new first issue and expire dates. The output will appear in the path/file (quote space delimited format) that displayed to the right of the question when answered.
- After reviewing the information and finding it to be correct, run the Issue Date Change Program again with “Report Only “ = no.
- After the program finishes, check the post report generated against the “pre-report” from step #5. Verify that the correct changes have been made by the program.
- Because of the changes to the product, several governing rules about how the product should act may also be affected. Review and update these rules as necessary:
- a) New rate codes may need to be created adding prices/discounts for the new term.
- b) Check the renewal policy of old rate codes for the product, specifically the “renew at”, realizing that renew at Annual will now renew at the product’s new annual number of issues (if this value changed).
- c) Review the suspend/cancel policy for the product, and verify that the information is correct for the new annual number of issues.
- d) Review the Invoicing schedule and verify that the information is consistent with the modifications made.
- e) Review the missing issue policy for the product and verify that information (if a policy is not set up for the product – orders will use the policy for the new number of annual issues, rather than the old policy).
- f) Review product setup for auto renewal policies (the change in frequency may require a change in timing of when auto renewal orders are created)
- g) Review the product setup for grace issues policies (the change in frequency may require a change in timing of how many grace issues to serve). NOTE: If you desire to change the grace to a higher number of grace issues, be aware that the system will serve several records that had graced for a while, stopped gracing, have not yet renewed, but would now, with the change, be eligible for grace once again. The eligibility for grace is calculated by the different between the current issue on the product and the expire on the order. If the number of issues between is equal to or less than the grace number, the record will be selected, regardless of whether they were selected for the prior issue. Users should consider phasing in the grace by adding 1 to the grace count after each post so that those records that had stopped gracing will not be started again but those not yet reaching the ultimate grace value will continue to grace until the new total value is reached.
- Unlock the product to allow data entry to proceed.
Important Notes:
For those customers with a TRAIN system under maintenance contract, this process should first be completed on the TRAIN system. This holds especially true if
- a) this is the first time this process has been completed on your system
- b) staff new to the system have not experienced the affects of this program in the past (results are sometimes surprising to persons newer to the system)
- c) it has been quite a long time (more than a year) since this process was run (as this program continues to be enhanced and results received now may be slightly to significantly different than those results received in the past)
- d) there is a significant change in frequency (such as quarterly to monthly, weekly to daily, etc).
This test will give all departments (fulfillment, management, marketing, accounting, etc) a chance to study the affects of moving forward with the process before affecting the live system. DSI highly recommends the testing continue after the issue date change is complete by completing several label sort and posts with related reporting after the change to the issue dates to simulate the results on future processes after the issue date change. This is especially crucial if processing auto renewals, offering grace issues, making changes to suspension/cancellation policies, accounting keeps a tight reign on revenue recognition, etc. Do not hesitate to contact DSI support at any point along the way to discuss questions about results.
1) The program will NOT alter any orders with a send frequency on the order. The report will display all records that have a send frequency attached so they may be changed manually. It is critical that every order for the product have a valid first issue and expire date as defined on the new issue date table.
2) The program assumes that the entire term for an order will be filled, even if the order has been suspended/cancelled and reactivated. In this case, it will extend the order based on the term, even if the product’s missing issue policy stated no backorders and do not extend the end issue date. (For example, an order with a term of 12 suspends after receiving three issues. It lapsed for six issues and then reactivated with no backissues and no change to the ending issue date. When the utility runs, it would extend the order by the six missing issues that would not have served had the program not been run).
4) The program assumes issues should be served to cover through an original expire date in the case where the expire date was pushed out without adjusting the term. The program uses the old issue date table to compare the first issue to the expire and then figures the number of “free” issues served and extends the new suggested expire accordingly as needed.
5) The program will verify an order’s renewal campaign record and remove from the prior renewal campaign and add onto the different renewal campaigns if a valid match can be found. In order to find a match, the new expire pool the order belongs to must already have a campaign on file and that campaign must have been generated with campaign criteria, not via a query, in order to find a match. For those orders with dates so far in the future that no campaign yet exists, they will be pulled onto the campaign at the time the campaign is created in the future.
6) The program reassigns expire dates to all orders and first issue dates, as necessary, to future renewal orders (which in turn can affect the assignment of the expire for that and consecutive future orders). Any status 06 or 31 (prepay required) orders will have first issue and expire remain assigned to ‘?’ until payment is applied at a later date. At that time, the data entry programs will determine the appropriate issue dates to assign based on the current issue and issue date table assigned to the product.