The base product provides the C1–DirectDepositBankEvent business object, which supports
the following lifecycle steps:
-
A direct deposit bank event is created in a Ready to Extract state. When an
overpayment process is at the point in its lifecycle where it’s ready
to issue the refund, it can create a bank event. When it does, it
also populates the extract batch control (from the bank event’s type)
and the next run number on the bank event, so that it gets picked
up the next time the bank event extract batch process runs.
- An extract batch process runs and picks up all bank events that
are stamped with the extract’s batch control code and the current
run number. For each bank event, the Bank Event Extract algorithm (defined on the bank event’s
type) is executed, to map the bank event information into a corresponding
transaction record in the extract file. When the bank event is processed
successfully, the Extract Date/Time and Monitor Control Date are both
set to the process date. The Monitor Control Date controls when the
bank event transitions to the next state — in this case, to Extracted. Setting this date to
the current processing date would cause the Bank Event Deferred Monitor
(with Date) to pick up the bank event in the next run and perform
the state transition accordingly
-
An
Extracted direct
deposit bank event stays in that state until the financial institution
accepts or rejects the transaction. The bank event can be monitored
to do any necessary timeout processing or automatic transitions when
a response is not received within a specified period of time. In addition,
an adjustment (to affect the obligation’s balance) can be created
at this point, if business rules dictate that the balance is impacted
upon extraction/download.
Note: The base product provides a number
of algorithms that are not plugged in on the base business object
by default. Implementations will need to configure these algorithms
based on their business rules. Refer to the detailed description of
the C1–DirectDepositBankEvent business object for details on algorithms that can be plugged in
on the Extracted state.
-
When the financial institution accepts the direct deposit,
the bank event can transition to
Accepted. The assumption is that this transition is done
from back end services because it involves processing responses from
financial institutions. An adjustment (to affect the obligation’s
balance) can also be created at this point, if business rules dictate
that the balance is impacted only after the direct deposit is accepted.
Note: Since the base product does not provide logic for receiving bank
responses, logic for transitioning to Accepted is assumed to be implementation responsibility.
Note: Refer to the detailed description of the C1–DirectDepositBankEvent business
object for details on the Create
Adjustment algorithm that can be plugged in on the Accepted
state.
-
When the financial institution rejects the direct deposit,
the bank event can transition to
Rejected. The assumption is that this transition is done
from back end services because it involves processing responses from
financial institutions.
Note: Since the base product does not provide
logic for receiving bank responses, logic for transitioning to Rejected is assumed to be implementation
responsibility.
-
Rejected bank
events are usually caused by invalid bank details. The base package
supports the ability to reprocess a rejected direct deposit. An algorithm
can be plugged in on this state, to create a new Overpayment Process.
This is to allow for retry processing, which includes attempting to
look for a new set of bank details. Another algorithm can also be
plugged in, to reset existing bank details so that it they are not
used in future direct deposits. A base algorithm is plugged in on
this state, for canceling any existing adjustment, i.e. created upon
extraction.
Note: Refer to the detailed description of the C1–DirectDepositBankEvent business
object for details on algorithms that can be plugged in on the Rejected state.
-
In some exceptional cases, there may be a need to reject a
previously accepted direct deposit. This is for cases where the financial
institution encounters specific problems after accepting the transaction.
The lifecycle allows for this transition.
-
Ready to Extract and Extracted direct
deposit bank events can be Canceled. If canceling from Extracted state, any existing adjustment is also canceled. The lifecycle supports
system cancellation from a related process. The Standard Overpayment
Process business object supports the ability to cancel a related bank
event when the overpayment process is canceled. The Allow System Cancel (C1AC) status
category value is used to determine which states allow for system
cancellation. The Ready to Extract state is configured with this value. Implementations can add this
value to other states (e.g. Extracted) as needed. Note that logic to alert a user about cancellation
is not provided by base.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]