Purpose
The Automatic Receipts process may
error out due to various possibilities like code issues, database issues,
system errors etc., that could result in documents being processed partially.
It is not correct to roll back the Unapplied receipts created as the Credit
Card Authorizations for such unapplied receipts created is successful for these
documents and are already recorded in the system (iPayment). Currently there
exist no mechanism in place to re-submit and complete apply the Unapplied
receipts for such cases. This will restrict the user from doing further
activities on these documents resulting in additional efforts needed to report
and get the issue fixed.
This “break” in the process results
in:
● Unapplied
receipts in the system.
● Stamped Invoices
marked as part of the batch due to which
the user will not able to make any
applications/adjustments from the workbench.
● Open Invoices
which are yet to be closed by applying unapplied Receipts.
to address this issue, Receivables
now has a new feature "Resubmit Approval" in Automatic Receipts Batch
form.
Details
In case of Automatic Receipt Creation
Program, AR code call IBY Public API to authorize the receipts [
IBY_FNDCPT_TRXN_PUB.Create_Authorization ]. Once the Authorization is
successful , these receipts will be retained by AR, even if invoice application
failed OR some database error encountered. The solution approach is based on
current status of the batch, status can be one of the following:
● Completed Approval: Auto Receipts batch will be marked as Completed
Approval once all the documents associated to the batch are processed
completely.
● Started Approval: This is the batch status when the Automatic process is
either running attempting to approve the receipts or when the process has
completed abnormally due to any instance issues like Table space allocation
etc.
This feature to process these
unprocessed rows, will enable the User to be allowed to submit the partially
processed batches for approval with current status as Started Approval. A
distinction will be made if the process is currently running or if it is the
case of an abnormally terminated process.
Note : The
users will be allowed to re-submit the process only in case of an abnormally
terminated process.
The request can be submitted from
both Receipt Batches UI (User Interface) and Standard Request Submission
window.
Details of Solution Component
a. Changes to Control the batch status
The current batch status will be set
to 'Started Approval' and the changes will be committed in order to retain the
status even when the program errors out. Batch status will be changed from
'Started Approval' to 'Completed Approval' only after successful completion of
the request (i.e., there should not be any partially processed documents
associated to the batch unless created intentionally like a receipt that has
been successfully authorized but the code found a corruption in transactions
while applying against those).
b. Batch Correction / Completion flow
Receipts
● Identify and
select the Receipts that are partially processed during the previous run
● Map the
identified receipts to the invoices for application - mapping can be based on
trxn_extension_id, customer number etc.. This mapping is purely based on how
the original process would have mapped using the creation rule set at the
Payment method level of the associated batch.
● Verify the
Authorization status of the receipt and do the payment processing if needed.
● Apply the
selected receipts to invoices.
Invoices
● Identify and select the invoices stamped with
batch id and are in closed status, null out the batch id for all such invoices.
● Identify and
select the transactions that are stamped with this batch id and are in Open
status, continue with the approval process for all the selected invoices.
● Nullify the
batch identifiers that are stamped once the receipts are applied
c. Changes to Receipt Batches UI
Submission of Approval process is
allowed for batches in started Approval status, the process can be submitted
for a given batch only it is able to acquire the lock on batch record in order
to avoid multiple submissions of the same batch as well as not disturb the
running process of other batches.
Resubmit Approval option provided from both Batches and Batches Summary screen for
partially completed batches.
The following shows screenshots of
where the Resubmit Approval button is available:
Receipt Batches
The Receipt Batch form shows an
option to resubmit approval for errored/partially completed batches, will be
shown only if no other request is currently running for the same batch
Batches Summary
The Batch summary form shows an
option to resubmit approval for errored/partially completed batches, will be
shown only if no other request is currently running for the same batch .
Overview
of Technical changes
a. Standard Approval flow
The steps involved in standard
approval flow after incorporating the required changes are as follows:
● Process creates
a receipt batch based on the input parameters passed to the concurrent program
and associates all the selected invoices to the current batch.
● The Approval
phase begins after setting the batch status as 'Started Approval', batch status
will be committed to the database prior to the start of the receipt creation in
order to retain the new status in case of abrupt termination of the program.
● The program will
lock the batch immediately after the batch status is committed to database and
the lock will be retained till the completion of the program, this will enable
us to control and restrict multiple submissions of the same batch while a
request is already running.
○ Standard (via Workbench & SRS Window child program): Program
obtains lock on batch record and continues with processing of the data, will
also ensure that lock is retained even with batch commits in place.
○ Parallel (SRS window Master Program) : Master program obtains lock on
batch record and submits child workers, child workers will do the actual
approval process and notify the master program after completion.
● Process
continues with the approval flow, logic to control the batch status varies
based on the program submission mode (Standard or With multiple workers).
Successful completion of the program results into
○ Standard: Batch
status will be changed from 'Started Approval' to 'Approval completed'
○ Parallel: Child
program completes in Normal status, based on child program status master
program updates the batch status to Approval Completed.
● In case the
program errors out then based on the submission mode batch status will be
handled as Standard Process will retain the batch status as 'Started Approval'
Parallel. Child program will complete in warning, based on this master process
will retain the batch status as 'Started Approval'. Receipt Creation API call will be followed by
stamping of the batch details on cash_receipt_history table, this will help us
in identifying any unapplied receipts associated to the batch during re-submit.
b. Re-submit Approval flow
● The logical
steps involved in Re-submit Approval flow are :
● Process will
validate current batch status and only proceed if the current status is
'Started Approval' and record is not locked, In case the program is submitted
from the Workbench then it should release the lock on batch record prior to
submission of the request.
● The concurrent
program will obtain a lock on batch record and the lock will be retained till
the completion of the program, this way we will restrict multiple submissions
of the same batch while a request is running for the given batch. Process to
obtain lock depends on the submission mode.
○ Standard (via
Workbench & SRS Window child program): Program obtains lock on batch record
and continues with processing of the data, will also ensure that lock is
retained even with batch commits in place.
○ Parallel (SRS
window Master Program) : Master program obtains lock on batch record and
submits child workers; child workers will do the actual approval process and
notify the master program after completion.
● Identify and
load existing global temporary table ar_receipts_gt with Unapplied Receipts
created during the previous run along with the related invoice details. Need to
make use of various invoice and receipt attributes based the creation rule to
identify the invoice and receipt mapping.
● Select all the
receipts loaded in global temporary table, verify and proceed with
authorization if needed for each of these receipts.
● Select all the
record from the global temporary table and perform receipt application using
the mapping details already populated in gt table.
● Complete the
control check and other verifications that are already in place for these
receipts, after successful verification cleanup the global temporary tables.
● Identify all the
invoices associated to the batch and are in closed status and nullify the
batch_id.
● Initiate the
standard approvals flow to process any open invoices existing in the system and
are associated to the current batch. Standard process will identify all such
open invoices and initiates the approval process.
Error Messages
New message with warning text to be
displayed for errored batch execution report. For e.g. if the Batch failed, you
may notice the following error in Automatic Receipts Execution Report For
Creation/Approval :
WARNING: Internal system error prevented the Automatic Receipts Program
to process receipts completely. Please resubmit the batch for approval using
Resubmit Approval button in Receipt Batches form.
No comments:
Post a Comment