Standard AR Controller – Create AR Payment Action Button (101-ar-fea-024)

Standard AR Controller – Create A/R Payment Action Button

Overview

NOTE: The following specifications will change due to enhancements, and as such may change.

This standard controller can be setup on different Account Forms (Real Property, Misc. Billing, Self-Reported Tax…) in order to provide the user with an Action Button to create an A/R payment for the users to enter payments, deposits or voluntary payments against this Account.

  • The Create A/R Payment button can be used for all Sub-Systems (Real Property, Self-Reported Tax, Personal Property, Miscellaneous Billing, etc.)
  • The AR Record to pay is determined by the action button controller setup….
  • This action button can be secured by profile user and role.

Functionality

This controller is used in different standard Forms distributed with the system. It can also be added and configured on a customized form.

NEW! The action button will open a Cash Collection Form in a modal window. When the form is opened, the focus will be on the Cash Collection tab. Next, a new Data Payment Entry record is created. The Subsystem and Transaction Type will be set to the ones specified in the action button properties. Note that these fields will be disabled in the Cash Collection form. If there are any ID’s, or a payer name is specified, they will be auto-loaded and set. When the payment is saved, the AR Detail links will be added if needed. At the end of the process, if required, the Cash Collection is closed.

Configuration

To add or configure this controller on a a form see below:

 

Read More...

 

Govern New Administration (GNA)

To configure in GNA…

  1. On the GNA ribbon select Editors (tab) > Editors (group) > Profile Editor.
  2. In the Profile Editor, ensure that you have linked the cash collection form that will be opened by the AR Create Payment action button.

OpenForms Designer (OFD)

In the OFD, follow these steps…

  1. Select the action for action button, i.e., the Ar_CreatePayment_Action.

The following are the available properties with their associated descriptions.

  1. AutoCloseAfterSave : When checked, the modal window in which the cash collection form was opened will be closed after the completion of the payment.
  2. AutoSearchDatasetTypeCode : Chose the Dataset Type code that defines the ids that you want to auto load (e.g ar_id, p_id)
    • If this is not set the Auto load will not function properly
  3. AutoSearchIds : An expression that returns a list of ids seperated by “;” that you want to load in the cash collection form automatically
    • E.g of a the output of a the expression = “10;30;100” or “20”
    • If this is not set the Auto load will not function properly
  4. CashCollectionForm : The form that you want to open for the payment.
    • This must be a form that is linked to the current profile
  5. CashCollectionPayorNameId : An expression that returns a na_id that you want to set as the default payor for the payment
  6. CashCollectionSubSystem : The subsystem for the payment transaction.
  7. CashCollectionTransactionType : The transaction type for the payment transaction (Note: The transaction field on the cash collection form will be disabled so you should use this property to set the correct transactiontype)
  8. DetailLinkCreation : If checked, a detail link will be created for all the Ar Details that are created for the payment transaction.
  9. DetailLinkId : An expression that returns the link id that will be inserted for the new ar details links (AR_DETAIL_LINK.LINK_ID)
    • If this is not set, no detail link will be created even if the DetailLinkCreation property was set to true.
  10. DetailLInkType : The type for the new detail links (AR_DETAIL_LINK.LINK_TYPE)
    • If this is not set, no detail link will be created even if the DetailLinkCreation property was set to true.

 

 

 

 

Contact your System Administrator or Business Analyst for more information on this feature implementation in OpenForms.

 

Related Topics

 

 

101-ar-fea-024

 

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this.Loading...

AR – Inquiry Payment Plan

Accounts Receivable (A/R) Inquiry Payment Plan

Overview

The A/R Inquiry Payment Plan is used for defining a payment and calculating when payments are due. The form provides some flexibility. Payments can be received between dates and made for less than the amount specified in the Amount per Period field. The Next Payment Date field is updated when the full amount for the period has been paid.

Documentation

For the complete reference guide, see Govern Accounts Receivable.
For the A/R Transaction Rules, see 101-ar-001-AR-TransRulesGL.

Running Reversal and Refund Batch Processes

If you run the A/R Refund Posting or A/R Reversal Posting batch processes for a payment made through the Payment Plan, start with the last payment entered.

NOTE: Running one of these batch processes on a payment prior to this may corrupt the Payment Plan data.

