SAP Fiori / OData V4 – Interface Design for a New Account Assignment Function

SAP Fiori / OData V4 – Interface Design for a New Account Assignment Function Key Facts Project title: Design & interface design of a new OData V4 service for account assignment (SAP Fiori) Area of work: SAP Fiori / SAPUI5, OData V4 service design Target platform: SAP S/4HANA on-premise System access: Not required for the first three work packages ABAP knowledge: Not required (ABAP implementation is done in-house) Start: Can begin shortly after commissioning Estimated effort: Approx. 30 person-days in total (see breakdown below) Contract type: Freelance / project basis Current Situation The current solution is an ABAP-based SAP Fiori application, embedded in the SAP system and launched from the Fiori inbox. Today it lets a user display an invoice, display the document image, and approve or release it. On the back end, this is plain ABAP inside the SAP system – no SAP BTP, no separate back end, no CAP, no side-by-side scenario. The application consumes an existing OData service that is read-oriented and built specifically for display and release. What Is Missing: Account Assignment What is missing today is account assignment – entering the accounting information for an invoice: G/L account, cost centre, internal order, WBS element, asset, profit centre, tax code, and splitting the invoice amount across several assignment lines by amount or percentage. It may also be possible to keep a history of “identical postings”, so that account assignment suggestions from the past can be called up directly. Target Solution A new OData V4 service for account assignment is being built, with the following key points: • Target platform: SAP S/4HANA on-premise only. • Its own persistence for invoice data, addressed by a stable business object key rather than a workflow-step reference. • Draft handling, value helps on real master data, and validation against accounting are first-class requirements of the new service from day one, not later additions. • The ABAP-side implementation (data model, service, posting) is done in-house at inPuncto. • The Fiori application is a shipped product component, delivered to customers as part of the overall solution. The service is designed consistently from the consumer side: the interface is defined by what the user interface and the business task actually need, rather than the other way round. The freelancer is intended to contribute right at this interface design stage, from the very beginning; the interface design comes first, and everything implemented internally is built against it. Scope of Work / Work Packages The task is organised into four work packages: Work Package 1: OData V4 Service Contract for Account Assignment • Entity sets, associations, cardinalities, keys. • Invoice header, account assignment lines, invoice items where a purchase order reference exists, document image reference, workflow history. • Value help sets per field. • Actions for check, park, post, forward and reject, each with message return. • Annotation requirements for value help, mandatory fields, side effects and message handling. • Deliverable: written specification plus a CSDL/EDMX draft. Work Package 2: Field Matrix and Interaction Behaviour • Per field: display, editable or read-only and under what conditions; mandatory when; value help required and what the user searches by; whether a change triggers re-determination of other fields; client-side checkable versus back-end check required. • Cross-field rules: amount and percentage split and how they interact, the assignment total against the invoice amount and the behaviour on deviation, tax code handling, and which combinations are mutually exclusive. Work Package 3: Draft and State Concept From the Consumer Perspective • What happens to an unfinished assignment when the user leaves the application and returns. • What happens when the invoice advances a workflow step. • What happens when the same invoice is open in the SAP GUI and in Fiori simultaneously. • Behaviour on explicit discard and when a posting attempt fails. • Which states exist from the user's point of view and which transitions are permitted. Work Package 4: The Fiori Application as a Deliverable Product Component • Fiori Elements versus freestyle SAPUI5, decided with reasoning. • Account assignment lines and document viewer visible side by side, usable on a tablet. • Split with a running total against the invoice amount. • Value help dialogs, message display for check results. • Internationalisation, accessibility and Fiori design guideline conformance. Development starts against a mock service that returns exactly what the contract in package 1 specifies, and switches to the real service once it is available. The application itself is production code from the first commit – not a prototype to be rebuilt later. One limitation is stated deliberately: while the application runs against mock data it must not be presented to customers as a working solution. Development Environment and Delivery Path • Development takes place in SAP Business Application Studio, in a dev space on inPuncto's BTP subaccount. The development system is reachable from there via a destination. • The project is generated with SAP Fiori tools and lives in inPuncto's Git repository from the first commit – keeping it portable to a local VS Code setup later without rework. • The application is deployed into the ABAP repository as a BSP application and shipped to customers as a transport. The runtime is the on-premise Fiori launchpad, not BTP; BTP is used for development convenience only. • Deployment and transport handling stay with inPuncto. Estimated Effort Interface contract (Package 1): 5 person-days Field matrix (Package 2): 3 person-days State concept (Package 3): 3 person-days Fiori application (Package 4): 19 person-days Start Conditions Work packages 1 to 3 require no system access and can begin immediately after the contract is signed. Package 4 (the application) starts against a mock service first; system access to the development system is not required at that first step. Profile Sought • Solid experience with SAP Fiori / SAPUI5, ideally including Fiori Elements. • Experience designing OData services (ideally OData V4), including CSDL/EDMX, annotations and value helps. • Experience with draft-handling and state concepts in transactional Fiori applications. • Ability to design a back-end interface consistently from the perspective of the UI and the business process, independent of the concrete ABAP implementation. • ABAP knowledge is a plus – but not required for the task at this stage. • Good communication skills in English and/or German for close coordination with the internal development team.