Batch Refunds

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 Available Refunds Report.

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).

To enter refunds to subscribers:

• Select Batch Refunds from the Subscriber menu to display the Subscriber Refund Batch screen.

  
• Enter batch default information in the fields on this screen.

  Field	Type	What to enter
  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.

• 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.

Field	Type	What to enter
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.

• 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.

Interfacing Refunds

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 Refund Journal and entering the refunds into Accounts Payable.

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.

Combo Considerations

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.