Highlighting on Accounts with Payment Plans

To indicate that a payment plan is associated with an account, the text for the record is displayed in red in the Summary Detail.

Payment Plan Command Buttons

Save: Click Save to save the payment plan record.
Delete: If no payments have been made on the current payment plan, you can remove it by clicking Delete.
Show Detail:
Click Show Detail to display the payment plan details. This button is enabled after the record is saved at least once.

Payment Plan Fields

Plan Option (On/Off)
Select the On or Off option according to the status of the project. If required, you could set up all the payment plan parameters; then, turn on the plan when all conditions are agreed upon.

Payment Plan Information

Payment Option: The Payment option is displayed if the ACH (PAP) Supported via Payment Plan option is selected in GNA.

  • Manual: Select this option if you are processing a payment on a Payment Plan made in person at the counter.
  • Payment by ACH (PAP): Select this option for pre-authorized Automatic Clearing House (ACH) payments.
  • Postdated Check: Select this option for postdated checks.

Payment Period: Select an option for the payment period from the drop-down list, according to how often payments are to be made:

  • Semi-Annual
  • Every two months
  • Monthly
  • Quarterly
  • Weekly
  • Other: When you select Other, you need to enter a date in the Starting Date and Final Payment Date fields. The Periodic Budget field is disabled. Payments are automatically generated.

Number of Payments: Enter the number of payments required for the plan.
Periodic Budget: Enter the amount of the budget that is agreed upon for the selected period. This field is disabled when the Other option is selected in Payment Period.

Payment Information

Starting Date : Enter the date the payment plan starts. By default, the current date is displayed.
First Payment Date : Enter the date the first payment is due.
Final Payment Date: Enter the date the final payment is due. This field is active when the Other option is selected in Payment Period.
Next Payment Date: The next payment date is automatically displayed when the first payment is made and after each subsequent payment.
Last Payment Date: The last payment date is automatically displayed when the first payment is made and after each subsequent payment.
Last Payment Amount: The last payment amount is displayed when the first payment is made and after each subsequent payment.

Period of Interest/Penalty Information

Not Subject to Delinquent Charges: Select this option to exclude the current record from interest, penalties, and other delinquent charges.
Effective Date: Enter the date that the interest comes into effect.
Ending Date: Enter the last date that interest can be charged.

Payment Additional Information

Resolution Number: Enter a resolution (reference) number for the record.
Reason: Select a reason from the drop-down list. Reasons are user defined. Examples include Credit Memo, Debit Memo, Duplicate Payment, and Overpayment (Table: VT_USR_AR_ REASON).
Authorized By: Enter the name of the person authorizing the payment plan.

Payment Plan Details

When you click the Show Detail icon the Payment Plan Detail window opens.
This window displays information about the total amount due and the details for each pay period within the plan. For example, if the total is $12,000 and the payment period is monthly, 12 payment periods of $1,000 each are listed.
Amount Due: This field displays the total amount owing on the account.
Amount Distributed: This field displays the amount that is spread across the payment periods.
Difference: This field displays the difference between the Amount Due and the Amount Distributed.

Payment Period Information

The information in the grid is automatically calculated based on the amount due and the number of payment periods. The first column displays the number of the payment period. If there are 12 periods, the numbers 1 to 12 are displayed.
Due Date: This field displays the due date for each period. The dates are automatically calculated based on the starting date and the number of periods. Select a date and click the Calendar icon to change a due date if required.
Period Amount: This field displays the amount calculated for each period. This is based on the amount due and the number of periods.

  • You can change the amount due per period by overwriting the amount that is displayed. For example, if there is a small difference between the amount due and the amount distributed, you can add the difference to the first payment or spread it across all payments. If the total amount is uneven, you could add a small amount to the first payment in order to make the other amounts equal. When you change one amount, the others are automatically calculated.

Amount per Period: Enter the amount to be paid for each payment period.

NOTE: If you run the A/R Refund Posting or A/R Reversal Posting batch processes for a payment made through the Payment Plan, start with the last payment entered. Running one of these batch processes on a payment prior to this may corrupt the Payment Plan data.

 

Whats New!

Semi-Annual Payment Plan

