Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This section guides the user through the menu options that are available under the Subscriber menu.
Circulation considers printing a renewal notice a transaction (this allows the system to distinguish subscribers who have received their 1st, 2nd, and 3rd renewal notices for a period, etc.). Select this option to reverse renewal notice transactions. This is a necessary step when errors occur during renewal notice printing.
Undoing renewal notices is not recommended if the renewal notice batch has already been sent to the printer.
You can also use this option to undo an eBill batch, if you e-mail electronic renewal notices via the Send eBill option.
When you undo renewals, the Printed Bill Fee is deleted along with the renewal transaction. Refer Renewal Notices, Customer Services | Transactions | Renewal Notice and Customer Services | Financial | Fees.
Select Undo Renewal Notices from the Subscriber menu to display the Undo Renewal Notices window.
Click Add and enter the product, run date, and other information about the undo process in the fields described in the table below.
PRODUCT
setup
Enter the product for which to reverse renewal notice transactions.
RUN DATE
date
Enter the date for which renewal notices should be reversed for this product.
UNDO PRINTED BILLS, UNDO EBILLS
yes/no
If an eBill batch exists for this product and date, these fields are active. Check Undo Printed Bills to undo renewal transactions for non-eBill subscribers. Check Undo eBills to undo an eBill batch.
EBILL BATCH
setup
If Undo eBills is checked, enter the eBill batch that should be deleted.
An eBill batch can be undone as long as e-mails have not yet been sent for it.
DELETE GRACE EXPORT TRANSACTIONS
yes/no
If grace owed transactions were exported with the renewal information (Print Grace Owed was checked in Renewal Notices) this field opens.
Flag the checkbox if grace owed export transactions should be removed with the renewal transactions.
Click OK and then Continue to undo the renewals.
A refund may be available to subscribers who are permanently stopped (the amount would be the remainder of their subscription). The subscribers, however, may never claim this refund, and after a certain number of days (defined in Business Rules) the publication can “write off” this refund. Business Rules determine how many days a refund may be kept available.
When you select this option, Circulation finds all refunds that can be written off, based on the number of days a subscriber refund should be maintained as available. For example, if the number of days is “180”, only refund amounts that have been maintained as available for longer than 180 days will be written off. A report will be created as part of the process, and refund writeoff information may be exported to an ASCII file in the /dti/exchange/cm directory (see Appendix B).
Select Refund Writeoff from the Subscriber menu to display the Refund Writeoff Report window.
Click Add and complete the following fields.
PRODUCT
setup
Enter the product for which to write off available refund amounts.
CUTOFF DATE
date
Enter the cutoff date for writing off refunds. Any available refund whose transaction date plus the writeoff days from Business Rules is on or before the cutoff date will be written off. For example, if the writeoff days is 30 and the available refund transaction date is September 15, the cutoff date must be on or after October 15 in order to write off the refund.
ACTIVE SUBSCRIBERS
yes/no
Indicate whether refunds should be written off for active subscribers. If this checkbox is not selected, refunds will be written off only for inactive subscribers.
RUN TYPE
predefined
Specify whether refunds for amounts over or under a certain amount should be written off, or both.
ALL STATES STATE
yes/no setup
Select the state or states to include, or select All States.
WRITEOFF LIMIT
decimal (10)
If Run Type is “over” or “under”, enter the refund amount limit here. For example, if RUN TYPE is “over” and Writeoff Limit is 20.00, only available refunds of over 20.00 will be written off. If a refund writeoff limit has been entered in Publication Setup (see Publication in the Setup Manual), it will be displayed here and cannot be changed.
WRITEOFF
yes/no
Indicate whether to write off available refund amounts. Print the Refund Writeoff Report to review the items that will be written off before selecting this checkbox.
G/L TRAN DATE
date
If transactions should be written off (i.e., WRITEOFF is selected), enter the general ledger date for these writeoff transactions.
SOURCE
setup
Enter a source code for this writeoff, such as “accntg”.
REASON
setup
Enter a reason code for this writeoff, such as “old”.
EXPORT, FILE NAME
yes/no, open (15)
If refund writeoff information should be exported to an ASCII file, select Export and enter additional information in the Export Header Information panel. Then, in file name, enter the file name.
Click OK and then Continue to proceed with the writeoff. As part of the writeoff process, the Refund Written Off report will be created, listing subscribers who have had available refunds written off. Once they have been written off, the “refund available” transactions change to “refund writeoff” (RefundWOFF) in the subscribers’ transaction history window.
A newspaper may wish to export available refunds created in Circulation for use by another software program. For example, the export could be used to create letters to customers with an available refund. This option, Avail Refund Export, will export available refunds to an ASCII file in the /dti/exchange/cm directory. Available refunds can be exported based on the date of the available refund and the refund amount. Once a subscriber’s available refund is exported, they will have a RefundExprt transaction, which will prevent the available refund from being exported again.
Select Avail Refund Export from the Subscriber menu to display the Available Refund Export window.
Click Add and complete the following fields.
PRODUCT
setup
Enter the product for which to export available refunds.
START DATE, END DATE
date
Enter a date range for the export. Available refunds created within this date range will be included in the export based on this date range.
RUN TYPE
predefined
Indicate whether refunds that are over or under the limit entered below should be exported.
REFUND LIMIT
decimal (7)
Enter a refund limit. Available refunds over or under this limit (depending on what is entered in Run Type) will be exported. To export all refunds, set Run Type to “over” and enter zero here.
ALL STATES STATE
yes/no setup
Enter the state or states to include, or select all states.
FILE NAME
open (15)
Enter a file name. Available refunds will be exported to this file in the /dti/exchange/cm directory.
PRINT DETAIL
yes/no
Indicate whether the processing report should list the available refunds exported.
Click OK and then Continue to export the available refunds. The available refunds will be exported to the file name specified; see Appendix B for the format. A processing report will list the available refunds exported (if Print Detail was selected) as well as totals.
Some newspapers send notices to subscribers in grace, informing them of the grace amounts they owe. This can be done using this option to export a list of grace-owed subscribers and amounts to an ASCII file. This file can then be imported into another application (such as a word processor) to print the actual bills.
Business Rules determine the minimum grace-owed amount that will be included in the export. Subscribers whose grace owed is below this minimum will not be included.
Select Grace Owed Export from the Subscriber menu to display the Grace Owed Export window.
Click Add and complete the following fields.
Click OK and then Continue to run the export. The ASCII file will be named gracemmddyyyy-sss (where “mm” and “dd” are the month and day, “yyyy” is the year, and “sss” is a sequence number) and will be located in /dti/exchange/cm (see Appendix B for the file format). Exporting grace creates grace export transactions for the subscribers included.
PRODUCT
setup
Enter the product whose grace owed information should be exported. Enter “*” to multi-select products.
RUN DATE
date
Enter the date on which to base the export. Grace owed amounts will be selected and exported as of this date.
GRACE OWED TYPE
predefined
Indicate whether Circulation should export only start & bill subscribers (subscribers who have not made a payment), only renewal subscribers, or both.
FILE FORMAT
setup
Select the file map to use for this export. A file map must be set up previously.
FILE NAME
open
You can accept the default file name or modify it.
Some newspapers print invoices for their carrier collect subscribers, which they give to their carriers. The invoice tells the carrier how much to collect from the subscriber for a particular period. This is useful, for example, in cases where the newspaper wants to extend promotions to carrier collect subscribers, or has a number of carrier collect subscriber rates. CC Invoice Export is the option that produces carrier collect invoices. It writes invoice information to an export file, which can then be imported into a word processor or other system for invoice printing.
Carrier collect invoices can be created for all carrier collect subscribers on routes in the area selected.
Carrier collect invoices can be created for carrier collect subscribers who have had certain activity before or after a particular date (the billing date) within the period—this is known as “in between” billing. The reason code of a transaction determines whether it should cause a carrier collect invoice to be generated.
In order to print carrier collect invoices, the Business Rule, Are carrier collect invoices produced? (Account Finance section), must be set to “y”. The Print CC Invoices field in Route Setup (see Home Delivery Route in the Setup Manual) determines whether invoices will be created for a particular route. And the next field, Bill When, determines whether the invoices are created in arrears or advance. These two terms are also used in account billing, and have a similar meaning:
If a route prints in arrears, the amount on the carrier collect invoice is based on the subscriber’s draw in the current period. This will be the actual draw for days published, and projected draw for unpublished days (not pending draw—unprocessed transactions will not be taken into account).
If the route prints in advance, the amount on the carrier collect invoice is based on the subscriber’s projected draw in the next period.
If the actual draw turns out to be different from the projected draw (for example, because of a delivery schedule change or temporary stop), there will not be an adjustment on the next period’s invoice—it is up to the carrier to modify the amount collected accordingly.
When it generates invoices, CC Invoice Export will bill carrier collect subscribers for a certain billing period. The amount owed that appears on the invoice will be calculated using the subscriber’s rate, in the same way an office pay subscriber is rated (see About Subscriber Rating for more information).
Billing periods for carrier collect invoices are independent from account billing periods and must be set up in advance, using the CC Invoice Calendar (see CC Invoice Calendar in the Setup Manual). The billing dates themselves must also be set up, on the CC Run Date Calendar (see CC Run Date Calendar in the Setup Manual). Only one billing date should be set up per billing period.
The billing date is entered when CC Invoice Export is run, and indicates the billing period that should be used. The billing date also defines what transactions are picked up when “in between” billings are done—our next topic of discussion.
As mentioned before, CC Invoice Export can be run to include all carrier collect subscribers (the regular billing) or subscribers with transactions before or after the billing date, based on the reason code of the transaction (“in between” billing). If running an “in between” billing, you can specify whether transactions with transaction dates before the bill date (Before Batch) or after the bill date (After Batch) should be considered.
Whether or not a transaction causes an invoice to be generated is governed by the reason code. Two fields in Reason Code setup, Generate Arrears and Generate Advance, control this (see Reason in the Setup Manual). Generate Arrears is used when CC Invoice Export is run for arrears; Generate Advance is used when this option is run for advance. Each field has four possible settings:
Before Batch. Transactions with this reason code will cause an invoice to be created if the transaction date is before the bill date and CC Invoices is run with the Before Batch option. The bill will reflect the amount owed from the start of the billing period to the transaction date.
After Batch. Transactions with this reason code will cause an invoice to be created if the transaction date is after the bill date and CC Invoices is run with the After Batch option. The bill will reflect the amount owed from the transaction date to the end of the billing period or (if running for advance) the end of the next billing period.
Both. Transactions with this reason code will cause an invoice created in both the “before” and “after” scenarios described above.
Never. Transactions with this reason code will never cause an invoice to be generated.
Different transaction types will typically have different settings. For example, it makes sense to set a stop reason code to “Before Batch”. Then, if CC Invoices is run before the bill date, an invoice will be printed for the stopped subscriber, and the carrier can collect sooner (before the subscriber moves out of town, for example). In contrast, it makes more sense to set up start reason codes to “After Batch”—this insures that start transactions occurring after the bill date will produce invoices for that period (if you wait until the next bill date, the amount owed in the current period will not be included in the invoice). You may want other transactions, such as reroutes, set to “Both”.
Three common scenarios for “in between” billing are given in the following illustration.
To generate carrier collect invoices, follow the procedure below:
Select CC Invoice Export from the Subscriber menu to display the Carrier Collect Invoice Export window.
Click Add and complete the following fields.
PRODUCT
setup
Enter the product for which you are generating carrier collect invoices.
RUN DATE
date
Enter the billing date for the invoices. This date must be set up in advance on the CC Run Date Calendar. Note that you do not have to be generating the invoices on this date—the run date is simply used to indicate the billing period to use and determine what transactions to include, if this is an “in between” billing.
COLLECTION TYPE
predefined
Indicate whether invoices should be created for routes that bill in arrears (for current billing period) or advance (for the next billing period).
RUN TYPE
predefined
Indicate whether invoices should be created for all subscribers (regular billing), or only subscribers with transactions that have transaction dates before the billing date (before batch) or after the billing date (after batch) and applicable reason codes.
START DATE, END DATE
date
If this is an “in between” billing (i.e., “before batch” or “after batch” are entered in the field above), enter the date range for the billing. Only transactions with transaction dates within this date range will be considered.
SELECTION AREA
predefined
Indicate the area for which you are generating carrier collect invoices. You may pick certain routes, include all routes in an area, region, distribution zone or district, or include all routes.
SELECTION
setup
Enter an area, region, zone, district or route, or enter * to multi-select areas. If you entered “all” above, this field will not open.
Click OK and then Continue to generate the invoices.
When processing is complete, the file ccinvddmm (where d=day and m=month) will be created in /dti/exchange/cm. See Appendix B for the format of this file. The Carrier Collect Invoice Export report will be produced, listing information about the process.
Your publication may have a grace period for subscribers who have passed their expire date without any new payments. For a certain number of grace days, then, the subscriber is receiving “free” papers. If they later send in a payment, the cost of these days (the “grace owed” amount) may be deducted from the payment (depending on Business Rules). For example, if a customer paid for three months of the Daily Bulletin, but had two weeks of grace, the subscription would only last for two and a half months.
Another situation arises when a customer in grace does not end up sending in a payment—they become permanently stopped after being in grace a specified number of days. At some point this grace amount must be “written off”—that is, the amount must be transferred from Subscription Accounts Receivables to Bad Debt in the general ledger.
Use this option to write off grace. Grace can be written off in the GL, in Customer Service, or in both places. For example, you might want to write off grace in the GL for fiscal reporting reasons but retain it in Customer Service in case the subscriber later sends a payment (allowing the grace owed to be paid).
The number of days subscribers stay in grace before they are stopped, and the number of days that must elapse before a grace owed amount can be written off, are tied to the subscriber’s credit status. All grace amounts where the grace end date plus the number of days specified in Setup is less than or equal to the cutoff date, will be written off.
Note:
Grace will not be written off for subscribers who have pending (unprocessed) payments.
Select Grace Writeoff from the Subscriber menu to display the Grace Writeoff Report window.
Click Add and complete the following fields.
PRODUCT
setup
Enter the product for which Grace Owed transactions should be written off, or enter “*” to multi-select products.
CUTOFF DATE
date
Enter the cutoff date on which the writeoff selection should be based.
ACTIVE SUBSCRIBERS
yes/no
Indicate whether grace should be written off for active subscribers. If this checkbox is not selected, grace will be written off only for inactive subscribers.
SEPARATE WRITEOFF
yes/no
Indicate whether grace should be written off separately for Customer Service or the GL. If this checkbox is not selected, grace will be written off in both places.
SELECTION TYPE
predefined
You can choose to write grace off only in the GL, in which case the grace owed amount would still appear for the customer and be deducted from payments in Circulation. If so, enter General Ledger here. If, conversely, grace should be written off in Circulation but not in the GL, enter Customer Services. If grace should be written off in both places, enter “*” (note, however, that grace owed will only be written off for Customer Service if the grace period has ended). This field will only be active if Separate Writeoff, above, is selected.
WRITEOFF
yes/no
Indicate whether grace owed transactions should be written off. You may want to run this option initially without Writeoff selected to see which grace owed amounts will be written off.
G/L TRAN DATE
date
If transactions should be written off (i.e., Writeoff is selected), enter the general ledger date for the writeoff transaction.
SOURCE
setup
If grace will be written off, indicate the party that originated the writeoff (for example, “DM”).
REASON
setup
If grace will be written off, indicate a reason for the writeoff.
CHANGE CREDIT STATUS
yes/no
Indicate whether to change the credit status of subscribers whose grace is written off. Circulation will change the credit status to the Stop Credit Status setting of the subscriber’s current credit status, as defined in Credit Status setup (see the Setup Manual).
IS WRITEOFF NOW UNPAID
yes/no
When this checkbox is selected, in addition to performing the usual grace writeoff processing, a suspended batch of draw adjustments will be created to change the draw from “paid” to “unpaid” for AAM purposes. The name of the batch will be “GW” followed by the GL Tran Date entered (yymmdd format) followed by a four-digit sequence number. This checkbox is active when: • The Active Subscribers checkbox is not selected • The Selection Type is * (all) or Customer Services • The Writeoff checkbox is selected • Transaction Security, GraceWOffUnpaid, is activated
Click OK and then Continue to proceed with the grace writeoffs. The Grace Writeoff Report will be produced as part of this process. When Grace Owed has been written off, the Grace Owed transaction changes to Grace Writeoff in the subscriber’s transaction history window.
The Send eBills option can be used to e-mail electronic renewal notices to eBill subscribers who qualify for renewal. The e-mail can be in HTML or text format, and Circulation uses templates to determine the e-mail content. If you do not support the eBill renewal delivery method, or if your eBill renewal notices are generated outside of Circulation, you do not need to use this option.
Below is an example of an eBill e-mail. Note that only one amount appears on the notice—the amount of the subscriber’s current rate term. If the subscriber makes a payment in iServices by clicking the Make a Payment link, all of the qualifying rate terms will display.
In order to e-mail renewal notices to your eBill subscribers, you must:
Have the Business Rule— Should E-bill emails be sent from Circulation to E-bill subscribers? (Subscriber Billing section) set to “Yes.”
Have the Business Rule— Which mode should Send eBills be run in? (Email section) set to “Live.”
Customize the eBill e-mail templates to reflect your publication’s look and feel. Different templates can be utilized, based on the notice number and whether you are sending renewals or invoices. See E-mail Templates for information on customizing these templates.
Run Send eBills in test mode, as described in “Testing eBill e-mails” below.
Run Renewal Notices, which creates an eBill batch as part of the process. Send eBills is run for a particular eBill batch. Once an eBill batch is created, it can be deleted by Undo Renewal Notices, as long as the e-mails have not been sent.
See FAQ #115 for more information about eBill renewal notices.
Follow the procedure below to send eBill e-mails.
Select Send eBills from the Subscriber menu to display the Send eBills window.
Specify the product and run date for the eBills, and then select the eBill batch (only unsent eBill batches for that product and date can be selected).
Check Send Emails to actually send the e-mails. If left unchecked, no e-mails will be sent, but the processing report will display.
Note:
If the Business Rule— Which mode should Send eBills be run in? is set to “Test,” e-mails will not be sent even if Send Emails is checked. Instead, a window will display prompting for the number of test e-mails to send, the test e-mail address, and whether or not the notices in the batch should be marked as sent.
Select OK and then Continue to run the Send eBill process. When complete, a processing report will display, showing processing messages and listing accounts selected for eBill e-mails.
If e-mails are sent, they will be in HTML or text format using the e-mail template matching the bill type (invoice versus renewal notice) and number. The e-mail “from” address, name, and BCC address will be based on Business Rules. The subject will by default be “Bill now available.” However, that text is stored in a resource message and can be modified using Circulation’s Translation feature.
Once the e-mail is sent for a subscriber, it will be flagged as sent, so that the eBill e-mail cannot be sent again.
Before sending eBill e-mails in a live environment, Newscycle recommends carrying out a testing program, as outlined below.
Copy the renewal notice e-mail templates to your custom template folder and modify them to meet your publication’s look and feel.
Set the Business Rule— Should E-bill emails be sent from Circulation to E-bill subscribers? to “Yes” and Which mode should Send eBills be run in? to “Test.”
Find some test subscribers with a renewal delivery method of “eBill” who are due to receive their renewal notices or invoice.
Run Renewal Notices with “eBill” selected for the Renewal Type.
Run Send eBills with the Send Emails checkbox flagged. You will be prompted for testing information (the number of subscribers to test and test e-mail address, such as your own e-mail address).
Confirm that the correct number of eBill renewal notices were e-mailed to the test address, and that the format and content are correct. Be sure to check all of the links in the e-mail, and view the e-mail with different e-mail clients (such as Outlook and Gmail).
When you run the Auto Notice Export, Circulation creates an ASCII file of subscribers with subscriptions that expire within a certain number of days (defined in Setup—see Publication in the Setup Manual). This file can then be incorporated into a form letter using your word processor. See Auto Notice Export Format for the formats.
When it searches for subscribers who should receive an auto-renew notice, Circulation will use three values: the run date that you specify, the expiration date for the subscriber, and the number of notice days specified in setup. If a subscriber has already had an auto-renew notice for this expiration date, that subscriber will not be selected.
If the expire date minus the run date is less than or equal to the notice days, the subscriber will be selected for an auto-renew notice:
Subscriber Expiration Date - Run Date <= x Where x = number days from Auto Renew Term
For example, if the run date is 12/15, and auto-renew notices are generated 4 days before the expiration date, an auto-renew credit card subscriber with an expire date of 12/18 would be selected (18 - 15 <= 4). So would a subscriber with an expire date of 12/12, provided a notice had not already been sent (12 - 15 <=4). A subscriber with an expiration date of 12/21, however, would not be selected (21 - 15 > 4).
Any unprocessed payment, auto-renew, or transfer-in transactions may push the expire date beyond the run date.
An auto-notice transaction has been sent since the last auto renew and a message will be sent to the log file for any skipped subscribers.
Select Auto Notice Export from the Subscriber menu to display the Auto Renew Notice Export window.
Click Add and complete the following fields.
PRODUCT
setup
Enter the publication for which you will send auto-renew notices.
RUN DATE
date
Enter the date on which the notices will be printed. This field defaults to the current date.
RENEWAL TYPE
predefined
Indicate whether you want to select subscribers who pay by Bank Draft, Credit Card, PayPal, or All. If you select All, all types of auto-renew subscribers will be selected.
NOTICE TYPE
predefined
Indicate if this export should include only Trial End, Auto-Renew, or both notices.
Trial End — returns a list of auto-renew subscriptions that have a Trial active on them)
Auto-Renew — returns regular auto-renew subscriptions, and
Both — returns a combination of the two subscriptions mentioned above.
BILLING GROUP
setup
Select the auto-renew billing group from which you want to select subscribers.
INCLUDE PENDING RATE CHANGES
yes/no
If subscription-length pricing is being used, select this checkbox if you want pending rate changes to be considered when valuing subscription terms.
PRINT RATE CHANGE ONLY
yes/no
Indicate if the export should include only those subscribers whose next auto-renew will be at a different rate.
PRINT BY ROUTE
yes/no
Indicate if the notices should be exported in route order. This is helpful if the notices will be delivered by carriers. If you do not export the notices by route, they will exported in mail sort order (by Zip code, street, and house number).
GENERATE CREDITS
yes/no
If the notices will be delivered by carriers, indicate whether carriers should receive Targeted Marketing credits for the delivery. You must have a TM rate defined for your product in order to do this (see Account Rates in the Setup Manual).
DELIVERY DATE
date
If the notices will be delivered, enter the delivery date.
USE FILE MAP
yes/no
Select this checkbox if you want to create an export file.
FILE FORMAT
setup
Select the file map to use for this export. A file map must be set up previously.
FILE NAME
open
You can accept the default file name or modify it.
Select Continue to create the file. As part of the process, a report will be created listing any errors that occurred during processing, and other information. An auto-renew transaction will be created for the subscription.
The Refund Journal lists all subscribers who have been paid refund amounts within a specified date range or in a specified batch. Subscribers who have available refunds but no refund payment transaction do not show up on the report. The Refund Journal will, however, include subscribers in suspended refund payment batches.
Select Refund Journal from the Subscriber menu to display the Subscriber Refund Journal window.
Click Add and complete the following fields.
PRODUCT
setup
Enter the product for which to list subscriber refunds.
REPORT TYPE
predefined
Indicate whether you want the report to print for a batch, an entry date range, or a transaction date range.
BATCH
open (10)
If you are printing the journal for a specific batch, enter the batch name here.
START DATE, END DATE
date
If you are printing the journal for an entry or transaction date range, enter the date range here. Print a monthly Subscriber Refund Journal to balance with the General Ledger report.
REFUND TYPE
predefined
Indicate whether bank draft refunds, cash refunds, credit card refunds, manual refunds, PayPal refunds, or all should be listed in the journal.
SORT OPTION
predefined
Indicate if you want the report sorted by subscriber name, account, refund sequence, or operator.
SUSPENDED ONLY
yes/no
Select this checkbox to include only suspended batches in the report; do not select it if you want to include all batches.
BILL TO ADDRESS
yes/no
Indicate whether the subscriber’s bill-to address should appear on the report along with their delivery address, if the two are different.
EXPORT
yes/no
Select this checkbox if you want to create an export file.
FILE FORMAT
setup
Select the file map to use for this export. A file map must be set up previously.
FILE NAME
open
You can accept the default file name or modify it.
Click OK and then Continue to produce the report.
Use this option to enter refunds for subscribers. You can enter a refund for any subscriber (based on Business Rules), but a warning will appear unless the subscriber has an available refund, which means the subscriber has a stop transaction with a balance.
For a list of subscribers with available refunds, print the .
Business Rules determine the amount by which a refund may vary from the refund amount due (if the subscriber has an available refund) and how many days a refund may be kept available. Business Rules also determine whether refunds are interfaced with SBS (DTI Standard format), Compu-Share, Dunn and Bradstreet, Great Plains, JD Edwards, Lawson, or PeopleSoft software systems and, if so, whether different vendor information should be supplied for each subscriber.
Note:
You will not be allowed to modify or delete a refund batch if it contains credit card refunds that have already been authorized (i.e., through real-time credit card authorization in Customer Service).
Select Batch Refunds from the Subscriber menu to display the Subscriber Refund Batch screen.
Enter batch default information in the fields on this screen.
Select Accept to accept the batch defaults.
The refund entry screen will display next.
Depending on what was entered in Selection Option, some subscriber refunds may already be added to the batch. If not, enter refunds for each subscriber, one at a time; you may also need to delete some refunds if they were added by the system but you do not wish to give a refund to the subscriber. The following describes the columns on this screen.
When you have entered all refunds, press F4 and select Accept. You may also Suspend the batch and come back to it at a later time. If you interface the refunds to SBS, PeopleSoft, Compu-Share or Lawson, additional fields for vendor information will open up after you Accept the batch of refunds. Depending on how Business Rules are set up, you may be prompted for vendor information for each subscriber in the batch individually, or only once (with the same vendor information used for all subscribers).
If the total number or amount of refunds entered does not match the total number or amount entered for the batch, you must either modify the refund information or the batch totals.
If you interface refunds to another application (as determined by the Business Rule— To which system should refunds be automatically interfaced?), an ASCII file will be created for the refunds. This file will be named aprefund.d and be located in /dti/exchange/cm/secure. If the subscriber payment was via credit card, the refund will instead be exported to a special credit card file, ccrefund.d. See Appendix B for the refund file format.
If credit cards are exported in the Edgil format, credit card refunds will be exported to the file edgilrefcc[pub].mmddyyyy[x], where [pub] is the publication ID, [mmddyyyy] is the month, day and year, and [x] is a sequence number. The file will be in the Edgil credit card payment format (see Appendix B), but the transaction code is “CR” (for credit).
In the case of SBS and PeopleSoft, a vendor file, apvendref.d, will also be created in the same directory. This file contains the vendor information and can be used to create vendor IDs and vendor company IDs in your general ledger system. Information in all files is appended, not written over; therefore when you read these files into your general ledger system you should remove them from /dti/exchange/cm. The format for the vendor file is the same format used with carrier credit transfers to Accounts Payable (see Appendix B). If you use PeopleSoft, no vendor file is created.
Refunds can be entered for combo subscriptions, using one of the component publications of the combo.
If a combo with a balance is perm stopped, available refunds are created for each component publication, and these in turn can be accepted as individual refunds by Batch Refunds. However, as long as the combo refunds are in the same refund batch, they are interfaced as a single refund. This means, for example, that a subscriber’s credit card will only be credited with one amount.
If manual refunds (refunds for subscribers that have no available refund) are entered for subscribers with active combo subscriptions, the manual refund will reduce the balance of all component products, and be interfaced as a single refund. If the combo is perm stopped, the refund will be only for the individual component product, and each product’s refund will be interfaced separately.
If a combo has pending payments, cancel payments, or transfer transactions, manual refunds will not be processed but will be placed in a separate refund batch with a batch name that starts with “RB.” Once the transactions are processed the “RB” batch can be accepted and the refund transactions will be created. If some, but not all, of the component products in the combo have unprocessed billing change, combo change, or expire transactions, or if the expire dates of the component products are out of sync, refunds will likewise be put in the “RB” batch.
When accepting an “RB” batch, if some refunds in the batch still have the pending transactions or out of sync expire dates described above, they will be moved to a new “RB” batch and not be processed. If none of the refunds in the batch can be processed, the user will not be allowed to accept the batch.
The option exports information about credit card subscribers due to auto renew. Credit Card Expires exports similar information, but does not create an Auto Notice transaction.
Select Credit Card Expires from the Subscriber menu to display the Credit Card Expires window.
Click Add and complete the following fields.
Click OK and then Continue to export the credit card auto renew information. The Expiring Credit Cards report will appear, listing the number of records exported and (if Print Details is selected) the auto renew subscribers. See Appendix B for the standard export format.
Renewal notices are notices sent to current office pay subscribers from whom you have received at least one payment and whose expiration date is approaching.
Invoices are bills sent to new start and bill subscribers (subscribers who start immediately and pay for their subscription later, and are therefore initially in grace). For example, an office pay subscriber might start a subscription and, two weeks later, pay for three months. The invoice would be for three months, but the subscriber at that point would owe for only two weeks.
Renewal notices and invoices have the same format, and they are printed together using this option. Circulation will print renewals or invoices for subscribers:
Who were flagged for invoice or renewal when their new start was entered,
Who have the delivery type you specify,
Whose expire date minus the current date is less than the days required for a notice number (or invoice number), and
Whose notice number or invoice number is selected to print.
The “notice number” mentioned above corresponds to the number of renewals sent to this subscriber for payment; i.e., “1st notice”, “2nd notice”, or “3rd notice”. Each notice number should be set up to be sent a certain number of days before expire. The days can vary depending on the publication, delivery method and other factors. For details, see Publication in the Setup Manual.
eBill subscribers, who receive an electronic rather than printed renewal notice, can be managed in one of two ways:
They can be e-mailed a renewal notice (in HTML or text format) via the option.
They can be exported to a file, either in a special eBill format, or in one of the standard renewal notice export formats, as defined by the Business Rules. Both eBill subscribers and/or “promotional eBills” (subscribers who are not on eBill but who are receiving a notice number specified in the Also Include Renewal Periods field for the eBill delivery method in Renewal Delivery Publ setup) can be included in this file, based on the Business Rule Which subscribers should be included in the ebill export file? The file can be used to generate and send electronic renewal notices outside of Circulation (for example, in PDF format).
Creating invoices and renewal notices with this option also creates subscription transaction records, such as “1st Renewal” or “1st Invoice”. These records are displayed in the Transactions portion of the Customer Service window. They tell Circulation the notice number for a subscriber. For example, to qualify for a 2nd renewal notice, a subscriber must have a “1st Renewal” transaction.
Notes:
Renewals will not be printed for temporarily stopped subscribers.
If subscribers have paid for grace days after their expire date, the grace paid days will be added to the expire date when determining whether the subscriber should be selected for renewals.
If you charge for bonus days using the “premium day” method (see ), subscription rates will include premium amounts for bonus days that occur within the term. In addition, if the Business Rule Should premium day detail be exported in renewals? is set to “Yes”, premium day information will be exported when using the Detailed Export 2 format or viewing dynamic renewal notices in iServices or Customer Service.
If you use PostWare and the Detailed Export or Detailed Export 2 format for renewal notices, and choose to include grace, the grace-owed records exported at the end of the renewal file will not be included in mail labels and associated mail reports. Only invoices and renewal notices will include grace owed.
Grace-owed records exported at the end of the renewal file will include all grace-owed amounts; not just those for the selected rate code.
Renewal notices can be viewed in HTML or PDF format in iServices Subscriber (see the iServices Subscriber Manual for details) and in Customer Service (see ).
It is recommended that the Business Rule—Limit renewal payment terms to last paid term and rates with longer terms? (Subscriber Billing section), be set to Yes only if you are using weekly rate terms in the Subscriber Rate Code Setup. The system calculates a term depending on the number of days calculated for purchase (regardless of actual term, "1 month" etc.). As a result, even though there are always only seven days in a week, the length of a one-month term might differ from month to month, leading to certain terms disappearing for certain renewals.
Before processing renewal notices for the first time, verify that there is at least one notice number set up for both invoices and renewals for each delivery method. Also, verify that at least one subscriber rate term is set up to print on renewals and invoices.
Subscribers on home delivery routes will have their notices and invoices delivered by their carrier/dealer, if the route they are on is set up to deliver renewals (see Home Delivery Route in the Setup Manual) and their renewal delivery method has not been overridden. If carriers deliver the renewal notices and invoices, Circulation calculates delivery credits by using the number of renewal notices/invoices delivered by a carrier/dealer and the delivery credit rate. Credits are processed during account billing. In order to generate credits, an account rate for the specified product with a draw type of “TMC” must be defined.
The subscriber has chosen not to opt out of Print Bill fees.
The subscriber is not set up for AutoRenew or E-Billing.
Subscribers are not included by the Business Rule— "How many days should elapse before a subscriber is eligible to receive another printed bill fee?". This rule prevents another printed Bill Fee from being charged to a customer within a specified number of days. Since each renewal term may only have one printed bill fee, this rule will only apply if the specified number of days exceeds the end of the current renewal period.
The subscriber must not have an unpaid Printed Bill fee.
The subscriber is due for an invoice or renewal.
Note:
You should run this option frequently to give all of your subscribers enough time to send in payments before their expiration dates.
Note:
Information printed on the renewal notice or invoice includes:
Subscriber name and address
Bill-to name and address
Subscriber ID, or account number
Messages (see below)
Expiration date. The expiration date will not be printed on start and bill invoices (the expire date on these invoices is the day the subscription begins)
Route, if applicable
Publication name (optional, based on Business Rules)
User-defined general message, if desired
The total number of renewals printed is displayed on the last renewal notice
Note:
Four types of messages can be printed on renewal notices, as shown below. Since some renewal notice forms (see the table that follows) cannot accommodate all messages, the message printing order is as shown.
Tax messages (if applicable for the subscription).
Renewal messages (defined by selecting Setup | Business | Publication | Specifics | Renewal Periods). These may contain one or two lines of information.
Rate messages (defined by selecting Setup | Accounting | Subscription Rates | Rate Code).
General messages (as entered in this option).
Export. This is a fixed length format
Export Delimited. This format contains the same information as the export format, but is pipe (|) delimited rather than fixed length.
Detailed Export. This pipe delimited format contains additional information, such as the last renewal date and grace owed amounts.
Detailed Export 2. This format is similar to the Detailed Export, but contains some different information, such as payment history and Fees-related fields Note: Fees-related fields are only displayed if FeeManagement add-on is activated.
eBill. If renewal notices are run for all renewal types or the renewal type of “eBill”, subscribers who have a renewal delivery method of “eBill” will not appear on the renewal notices (or be in the renewal notice export, if an export is used). Instead, these subscribers will be exported to a separate ASCII file, in a special eBill format. If the carrier or mail renewal delivery methods are set up to export subscribers picked for renewal or invoice to the eBill file (as defined in Renewal Delivery Publication setup), they will be exported to the eBill file in addition to printing on the renewal notices.
Business Rules determine the following things for invoices and renewal notices: the format that should be used (postcard, mailer, etc.), whether the publication name, Zip PostNet barcode, and carrier route should be printed, whether renewals should be printed for subscriptions automatically switched to carrier collect, how many days an office pay subscriber must be temp stopped before the last invoice or renewal is resent, whether term amounts are based on the subscriber’s expire date or last payment effective date, and (if using expire date) whether the expire date should be adjusted for temp stopped periods.
There are also some Postalsoft considerations: whether renewals should be sorted via Presort, if so what the job file name is and how long sort information should be kept, and whether Presort or Circulation should provide carrier route information on the notices.
For eBill renewal notices, Business Rules determine whether eBill e-mails are sent directly from Circulation, which subscribers should be exported to the eBill file, and the format of the eBill file.
Select Renewal Notices from the Subscriber menu to display the Renewal Notices window.
Click Add and complete the following fields.
If you are using PostWare to sort your renewal notices Standard A class mailing order (a Business Rules consideration), PostWare will produce different reports according to how your job file is set up. Among reports that could be produced are: a Mail Sort Listing, Form 3602 (statement of mailing), Job Summary, and Qualification Report. These reports will be saved to spool and can be printed from the View/Print Utility.
Once invoices/renewal notices have printed, verify that “Number of Errors” = 0 (as displayed on the last renewal notice). If there are any errors, select Utilities | System | Process Log to print the errors and then make any corrections.
To give a brief example of how subscribers are selected for renewal notices, let’s assume that renewal notices are run for 12/3 for notice numbers 1 and 2, and the renewal and invoice notice periods are as follows:
Assume further that our newspaper publishes every day and has the following office pay, carrier-delivered subscribers:
Ella started a subscription on Nov. 30 and has not received an invoice.
Renee started a subscription on Nov. 27 and received an invoice on Nov. 28.
Conrad’s subscription expires Jan. 15.
Julia’s subscription expires Dec. 12, and she has not received a renewal notice.
Abdul’s subscription expires Dec. 5, and he has not received a renewal notice.
Heidi’s subscription expired Nov. 22, and she has received two renewal notices.
Ella would qualify for invoice 1. Renee has already received invoice 1 and cannot yet receive invoice 2 (no invoice prints). Conrad’s expire date is too far out for a renewal. Julia will receive renewal 1 and Abdul renewal 2. Heidi would qualify for renewal 3, but we are not printing renewal 3 in this run.
Have e-mail configuration settings defined. This includes the type of e-mail sent (text or HTML) as well as the e-mail protocol, style set, BCC recipient, “From” name and address, and other attributes. E-mail settings are configured by website in .
After they are entered in Circulation, the refunds should be transferred to Accounts Payable in the general ledger, so that refund checks can be issued. This can be done manually by printing the and entering the refunds into Accounts Payable.
Once the renewal notices have been processed and the above criteria have been met, the customer will get a new renewal notice and be charged a new Printed Bill Fee. This will appear on the and .
Print the to verify there are no suspended subscriber payment batches.
If applicable, select to create a batch payments for subscribers with the automatic renewal option.
Select to verify that all subscriber payments have been processed.
Select Renewal Notices to print subscriber invoices/renewal notices. Verify that “Number of Errors” = 0 (as displayed on the last renewal notice). If there are any errors, select to print a list the errors. You may select , correct the problems and, when error-free, print the renewal notices again by selecting Renewal Notices.
If you export renewal notices, the errors sent to the process log will be listed in the export file. See .
Renewal periods and rates. If the subscriber was given a quote, only the quoted period and rate may be printed (see ).
Barcodes, if you are set up for barcode printing (see in the Setup Manual). See Circulation FAQ #113 for instructions on how to print Intelligent Mail (IM) barcodes.
If you export renewal notices, a recap will be included that shows the number of bills generated by delivery method, the notice numbers, and a total number of bills processed. It will also list the errors sent to the process log, rather than displaying the number of errors. See .
Instead of printing renewal notices, you may choose (in Business Rules) an export format that places renewal notice information in an ASCII file in /dti/exchange/cm. The file name will be renewalsmmdd, where mm and dd stand for the month and the day. Five export formats are available (see).
Click OK and then Continue to print the renewal notices. See for information about printing forms. Renewal notices and invoices are printed in the following order: mail with barcode, mail without barcode, and then route delivered renewal notices and invoices. If you use PostWare for renewal notices, the mail notices will be printed in Standard A sort order. The format of the notices (postcard, mailer, etc.) is determined by Business Rules. If one of the “export” formats is being used, renewal notice information will be placed in an ASCII file in /dti/exchange/cm.
If you have run renewal notices and/or invoices for a day and need to run them again, select so that another renewal notice will be generated for subscribers who have already received one.
SUBSCRIBER
setup
Enter the subscriber’s name, telephone number, or subscription ID. If more than one matching subscriber exists, a window opens so you can select the correct one. If no refund is due, a warning appears.
REFUND TYPE
predefined
Indicate whether this refund should be applied to a bank draft, credit card, or cash. If the refund is to a bank draft, a Bank Draft window will open so that you can enter the bank number, account number, and authorization number. If the refund is to a credit card, a Credit Card window will open so that you can enter the card number, expiration date, and authorization number.
NAME
display
The subscriber name is displayed.
AMOUNT
decimal (7)
If a refund is due, that amount is displayed here. The available refund is the subscriber’s account balance. This includes the subscriber’s wallet amount, if they have paid for undelivered premium days (see Paying for Premium Days). It may be necessary to override this amount. For example, a customer begins a “3 month satisfaction or 100% refund” subscription and, after one month, stops the subscription and wants the 100% refund. Amount shows the refund amount for two months, so you must override this to reflect the entire three months. The amount will display in the Refund column of the Unearned Revenue Report.
W/OFF?
yes/no
If the amount being refunded is less than the available refund, entering “yes” here will write off the entire balance.
PRODUCT
display
The product name is displayed.
ADDRESS
yes/no
If the refund should be mailed to an address other than the customer’s delivery address, set this field to “y” and enter the refund name and address in the window that opens.
PRODUCT
setup
Enter the publication for which auto renew information should be exported, or enter “*” to multi-select publications.
CUTOFF DATE
date
Enter the auto renew cutoff date, using the format MM/DD/YYYY (month, day, and year). Subscribers with an expire date that falls in or before this month will be included in the export.
PRINT DETAILS
yes/no
Indicate whether the auto renew information should be displayed as a report after the export is complete.
PRINT PRIVATE DATA
yes/no
If PRINT DETAILS is selected, indicate whether private banking and credit card information (such as account numbers and credit card numbers) should be displayed on the report.
DISPLAY OPTION
predefined
If you selected PRINT PRIVATE DATA, indicate here whether private credit card and banking information should be masked (only the last four digits shown) or displayed in full. Note that users without the proper security will not be able to see private data even if “full” is selected.
GENERATE TASKS
yes/no
Indicate whether tasks should be created. In order to create tasks, a task type and event must be defined for the report in Task setup.
FILE FORMAT
setup
Specify the file map to use for the export. The standard file map, CCExpireExp, will default.
EXPORT FILE NAME
open (12)
Specify a file name. The standard file name, ccexp.th, will default when the CCExpireExp file map is used. The information will be exported to this file in the /dti/exchange/cm/secure directory.
Post Card and Old Post Card
There is room to print two lines of messages; for example, one taxing authority (if applicable) and only one line of the Renewal message. If the subscription has a purchase order number, that number is printed instead of the Renewal message. If the subscription is not subject to tax, one line of the Renewal message and the Rate message or General message may be printed.
Mailer
There is room to print three lines of messages. If the subscription is taxable, up to two lines of Tax messages and one line of the Renewal message will be printed. If the subscription is taxable in one tax authority, one Tax message and up to two lines of the Renewal message will be printed (or, if only one line of the Renewal message is set up, that line and the Rate message or General message may be printed).
Envelope
There is room to print two lines of messages. It follows the hierarchy shown above; i.e., two lines of Tax messages are printed, if applicable, or two lines of the Renewal message are printed (if two are set up), and so on.
Canadian Mailer
There is room to print eight lines of messages: up to three Tax messages, two lines of Renewal messages, the Rate message, and the General message.
Tax Envelope and Two Tax
Same as Mailer, above.
Other Envelope
There is room to print two lines of messages. It follows the hierarchy shown above; i.e., two lines of Tax messages will be printed, if applicable, or two lines of the Renewal message will be printed (if two are set up), and so on.
Other Mailer
There is room to print five lines of messages. It follows the hierarchy shown above.
PRODUCT
setup
Enter the product for which to print subscriber renewal notices. Enter “*” to multi-select products.
RUN DATE
date
Enter the date for which renewal notices should be run. This date, along with the subscriber’s expiration date, determines whether a renewal is printed for the subscriber.
NOTICE NUMBER
predefined
Enter the renewal or invoice notice number (1st, 2nd, etc.) to include. Enter “*” to multi-select notice numbers.
PRINT INVOICES
yes/no
Indicate whether invoices should be printed.
PRINT RENEWALS
yes/no
Indicate whether renewal notices should be printed.
INCLUDE PENDING RATE CHANGES
yes/no
If subscription-length pricing is being used, select this checkbox if you want pending rate changes to be considered when valuing subscription terms.
SEPARATE BY GROUP
yes/no
If your renewal notice format is an export, indicate whether renewal notices should be exported to separate files, based on renewal group. See Renewal Group in the Setup Manual for more information.
NUMBER OF PAYMENTS
integer (3)
Subscribers can be selected for renewal notices based upon how many payments they have sent in since their start. Enter a payment range (between 0 and 999) here.
GENERAL MESSAGE
open (30)
Optionally, enter a general message to print on all renewal notices/invoices.
PRINT BY ROUTE
yes/no
Indicate whether the renewal notices/invoices for subscribers on home delivery routes should be printed in route order. Select this checkbox if carriers deliver renewal notices for their routes.
If you do not select it, all renewal notices print in Zip code order (or, if sorted by Presort, in Standard A class order). You cannot print by route if you entered “*” in Product.
GENERATE CREDITS
yes/no
If you selected Print By Route, the Print By Route window will open with this and the following three fields. Indicate whether to automatically generate credits for carriers for delivery of renewal notices. You may print a report of renewal notices delivered by your carriers for delivery credit by selecting Reports | Route | Delivery Credit.
DELIVERY DATE
date
If you selected Print By Route, enter the date that the carriers will be given the notices for delivery. A Business Rule (Subscriber Billing section) determines the days of the week that are valid for route delivery.
DEPARTURE
setup
If you are printing by route, indicate the truck departure order that should be used (routes print by truck, and trucks print in departure order sequence).
TRUCK SEQUENCE
setup
If you are printing by route, indicate the truck sequence that should be used (this determines with what truck and in what order within the truck a route will print).
PRINT GRACE OWED
yes/no
This and the following field are open for entry only if you are exporting renewal information in the Detailed Export or Detailed Export 2 formats (a Business Rules consideration). Indicate whether the export should include subscribers (active or stopped) that owe grace. If you select this checkbox, the ASCII file created by the detail export will also contain subscribers that owe grace, along with their grace owed amount.
TYPE
predefined
If you selected print grace owed, indicate which grace owed subscribers should be included in the export file: those that renewed their subscription at least once, were start-and-bill and never renewed their subscription, or both.
PRINT REBILLS
yes/no
If a route type change has been done to a group of routes (see Route Type Change), you might want to reprint renewal notices for subscribers on the routes affected. If so, select this checkbox.
REASON
setup
If you are printing rebills, enter the rebill reason code.
ALL RATE CODES RATE CODE
yes/no setup
Indicate whether renewal notices should be printed for all rate codes and, if not, enter the rate code for which to print renewals (enter “*” to multi-select). Renewals will be printed only for subscribers assigned to the rate codes entered here.
ALL START REASONS START REASON
yes/no setup
Indicate whether renewal notices should be printed for all reason codes and, if not, enter the reason code for which to print renewals (enter “*” to multi-select). Renewals will be printed only for subscribers whose start had one of the reason codes entered here.
ALL RENEWAL TYPES
yes/no predefined
Indicate whether renewal notices should be printed for all renewal delivery methods (carrier, mail, and eBill). If this field is set to “n”, a specific renewal delivery method can be entered in Type. If a specific renewal type is entered, only subscribers with that renewal delivery method will be selected for renewals.
ALL DELIVERY TYPES
yes/no setup
Indicate whether renewal notices should be printed for all delivery types (all route types, plus mail). If you enter “n” here, a Delivery Types window will open, allowing you to select specific route types and/or mail (renewal notices will be printed only for the delivery types selected).
1
20
1
0
2
5
2
-8
3
-10
BATCH
open (10)
Enter a name for this batch of refunds.
DESCRIPTION
open (30)
Enter a description for the batch.
REFUND DATE
date
Enter the date these refunds should be applied to the general ledger. This will be the GL transaction date.
SOURCE
setup
Enter a source code for the refunds. This is the party that originated the refund.
REASON
setup
Enter a reason code for the refunds. The code indicates why the refund has been given.
SELECTION OPTION
predefined
To make refund entry more efficient, the system can automatically add subscribers with available refunds to the batch. In this field, indicate whether to automatically include all subscribers with available refunds, or only those subscribers who have requested a refund as part of their stop. Select entry here if no refunds should be automatically added.
PRODUCT
setup
If you entered “all” or “requested” in Selection Option, this and the following three fields will open. Indicate the product for which available refunds should be automatically added to this refund batch.
REFUND TYPE
predefined
Indicate whether this batch may contain cash refunds, credit card refunds, bank draft refunds, or all.
BANK
setup
If the refund type is “bank draft”, enter the bank to which these refunds will be sent.
SHORT DESCRIPTION
open (10)
If the refund type is “bank draft”, enter a short description (e.g., “refund”) for the subscriber’s bank statement.
CUTOFF TYPE, CUTOFF AMOUNT
predefined
Refunds can be automatically included based on the amount of the refund. In Cutoff Type, indicate whether refunds should be included based on whether they are over or under the amount, which you then enter in Cutoff Amount.
CUTOFF DATE
date
Refunds are automatically added based on their available refund date. Only available refunds created before the date in Cutoff Date will be automatically added to the batch.
TOTAL CASH TOTAL
integer (7) decimal (11)
These two fields will open only if Selection Option is set to “manual”. Indicate how many refunds you will be entering and the total cash amount of the refunds.
OVERRIDE CC FILE NAME
y/n
This field and the next are active only when interfacing credit card refunds to ICVerify. If you use ICVerify and want to override the default credit card file name, enter “y” here, and the file name in cc file name. The file will be saved in the secure directory. If you enter “n”, the default file name of ccrefund.d will be used.
CC FILE NAME
open (30)
If applicable, enter a name for the ICVerify credit card file. The default is the batch ID.
Some states allow a subscription’s delivery cost to be exempted from taxes (see Trans Exclusion for more information). Newspapers that take advantage of this exemption may be required to inform subscribers of their delivery cost. Most office pay subscribers can receive this information via their invoice or renewal notice (transportation cost is included in the renewal export formats—see Appendix B). For the remaining subscribers, a special notice must be sent. This option, Trans Cost Export, exports delivery cost information to an ASCII file, which can be used to create the notices.
Note:
The Transportation Cost Export is part of the Taxing add-on feature. Contact the Naviga Global Support Center if you wish to purchase the Taxing add-on.
The Transportation Cost Export will include the following subscribers:
Auto renew subscribers who have auto renewed within the date range entered.
New office pay subscribers who have sent in a payment within the date range entered, but have not yet received an invoice.
All carrier collect subscribers who were active within the date range. In order to do this, the carriers must be credited for the carrier collect draw (the credit amount should be the tax on the transportation cost).
All subscribers (such as newspaper employees) assigned to a certain rate code.
Note: Subscribers who are tax exempt will not be included in the export.
As part of the export, a TM product set up to credit carriers for delivery of the notices can be processed.
Select Trans Cost Export from the Subscriber menu to display the Trans Cost Export window.
Click Add and complete the following fields.
PRODUCT
setup
Enter the product for which to export delivery costs.
START DATE, END DATE
date
Enter a date range for the export. Subscribers will be included in the export based on this date range.
RATE CODE
setup
Enter the rate code used for newspaper employees. Subscribers with this rate code will be included in the export. Leave this field blank if employees should not be specifically included.
UPDATE TM
yes/no
Indicate whether a TM product should be processed as part of the export.
TM PRODUCT, DELIVERY DATE
setup date
If UPDATE TM is selected, enter the ID of the TM product that should be processed for delivery credits. This TM product must be set up in advance and should be flagged for delivery credits. Also enter the delivery date for the notices—the TM delivery credits will be based on this date.
Click OK and then Continue to run the export. Delivery cost information will be exported to the file /dti/exchange/cm/TCEXPORT (see Appendix B for the file format).
