01
Structured entry
Fuel and vendor fields are organized around the business workflow instead of free-form capture.
Case study / SAP BTP
Fuel Vendor Invoice Management System
Built SAPUI5 applications to support structured fuel data entry and earlier validation in vendor invoice processing.
StackSAPUI5 · OData · Fiori
Recruiter snapshot
The project in about ten seconds.
Focus
SAP BTP · UI/UX
Challenge
Fuel data for vendor payments was manually entered across disconnected processes, leading to data inconsistencies, validation issues, and delays in invoice processing.
My contribution
Developed four SAPUI5 form applications integrated with OData services to standardize fuel-data capture and surface validation earlier in vendor-invoice workflows.
Outcome
Structured Invoice Workflows
- Apps
- 4
- Flows
- 4
- Delivery
- Production
Business Challenge
What was at stake
Fuel-data entry feeding vendor invoice processing was spread across spreadsheets and disconnected manual workflows. Data inconsistencies surfaced downstream as invoicing discrepancies, contract violations, and reconciliation overhead for finance teams.
Key Problems
- Manual data entry across multiple sources with no canonical workflow
- Validation deferred to backend systems or human review
- No structured workflow path for daily operations
- Errors caught late, after submission to vendor systems
- Operational users without consistent workflow tooling
Stakeholders Affected
Operations staff entering daily fuel data, vendor management, finance/AP teams, and business owners accountable for invoice accuracy.
Technical Approach
Validation at the point of entry, not at the backend
Mapped fuel-entry and vendor-payment workflows with business users, then built SAPUI5 form applications with client-side validation enforcing vendor-contract rules. Integrated to OData services so validated data reached backend systems cleanly the first time.
Workflow mapping sessions with business users to define real entry paths
Four form-based SAPUI5 applications covering distinct vendor scenarios
Client-side validation enforcing contract limits and required fields
OData integration for backend submission with audit trail
Rollout support during early production adoption
The Process
Project Lifecycle
01
Discovery
Collaborated with business users to map fuel entry and vendor payment workflows.
03
Development
Developed SAPUI5 applications with a focus on usability, validation, and efficient data entry.
04
Deployment
Supported rollout and adoption for daily invoice processing by business users.
Annotated interface proof
How the workflow moved through the interface.
Generalized reconstruction based on the documented project workflow. It illustrates the interaction model without presenting client UI or confidential implementation details.
Fuel invoice workflow / generalized
Vendor fuel entry
01
Selected vendor
MM / DD / YYYY
02
12,500 gal
Assigned account
Validation
Quantity must satisfy the applicable business rule before submission.
OData service handoff03
04
Structured, validated data continues into backend invoice-processing workflows.
02
Validation boundary
Client-side rules surface invalid values before the record reaches backend processing.
03
OData handoff
Validated form state is submitted through an OData service for downstream processing.
04
Workflow outcome
The interface supports more consistent invoice data before vendor-payment processing continues.
Execution Approach
Project Details
Form-Based Workflow Design
The applications focused on structured data capture and validation, ensuring that fuel entries aligned with vendor contracts and reducing errors before submission to backend systems.
javascript
Implementation
Representative implementation pattern
// Advanced Validation for Fuel Invoice Entry
onFuelEntryChange: function(oEvent) {
const sValue = oEvent.getParameter("value");
if (!this._validateFuelQuantity(sValue)) {
oEvent.getSource().setValueState("Error");
oEvent.getSource().setValueStateText("Quantity exceeds vendor contract limits");
}
}Architectural Decisions
Choices that shaped the build
01
Form-based UI patterns over freeform entry
Decision
Structured forms with field-level validation per workflow.
Rationale
Operational users benefit from guided entry. Freeform invites errors and shifts validation burden onto downstream systems.
02
Client-side validation as primary
Decision
Enforce vendor-contract rules in the UI before submission.
Rationale
Immediate user feedback reduces backend rejection cycles and AP rework. The error is cheapest to fix at the keystroke.
03
Workflow-per-vendor scenario
Decision
Four distinct applications rather than one generic form.
Rationale
Vendor contracts differ in rules and fields. A single configurable form drifts toward complexity and confuses users.
04
OData integration with structured payloads
Decision
Submit through OData service contracts rather than ad hoc API calls.
Rationale
Versionable, traceable, aligned with broader SAP integration patterns, and recoverable when contracts change.
Key Tradeoffs
What was chosen, and against what
App granularity
Chose
Four focused applications
over
Instead of
One configurable workflow
Reasoning
Configurable forms drift toward complexity. Four focused apps stay maintainable and align to actual user roles.
Validation layer
Chose
Client-side primary, backend secondary
over
Instead of
Backend-only validation
Reasoning
Both UX and backend correctness matter. Client catches the majority before submission; backend remains the source of truth.
UI technology
Chose
SAPUI5
over
Instead of
Generic web framework (React/Angular)
Reasoning
Native integration to SAP landscape, Fiori-consistent UX, and transport-friendly delivery. Generic frameworks add integration cost without UX upside.
Outcomes
Proof in production
Key outcome
Structured Invoice Workflows
4
Apps
4
Flows
Production
Delivery
Qualitative Outcomes
Beyond the numbers
- Consistent data entry across operational users
- Errors caught at entry rather than during AP reconciliation
- Reusable form patterns adopted across related workflows
- Reduced manual rework cycles for vendor invoicing
- Documented workflow patterns the team can extend without external help
Lessons Learned
What generalizes
- 01
Validation belongs as close to the user as practical so issues can be addressed before downstream processing.
- 02
Operational users adopt UIs that respect their workflow rhythm, not just visually polished ones.
- 03
Vendor contracts change. Validation rules should be data-driven where possible rather than hard-coded.
- 04
Four focused apps outperform one configurable monster for distinct workflows.
- 05
Adoption coaching during the first two weeks of rollout determines long-term success more than any technical decision.
When This Approach Makes Sense
Is this a fit for your program?
Strong fit when
- Operational workflows depend on manual entry feeding SAP backend systems
- Validation rules are well-defined—vendor contracts, business rules, regulatory limits
- Users perform daily structured tasks rather than ad hoc analysis
- Errors should be caught at entry, not in reconciliation
Probably not when
- Workflow is highly variable or analytical rather than transactional
- Users prefer Excel and process change isn't sponsored
- Backend services aren't ready to consume structured input
Continue evaluating Bryan
See the engineering in context.
Review my experience, compare selected work, or start a conversation about a senior engineering or SAP BTP technical lead opportunity.
Looking for selective enterprise project support instead? Enterprise consulting stays available as a secondary path.