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.

APP-SQLAP-10000: ORA-01403: no data found occurred in with parameters (Terms id = Seqiemce num =1)

Issue:

Unable to validate invoice where the item line has a withholding tax group due to:

APP-SQLAP-10000: ORA-01403: no data found occurred in
with parameters (Term id = Sequence num = 1) while performing the following operation: &DEBUG_INFO the following error occurs.

Solution:-

This error is caused because when the invoice is validated the system tries to create the automatic withholding invoice yet there is no Payment Term associated with the Supplier (Tax Authority) site. Since the invoice could not be created without this, the validation fails.

1. Navigate to Supplier form
Payables > Suppliers > Entry

2. Query the Supplier/Tax Authority linked to the withholding group on the problematic invoice
Click Update
Select the Key Payment Setup tab

3. Scroll to the Payment terms section and add a Payment Term to the Tax Authority for that Vendor Site.

4. Retest the issue

Check the opening and closing balances in the control totals

Issue: 

Check the opening and closing balances in the control totals.

Solution:


The Bank Statement Import program checks if the Control end balance matches:
(Control begin balance) + (Control cr amount) - (Control dr amount)

If not, it shows the warning, "Check the opening and closing balances in the control totals."

Here's the steps to address the warning:

Case 1:
Bank statement file does not provide the opening and closing balances and these optional fields are not populated.
So CONTROL_TOTAL_DR and CONTROL_TOTAL_CR are populated but not the begin and end balance.

Workaround:
Either null out the CONTROL TOTAL DR and CONTROL TOTAL CR, or populate begin and end balance for the Bank Statement Import Parameters.

Case 2:
CONTROL_BEGIN_BALANCE and CONTROL_END_BALANCE is populated but not CONTROL_TOTAL_DR and CONTROL_TOTAL_CR

The issue can occurr when there is a missing transaction code setup.

1 - With the Bank Statement in the Interface tables , navigate to the Bank Statement Interface form.

2 - Check the Bank Transaction Codes assigned to the Bank Statement Lines.

3 - Ensure Bank Transaction Codes identified on the Bank Statement are correctly setup in the system prior to importing the bank statement.

Please check the information from bank statement loader TDD:
-----------------------------------------------------------
After you load SWIFT940 bank statement files into the open interface tables,
you may need to define new bank transaction codes in Cash Management.
SWIFT940 transaction codes represent the type of transaction. For example,
TRF represents transfers. SWIFT940 transaction codes do not, however, contain
information about the debit or credit nature of the transaction. Instead,
the Debit/Credit Mark field is used to differentiate debit and credit
entries, where D means debit and C means credit. When the Bank Statement
Loader program populates the TRX_CODE column in the Bank Statement Lines
Interface table, it appends the Debit/Credit Mark to the transaction code to
form a new code. For example, debit transfers are identified as TRFD and
credit transfers as TRFC. You must set up these new transaction codes before
you can import the bank statement information.


4 - Once this is checked and corrected ( if required ), make a change to the Bank Statement in the Interface form and save.

5 - Now, try to import the Bank Statement.