Automatic Renewals
Automatic Renewals
Multipub provides an optional feature named Autorenewals. Autorenewals were designed for ‘till-forbid’ subscriptions. Till-forbid subscriptions are those subscriptions that automatically renew at the end of each term until the subscriber cancels the subscription. Before implementing autorenewals, please investigate any legal requirements for obtaining the subscriber’s authorization.
Autorenewals are implemented by product on a subscriber-by-subscriber basis; a subset of subscribers may be autorenewed while the remaining subscribers to the same product are managed through the traditional renewal campaign process. A subscriber may also choose to be autorenewed for one product but not for other products. The decision to autorenew is made separately for each subscriber and product. Note: The decision is not separate for each order. If there happen to be two orders on file for the same product, either all orders will be marked to auto renew or all will be marked to not autorenew, for the same product, same subscriber.
Only Type A orders are eligible to be autorenewed.
Understand where autorenewals fit in the renewal process
When a subscriber is an autorenewing subscriber, the orders are not part of the renewal campaign process. This is because the goal of a renewal campaign is to obtain the subscriber’s agreement to renew. In the case of autorenewals, this agreement has already been obtained. Autorenewals, therefore, begin one step ahead in the renewal process.
Autorenewals begin here
Original order entered as autorenew = yes
At the appropriate time, depending upon system setup, autorenewal order created
If payment is not applied (via carry credit card over or use of Installment Billing), then the autorenewal order enters the invoicing cycle.
The autorenewal order is served while the order is active.
If the autorenewal is not paid, the order is suspended and/or cancelled according to policy.
At the appropriate time, the next autorenewal order is created, etc.
Renewal Campaigns begin here
Original order is entered, autorenewal = no.
At the appropriate time prior to expire, a renewal statement is generated for all active, paid orders in this pool.
A renewal order is entered only if the appropriate response is received from the customer.
Understand how autorenewals work
What makes an order autorenew
For a subscription to autorenew, several switches must be set properly.
1) First, the product must be marked to autorenew and have an automatic renewal policy defined within the product setup. The primary decisions in setup are whether to autorenew with label runs (the preferred method) or via a custom program. Additionally the user should consider the number of “Renewal Issues”, whether to create transactions or orders (new with V10), and whether or not to carry over credit card information from the current to the auto renewed order (new with V10). The Renewal Issues tells the system to create the renewal order when an autorenewing subscriber has X number of issues remaining on his current order. For example, if the number of renewal issues is defined as 2, then the autorenewal order is created when the subscriber has 2 issues remaining on his current order.
2) Secondly, the product demographics must have the auto renew field open to allow entry and may also require entry, if desired. If the product is marked to autorenew but the demographic flag is not opened, the system will not allow entry into this flag to appropriately set it for the customer orders. Also, be certain the setting for ‘carry over to renewal’ = yes to keep continuous auto renewals creating. If this flag is no, an auto renewal will be created once from the first order, but then will stop after that (since the flag is not carried over with the creation of the renewal).
3) Thirdly, the batch setup must either have the auto renewal flag set to Y or blank. Any batches defined as N will automatically set all newly created orders (new or renewal) in that batch to auto renewal no, regardless of the product setup. NOTE: If an order has previously been entered and posted, setting the auto renewal flag on the batch will not change the auto renewal flag on the order. Each change to the flag must be entered manually; therefore to change existing records, be sure to set the auto renewal flag to blank on the batch to access and change the flag as necessary.
4) Finally, the orders entered for the product must be marked as Autorenew? = yes. When entering an order for a product that is marked autorenew yes, the system will default the auto renew question to yes, which can be changed. This setting is stored on the SC (subscription control file); therefore, the value will match the latest entry for any particular product for a specific sub, regardless of how many orders are on file for the product.
Timing of when autorenewals are created
When the product is marked to create autorenewals with Labels, the system creates the appropriate autorenewal orders when issue labels are posted. For example, suppose that the current issue is 10/01/18 for a monthly product and the Renewal Issues on the product is 2. Any autorenewing subscriber with an expiration date of 12/01/18 will have his autorenewal created when the 10/01/18 labels are posted. This is because the subscriber has just received the 10/01/18 issue and has 2 more issues to go – the 11/01/18 and the 12/01/18. This is assuming there is not already a future order on file with first issue greater than the expire issue for the order to be auto renewed. An autorenewal will be created ONLY if:
the product is marked to auto renew
the timing for this order fits the timing for when an auto renewal should be created, i.e. number of renewals issues to go matches product setup
the order to be auto renewed is in status 01 to 04 (or 09 or 10, if the suspension/cancellation records allow creation of auto renewals for 09 and 10)
the sc.arnwl (the answer to the auto renew yes/no in data entry) is yes
the sc.renew is yes (i.e. person has not been marked as a Do Not Renew)
there are no future orders on file for this product (where future renewal is defined the first issue date is greater than the expire date of the auto renewing order), unless that order is a status 17 input error (all active statuses, suspensions, and other cancellation statuses will suppress the creation of another auto renewal)
When the product is marked to create custom autorenewals, the timing is controlled more by the user and can vary from Multipub user to user. Contact DSI for additional information about implementing any custom autorenewals.
Nature of autorenewal orders
An autorenewal order created by the system is identical to a renewal order entered manually; i.e. it has the same fields.
Multipub uses standard rules for assigning the various codes and values to the autorenewal orders it creates. The number of Copies is carried over from the prior order. The Rate Code is determined by looking up the Rate Code of the prior order and using its renewal rate code instructions. The Term is determined by the “Renew At” field on the Rate Code setup. The Subscription Amount and Miscellaneous Charges are calculated using the Copies, Rate Code and Term. Taxes are determined by the tax policies under Setup and whether the subscriber is tax-exempt or not. Demographic codes are carried over from the prior order only if the demographic codes are marked ‘carry forward to renewal’. If this field is marked Y, the values carry over otherwise they do not. In this way the customer can control which fields to carry through on a field by field basis, by product.
After labels are posted, if the product is marked to create auto renewal transactions, the user must run an edit list for the auto renewal batch (displayed at the time labels were posted), review, make any necessary adjustments, and then post. If the product is marked to create orders, the Accounting/ Activity Report/ Auto Renewal reports can help evaluate the auto renewals that were just created – the summary gives counts by product and the detail gives listing of the specific subscribers that were created.
Effect of autorenewals on accounting reports
Like a manually entered renewal, the subscription amount on an autorenewal is deferred income; it is recorded on the general ledger as deferred income and is reported on the Deferred Income Report. Billing can occur in one of three ways:
1) Autorenewals can have credit cards carried over and processed, therefore, posting the payment to the cash account for the credit card.
2) Autorenewals can use Installment Billing. The amount due will post to AR as a not yet due amount until it is time to run the installments.
3) Autorenewals can be bill me renewals. In this case, the full amount due will post to the AR account.
All GL transactions for an autorenewal are recorded when the autorenewal is posted. The system uses the Ship Date from the Label Batch as both the transaction date on the GL and the Order Date on the order.
Billing autorenewals
If the subscriber has agreed to have payment automatically charged to his or her credit card and the product is marked to create transactions and the system has a credit card processing module, run the batch created through the processing module prior to posting. This will charge the credit card for the payment on this renewal order.
If the product is marked to create orders or the system does not use the credit card processing module, the payment must be entered through the regular data entry programs. The payment must be posted before invoices are produced or else an invoice will be sent to the subscriber. In this situation, the Detailed Autorenewal Report (found under Accounting / Activity Reports) may be helpful; it allows printing of a detailed list of autorenewals just created.
If Installment Billing is implemented, the order will post without payment but will not invoice as install bill processing is a separate action.
Each autorenewal order is assigned an appropriate invoice number when it is created. Autorenewal orders are combined onto one invoice if all of the following conditions are met:
The order is a bill me- i.e. not paid via credit card carry over or installment billing processing.
The orders are for the same subscriber and billto.
The orders’ products, as defined under Setup, are allowed to combine together on an invoice.
The orders are autorenewal orders, not manually entered orders.
The orders have the same order date. (Remember that the order date of an autorenewal comes from the Ship Date on the Label Batch that creates it)
The orders are in the same transaction batch if create autorenewals with transactions, i.e. they must be created from the same Label Batch.. If autorenewals are created as orders, not transactions, then orders with the same order date but from different label batches could also invoice together (if the batches all posted on the same day, same order date and considered one lump batch).
The orders have not yet received any invoice efforts.
A payment has not already been applied.
Autorenewals are invoiced the same as any other bill me renewal order. The invoicing decisions under Setup determine how the autorenewal is invoiced. The invoice schedule and forms defined for renewal orders are used to invoice the autorenewal. If the product is invoiced based on Order Date, then the Ship Date of the Label Batch is used as the first eligible invoice date on the autorenewal. (This means the autorenewal will receive invoice effort one as soon as invoices are produced with an Effort Date greater than or equal to this date). If the product is aged based on Order Date, then the Ship Date of the Label Batch is used as the Aging Date for the autorenewal.
Monthly Billing
Multipub has the ability to renew daily products by month. This will actually calculate the renewal term to be the number of days in the month, so that it renews the same day each month, even though some months have 30 days, some 31, some 28, etc.
To do this, you will again go to Setup > Rate Codes > Renew At (under Multiple Issue Pricing) and select Monthly (See Below)
Suspending/Canceling autorenewals
The autorenewal, if not paid, is subject to being suspended and/or cancelled if its Suspension / Cancellation policy allows this. A suspended autorenewal becomes a status 10, but an autorenewal cancelled for non-payment becomes a Status 18 rather than the system standard 15. A Status 18 is a special cancellation status reserved for autorenewals that do not pay. Status 18 does not carry the negative connotation that a Status 15 does because an autorenewal that does not pay is considered the equivalent of canceling by request.
DSI recommends that unpaid autorenewals be cancelled at least some time before they get autorenewed again, either via suspension cancellation policies or manual system tracking; otherwise a subscriber who never pays will continue to autorenew and could received their subscription for free continually. Manual cancellations of auto renewals may use any status (other than 17) to suppress the creation of future auto renewal orders. The cancellation of an auto renewal (either by the system or completed manually) does not change the sc.arnwl flag – once it is set to yes, it remains yes unless the user changes the do not renew flag or manually changes the auto renewal setting in data entry.
Serving issues on autorenewals
When the first issue of an autorenewal is served through Issue Labels, the autorenewal, like any other order, will be served if it is still active. Issues served on an autorenewal are handled like any other order; the order is marked as receiving issues, income is earned on the GL, etc.
If the business goal is to serve issues on autorenewals only if they have paid, it is important to define Suspension/Cancellation policies that suspend the subscription before the first issue is served.
Grace copies and autorenewals
Grace copies, defined as free, post-expiration issues served to non-renewing subscribers, are only served to non-renewals; by definition, autorenewals have renewed. The autorenewal order always begins with the first issue after the previous expire and there should never be a lapse in service. (A lapse could only occur if the system is dependent upon the running of a custom create program).
Analyzing renewal percentages
It is important to realize that an autorenewal order is truly a renewal. When analyzing renewal percentages (using such tools as the Renewal Tracking Projections), autorenewals count as a renewal and contribute to increase the renewal percentage.
Know the various applications for autorenewals
Over time, our customers have come up with three different applications for autorenewals:
Till-forbid Subscriptions
Installment Billing
Replacement for Renewal Campaigns
It is important to know that only one of these, Till-forbid Subscriptions, is a “perfect fit” because it was the original purpose of autorenewals. The other two are “creative” applications with both serious pros and serious cons. With the implementation of true installment billing with V10, the use of auto renewals to ‘trick’ the system into installment billing should no longer be necessary.
Pros and Cons of the use of auto renewals to mimic Installment Billing
The Multipub system now has an integrated Installment Billing feature. In the past, some customers who offer installment billing found they could meet at least some of their requirements by using autorenewals. While this application may be of benefit, autorenewals were not designed for this purpose and there are limitations to this use of autorenewals.
Installment billing subscriptions are represented on the system with multiple orders, one order for each billable portion of the subscription. The first order, for the first billable portion, is entered manually through Paid Order Entry. The subscription amount is entered as that portion that is currently billable and the First Issue, Term and Expire Issue represent just that portion of the subscription that is being billed. The order is marked as Autorenew = yes. Invoices are produced for the first order. At a predetermined point prior to the expiration of the first order, an autorenewal order is created. The autorenewal order is created for the same subscription amount as the previous order, the same term, but the First Issue and Expire are continuous with the previous order. Invoices are produced for the second order. At a predetermined point, a third autorenewal is spawned from the second order and it begins to be invoiced. This autorenewal process will continue without end because that is the nature of autorenewals. If the subscription should not autorenew past a certain point, then it must be monitored and manually cancelled at the correct point in time.
Some customers make special use of Renewal Rate Codes for their installment billing orders. They define a different Rate Code for each installment in the billing series. For example, suppose an annual subscription is billed in quarterly installments, they might define Rate Codes called QTR1, QTR2, QTR3, QTR4 and QTR5. They would use the QTR1 rate on the first, manually entered order and set up the QTR1 rate with a Renewal Rate Code of QTR2. The autorenewal order spawned from the first order would have a Rate Code of QTR2 and the QTR2 rate would have a Renewal Rate Code of QTR3 etc. etc. In this fashion, the order’s rate code tells which installment the order is in. Queries could be run for QTR5 rates after each Issue Label posting (which creates autorenewals). The QTR5 rate codes could then be cancelled by hand if the autorenewal process should be stopped.
Some of the pros of the “Installment Billing” application
Autorenewals are the only automated feature that can meet some of the requirements of installment billing.
Some of the cons of the “Installment Billing” application
Multiple orders are used to represent one subscription.
The autorenewals must be manually stopped at the end of the billing series.
Any analysis of sales, deferred income and receivables must recognize and accommodate the fact that the sales amounts are recorded in installments and not all at once at the beginning of the subscription.
Analysis of renewal percentages must recognize that each autorenewal counts as a renewal of the previous installment.
The full subscription amount can not be printed on the invoice since each billable portion is on a separate invoice. It is difficult to show the billing status of the entire subscription on the invoice.
If a subscriber is behind on his or her payments, they will receive multiple invoices, one for each unpaid portion, instead of a cumulative statement.
If the time between installments is short, it may be difficult to suspend/cancel an unpaid order before the next autorenewal order is created. If the suspension/cancellation happens after the next autorenewal is created, the suspend/cancel policies are basically impotent; the subscription will continue to be autorenewed even if it is not paid.
The actual Installment Billing Module has been designed to meet the needs that this application outlines and should be considered to be utilized fully rather than using a more manual process as described here.
Understand the “Replacement for Renewal Campaigns” application
Some customers use autorenewals as a replacement for renewal campaigns, thus making autorenewals the primary means of obtaining renewals, different from the purpose of the autorenewals design.
Those who use this application totally eliminate the use of renewal campaigns. Instead, all Type A subscribers are entered as autorenewing subscribers. The renewal invoice cycle is dedicated to billing of the autorenewals; the efforts, timing, invoice forms and suspension/cancellation policies are all designed to be appropriate to a renewal request process; for example, the invoice forms may have wording appropriate to renewal requests and not to usual billing invoices.
The ‘philosophy’ behind this application is that autorenewals that pay are considered the true “renewals” and autorenewals that do not pay are treated as “non-renewals”.
Since autorenewal orders are recorded as deferred income and can affect AR, customers who use this approach must use previous renewal history to forecast the amount of deferred income and receivable that will be written off due to non-payment of autorenewals.
Some of the pros of the “Replacement for Renewal Campaigns” application
Elimination of renewal campaigns saves time and reduces errors. Since this strategy totally eliminates the use of renewal campaigns, an enormous amount of time can be saved. Campaigns do not need to be generated and campaign statements do not need to be printed and posted. Because these campaign functions are eliminated and replaced with automated renewal orders, the potential for error is decreased. All expire pools are renewed and bill me orders are invoiced.
Renewal orders are created by the program, saving time and reducing errors over manual data entry.
Some of the cons of the “Replacement for Renewal Campaigns” application
Standard bill-me or credit renewals cannot be accepted.
Since the renewal invoice cycle is dedicated to billing autorenewals, there is no way to support a “second” invoicing series if the subscriber wants to “renew” but be billed for the renewal. The same is true of debit memos applied to existing renewal orders; these must be paid at the time of the debit because, if the order carries a balance, it will receive any invoice efforts it did not receive already. The invoice forms may present confusing or inappropriate wording to the subscriber since they were designed to obtain agreement to renew, not to bill for money owed.
The user must project for the accounting effects of autorenewals
Autorenewals affect accounting in the same way that manually entered renewals do – they are reported as deferred income and as receivables when they are created. Autorenewals that do not pay can be cancelled automatically by the system. When this happens, any balance due is written off from deferred income (and/or earned income if issues have been served) and from accounts receivable. In this case, previous renewal history must be used to forecast the amount of deferred income and receivables that will be written off due to non-payment of autorenewals
This method can not support traditional grace copies
Grace copies are only served to non-renewals and by definition autorenewals have renewed. Grace copies may be simulated by allowing a certain number of issues to be served on unpaid autorenewals before they are cancelled. These issues, unlike traditional grace copies, earn income when they are served and the income is later reversed if the order is cancelled.
Analysis of renewals and sales must be modified.
Autorenewal orders are recorded as sales and as renewals as soon as they are created. This means that any report that analyzes sales (such as the Order Activity Report) will report autorenewals in the sales totals. In addition, any report that analyzes renewals (such as the Renewal Tracking Report) will include autorenewals in their renewal percentage. Basically a ‘philosophical’ adjustment is required in the analysis of renewal orders; a change must be made from counting any renewal order as a true renewal to counting only paid renewal orders as true renewals.
Implementing auto renewals
Following the summary list below (details of each follow), implement the use of autorenewals:
Verify no custom programming is needed.
Check that no orders already exist for the product where autorenewal = yes, unless the intent is for the order to autorenew
Make Setup decisions
1. Product Codes
2. Invoice Control
3. Invoice Schedule
4. Form Design
5. Rate Codes
6. Suspension Cancellation Rules
Establish new procedures for data entry, customer service, issue labels, non-spooled invoices,
Oversee the autorenewal process
Verify no custom programming is needed
The Multipub system uses standard rules for assigning various codes and values to an automatic renewal order it creates. Before implementing autorenewals, be sure that these rules are appropriate to the business. If any of these rules do not fit the needs of the company, please contact DSI Support to discuss custom programming before using the autorenewal feature. A discussion of the rules are found in this document under the section ‘Nature of Autorenewal Orders’.
Check that no orders already exist for the product where autorenewal = yes, unless the intent is for the order to autorenew
Before implementing autorenewals, be certain there are no existing active orders with autorenew set to yes. Even if the product has been marked auto renew = no, the product could have previously been marked yes allowing this flag to be marked and earlier versions of Multipub allowed the flag to be set whether or not the product was autorenewable. Be aware that:
These orders have not been part of renewal campaigns (at least since the time they were marked as Autorenew = Yes) because autorenewing orders are ineligible for renewal campaigns.
Unless these orders are changed to Autorenew = No, they could suddenly create an autorenewal as soon as the product is changed to autorenew, if the order meets the minimum criteria. This could result in out-of-date autorenewals because, if the subscription is not current, the system will create autorenewal orders to make the subscriber “catch up” to the current issue.
To research, create a query that selects orders with Autorenewal equal to Yes. Evaluate any orders that are selected and take appropriate action before proceeding with the next step.
Make setup decisions
1) Setup / Product Related / Product Codes
Make the following changes to each product that may have one or more autorenewing subscribers.
Answer YES to “Automatic Renewal?”.
Answer L to “Create w/ Labels/Custom?”, unless custom programming is being discussed with DSI.
Enter the desired number of “Renewal Issues”.
Answer O or T for create orders or transactions. (T is the recommended selection)
Answer yes or no to carry credit card # over.
The Renewal Issues tells the system to create the renewal order when an autorenewing subscriber has X number of issues remaining on his current order. For example, if the number of renewal issues is defined as 2, then the autorenewal order is created when the subscriber has 2 issues remaining on his current order.
When the product is marked to create auto renewals with labels, the system creates the appropriate autorenewal orders or transactions when Issue Labels are posted. For example, suppose that the current issue is 10/01/18 on a monthly product and the Renewal Issues on the product is 2. Any autorenewing subscriber with an expiration date of 12/01/18 will have his autorenewal created when the 10/01/18 labels are posted. This is because the subscriber has just received the 10/01/18 issue and has 2 more issues to go – the 11/01/18 and the 12/01/18.
2) Setup / Product Related / Invoice Setup / Invoice Control
First select Product Related/ Product Code/ CHANGE and view the Invoicing Method assigned to the Product. Then on the invoice control, check the answer to “Invoice w/Order/1st Ship Date”. If it is set to Order, autorenewals will be eligible to begin invoicing after they are posted. If it is set to Invoice with 1st Ship Date, autorenewals will not invoice – and will not be able to suspend or cancel – until they begin to be served.
Check the answer to “Age w/Order/1st Ship Date”. If it is set to Order, autorenewals will begin aging when they are created. If it is set to Age with 1st Ship Date, autorenewals will be reported on the Aging Report in the “Not Yet Due” column until they begin to be served, at which point they will begin aging as current.
Note: Invoice Controls govern all orders for the product and should not be changed without consulting DSI Support.
Make a note of the value for “Renewal Invoice Scheduling Code”.
3) Setup / Product Related / Invoice Setup / Invoice Schedule
Select the option change and enter the scheduling code noted in the step above. Review the invoice efforts, timing and form names to be sure they are appropriate for autorenewals as well as manually entered renewals. Invoice Schedules should not be changed without consulting DSI Support.
Make a note of the form names entered on the schedule.
4) Setup / Product Related / Invoice Setup / Form Design
If necessary, review each Form that is on the Renewal Invoice Scheduling Code. Be sure each is appropriate for autorenewals. Forms may be changed as needed, but keep in mind that they are used for all renewal orders, not just autorenewals.
To use different text on autorenewal invoices, investigate the use of Product Comments or Form Messages.
5) Setup / Product Related / Rate Codes
The system does not require that autorenewed orders use different Rate Codes than regular orders. It may be beneficial to establish different Rate Codes. With separate Rate Codes, different Suspension/Cancellation policies may be defined for the autorenewals. Autorenewals could then also be listed separately on any report that totals by Rate Code (such as the Order Activity Report and Renewal Tracking Report).
Whether defining new Rate Codes or using existing ones, check the accuracy of the following items that are especially pertinent to autorenewals:
Renewal Rate Code – The autorenewal order will retain the same Rate Code as the previous order unless a different rate is specified in the Renewal Rate Code field.
Renew At – The Renew At field controls the term used on the autorenewal order. If the autorenewal order should always be created with an annual term, enter A. If the autorenewal order should be created using the same term as the previous order, enter C. If it should be created with some other specific term, enter S and enter the desired term in the “Renewal # Issues” field.
Prices by Term – It is vitally important that all necessary rates are defined. The system always needs a) the Rate Code of the previous order (which should already be on file and should never be deleted) and b) the Rate Code and price for the term of the renewal order.
Be cautious when setting Renew At = Current on a rate code. This means that the autorenewal order will have whatever the term was on the previous order; this term, regardless of how irregular it is, must be defined on the Rate Code in order for the system to determine the price of the autorenewal.
6) Setup / Product Related / Suspend-Cancels
Evaluate the Suspend/Cancel policy for each Rate Code that is used on an autorenewing subscription. If both autorenewals and regular orders share the Rate Code, the policy needs to be appropriate for both.
DSI recommends that unpaid autorenewals be cancelled at least some time before they get autorenewed again, either via suspension cancellation policies or manual system tracking; otherwise a subscriber who never pays will continue to autorenew and could received their subscription for free continually.
In order to prevent unpaid autorenewals from renewing again, the Suspend/Cancel policy must be set to cancel the subscription before the next autorenewal is created. Determine when the subscription will autorenew based on the number of Renewal Issues and be sure the timing for suspension and cancellation will work in conjunction with this. Remember that system-generated cancellations based on invoices do not get posted until the next invoice sort after the last invoice is produced.
Establish new procedures in the following areas:
1. Data Entry / Customer Service procedures
Paid Batch Entry
The question “Auto Ren (Y/N)” is important for anyone who defines paid batches within the company where any products on the system are marked auto renew = yes.
There are three possible answers to this question and each performs differently:
Y means that every new or renewal order entered in the batch (that hasn’t previously been entered and posted) is automatically marked as Autorenew = YES and the cursor does not stop on the field to allow the data entry person to override.
N means that every new or renewal order entered in the batch (that hasn’t previously been entered and posted) is automatically marked as Autorenew = NO and the cursor does not stop on the field to the data entry person to override.
Leaving the field blank allows the cursor to stop on the Autorenew field on each order entered in the batch and allows the data entry person to enter either YES or NO. This will default to the value on the product, i.e. if the product is set to auto renew no, the default is no and if the product is set to auto renew yes, the default is yes. Be certain to leave the field blank to change the auto renewal flag on previously posted orders.
Paid Order Entry
The field will default to the value set on the batch (Y or N) or to the value on the product if the value on the batch is left blank. If different rate codes have been defined for autorenewal orders, data entry needs specific instructions on how to choose the correct rate. If an autorenewing subscriber wants to complete his current subscription but not autorenew beyond that point, data entry would:
• Mark Do Not Renew yes to suppress future auto renewals and renewal statements.
• If the subscriber should be solicited to renew but not have renewals automatically created, then the autorenew flag should be set to no. If a future autorenewal has already been created, it needs to be cancelled.
• If an autorenewing subscriber wants to cancel his subscription immediately, the current and any future created orders need to be cancelled.
Customer Service
To determine if a particular subscription is autorenewing, select the subscriber in Inquiry. Choose #2 for Prod Info and select the appropriate order for the product in question.
Look in the middle left column at the “Autorenew?” field. “Yes” means the subscription will be autorenewed in the future (if it remains active). “No” means the subscription will not be autorenewed in the future. (Please note that the Autorenew Yes/No field does not tell whether a particular order was created as an autorenewal, only what will happen in the future).
2. Issue Labels procedures
Assign appropriate Ship Dates on Label Batches. The Ship Date assigned on the Label Batch is a very important date for autorenewals. It is used as the Order Date for an autorenewal created when the Label Batch is posted. If invoicing is based on Order Date, then it is also used as the first effort date the autorenewal can be invoiced. If aging is based on Order Date, then it is also used as the Aging Date for the autorenewal. The Ship Date must be in the current accounting period at the time the Label Batch is posted. It is therefore helpful to establish clear guidelines for assigning the appropriate Ship Date on Label Batches.
In order to obtain the timing wanted with autorenewals, it is important to process Issue Labels according to a strict schedule for autorenewals created with label runs. The autorenewals are created when Issue Labels are posted. Once created, the invoice cycle begins. At the proper timing, the order is typically suspended and/or cancelled if they are not paid. The timing of each of these events is influenced by when the autorenewal was created and , therefore, dependent upon the Issue Label schedule.
3. Non-Spooled Invoice procedures
In order to retain proper timing, it is important to process Non-Spooled Invoices according to a strict schedule. Autorenewals are usually eligible for invoicing as soon as they are created (when invoice with order). At the right point in the invoice efforts, the autorenewals are typically suspended and/or cancelled if they are not paid.
The setup and procedures described thus far prepare the system to accept new subscriptions as autorenewals. If existing subscriptions should be converted to autorenewals, carefully consider the timing and affect on orders before making the changes to product setup. If necessary, extend expiration dates of current orders and change autorenew flag to yes so that the timing of the first autorenewal is correct. (If this is an audited publication, this may not be an option; please discuss the issue with the auditor). Another option may be to manually create future renewals marked auto renewal yes, whether or not the subscriber has requested a renewal, to kick off the process. If a subscriber is on an active renewal campaign that has recently changed to auto renew, use Campaign Maintenance and delete it from the campaign.
Oversee the autorenewal process
There are various reports that may help oversee the autorenewal process:
• Data Entry Edit Lists for the batch created for auto renewal transactions.
• The Detailed Autorenewal Report (under Accounting / Activity Reports) lists each autorenewal, order by order, that was created for a time period specified, especially helpful when create orders for autorenewals rather than transactions.
• The Summary Autorenewal Report (under Accounting / Activity Reports) lists summary information, including sales totals by product, for autorenewals created for a time period specified.
• Queries allow selection of both those subscriptions that are currently set up to Autorenew in the future AND whether or not the individual order was created from an automatic renewal. Be sure and note the description when generating queries.
For those who work directly with the database files, the following technical information may be of use. There are two fields related to autorenewals. One is stored on the SC file and is called ARNWL. This field represents whether the subscription should autorenew in the future. This is the field that is used in queries. It is also the field that is displayed in Inquiry when the “Autorenew?” field is viewed. The other field is stored on the ORD file and is also called ARNWL. This field represents whether this particular order was created by the system as an autorenewal.