The semi-annual payment plan will calculate the payment dates starting from the starting date, i.e. Begin Date, and then taking into account the user specified Number of Payments, calculate the dates of payment every six (6) months. For example, if we were to create a payment plan, specify the Payment Period to Semi-annual, with the number of payments entered as five (5). The plan will break down the amount owed into a Periodic Budget of five (5) payments that are to be made Semi-Annually, i.e. every six (6) months.

Entering a Semi-Annual Payment Plan

For example in the Govern A/R Module, we have an amount due of $1,585.14, the Begin Date is 08/15/2017, when we set the Payment Period to Semi-annual, and the Number of Payments to 5, Govern will determine the following first and final payment dates as:

  • First Payment Date – 2/15/2018
  • Final Payment Date – 2/15/2020

In Govern, locate an account via its AR_ID in the Govern search form. When the record has been located, click the A/R Payment Plan Info tab.

Applying a Semi-Annual Payment Plan

  1. Click New (Ctrl + N), to create a new payment plan.
  2. Select the Payment Period.

When the Number of Payments parameter is entered as 5, the First Payment Date and the Final Payment Date will be indicated. The details for our payment plan have been entered.

  1. Click on Save (Ctrl + S)
  2. Next click on the Show Periods Detail icon to display a modal screen with the scheduled payment dates (Payment Plan Detail).

The full details of the payment schedule are displayed as follows:

Period Due Date Period Amount Amount Paid
1 2/15/2018 $317.03
2 8/15/2018 $317.03
3 2/15/2019 $317.03
4 8/15/2019 $317.03
5 2/15/2020 $317.02

Paying Less than Periodic Budget Amount

The Periodic Budget amount is the system calculated payment amount. This amount is displayed in the Periodic Budget parameter. When a payment is made, after the click to save the payment, the Cash Collection dialog box will appear displaying a log of the transaction. This will include the Account No., the Account Name, and the Minimum to Collect. Situations may arise where the system generated Periodic Budget amount cannot be paid. In such instance a supervisor can give permission to allow a lower amount to be paid.
Configuration of this temporary transferring of permission is performed in the OFD. See the Enable Supervisor Permission Transfer for Minimum Payment in the Security section.

Change Payment with Supervisor Permission

NEW! When the option to “Allow to pay less than minimum to collect” is set in the OFD, an authorized user can enter their password and override the system requirement for a minimum payment. To use the supervisor override, after the prompt of the Cash Collection confirmation screen…

  1. Click OK to dismiss the screen.
  2. On the Payment Data Entry tab, click the padlock icon, i.e. Change the permissions for the form.
  3. At the Govern Login prompt, an authorized person can enter their Username and Password.

After the Supervisor enters the Username and Password, click the Save icon to confirm the permission transfer for the minimum payment.

NOTE: If a payment type is not selected, a Cash Collection dialog box will be displayed indicating that a “Payment Type is Required”; click OK. Choose a payment type, e.g. Cash.
Unless the user option to “Allow to pay less than minimum to collect” is set in the OFD, the minimum payment will be required to be entered.

Security

OpenForms Designer (OFD)

Enable Supervisor Permission Transfer for Minimum Payment

NEW! Security for this feature can be set by Role or by User. Enabling or disabling security options must be performed by a user with administrator level rights.

  1. In the OFD, open the Cash Collection form.
  2. Click the padlock icon to select Security Mode.
  3. Select the Payment Data Entry Tab
  4. Click to select the Custom Control (CCPaymentDataEntry_Control).
  5. On the Security pane on the Left Hand Side (LHS), select security type as Type: Normal (default selection).
  6. Click the required profile.
  7. Beside the Custom Control click the black arrow [V] to select the security option to enable “Allow to pay less than minimum to collect” for the Role or User.

Typically this option is enabled for a Supervisor or user that has administrator rights.

Related Topics

Accounts Receivable Module
Accounts Receivable – What’s New
Accounts Receivable Configuration
A/R Inquiry Payment Plan

 

101-ar-frm-005

 

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this.Loading...

AR – Payment Data Entry

Payment Data Entry

Overview

The Payment Data Entry form is used for accepting payments at the counter, by cash, check, credit card, debit card, or by any other user-defined method. The current property owner associated with the account is automatically defined as the payer.

Documentation

