Know what you’re taking into delivery.

The architecture

The app is an experience layer. It displays compensation results from Fusion and configured services; it does not implement customer compensation calculations in the browser. The demo estimator uses stand-in sample logic.

Interactive service reads and actions run as the signed-in user. The notification service’s scheduled digest job has no interactive user and requires its own configured service-account credential.

Prerequisites: Oracle Visual Builder runtime 2510, JET 19 Redwood, a Fusion Cloud pod with the required ICM and HCM resources, CX Sales resources for partner experiences, and a host for the reference services or equivalent contracts implemented in OIC or ORDS.

The experience included in the source

• Desktop icon sidebar and phone/tablet bottom tabs, with one navigation mode visible at a time.
• Seller payout summaries, component earnings, previous-period comparisons and rate milestones, subject to complete source aggregates.
• Manager coaching priorities, readable Team tables or labelled narrow-screen rows, and paysheet confirmation showing selected count and amount.
• Dispute review with financial context, comments and attachments where provided by the configured service, plus queue sorting, age filters and density controls.
• Customer name, logo and accent preview with downloadable configuration. Preview is session-only; partner deployment applies branding for all users.
• Optional included starting links and terminology help, which can be disabled when Oracle Guided Learning is used.

Automated browser checks cover responsive layouts, translations, settings, failure states and role-based screen flows. They establish local sample behavior, not comparative usability gains or Oracle backend capacity. See the 26C evidence comparison and decision brief for the current seller earning, paysheet and dispute evidence paths and their validation limits.

What to verify in the source

npm run verify checks JavaScript syntax, Visual Builder schemas, reference-service tests, application logic, then builds a fresh preview and runs browser smoke checks.

• English pages at desktop and phone widths, plus Spanish pages at phone width. The latest layout pass also checks 900px tablets and 1024px compact desktops, including exactly one navigation mode.
• Console errors, rendering failures, untranslated keys and unfilled placeholders.
• Basic contrast, named controls, keyboard-reachable rows, horizontal overflow, table boundaries and Team financial-column clipping.
• Service-call budgets, failed-service behavior and missing-integration notices.
• Selection identity, confirmation scope and amount checks for paysheet approvals.
• Reported earning fields and currency/status preservation; refreshed paysheet totals with scoped payment-record pages; dispute evidence linked by explicit record identity.

Ask for current verification output and the exact source revision during diligence. These checks run against samples and test doubles without a live Fusion pod.

Current source-evidence review

Seller and partner earning detail loads one earning by earning ID and credited participant, then displays reported input, output, credit, CommissionValue, tier count, amount, currency and posting status where present. It does not derive a rate formula or treat posting as proof of payment.

Manager paysheet review refreshes the selected paysheet summary and separately requests that paysheet’s payment records in pages capped at 50. The summary total remains the source of the displayed total; a partial page is not summed as the paysheet amount.

Dispute review preserves the case’s claim-time amounts and follows only explicit credit or earning links with identity checks. Missing, denied or mismatched records remain unverified. New-dispute prefill uses a uniquely linked credit only; it does not infer an expected amount or split.

These are implemented sample paths. Validate resource mappings, roles, field availability, currencies and exceptions against the target Fusion pod. The evidence comparison and decision brief describes Oracle 26C overlap and the proposed matched-task study; native comparative results have not been measured.

Known integration and product gaps

• Native dispute integration needs correction and pod validation. The current adapter uses placeholder SOAP operation and field mappings. Oracle documents getDispute, createDispute and updateDispute in the disputeManagement/disputeService namespace; the documented dispute payload uses fields such as ActualValue, ExpectedValue, DisputeId, Attachment and AttachmentName. A listing operation named find is not documented there. Approval and rejection are native human-task operations; a generic status update must not be presented as resolving that workflow. Correct mappings and validate dispute CRUD, attachments and task decisions against the target pod using Oracle’s dispute service operations and dispute request payload.
• The default manager profile retains a 5,000-report ceiling and assembles the roster in the browser. The optional server-summary profile adds paged team contracts; it must be implemented and validated before use.
• Some sample rates disagree between pages, and a driver-style dispute appears in the sales-manager sample team.
• Current sample and test-double checks do not validate earning mappings, payment exceptions or dispute source links on a customer pod.
• Spanish is selected from the browser or ?lang=es; there is no in-app language switch. Some legacy strings remain in English.
• Dark mode uses app theme tokens; some JET controls retain light chrome.
• The build targets JET 18 while the runtime is JET 19, producing a version warning.

Capacity and scale

No benchmark establishes 100,000 participants or 10 million input transactions per hour. That sustained input rate is about 2,778 records per second, or 240 million per day if every record is new. Crediting, rollups and recalculation can add further processing. Registered participants and concurrently active users are separate capacity measures.

Current boundaries

• The UI pages many detail lists, but the reference analytics service retrieves full BI Publisher report results before final filtering, sorting and paging. It defaults to a 5,000-row ceiling and a process-local, user-scoped cache.
• Manager rosters are assembled in the browser up to 5,000 reports. Dispute amount statistics scan at most 20,000 rows and disclose truncation.
• Large statements use an exact monthly Fusion summary and paginated detail when available. Complete component breakdowns require a server aggregate; missing or ambiguous totals produce an error.

Optional VBCS and OIC profile

The source now includes service contracts and client paths for server-side summaries, paged manager views, bounded caching and background paysheet approvals. The profile is disabled by default. The supplied flow definitions, native Visual Builder job-store specifications and secured report wrappers require a provisioned OIC environment, implementation, customer mappings, activation and live testing. They are not an importable OIC archive. A synthetic client benchmark checks bounded requests; it does not measure Fusion processing throughput.

Recommended data flow for a large deployment

Keep Fusion responsible for compensation results. Publish scoped participant, period and component summaries to a scalable read service, with stable detail pagination, bounded queries, horizontally scaled instances and cache keys that preserve authorization. Keep large mutations in asynchronous jobs with duplicate protection, per-item outcomes and audit history. Display result freshness and processing status in the app.

This adds infrastructure and data-freshness tradeoffs. Prefer direct Fusion reads for bounded supported resources; use a separate read store where report-based reads cannot meet the measured target. Preserve participant and manager permissions in every query.

Evidence needed before claiming support

Agree the input definition, hourly completion deadline, peak rate, credit fan-out, transaction skew, retention and concurrent-user load. Validate collection, crediting, calculation and payment throughput on the actual customer pod with Oracle capacity guidance. Separately load-test UI APIs, freshness, access isolation, retries, failure recovery and backlog clearance. Revisit partitioning, retention and summary refresh as volume grows.

Oracle documents worker and batch tuning and participant grouping; it advises refining settings based on tests. Those documents do not establish this application's throughput: throughput guidance and transaction grouping.

Acceptance before customer rollout

1. Import and rebrand the app; confirm Oracle prerequisites and customer field mappings.
2. Run the pod-readiness script against the target pod and resolve missing resources or attributes.
3. Validate each role’s participant scope and IAM permissions with actual customer accounts.
4. Reconcile statements, attainment, rates and estimates against Fusion results.
5. Test disputes, attachments, paysheet approvals and partial failures on that pod.
6. Validate performance at the customer’s volume and complete user acceptance testing.
7. Review security, hosting, monitoring and promotion procedures before production.

The commercial boundary

The current offer is a one-time US$120,000 source-code assignment to one firm, delivered as-is without ongoing support or updates. The written agreement controls the assignment. Oracle runtime and third-party assets remain subject to their own terms and are not included in the code assignment.

No delivery-time or savings claim is made without measured evidence from an implementation.