If we've ever needed our NACHA, wire, or check files to carry a running sequence number that resets on a schedule — say, a daily batch number for a NACHA file — Oracle Fusion Cash Management gives us a built-in feature for this: the Periodic Sequence. It sounds simple, but there are a handful of setup details that, if missed, will silently stop the sequence from updating. This post walks through the setup end to end.
Where PPP Details Live
Before diving into the setup, it's worth knowing where this configuration is stored under the hood. The Payment Process Profile (PPP) details — including the periodic sequence assignment — are stored in the table:
IBY_SYS_PMT_PROFILES_B
This is the base table for Payment Process Profiles in Oracle Fusion Payments, and it's a useful reference point if we're ever troubleshooting from the backend or writing a diagnostic query.
Follow the Oracle Support Documentation
The actual creation of the periodic sequence is documented in two My Oracle Support notes:
- Doc ID 2266596.1 — How To Setup Periodic Sequence For Payment Files
- Doc ID 1999286.1 — related setup reference
Start there for the base configuration steps (navigation, sequence creation screen, etc.). The rest of this post covers the details that aren't always obvious from those docs.
Match the Sequence Name Exactly
This is the single most common point of failure. The sequence name you define must be identical in two places:
- The Payment Process Profile (PPP) setup, where the periodic sequence is attached.
- The payment file template, wherever the sequence is referenced.
For example, if we name our sequence US_NACHA_DAILY_SEQ in the PPP, our template must reference that exact same name. In the payment XML, this shows up at:
/OutboundPaymentInstruction/PaymentInstructionInfo/PaymentSequence/SequenceName
which should resolve to US_NACHA_DAILY_SEQ.
If the names don't match, the sequence simply will not update. There's no error message — it just silently fails to increment, which makes this easy to miss during testing.
Fix the "Increment by 2" Behavior
By default, the standard update method increments the sequence by 2 instead of 1. If our requirement is a simple +1 increment per file, we'll need to modify the XSLT/XML condition for the last value calculation:
/OutboundPaymentInstruction/PaymentInstructionInfo/PaymentSequence[SequenceName='US_NACHA_DAILY_SEQ']/LastValue + 1
Adjust this expression in our template to match whatever increment logic our business actually needs.
Prerequisites in the PPP
A few settings need to be in place before the periodic sequence option even becomes available:
- Payment confirmation point must be set to "After Payment Formatting" — not "After Transmission." If it's set to the latter, our sequence logic won't behave as expected.
- A payment system must be attached to the PPP. This is a hard prerequisite — until a payment system is linked, the periodic sequence option won't even appear as a configurable field in the PPP setup screen. This trips people up because it's not obvious that the two are related.
Schedule the Reset ESS Job
Periodic sequences need to reset on some cadence — daily, in most NACHA-type scenarios. This is handled by the "Reset Period Sequence" ESS (Enterprise Scheduler Service) job.
- Schedule this job to run daily (or on whatever cadence matches our business cycle).
- Reset the value to 0 — this makes the increment logic in our template much simpler to manage and reason about.
Using the Sequence Identifier for Multiple Sequences
If we need more than one periodic sequence - for example, separate sequences for different payment types or bank accounts - we can define up to three sequences within a single PPP. Each is distinguished by a Sequence Identifier parameter, which takes a numeric value: 1, 2, or 3, corresponding to the sequence we want to reference.
No comments:
Post a Comment