For the complete reference guide, see Govern Accounts Receivable.
For the A/R Transaction Rules, see A/R Transaction Rules.

Transaction Types

The following transaction types can be accepted and processed through the Payment Data Entry form.
Payment: Money given in exchange for goods or services.
Deposit An amount of money placed in a bank.
Postdated Payment: A payment dated later than the current date. Note: For a posted payment, you can create a payment transfer. A payment transfer is similar to a payment reversal.
Voluntary Payment / Advance Payment: An amount that is paid before the bill is received; for example, a taxpayer may forward a payment to cover bills during a predicted absence. Note: If you select Voluntary Payment, as the transaction type, for a Payment Data Entry, an AR_ID must already exist for the person or property associated with the payment.

For details on the A/R Transaction Types, see A/R Transaction Rules.

User Form

The Payment Data Entry form is divided into four sections:

  • General Information displaying the subsystem, year, bar code, and cashier ID
  • Summary for the transaction type, deposit information, and notes
  • Detail: for the transaction information including the effective date, A/R balance, interest, penalties, fees, etc.
  • Payer Information: for the name and address of the taxpayer

General Information

Subsystem: This field displays the subsystem for the record selected on the A/R Inquiry form.
Year: This field displays the fiscal year of the transaction.
Bar Code: This field displays the bar code or A/R ID in the Bar Code field.
Cashier ID: This field displays the Cashier ID defined on the Cash Collection Parameters form in GNA.

Summary

Select one of the following transaction types from the Transaction Type drop-down list:

  • Payment: Money given in exchange for goods or services.
  • Deposit: An amount of money placed in a bank.
  • Postdated Payment: For this transaction type, an AR_ID must be set up previously for the NA_ID or P_ID associated with the payment.
  • Voluntary Payment / Advance Payment: An amount that is paid before the bill is received; for example, a taxpayer may forward a payment to cover bills during a predicted absence.

Deposit Information: These fields display the current Deposit Number and the total amount of the deposit.
Notes: Enter any notes or comments that are applicable to the payment.
The data entry field for the Deposit transaction type are different from the fields for the Payment transaction Type.

Detail for Payment Transaction Types

This section describes the data entry fields for the Payment, Postdated Payment and Voluntary or Advance Payment Transaction Types.
The fields at the top of the Detail section are automatically populated. You can modify them only if you have full access rights to the function. The Reference, Type, Amount, and Money fields are available for user input.
Effective Date: This field displays the date of the payment. By default, this is the current date. To change the date, click the calendar beside the field and select a new date.
Installment: For payments by installment, this field displays the installment number: 1st, 2nd, 3rd, 4th, or Total.
A/R Balance: This field displays the amount to apply to the bill. By default, this is the balance due and the field is read-only.
Interest: This field displays the current Interest owing on the account.
Penalty: This field displays the current Penalty owing on the record.
Fee: This field displays the current fee.
Discount: This field displays the current discount if applicable.
Charge: This field displays the current charge.
Demand: This field displays the current value of the Demand to apply on the A/R Balance amount.
Note: Changes to values are displayed when the record is saved.

Total to Pay: This field displays the total amount due on the bill. This total includes the amounts from all fields in this section.
For example, interest charges, penalties, fees, and discounts are added to the value in the Total to Pay field.
You can modify the value in the Total to Pay field. Your modification is applied to the A/R Balance.

Detail for the Deposit Transaction Type

This section describes the parameters for the Deposit Transaction Type.
Effective Date: This field displays the date of the payment. By default, this is the current date. To change the date, click the calendar beside the field and select a new date.
Installment: For payments by installment, this field displays the installment number: 1st, 2nd, 3rd, 4th, or Total.
Total to Pay: This field displays the total amount due on the bill. This total includes the amounts from all fields in this section.

Payer Information

By default, the Payer information fields display the name of the taxpayer and a code that identifies the type of letter to be issued with the bill.
To modify the payer information:
1. Click C beside the Payer information field to change the name. This displays the Search screen with the following options:

  • By Name ID: By Tax Payer Account Number
  • By Name: By Phone Number
  • From NA_External

2. Enter the required information on the search screen. Then, select the applicable record.
3. Select a code from the Letter Code field to identify the type of letter the payer receives, such as, duplicate payment, over payment or payment reversal (Table: VT_USR_LETER_C).
4. Click Save.

