Skip to end of metadata
Go to start of metadata

The Electronic Bill Presentment and Payment ES bundle provides billers a way to electronically deliver invoices and account information to a customer for review using a web browser and to accept payment of invoices online. It also includes the authorization and settlement capabilities for communicating with credit card clearing companies.

The Electronic Bill Presentment and Payment (EBPP) ES bundle offers a similar solution to that of SAP Biller Direct. The primary difference is that EBPP does not require a company to use a dedicated user interface. Instead, it delivers the business objects and enterprise services that enable bill presentment and payment in the backend system and allows the company implementing this ES bundle to integrate the functionality into the customized look and feel of a preexisting or newly created user interface, such as an existing portal.

As with all ES bundles, the services included here can be deployed in many different combinations to achieve whatever outcome best suits the needs of your environment. It also allows you to integrate backend data from SAP and non-SAP systems alike.

By deploying the EBPP ES bundle, your business will gain basic electronic billing capabilities. This includes the ability to:

Electronic Bill Presentment and Payment (click to enlarge)

  • Present customers with an overview of an account, or multiple accounts
  • Present customers with a list of open invoice items
  • Present customers with a list of paid invoice items
  • Accept payment of invoices through direct deposit or credit card
  • Request and receive credit card authorization
  • Request and receive credit card settlements
  • Enable customers to add and update credit card information

Furthermore, the EBPP ES bundle supports both accounts receivable and contract accounting. Use case 1 shows how bill presentation works in accounts receviable; use case 2 shows how bill presentation works in contract accounting, and payments, shown in use case 3, are the same for both accounts receivable and contract accounting.

Audience

