How the GL Account Mapped in PSRM Financial Transaction

Accounting entries for financial transactions,

- Bill

- Payment

- Adjustment


Bill:- If a bill segment has a financial effect, the distribution code to debit comes from the distribution code on the obligation type; the distribution codes to credit come from the calculation lines used to calculate the bill segment. Calculation rules define the distribution codes to be used when creating bill calculation lines.

Payment:- Payment segments always have a financial effect; the distribution code to debit comes from the bank account on the tender source of the tender control of the tender, the distribution code to credit comes from the obligation type.

Note: The information in this topic refers to bills created using calculation rule based functionality. For details of the source of FTs for rate-based bills

How the adjustments affect the general ledger (GL) :-


• For many adjustments there is a single accounting entry generated:

• One side of the accounting entry is taken from the distribution code on the obligation type of the obligation affected by the adjustment. For example, if you are adjusting the payoff balance on a normal obligation, the A/R account is constructed from the distribution code on the obligation's obligation type.

• The other side of the accounting entry is taken from the distribution code on the adjustment's adjustment type.

• For transfer adjustments (i.e., adjustments used to transfer moneys between two obligations), there are two accounting entries generated - one for the "from" side and one for the "to" side. Each adjustment carries its own set of balanced GL accounting details.

• For each adjustment, one side of the entry is taken from the distribution code on the obligation type of the obligation affected by the adjustment

• The other sides of both accounting entries have the same GL account. This account should be the intermediate clearing GL account that is to be used for the transfer. The source of this clearing GL account is the distribution code on the adjustment type used to transfer the funds.

• For generated adjustments, the accounting entry may include several GL details:

• One side of the entry is taken from the distribution code on the obligation type of the obligation affected by the adjustment.

• The other side of the entry depends on configuration on the adjustment financial transaction algorithm. If it is configured to use the Calculation Lines as the source, the distribution codes are taken from the calculation lines. If it is configured to use the adjustment type as the distribution code source, the other side of the accounting entry is taken from the distribution code on the adjustment type.

PSRM basic accounting Entries:-

The table explained the basic PSRM accounting entries

Financial Transaction Example screen for Payment event:- 

Ways to submit batch processes in PSRM/ETPM

There are a number of ways of submitting batch processes within the Oracle Utilities Application Framework. The various ways reflect the different uses for the product at a site. The figure below summarizes the various submission methods:






• It is possible to submit the batch process in a basic interactive mode where the batch object executed in a single JVM. This mode is known as THIN mode and is primarily designed for developers to test their code in isolation from the rest of the system. The mode is not efficient enough to be recommended for any activity other than developer testing. Refer to Interactive Submission section for details on how to use this method.

• The product browser user interface allows the registration and execution of batch processes within the JVM used online. This mode allows part of the resources of online be devoted to registering and executing of batch processes. This method is primarily designed for use for testing purposes. Refer to the Online Submission section for details on how to use this method.

• Typically at a site, a batch scheduling tool is used to schedule and manage all of the background tasks required at a site. This can include running product batch processes and any related maintenance process such as transferring interface files to and from other systems, backup and other maintenance activities. This method is designed for production use and has a number of variations to support flexible scheduling options. Refer to the External Scheduler Submission section for details on how to use this method.

Tax Forms Common Lifecycle Statuses - Public Sector Revenue Management (PSRM)

Common Lifecycle of Tax Forms 

The base product supplies a parent business object for tax forms that defines the following lifecycle:

Pending
 
 The tax form is created in an initial state where processing rules are not yet executed. This allows the form to be saved as work-in-progress.

Validated
    A validation step verifies the information on the tax form. Validation form rules specific for the form type are executed to check the validity of the form data. Any issues detected at this step usually causes form processing to stop.

Suspended
    A tax form goes into this state when the validation step detects errors on the form that a user may be able to investigate and resolve. Exceptions are stored in the system so that a user can resolve the issues accordingly. The form needs to be re-validated after the issues are resolved.

Waiting for Information
    A tax form goes into this state when the validation step detects missing information, thus preventing the system from further proceeding with form processing. Exceptions are stored in the system so that a user can track the issues accordingly. In addition, this state usually triggers correspondence to the taxpayer, requesting for the missing information. The form is usually re-validated after the missing information is received.

Ready for Posting
    When a tax form passes validation, it transitions to Ready for Posting. From here a user may choose to make further changes by re-editing the form. Or the form can transition to Posted.
    Note: For implementations that use form control functionality, the tax form is only progressed to Posted by linking it to a form control that gets approved. Refer to The Big Picture of Form Control for more information.

Re-edited
    When a user is creating or correcting a form and it passes validation, there may still be a need to review and correct the data further. A form in the Ready for Posting state may be updated by transitioning it to Re-edited. The form needs to be re-validated once it is re-edited.

Posted
    When a tax form passes validation, it can be posted in the system. The posting of a form typically causes other data in the system to be added or updated. For example, adjustments are created for the assessments. Taxpayer data may also get updated based on newer information from the form. Posting form rules specific to the form type are responsible for the posting logic.

Adjusted
    A posted tax form can be adjusted for any of the following common reasons:

        Correcting data capture errors or data entry errors

        Line item adjustments initiated by the taxpayer

        Adjustments initiated from an audit

    When a tax form is adjusted, the financial effect of the existing tax form is canceled and new financial transactions are created for the updated line items. Note that the effects of adjusting a form are controlled by form rules.

Transferred
    A tax form can be transferred to a different taxpayer/obligation if it previously posted to the incorrect taxpayer/obligation.

    When a tax form is transferred, the current tax form transitions to Transferred and a new tax form is created, allowing a user to indicate the correct taxpayer / obligation. The financial effect of the existing tax form is removed from the current obligation using form rules. The new form goes through the same lifecycle of validation and posting and new financial transactions are created for the 'transfer to' obligation via the new form's posting rules.

Reversed
    Some exceptional cases may require that the financial effect of a tax form be canceled, without necessarily creating new financial transactions. A tax form reversal is a way of voiding a tax form that has already posted.

Canceled
    Forms that are not yet posted may be canceled if a user determines that the form was created incorrectly.

The base package provides a tax form business object C1-ParentTaxForm that has the lifecycle described above. Specific form business objects created using form generation are child forms for a common parent form BO so that the lifecycle is consistent for all forms. The base parent BO may be used or an implementation may create a custom business object. Refer to the business object meta-data for more details on the lifecycle, including the allowed transitions and the algorithms provided.