Payment Transfer

For a posted payment, you can create a payment transfer. A payment transfer is similar to a payment reversal.

 

 

101-ar-frm-020

 

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this.Loading...

AR – Payment Data Entry Rules

Accounts Receivable Payment Data Entry Rules

Overview

In addition to the security setup in OFD, different business rules apply when a payment is entered in Govern and the behavior of the form may vary.
The following rules apply whether the payment is entered from the A/R Inquiry Payment or from the Cash Collection form unless identified as such.
Furthermore, other Cash Collection business rules and validation can apply.

Parameters

The following parameters impact payment data entry.

Parameters – Accounts Receivable General Parameters

Use Proportional Distribution (Deprecated in 6.0)

  • Select this option to enable Proportional Distribution for cash collection. With Proportional Distribution, payments are distributed according to the amount owed on each account.
  • For example, if the client pays $100.00 but owes $150.00 for electricity and $50.00 for water, $75.00 is paid towards the electric bill and the remaining $25.00 towards the water bill.

Minimum Percent or Amount to Collect

The user cannot enter less than the calculated amount on the Payment Data Entry forms in Govern, unless:

  • The Allow Payments < Late Charges Due option is selected
  • The User has the Security access to the Payment Amount define in OpenForms Designer (OFD) – to be validated in cc
    • For example: If you enter 50%, the minimum payment amount is 50% of the installment due. The user cannot enter less than the calculated amount in the Payment Amount
  • If the previous installment is not completely paid, the remaining amount is added to the current installment. This amount needs to be paid before the minimum amount on the current installment can be collected.
    • For example, a $3,000. Tax bill is divided into three installments of $1,000.
      • The minimum collection amount is 50% ($500. in this example).
      • The client pays $800.00 on the first installment, leaving $200.00 remaining.
      • This is added to the second installment.
      • The minimum amount that can be paid on the second installment is $700.
      • $200.00 (unpaid amount from first installment) +500.00 (minimum collection amount for second installment).
  • The Minimum Percent or Amount to Collect can be the same for ALL sub-systems (General) or vary by module (Sub-System)

Allow Payments < Late Charges Due
Used with the Minimum to Collect option

Collection Year

For Real Property and …..

  • The last year for which you are collecting bills.
    • For example, if you enter 2015, payments cannot be made on bills dated 2014 and before.
  • Typically, this option is used by municipalities that transfer bills to the county, or to another level of government, after a set time has passed.

 

Use Exact Installment

  • Select this option to prevent collection of the second installment through the Payment Data Entry form before the first has been collected. Otherwise, if the second installment is collected while the first remains outstanding, the second installment payment is registered as the total payment in the database.

Security

T/C

 

 

101-ar-brules-payment-entry

 

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this.Loading...

 

AR – Payment Application Priorities Business Rules

Accounts Receivable (A/R) Payment Application Priorities Business Rules

Version 6.1

Overview

The following explains the payment application and priority business rules.
[under construction]

Parameters

Mainly, the following parameters impact the payment priority order:

A/R Sub-System Priorities
Enter a number in the Priority field next to each subsystem to define the order in which bills are paid.
The higher the number, the higher the priority and the sooner the bill is paid.
Note: If a collection year is entered on the Accounts Receivable General Parameters form, no payments will be made on bills dated prior to this year.

Ignore Year:

Select Ignore Year to use only the subsystem priority when making payments.
Bills from the subsystem with the highest priority are paid first.
Otherwise, if this option is deselected, payments are made on all outstanding bills according to year; i.e., all bills from 2012 are paid before the bills from 2013.

Application Order

Payments application order:

Sub-System

  • Payments are made first to the subsystems with the Ignore Year option selected, according to Priority Number. The subsystem with the highest priority number is paid first.
  • Payments are then made to subsystems with the Ignore Year option deselected, according to Priority Number. The subsystem with the highest priority number is paid first.
    • Note: If a collection year is entered on the Accounts Receivable General Parameters form, no payments will be made on bills dated prior to this year.
  • If two subsystems have the same priority number, payments are made in alphabetical order.

A/R Class Code