(Back to #EBPP Table of Contents)

The EBPP ES bundle is of value to any company of any size that presents invoices to and collects payments from customers. It is primarily for direct business-to-consumer interactions that require credit card authorization and payment. This ES bundle can be used by SAP customers who wish to upgrade the functionality of their existing backend systems, or by non-SAP customers who wish to extend the functionality of key software components of their backend systems.

For details on Service Operations, Business Objects and Process Components, please check the ES Workplace.


How to Use This ES Bundle

Billions of invoices are still being processed on paper. This requires the creation of a printed bill, putting it into an envelope and paying for postage. If an error occurs, or there is a problem with a bill, the customer service response time is delayed by the nature of the paper-based transaction and transit time.

This ES bundle delivers obvious cost savings through the ability to electronically present bills and process payments. This ability not only streamlines business processes associated with archiving, but it vastly reduces the potential for errors that can occur during the reconciliation of incoming payments.

The customer also benefits from an easy-to-access source of information about paid and unpaid invoices, as well as rapid communication and self-service functions. In addition, this ES bundle offers an easy way to integrate with credit card processors, thus enabling real-time authorization and settlement of credit card transactions.

This section explores a series of use cases for the EBPP ES bundle. Each use case shows how different outcomes can be achieved by using the enterprise services in different combinations. While these examples illustrate a few of the ways that this ES bundle could be used, the intention is to show the flexibility and reusability of these business objects and enterprise service operations so that you will have a clearer understanding of how to best deploy them in your own environment.

Support for Contract Accounting

This bundle offers connections with two backend systems: Accounts Receivable (FI-AR) and Contract Accounts Receivable and Payable (FI-CA). Services that connect with Accounts Receivable are described in Use Case 1; services for Contract Accounting are described in Use Case 2. Payment capabilities, which are common to both, are described in Use Case 3.

EBPP Table of Contents

Use Case 1: Presentation of Open and Paid Invoices (Accounts Receivable)

(Back to #EBPP Table of Contents)

This use case begins when a customer places an order. The sales order updates the backend system with all of the relevant details about the item or items being ordered. It also updates the backend system during the billing process to reflect that there is now an open item with a due payment and that this invoice is posted to the customer's account. Anytime the customer is logged on to the composite application, he can review a list of open and paid invoices.

Once the customer is logged into the composite application and wants to display his customer account, the Trade Receivables Payables Account business object is accessed. This includes two service operations that are central to this ES bundle: Find Open Item by Customer and Find Cleared Item by Customer.

Find Open Item by Customer fetches a list of unpaid invoices from the backend system. The list is compiled by customer ID number.

The Find Cleared Item by Customer service operation fetches the list of paid invoices from the backend system. Again, the list is compiled based on a customer ID number. This information can be shown on the same page as the unpaid invoices or on a separate page, whatever best fits the needs of your company and the design of the composite application you create to consume these services.

The customer can now see a complete history of his transactions with the company. The number of transactions listed can be customized by a business architect in the backend system during the planning of this process.

The following table summarizes these steps and the related enterprise services:

Step

Enterprise Service Invoked

Step 1: The customer places an order, which creates an open item in SAP ERP

(no enterprise service is invoked during this step)

Step 2: The customer logs into the composite application

(no enterprise service is invoked during this step)

Step 3: The composite application finds all open and cleared items for the customer

Find Open Item by Customer
Find Cleared Item by Customer

Step 4: The customer can review a complete history of his transactions

(no enterprise service is invoked during this step)

Use Case 2: Presentation of Open and Paid Invoices (Contract Accounting)

(Back to #EBPP Table of Contents)

Some companies, especially telecommunications companies and utilities, use contract accounting instead of a standard accounts receivable system. In contract accounting, a customer may have contracts for a number of services with the company. For example, a telecommunications company may provide both mobile and landline telephone service, yet present the customer with a consolidated bill for these services. The services in this use case "parallel" the services in Use Case 1, but describe how presentation of open and paid invoices works for a contract accounting backend system.

Once the customer is logged into the composite application and wants to display his customer accounts, the Contract Account business object is accessed. This business object shows a customer what services he has with the company. This includes two service operations: Find Contract Account Receivables Payables Register Item by ID and Find Contract Account Split Item Group by Business Partner ID.

If a user identifies himself by contract account ID, the Find Contract Account Receivables Payables Register Item by ID enterprise service retrieves the open items for his accounts in the back-end system and displays them.

If the user supplies a business partner ID, the Find Contract Account Split Item Group by Business Partner ID enterprise service can be invoked to show the user all of his open items.

The customer can now see a complete history of his transactions with the company. The number of transactions listed can be customized by a business architect in the backend system during the planning of this process.

The following table summarizes these steps and the related enterprise services:

Step

Enterprise Service Invoked

Step 1: The customer logs into the composite application to view charges for his account

(no enterprise service is invoked during this step)

Step 3: The composite application finds and displays all charges for this contract account

Find Contract Account Receivables Payables Register Item by ID
or Find Contract Account Split Item Group by Business Partner ID
(depending on whether the customer identified by contract account ID or business partner ID)

Step 4: The customer can review a complete history of his charges

(No enterprise service is invoked during this step)

Use Case 3: Downloading a Detailed Invoice

(Back to #EBPP Table of Contents)

Customers often have questions about their invoices. In addition to seeing the invoice and the amount, the customer may want to download an invoice.

The customer selects the option to download a PDF of the invoice in the composite application, which triggers the Read Customer Invoice Portable Invoice Document enterprise service operation. The customer can then view the detailed invoice in PDF format.

The following table summarizes these steps and the related enterprise services:

Step

Enterprise Service Invoked

Step 1: The customer, logged into the composite application, selects the option to view a particular invoice in PDF format

(no enterprise service is invoked during this step)

Step 2: The composite application retrieves the PDF of the invoice the customer requests it and displays it to the user

Read Customer Invoice Portable Invoice Document

Use Case 4: Payment by Direct Debit (for both Accounts Receivable and Contract Accounting backend systems)

(Back to #EBPP Table of Contents)

Your customer can now see a list of paid and unpaid invoices. The next step is to provide a way for the customer to pay invoices via the composite application. There are two options available to the customer using this ES bundle: pay by direct debit or pay by credit card.

The Contract Account Receivables Payables Register business object holds the customer's bank and credit card information. Any time the customer selects open invoices for payment he can choose the way he wants to pay.

When the customer decides to pay by direct debit, the general ledger account is accessed and the Release Trade Receivables Payables Account Split Item Group for Payment enterprise service is triggered, which flags this item for payment during the next payment run.

A dedicated payment method for direct debit is set in the open items in the backend system. Open items with the dedicated payment methods are picked up by the payment run in the backend system.

The payment run clears the open items through a posting in the backend and creates a data medium file that is sent to the house bank. The house bank processes the data medium file and transfers the funds to the companies bank account.

The following table summarizes these steps and the related enterprise services:

Step

Enterprise Service Invoked

Step 1: The customer can see their account (using the process from either use case 1 or use case 2)

(no enterprise service is invoked during this step)

Step 2: The customer decides to pay by direct debit

(no enterprise service is invoked during this step)

Step 3: The customer indicates what items to pay and selects an option to pay them

Release Trade Receivables Payables Account Split Item Group for Payment

Step 4: The items are now flagged for payment during the next payment run

(no enterprise service is invoked during this step)

Use Case 5: Payment by Credit Card (for both Accounts Receivable and Contract Accounting backend systems)

(Back to #EBPP Table of Contents)

Customers can also pay by credit card. This process is a bit more complicated than direct debit, but since most everyone shops online, the steps for paying by credit card are quite familiar.

Updating Credit Card Information

Customers can update their credit card information or can enter a new credit card.

To add a new card, the customer selects the appropriate option in the composite application. The customer enters all the payment card details, such as the type of card, the card number, and the expiration date. The composite application does some validation on the data and then invokes the Create Payment Card enterprise service operation to create the payment card in the backend system. It then invokes the Change Customer Payment Card Details enterprise service operation to assign the credit card to this particular customer.

(If the customer wants to update credit card information instead, the Change Payment Card enterprise service is invoked instead of the Create Payment Card enterprise service.)

The following table summarizes these steps and the related enterprise services:

Step

Enterprise Service Invoked

Step 1: The customer, logged into the composite application, selects the option to add a new credit card

(no enterprise service is invoked during this step)

Step 2: The customer enters payment card details

(no enterprise service is invoked during this step)

Step 3: The composite application does some validation of the input and then creates the payment card

Create Payment Card

Step 4: The composite application assigns this credit card to this particular user

Change Customer Payment Card Details

Authorizing the Credit Card Payment

Paying by credit card involves sending the data to a clearinghouse to authorize the card. After the customer confirms the credit card details, selecting the option to pay triggers the Request Payment Card Authorisation service operation. The payment request is sent to a credit card clearing house, with the card number and validity date, as well as customer information (name, billing address) and the transaction information (amount of purchase, article). The clearing house determines whether the funds are available and validates the card. The authorization response is sent back through the Request Payment Card Authorisation service operation, which outputs a positive response (or a negative one) and moves the process to the next step. Once the credit card has been authorized, the composite application can display a confirmation message to the user, who can then log out. The composite application can complete the process without user interaction.

When an authorization is granted for a particular open item, the composite application then invokes Release Trade Receivables Payables Account Split Item Group for Payment enterprise service operation, which sets a flag in the backend system to process this payment during the next payment run. During the payment run, the backend system picks up the open items with this payment method and transfers the items to a particular general ledger account.

Settling the Credit Card Payment

The settlement phase now begins - at this point, the credit card has been authorized and the customer does not need to be logged into the composite application. The general ledger account and the Request Payment Card Payment service operation are utilized to enact the transaction. The data associated with the open item to be paid by credit card is sent to the clearing house. The clearing house replies with a settlement response (via the Change Clearing House Payment Order Based on Confirmation service operation), and initiates the funds transfer. Settlement requests are usually sent to the clearing house in batches, but they can also be done in real time for each customer depending on the volume of business being transacted. Finally, the Change Clearing House Payment Order Based on Confirmation service operation posts a confirmation of the transaction in the backend system.

The following table summarizes these steps and the related enterprise services:

Step

Enterprise Service Invoked

Step 1: The customer, having confirmed which card to use, selects the option to pay using the selected credit card

(no enterprise service is invoked during this step)

Step 2: The composite application sends the request to the clearinghouse

Request Payment Card Authorisation

Step 3: The clearing house responds using the same service from Step 2 (because of the synchronous nature of the enterprise service)

See Step 2

Step 4: The composite application displays a confirmation message to the user

(no enterprise service is invoked during this step)

Step 5: The composite application sends the data to the clearinghouse and requests payment

Request Payment Card Payment

Step 6: The clearinghouse replies with a settlement response and initiates a funds transfer

Change Clearing House Payment Order Based on Confirmation

Step 7: Once the transaction is completed, the clearinghouse invokes the service again to confirm the transaction

Change Clearing House Payment Order Based on Confirmation

Use Case 6. Payment by Credit Card in SAP ERP Order-to-Cash workflow (Sales and Distribution - Financial Accounting)

(Back to #EBPP Table of Contents)

The Order-to-Cash workflow in the SAP ERP Sales and Distribution and Financial Accounting (SD-FI) modules support payments via payment cards. The payment card details are captured during Order Entry, the call for authorization is sent during Order Save and the Settlement Request occurs by executing transaction FCC1 after an Invoice is successfully posted to Accounting using a payment card. The external interface for Authorization and Settlement calls were previously satisfied by the Cross Application Payment Card Interface (CA-PCI) but can now be satisfied by Enterprise Services contained in the EBPP Bundle.

Sales Order Entry in SAP ERP

Similar to Use Case 1, this use case begins when a customer places an order - but via the SAP GUI, perhaps in transaction VA01. The sales order updates the backend system with all of the relevant details about the item or items being ordered. During Order Entry payment card information can be captured on the Sales Order in the Header Payment Card screen.

Authorizing the Credit Card Payment

Paying by credit card involves sending the data to a clearinghouse to authorize the card. After the end-user enters the payment card details and saves the sales order, the SAP ERP application will trigger the Request Payment Card Authorisation service operation. The payment request is sent to a credit card clearing house, with the card number and validity date, as well as customer information (name, billing address) and the transaction information (amount of purchase, article). The Customer Verification Value (CVV) may also be sent for validation. The clearing house determines whether the funds are available and validates the card. The authorization response is sent back through the Request Payment Card Authorisation service operation, which outputs a positive response (or a negative one) and moves the process to the next step. Once the credit card has been authorized, the SAP ERP application will capture a confirmation message which is visible to the end-user in the order's Payment Card Header screen
When an authorization is granted on a sales order the business logic in the SAP ERP application will allow for creation of subsequent Delivery, Invoice and Accounting documents. Once an Invoice has successfully been posted to Accounting, and the authorization details have been used to shift the open item from the customer A/R account to a Payment Card Receivable Account (ex: Visa/MC Receivable), the authorization details are eligible for settlement processing.

Settling the Credit Card Payment

The settlement phase now begins - at this point, the credit card has been authorized and the SAP ERP settlement program (transaction FCC1, program RFCCSSTT) will include the authorization details in the next settlement batch submission. The general ledger account and the Request Payment Card Payment service operation are utilized to enact the transaction. The data associated with the open item to be paid by credit card is sent to the clearing house. The clearing house may later reply with a settlement response (via the Change Clearing House Payment Order Based on Confirmation service operation), as part of the funds transfer process. Settlement requests are usually sent to the clearing house in batches, but they can also be done in real time for each accounting posting depending on the volume of business being transacted and the parameters entered in the selection screen of the SAP ERP settlement program. Finally, the Change Clearing House Payment Order Based on Confirmation service operation can be used to post a confirmation of the transaction in the SAP ERP application.

The following table summarizes these steps and the related enterprise services:

Step

Enterprise Service Invoked

Step 1: The end-user creates a sales order in the SAP ERP application via the SAP GUI (ex: via transaction VA01)

(no enterprise service is invoked during this step)

Step 2: During Sales Order SAVE the SAP ERP application sends the authorization request to the clearinghouse

Request Payment Card Authorisation

Step 3: The clearinghouse responds using the same service from Step 2 (because of the synchronous nature of the enterprise service)

See Step 2

Step 4: The SAP ERP application stores (and can display) a confirmation message visible to the user

(no enterprise service is invoked during this step)

Step 5: After an Invoice is successfully posted to Accounting with payment card authorization information, the SAP ERP application sends the data to the clearinghouse and requests payment

Request Payment Card Payment

Step 6: The clearinghouse may reply with a settlement response and initiate a funds transfer (OPTIONAL - based on clearinghouse capabilities)

Change Clearing House Payment Order Based on Confirmation

Step 7: Once the transaction is completed, the clearinghouse may invoke the service again to confirm the transaction (OPTIONAL - based on clearinghouse capabilities)

Change Clearing House Payment Order Based on Confirmation

Credit Card Number Security - Tokenization (Paymetric Partner defined Enterprise Service)

In addition to the processing of payments with payment cards via the Enterprise Services listed above, it is also possible to address PCI DSS requirements for securing credit card numbers across the systems in a Merchant's Enterprise environment through the use of Partner-delivered Enterprise Services.  Integration of the Paymetric Tokenization Service utilizes a Partner-delivered Enterprise Service to extract unencrypted card numbers from the SAP ERP application, transmit them to the Paymetric Tokenization service, encrypt the data and assign a Token, store the encrypted data centrally in the Paymetric Tokenization application outside the Merchant's other systems and return the Token to the SAP ERP application.  The Token is stored in the SAP ERP application in all standard Credit Card number fields linked to the CCNUM domain including:

  • FPLTC-CCNUM (card numbers linked to Sales Orders and Invoices)
  • BSEGC-CCNUM (card numbers linked to Accounting Documents)
  • VCKUN-CCNUM (card numbers linked to Customer Master records)
  • VCNUM-CCNUM (card numbers linked to Customer Master records)

The Paymetric Tokenization solution can be deployed as an On Premise appliance located in an internal data center in which the Merchant hosts the application or as an On Demand Service with Paymetric hosting the application and stored data external to the Merchant's environment.  Centralization of stored, encrypted credit card number data and the encryption keys will help minimize the number of encryption applications across and Enterprise.  Use of an external, On Demand tokenization service can help to greatly diminish the focus of a PCI DSS audit on a Merchant's internal systems and also provide the following benefits.

  • Centralize secure storage of data across multiple systems through integration with the Tokenization service
  • Centralize secure storage of encryption keys through consolidation of individual encryption applications currently deployed across multiple systems
  • Outsource secure storage service to an external provider and minimizing capture of RAW card numbers in internal systems
  • Facilitate passing of Tokens between internal systems (EX: Web Store passing order and payment data to SAP ERP) for secure "in transit" communication of payment data
  • Further restrict which end users have access to view RAW card numbers through use of customer defined SAP security objects - including direct access to the data in the database (EX: A user running transaction SE16 to view table FPLTC would only be able to view Tokens and not RAW card numbers)
  • Maintain security of card numbers when a Production system is periodically copied to a non-Production environment (EX: QA or Sandbox) - Tokens would be useless in such cases and would require no additional conversions or steps to render the data unusable
  • Requests for Authorization and Settlement sent through the standard SAP Enterprise Services could include a Token rather than a RAW card number thereby providing additional security during external calls to Service Providers not available with other methods of encryption in SAP ERP today

Using this ES Bundle with Partner Applications

(Back to #EBPP Table of Contents)

  • Paymetric
    The SAP enterprise services for processing credit card payments enable the outbound passing of authorization and settlement data to the XiPayNet On Demand Service. The XiPayNet On Demand service, the first SaaS payment service to support SAP's enterprise SOA payment services interface, is an intelligent transaction processing service that delivers payment card processing from within a secure, PCI DSS compliant environment. XiPayNet solutions utilize a modular architecture engineered for easy enterprise integration and support a variety of payment types across a number of geographical regions. An advanced graphical user interface provides point of sale transaction entry, research tools, and extensive reports to allow you to manage electronic payments. Paymetric also provides support and consulting services. More information about Paymetric and XiPayNet can be found at http://www.paymetric.com.
  • SECUDE International AG
    PCI DSS (Payment Card Industry Data Security Standard) compliance is an urgent topic for companies that process card payments and use SAP?s Electronic Bill Presentment and Payment ES bundle. Data encryption, secure user access, and application security are among the requirements for PCI DSS compliance. SECUDE offers proven solutions for strong 2-factor user authentication, encrypted communication in SAP environments and automated vulnerability checks for SAP NetWeaver. These solutions can be used with the Electronic Bill Presentment and Payment ES bundle. More information about SECUDE solutions for SAP security can be found at http://www.secude.com/sap.

Future Directions

(Back to #EBPP Table of Contents)

Another possible future direction would be to enhance this bundle so that suppliers could see whether customers have paid them or not. Providing a supplier self-service in this way would decrease telephone calls to the Accounts Receivables department asking whether a particular customer has paid a particular supplier.

Connectivity

(Back to #EBPP Table of Contents)

EBPP utilizes Extensible Markup Language (XML) messaging to communicate between SAP NetWeaver and third-parties such as credit card clearing houses.
Internal communication between backend systems is part of the basic functionality offered by SAP ERP 6.0.

System Requirements

(Back to #EBPP Table of Contents)

  • SAP Biller Direct (for use of some of the enterprise services in this bundle)
  • Connection to a payment service provider (clearinghouse)

Success Stories

(Back to #EBPP Table of Contents)
Author: Olaf Reiss, GISA GmbH, Feedback to: olaf.reiss@gisa.de
Customer experiences with the implementation of the ES Bundle EBPP - From paper to Process platform
Who is GISA?

GISA GmbH, a German services provider with strong focus on the utilities industry, is dedicated to a strong growth strategy focused on broadening its customer base and offering first-class customer services. In order to best serve their customers, the company needed an adaptable IT infrastructure that would scale as needed to serve its growing customer base and streamline business operations. Therefore GISA established a business process platform and decided to follow a service oriented approach in 2006.
 
Corporate Business Process Platform of GISA
One of the first steps on GISA's enterprise SOA roadmap was to put an improved electronic billing and payment process in place using the ES Bundle Electronic Bill Presentment and Payment (EBPP).
GISA participated in the ramp-up of SAP's 6.0 (ERP2005) Enhancementpack 1 with the solution EBPP and implemented the project together with SAP Consulting.

GISA corporate platform (click to enlarge)


What were GISA's pain points and how could the ES Bundle EBPP resolve them?
The invoicing process still invokes high costs, especially within the service industry. Services still have to be formally approved by the customer, requests and complaints need to be dealt with. Typically, this is a paper-based process with customer service response time being delayed by the nature of the paper-based transaction, transit and communication time.





Late invoicing and even later payments by customers have a negative effect on GISA's cashflow.
Using enterprise services of EBPP enables GISA to streamline the billing process in order to reduce transaction efforts and costs. Implementing a platform solution with the EBPP enterprise services also means  that GISA now offers immediate access to invoice information, improved payment facilities and in general more transparency to their customers. Furthermore it lowers TCO by easy incorporation of data from non-SAP and SAP applications into the process.
*How does the process look like and how does it work on the corporate platform?*

Information needed to be extracted from the SAP ERP system as well as from external systems e.g. SLA Tools. The decision was then taken to create a solution with 6 main scenario steps:

  1. Service Enrollment = Order Handling process
  2. Open Bills
  3. Pay Bills
  4. Cleared Bills
  5. Master data
  6. SLA / Quality Reports

Enterprise services from the ES bundle EBPP are used in the scenario as well as existing SAP interfaces and GISA's own web services.

For each of the scenario steps, details about the data sources, how to exchange the data between the different backend systems and the platform as well as the user interface design have been discussed within the project team and GISA business.

GISA Process including ES Bundle EBBP (click to enlarge)


The section below describes the main elements and functions of the entire order handling and billing process.
1.     Service Enrollment = Order Handling process
This process part starts with an sales order created in the SAP ERP system for the various services GISA delivers to its customers (e.g software/hardware maintenance, consulting services, outsourcing). The customer is informed by email that new sales orders are displayed on GISA's corporate platform. There the customer can then log on to the portal of the platform in order to review and approve the individual sales order or send an email with remarks/complaints.
Approved sales orders are automatically released for billing in the backend and the corresponding FI invoices are created.





This part of the process has been implemented using the following interfaces and web services:
-         Display of open sales orders - WebService
-         Change sales order - during approval - WebService
-         Display of sales order document - BAPI

-         Inbound Email service for customer complaints - GISA's own web service

2.     Open Bills
After the approval of the sales order and the automatic billing run, the customer receives an email notification informing him about new invoices on the portal of the corporate platform. The customer can review these open bills, print out the billing document, select the ones he wants to pay and enter his bank data for direct debit payment. Before executing the payment, he can review his selection and print this overview for his own reference. During payment execution, the FI documents in ERP module Accounts Receivables are updated with information.

This part of the process is covered by the EBPP enterprise services for Accounts Receivables:

-         Find open item by customer

-         Create due payment

SAP interfaces and GISA's web services have been included:

-         Display billing document as PDF - BAPI

-         Inbound Email service for customer complaints - GISA's own web service

3.     Cleared Bills
This process step allows the customer to view invoices he has already approved for payment and for which GISA has received the payment.

This step is based on the EBPP enterprise service

-         Find cleared item by Customer

4.     Master data
The customer is also given the possibility to view and change his address, communication and bank details. This is implemented using SAP standard interfaces.

5.     Quality / SLA Reports

GISA offers their customers regular quality reports showing the compliance of the negotiated SLA's to the customers e.g. amount and process time of the incidents, availability of the system landscape and so forth.

These reports are maintained in a SLA tool and displayed on the portal of the corporate platform via KM web interface.

Outlook

GISA plans to enhance the current platform solution in future by adding new enterprise and web services.

  • Enterprise Service enablement of Sales order and master data.
  • Extend customer base using this solution.
  • Extend services processed via this solution.
  • Two additional releases planned for 2007

GISA Project View - by SAP Consulting [Author: Susanne Bort; feedback to susanne.bort@sap.com]

From Blueprint to Implementation - Project Phases

GISA and SAP Consulting started the project with a detailed analysis of the company's current order handling and billing process.

A project plan was defined and special attention paid to activities regarding the usage of enterprise and web services.

The entire implementation time was about 8 weeks, and 2 weeks for the EBPP part.

Process Architecture (click to enlarge)


1. Project preparation





  • Decision about the business processes
  • Embedded the solution into corporate business and it strategy
  • Organization of the ramp of mySAP ERP 2005 enhancement pack 1 together with SAP ramp-up team

2. Business Blueprint

  • Modelling of the new order and billing process and embedding the process into GISA's company processes
  • Evaluation of the existing Enterprise Services and WebServices concerning  the service provisioning, to be used / reused in the project and
  • Decision which additional services have to be designed
  • Definition of a role and authorization concept and the naming convention for the product catalog, software and development components, and technical connections

3. Realization

  • During the implementation, all these services have been orchestrated to build GISA's business processes.
    This procedure is comparable to building a new house with the building blocks according to the architecture drawings

4. Production preparation

  • Preparation of the productive system landscape
  • Going Live Check

5. Going Live

  • Selected customers can access the portal and started the service consumption  
    SAP solution:
  • mySAP ERP2005, (Ramp-Up) Enhancement Pack 1, SP 7.0,
    Enterprise Service Bundle EBPP
  • SAP Netweaver Portal 2004s SP 10
  • JAVA WebDynpro  and Visual Composer for Portal development;

Prerequisites are configured processes in the ERP 2005 modules Sales and Distribution and FI-Accounts Receivables.

Technologies

A range of SAP technologies has been used to realize this project separating into designtime and runtime e.g.

1. Designtime

  • SAP NWDI with all regarding components (DTR,CMS,CBS,) and the SLD - System landscape directory
  • SAP Netweaver Developer Studio
  • Adobe Livecycle Designer,
  • SAP Visual Composer

2.Runtime

  • SAP NetWeaver Portal including Knowledge Management
  • SAP WebDynpro,
  • Adobe Interactive Forms
  • Adobe Flex
    Easy Implementation and Lessons learned

Enterprise Services are easy to orchestrate to build streamlined processes and easy to consume








(Back to #EBPP Table of Contents)

Paymetric