Priority can be setup by Class code
Priority (Highest Number = Highest Priority)
The Class Code with the highest number is processed first; i.e., the class code assigned priority number 2 is processed before that with priority number 1.

Apply Before Installment/Apply Before Date
If two class codes have the same priority number, they are processed according to these 2 fields.
The following table defines the four possible combinations that can be set for these options:

Process Order Priority Number Apply Before Installment Apply Before Date
1 x x x
2 x x
3 x x
4 x

History / Inactive Account

(To be validated if used for Cash Collection)
An account can be inactivated. This option is set in the Accounts Receivable A/R Inquiry Notes tab.
When turned on, no further Accounts Receivable transactions can be performed on the account.

 

 

101-ar-brules-payment

 

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this.Loading...

AR – Generate Payment Reversals BP

Generate Payment Reversals Batch Process

Overview

Payment reversal transactions (rev) are adjustments that are used as corrections. They are run typically when NSF checks have been processed or records posted incorrectly

Run the Payment Reversal batch process in order to void a group of payment transactions. This is useful if there are payments that were made in error or that were paid from accounts with insufficient funds (NSF).

Documentation

For the complete reference guide, see Govern Accounts Receivable.
For the A/R Transaction Rules, see A/R Transaction Rules.

Payment Reversal Transactions and Processes

Payment Reversal Transaction Type

Payment reversal transactions (rev) are used as corrections. They are run typically when NSF checks have been processed or records posted incorrectly.

Creating Payment Reversal Transactions

Payment Reversal transactions can be created individually or in a batch. Both methods create Payment Reversal Transactions, which can be viewed or deleted from the A/R Inquiry form.
It is faster to generate these transactions in a batch, especially if you have a large volume to process. However, if it is important to note the warnings that are described under the section. Running the Generate Payment Reversal Batch Process.

See Generate Payment Reversal Batch Process following this section.
See Creating a Single Payment Reversal Transaction 101-ar-frm-026.
See Generate Payment Reversal Batch Process: 101-ar-bp-041

Posting Payment Reversals

After generating Payment Reversal transactions, whether individually or in a batch, you need to post them. To post a payment reversal, run the Payment Reversal Posting batch process. See Posting Payment Reversal Transactions. See
Payment Reversal Posting: 101-ar-bp-026

Business Rules for Payment Reversals

All posted payment transactions can be reversed, with the following exceptions. The following payment transactions cannot be reversed:

  • Not posted Payment: If a payment is not posted, you can edit or delete it on the Payment Data Entry form. However, a payment must be posted before you can create a Payment Reversal transaction or include it in the Generate Payment Reversal batch process.
  • Payment Reversal (rev): If a Payment Reversal exists, the original payment is already reversed and a new payment reversal cannot be created.
  • Payment Refunded (rf): If a Payment Refund exists, the original payment is already refunded and a new payment reversal cannot be created.
  • Payment Transferred (tri or trp): If a Payment Transfer exists, the original payment is already transferred and a new payment reversal cannot be created.

For details on transaction types, see Transaction Types

Setting Up the Generate Payment Reversal Batch Process

Run the Payment Reversal batch process in order to generate a group of payment reversal transactions. This is useful if there are payments that were posted with incorrect information or payments that were paid from accounts with insufficient funds (NSF).

This process generates Payment Reversal transactions. These can be viewed in A/R Inquiry, as shown in the following screen shot. These transactions cannot be modified, but they can be deleted.
To configure the batch process:

  1. Launch GNA.
  2. Select Editors > Batch Process Definition Editor.
  3. Select 101-ar-bp-041 Generate Payment Reversals.
  4. Select the Transaction tab.

The Generate Payment Reversals batch process must run in the following

  • Transaction Mode: Synchronous
  • Transaction Type: Break if One Transaction Failed

Refer to the Govern Scheduler documentation for details on the standard setup.

Running the Generate Payment Reversal Batch Process

To run the Generate Payment Reversal Batch Process:

  1. Launch Govern.
  2. Open a Profile that contains the Generate Payment Reversal Batch Process.
  3. Open the Batch Process Explorer.
  4. Select A/R Generate Payment Reversal.
  5. Click the Parameters tab.
  6. The Date field displays the Entry Date of the Payment Reversal. By default, this is the current date.
    Click the drop-down arrow and select a different Entry Date if required.
  7. The Effective Date field displays the date that the payment reversal is applicable.
    By default, this is the current date. Click the drop-down arrow and select a different Effective Date if required.
  8. Select a reason for the payment reversals from the Justification Code drop-down list (Table: VT_USR_ARREASON).
  9. Enter any notes relevant to the Payment Reversal batch in the Notes field.
  10. Select the department responsible for the Payment transactions which you are reversing from the Department drop-down list
  11. Select a range of dates during which the payments you are reversing were posted in the To and From fields.All payments that match the criteria for the department and the range of dates are displayed by description and date.
  12. Select the payments that you want to reverse.
  13. Click Run.
  14. Click the Processing tab.

The following information is displayed:

Warnings

If selected payments were already reversed or cannot be reversed, they are listed by date and time.

Batch Process Information

  • Process Name: A/R Generate Payment Reversal
  • Payment Reversal Date: Entry Date
  • Payment Reversal Effective Date
  • Selected A/R Reason Code
  • Notes added to the Parameters tab
  • Department Code
  • Range of dates for selected posted payments
  • Maximum number of transactions posted
  • Transaction Mode and Type
  • Batch ID
  • User ID
  • Starting time
  • Total amount paid
  • Number of payments
  • Total amount reversed
  • Number of payments reversed
  • Total records to process
  • Total records processed
  • Ending time

Viewing a Payment Reversal Transaction

The section describes the Payment Reversal transaction data entry form.
To access this form:

  1. Open a Profile that has a Accounts Receivable module.
    The Accounts Receivable Inquiry form opens.
  2. Perform a search and select the required record.
  3. Right-click on a record in the Summary section of the A/R Inquiry form.
  4. Select Payment Reversal from the drop-down list If multiple records are available the Record Selection form appears
    You need to select the required record from this form.

The Payment Reversal form is divided into the following sections:

  • General Information
  • Detail
  • Comment
  • Payer Information

General Information

  • Subsystem The subsystem for the record or entry selected on the A/R Inquiry form is displayed.
  • Year This field displays the fiscal year of the record.
  • Bill Number This field displays the bill number for the selected record.
  • Cycle Code This field displays the Cycle Code associated with the record (Table: VT_USR_ ARCYCLE).The Cycle Code is mandatory for the Real Property and Person Property Tax modules. It is used for tax billing cycles and is linked to the A/R Class Code in GNA.

Detail

  • Date This field displays the entry date for the payment reversal. By default, this is the current date. To change the date, click the calendar beside this field and select a new date.
  • Effective On By default this field is blank. If an effective date is applicable, click the calendar beside the field and select a new date. For example, you may want to enter the posting date.
  • Amount This field displays the amount of the reversal.
  • Full Payment Reversal: A full payment reversal can be used when there are multiple records associated with a single name. For example, Bob’s Building Supplies owns three properties. Bob has made an overpayment of $10,000.00 on each property for a total of $30,000.00. You can create a full payment reversal to include all properties in the same payment reversal. Select the Full Payment Reversal option. This displays the total for all property records.
    Note: The full payment reversal option is only valid when at least one payment has been received for multiple records.

Comment

  • Justification Code Select a Justification Code to explain the reason for the payment reversal (Table: VT_USR_ARREASON).
  • Deposit Number Depending on the options selected in GNA, deposit numbers can be automatically generated or user-defined. Automatically generated deposit numbers are composed of one or two of the following fields: date, last deposit, and user ID. This number can be modified if security permissions allow.
    If Deposit Management is activated, a drop-down list is added to the Deposit Information parameter. This is populated by the deposit numbers created in the Deposit Management form.
  • Do one of the following:
    Enter a new deposit number if required.
    Select a deposit number from the drop-down list.
  • Notes Enter any notes or comments applicable to the payment reversal.

Payer Information

  • Letter CodeSelect a Letter Code that identifies the type of letter sent to the payer; for example, D: Duplicate Payment, O: Over Payment, RV: Payment Reversal (Table: VT_USR_LETER_C).
  • Payer’s Name and Address This field is displays the payer’s name and address.
  • Click R to remove the displayed name and address record.
  • Click C to add a different name and address record. This opens the Name Search screen.

 

 

101-ar-bp-041

 

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this.Loading...