Skip to end of metadata
Go to start of metadata

The External Cash Desk ES bundle provides companies with the ability to exchange information about open outstanding debts to external payment collectors, to receive payments for these open debts, and to process a day-end reconciliation between the company and external payment collectors.

The goal of this ES bundle is to create an environment to support the communication between external payment collectors, companies, and their customers, who are offered the flexibility to pay their bills in different locations. For example, a utility company may allow its customers to pay at a nearby location such as a grocery store, post office, or convenience store.

The advantage of this ES bundle is that it does not force a company to use a dedicated user interface. Instead, it delivers the business objects and enterprise services that enable payments in the SAP ERP 6.0 system and allows the company implementing this ES bundle to integrate the functionality into the customized look and feel of a pre-existing or newly created portal interface.

With SAP Enhancement Package 2 for SAP ERP 6.0 (EhP2), SAP delivered the ES Bundle External Cash Desk with an service oriented infrastructure to provide the possibility to exchange payment information between external payment collectors, Banks, Post Offices and Companies with high volume of invoices. The scenario in the EhP2 Solution was designed to support only external payment collectors. External payment collectors are 3rd parties who offer the services of payment collection for other companies. In this so called "external" scenario the cash desks are owned by these 3rd parties. This so called "External scenario" is based on the communication of as external payment collectors acting 3rd partis and companies.

External Cash Desk (click to enlarge)


With SAP Enhancement Package 4 for SAP ERP 6.0 (EhP4), the External Cash Desk bundle provides on top enhancements. It offers additional features to be used in a so called "Internal Scenario". The cash desks acting in the internal scenario are owned and operated by the companies which also send out the customer bills collected later on in the cash desks. The cash desks are used to collect the outstanding debts of the company. In addition to the external scenario additional features are necessary to support the internal point of view. The cash desk does not only receive customer debt information and communicate (customer) payment information - the cash desks communicate also cash desk balance related information such as deposits and withdrawals via enterprise services to the ERP backend system.

Some of the enterprise services can only be used in the internal scenario, some can be used in both, and some of them can be used only for external payment collectors.
The following table shows the availability and the scenario, which is supported by the corresponding enterprise service:

Enterprise Service

Internal scenario

External scenario

Available with

Read open Items

x

x

EhP2

Customer payment

x

x

EhP2

Reverse customer payment

x

x

EhP2

Day-End-Closing

not available

x

EhP2

Post Deposits

x

not available

EhP4

Post Withdrawals

x

not available

EhP4

Post Corrections

x

not available

EhP4

Post G/L Postings

x

x

EhP4

Request Cash Balance

x

not available

EhP4

Reverse deposit, withdrawal,
correction

ü

not available

EhP4

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.

By deploying the External Cash Desk ES bundle, your business will gain basic payment exchange capabilities. This includes the ability to send information about open items to a business partner who can then receive payments on your behalf. It allows cashiers at these locations to:

  • request a list of open items
  • select open items to pay
  • initiate payment
  • reverse payments
  • process a day-end closing procedure
  • create cash desk withdrawals
  • Create cash desk deposits
  • Create cash desk difference postings
  • Create G/L postings
  • Reverse withdrawal, deposit and G/L postings
  • Request the cash desk balance of an cash desk or branch

Table of Contents



Audience

The External Cash Desk ES bundle is of value to companies of any size that present invoices and collect payments from customers using external payment collectors. It is primarily for direct business-to-customer interactions that require exchange of open items as well as accepting payments and basis cash desk balance functionality. The enterprise services in 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. In this wiki, SAP ERP is referred to as the backend system, but with the standardization of web service interfaces, integration with other backend systems is also possible. More precisely, references to SAP ERP 6.0 relate to the Financial Contract Accounts Receivable and Payable component of SAP ERP 6.0.

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


How to Use This ES Bundle

In recent years, customer payment behavior and customer expectations have changed. For companies with broad customer bases, such as those in the utilities or telecommunications sectors, offering customers the flexibility to pay their bills at external locations has become essential. This ES bundle provides companies with the functionality to close that gap and to enable them to offer their customers convenience and flexibility when paying their bills.

Customers often pay their bills using direct debit, check, credit card, or bank transfer. But more and more independent external payment collectors are entering the market. These external payment collectors offer customers the ability to pay their telephone or electricity bills at other locations (or external agencies). In this bundle, the external agencies (or third parties) could be check-cashing businesses, post offices, bank branches, gas stations, or lottery shops, where a customer can go to pay an electricity, telephone, gas, or other type of utility bill.

From a user interface perspective, these external companies run different applications, deploying a cash desk application from any number of providers. Enterprise services, along with the mapping capabilities of SAP NetWeaver Process Integration (formerly XI), provide easy integration between SAP ERP and these applications.

Basically, the external payment collector requests the amount of any outstanding debts for a particular customer. When the open items have been transferred to the external payment collector's system, the external payment collector presents the items to the customer, who then selects the items he wishes to pay. The payment information is then transmitted back to the company, which clears the open items immediately in SAP ERP.

This ES bundle delivers obvious cost savings through its ability to easily connect with external payment collectors. In the past, this required an expensive custom integration and issues about error handling and reconciliation had to be handled by the integration team or handled manually using reports from each system. With the advent of this ES bundle, a monitoring tool in SAP ERP offers an easy to use interface providing immediate answers to any questions. The customer also benefits from an easy-to-access source of information for unpaid invoices, as well as from rapid payment processing. Reconciliation procedures are built into the process, and the near real-time processing of payments makes discrepancies much less likely.

In many cases the companies itself provide company owned cash desk. Also these cash desks may benefit from the new technology of the enterprise services. Beside the payment information the company owned cash desk communicates in addition cash desk balance related information, like withdrawal and deposis. The cash desks communicate also this cash balance related information via enterprise services to the ERP backend system. The ERP backend system receives and processes and present these cash balance related information accordingly.

This section explores a series of use cases for the External Cash Desk ES bundle. Each use case describes how different outcomes can be achieved using the enterprise services in various combinations (and in fact, the following use cases can be used in any combination). While these examples illustrate a number of 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 and to provide a clearer understanding of how they can best be deployed. Enterprise services are typically invoked by an application, but for the purpose of illustration and visibility into the integration, these use cases describe direct invocation by the people involved.

Use Case 1: Online Processing

This use case begins when an external payment collector requests open items for a particular customer using the Find Cash Point Open Item Summary by Elements enterprise service, which uses the Cash Point Open Item Summary business object. The backend system transmits the corresponding open items to the external payment collector.

Step

Enterprise Service Invoked

Step1: Request open item

The clerk is able to request the open item of an customer. The identification of teh customer is done by an reference (Contract Account number, Invoice number etc.)

Step 2: Send open Item

The ERP-Backend system sends the open items of the corresponding customer

Step 3: Present List of Items

The open items are received and presented.

Step 4: Send payment

The clerk selects the item the customer wants to pay and send the payment to the ERP System

Step 5: Post Payment

The payment information is received in the ERP backend system. The clearing(payment) of the corresponding item is done immediately.

Step 6: Monitoring

The payment amount can be monitored in the backend monitoring tool

Step 7: Retry

In cases where a clearing is not possible a retry of the posting is scheduled.

The following information is available for open items:

  • Open amount
  • Open tax amount
  • Proposed clearing amount
  • Due date
  • Description
  • Business partner
  • Contract account
  • Contract
  • Invoice number
  • Payment form ID

Contract account and contract are business objects in SAP ERP that describe information about the financial operations of a business partner. Contract account is mandatory to store financial information, which is used to control business processes. Contract is used in industries that offer several types of accounts, for example, landline and mobile telephone service.

Payment form ID is a special object used in SAP ERP to identify and group items. Using payment form ID, SAP ERP can produce a joint invoice that includes, for example, billing for gas, electricity, and water. When the invoice is paid, this field ensures that payments are correctly allocated in the backend system.

While these fields are included by default, using SAP NetWeaver Process Integration (formerly XI), businesses implementing this bundle can easily add fields to this list. For example, if license plate number were an appropriate search criteria, extending the list of fields to include this item would be a simple process.

After downloading outstanding invoices from this customer, the external cash collector (in consultation with the customer) selects an item to pay from the list of open items and initiates the payment. The payment information is exchanged using the Create Cash Point Payment based on Cash Point Payment Create Notification enterprise service, which forwards payment information to the backend system. In the backend system, the payment clears the corresponding open item immediately.

The following information is available when exchanging payments:

  • Office and cash desk ID
  • Unique payment transaction ID
  • Grouping key (groups together payments for one day)
  • Payment amount
  • Payment explanation (clearing information for open items)
  • Payment method information (cash, check, payment cards)

Functionality provided in the ERP backend system:

SAP ERP 6.0 provides a Cash Service monitoring tool for monitoring and administering the transferred payments. The Cash Service monitoring tool is a transaction within the SAP ERP 6.0 system. Using this tool, an SAP ERP 6.0 system user can monitor the payments that have been processed and observe and resolve any problems. The Cash Service monitoring tool provides SAP ERP 6.0 users with the ability to retrieve all information relating to the exchanged payments.

If a payment could not be posted in the SAP ERP 6.0 system, the item is marked with a retry status. Retry status is triggered for those items that are transmitted to the SAP ERP 6.0 system but that cannot, for one reason or another, be successfully posted. No notification is transmitted to the payment collector as to the success or failure of a payment transaction.

For example, a payment collector transmits a payment for a customer. The payment is received in SAP ERP 6.0 and the system attempts to process the payment. However, that particular customer's contract account is currently locked by another process, preventing the payment from being successfully processed. In this case, the system retries periodically (for example, every 5 minutes) to post the payment. After a certain number of retry attempts, it generates an exception and the payment item is assigned retry status. Retries can also be initiated manually using the Cash Service monitoring tool. This backend functionality guarantees that payments are processed in a timely fashion.

All the information originating from external cash collectors is stored within the SAP ERP 6.0 application's database, and from this information payments are posted asynchronously and the open items from the customer are cleared.

Various kinds of errors are possible. If there's an incoming queue for the business partner, it may take about 5 minutes to clear that queue and process the payment. Errors can also occur if options are not set correctly. Adjusting these options expedites processing.

Some errors cannot be handled automatically, for example in the case where a payment is received for a customer with no master data record in SAP ERP. Payments that cannot be processed are stored in a pool known as a clarification list. The SAP ERP 6.0 system may also move items to the clarification list if a retry posting repeatedly fails or if correct payment allocation is not possible.

From an accounting point of view, the amount must be posted on a special account such as a clarification account. After the accounting activity is completed, a clerk from the utility company who is responsible for the clarification list has to process all the clarification items manually. The clerk tries to clarify what should happen next. Research is done to see which payments belong to which customer. (The customer cannot be contacted directly because the researcher is trying to determine to which customer the payment belongs.) If a customer receives a reminder letter informing him of nonpayment of an invoice, he will almost certainly call and complain that the payment has already been made. The clerk is then able to access the clarification list and find the payment. If the customer knows when and where he made the payment, this information can also be used to correctly allocate the payment. In other cases, the clerk may contact the external cash collector to request further information as to how a particular payment should be processed.

Use Case 2: Preload of information

In this use case, the SAP ERP 6.0 backend system transmits information pertaining to the open items of selected customers up front. The SAP ERP 6.0 system uses the Notify of Open Item Summary enterprise service to push a batch of open items to the external payment collector. The external payment collector uses this information to simplify subsequent payment processing since data does not need to be requested for each customer. Furthermore, this allows payments to be received regardless of whether the external payment collector is offline (as described in use case 3) or online. Open items can be pushed out to the payment collector either by time range (today's open items) or for a particular region (all open items for customers in Hamburg and surrounding areas).

Step

Enterprise Service Invoked

Step 1: Send out open items

The open items of customers are selected in the ERP Backend system.
The open items are transmitted as pre-load information to the external payment collectors.

This enterprise service attempts to provide external collection agencies with all the necessary data to collect money from customers who wish to pay. Open items are pushed out to the payment collector before they are due. If a customer comes in to pay her bill, the payment collector has all the necessary information to collect the money, including amount due, due date, and relevant customer information.

Preloading this information requires an agreement between the company running the SAP ERP system and the external payment collector. For example, they may decide that the company running the SAP ERP system will transmit information every night within a certain batch window or between certain hours of the day.

Use Case 3: Offline Mode

In this use case, the external payment collector accepts payments in offline mode. Offline mode could be used if the payment collector's Internet connection is not always available, as is sometimes the case in South America or in Southern Europe, or if store policy for any reason precludes an always-on connection.

The customer who wishes to pay his bill, with the ES bundle in offline mode, has to identify himself using a customer number or an invoice. Invoices often come with a bar code printed on them that enables the external payment collector to gather information simply by scanning the invoice with a bar code reader. Based on the information in this bar code, the external payment collector reads and stores relevant information about the payment, including customer name, customer number, amount to be paid, and due date.

Step

Enterprise Service Invoked

Step 1: Transmit payment information

The offline collected payment information is transmitted as bundle to the ERP backend system.

Step 2: Process payment information

The payment information is received in the ERP backend system. The clearing(payment) of the corresponding item is done immediately.

The external payment collector accepts the payments and stores the information locally. Once the connection to the backend system is reestablished, the external payment collector transmits all the information concerning the payments received offline as a batch to the SAP ERP system using the Create Cash Point Payment based on Cash Point Payment Create Notification enterprise service which uses the Cash Point Payment business object. The SAP ERP 6.0 system processes the information and posts the payments immediately.

In this way, payment collectors need never turn away any customers who wish to pay their bills. Based on a prearranged schedule - once a day, once a week, or several times a week - payment data is pushed from the payment collector to the company running the ERP system.

Use Case 4: Handling Day-end Closing

This procedure is relevant for each of the use cases discussed so far. At the end of the day, the external cash desk collector exchanges information about payments collected that day to the SAP ERP 6.0 backend system using the Create Closing Document enterprise service, which uses the Cash Point Closing Document business object.

Step

Enterprise Service Invoked

Step 1: send day-end-closing message

The cash desk send the day-end-closing message, which includes the summary information about the collected payments over the day.

Step 2: Receive and process day-end-closing message

The day-end-closing message is processed and the total amount of the message is checks with the corresponding single payments. This reconciliation step checks the balance of the communicated/received payments

The following information is available during the day-end closing process:

  • Office and cash desk ID
  • Grouping key (groups together payments for one day)
  • Total payment amount for this day

After receiving the day-end closing information, the SAP ERP 6.0 backend system can post a debit item that represents the total amount of the collected payments to the contract account of the external payment collector. Follow-up processes such as collection and reconciliation use this contract account.

Use Case 5: Create Cash Point Deposit posting

A deposit means an amount of cash entered into the cash desk to be used for the daily work, for example this money may be used as change to be returned to the customer as completion of a payment transaction or for outgoing payments (refunds). The agency usually enters a deposit to start the daily work and sends the deposit notification to the FI-CA system.

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

Step

Enterprise Service Invoked

Step 1: deposit posting

The clerk is able to enter the deposit amount he deposited into the cash desk

Step 2: Transfer of deposited amount

Deposited amount is communicated using an enterprise service

Step 3: Post deposited amount

Deposited amount is posted in the ERP backend system as an result of the processing of the associated an enterprise service

Step 4: Monitoring

Deposited amount can be monitored in the backend monitoring tool

Use Case 6: Create Cash Point withdrawal posting

A withdrawal means an amount of money in any payment category (cash/check/credit card/postal order) are taken out of the cash desk to be deposited to the bank account or just for reducing the cash-on-hand amount in the specified cash desk. The withdrawal amount must be reported accordingly into the FI-CA system.

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

Step

Enterprise Service Invoked

Step 1: withdrawal posting

The clerk is able to enter the withdrawal amount he has taken out of the cash desk

Step 2: Transfer of withdrawal

The withdrawal amount is communicated using an enterprise service

Step 3: Post commissions

The withdrawal amount is posted in the ERP backend system as an result of the processing of the associated an enterprise service

Step 4: Monitoring

The withdrawal amount can be monitored in the backend monitoring tool

Use Case 7: Create Cash point correction posting

A correction means that in the balance of an cash desk and the amount of the cash desk is not in balance. The responsible cashier counts the money in the cash desk and checks the result with the amount determined by the cash desk own balance functionality. In cases of differences the difference amount must be reported accordingly into the ERP backend system. The following table summarizes these steps and the associated enterprise services:

Step

Enterprise Service Invoked

Step 1: enter correction amount

The clerk is able to enter an amount which is necessary to balance the cash desk in cases errors between cash balance and system recorded amounts. This corresponding correction amount is entered

Step 2: Transfer correction amount

The correction amount is communicated using an enterprise service

Step 3: Post correction

The correction amount is posted in the ERP backend system as an result of the associated an enterprise service

Step 4: Monitoring

The correction amount can be monitored in the backend monitoring tool

Use Case 8: Create cash point G/L posting

This scenario covers a special case where the communicated payment information is not related directly to a business partner. Usually customers are identified at the cash desk via the Business partner or Contract account number. The Business partner and Contract account number is also used to communicate the information about the open invoice, to initiate the payment and to clear the invoice in the ERP backend system.

But there exists also cases there no-named customer payments shall be communicated and posted. An example may be the payment of park or speed penalty charges, where the customer is not known with its details. In this case the payment is posted as an G/L posting with additional reference information to clear the corresponding penalty debt in the G/L.
The following table summarizes these steps and the associated enterprise services:

Step

Enterprise Service Invoked

Step 1: Enter Payment amount

The clerk is able to enter an amount and the reference information which is necessary for the G/L posting.

Step 1: Transmit payment

The amount is communicated using the payment enterprise service

Step 1:process and post payment

The associated document is posted in the ERP backend system as an result of the associated an enterprise ser

Step 4: Monitoring

The payment can be monitored in the backend monitoring tool

Use Case 9: Initiate commission posting

If a company receives payments collected by an external payment collector it may be agreed to pay commissions based on the received payments. Therefore the ES bundle "Enhancement to External Cash Desk" allows the integration of SAP ICM management. Please note that this functionality is only released for the external scenario (external payment collectors). The calculation of the commission is initiate din the external scenario using the Agent posting functionality. As a result of the calculation an debit will be posted on the contracts account of the external agent. The calculation rules are defined and executed in the ICM management system.

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

Step

Enterprise Service Invoked

Step 1: Commissions posting

Based on the day-end-closing procedure of a cash desk and the following agent posting a commission calculation is initiated

Step 2: Calculation of commissions

The calculation of commissions is done in the connected SAP ICM application

Step 3: Post commissions

Based on the result of the commission calculation in the SAP ICM application the commission amount is posted on the corresponding contract account

Use Case 10: Request Cash Balance

It might be interesting in the ERP backend system to know the actual cash balance of a specified cash desk. Due to the asynchronous character of the cash desk services (Cash desk payments, cash desk reversals, cash desk balance postings) it is not possible to calculate the cash balance of an cash desk based on the stored information in the ERP system, some postings may be not finally processed or may be delayed. . An enterprise service is offered to get information about the cash balance. This services requests the balance of the external acting cash desk. The balance itself is calculated by the software which is running on the cash desk locally. Usually this software is provided by 3rd . The cash balance of the cash desk is transmitted into the ERP system and it is presented there.

Step

Enterprise Service Invoked

Step 1: Request Cash desk Balance

A request is sent out to get the balance of the selected cash desk

Step 2: Receive and display balance

The received cash desk balance is displayed

Using This ES Bundle with an Existing Test Application

It is possible to test the enterprise services in the External Cash Point ES bundle with SAP ERP. Test interfaces must be used to link SAP Process Integration (formerly XI) interfaces with the interfaces in the payment processor's cash desk application.

You can use the following reports to simulate the Notify of Open Item Summary, Create Cash Point Payment based on Cash Point Payment Create Notification, Create Closing Document, and Cash Point Payment Reverse Notification enterprise services respectively:

  • RFKKEXC_OPENITEM_XI_TEST
  • RFKKEXC_PAYMENT_XI_TEST
  • RFKKEXC_CLOSE_XI_TEST
  • RFKKEXC_REVERSAL_XI_TEST

To simulate the corresponding service the following reports can be used:

  • RFKKEXC_CASHJOURNAL_XI_TEST => Test report to generate deposit, withdrawal and correction based on communication of cash desks
  • RFKKEXC_GL_PAYMENT_XI_TEST => Test report to generate G/L postings based on communication of (external) cash desks
  • RFKKEXC_REVERSAL_XI_TEST => Test report to generate reversal postings
  • RFKKEXC_RETRY_POST => Test report to initiate the retry of not posted messages

Using This ES Bundle with Partner Applications

  • The SAP enterprise services for processing payments using external payment collectors enables the outbound passing of item information as well as the inbound receipt of payment and day-end-closing information.
  • When used together, the External Cash Desk ES bundle and a partner application provide an out-of-the-box solution that completely handles interactions with external payment collectors. The enterprise services in this ES bundle for processing payments using external payment collectors enable the outbound passing of item information as well as the inbound receipt of payments and day-end closing information using a cash desk application such as the WinCash application platform.
    NTS's WinCash© application platform is one solution that supports the communication between the external payment collector and the SAP ERP system using enterprise services in this ES bundle. More information about WinCash can be found at http://www.nts-gmbh.com/.
    Details about the cooperation between SAP and NTS WinCash© application are attached in the product brief "A Winning Combination: SAP® ERP and NTSwincash".

Existing Sample Code

Sample Code to Share?

If you've developed any sample code for implementing this bundle, no matter what language the code is written in, please edit this page and add it here.

CashPointRunner - Des Fisher (*des.fisher@sap.com)*

CashPointRunner is a Java application to utilise a generated Java client (generated with CE7.1.1 NWDS using SAP NetWeaver as web service run-time) for the service interface "CashPointOpenItemSummaryByElementsQueryResponse_InService" or ecc_fkk_cashpnt_opbyelemqr. Note that I have used a internal SAP system (HU2 in the esworkplace does not appear to contain a PS-CD configuration). Also note you will need to supply a username and password (see code comments for details). This Java application contains some important code like being able to output the SOAP envelope to System.out, and being able to set Proxy and Timeout HTTP settings. I hope you find it useful.

import

java.util.Calendar; **import ****java.util.Date; ****import ****java.util.GregorianCalendar; ****import ****java.util.List; ****import ****java.util.Map; ****import ****{}javax.xml.bind.JAXBContext; ***import ***{}javax.xml.bind.JAXBElement; ***import ***{}javax.xml.bind.Marshaller; ***import ***{}javax.xml.namespace.QName; ***import ***{}javax.xml.ws.BindingProvider; ***import ***{}com.sap.engine.services.webservices.espbase.client.api.HTTPControlFactory; ***import ***{}com.sap.engine.services.webservices.espbase.client.api.HTTPControlInterface; ***import ***{}com.sap.xi.fica.global.BusinessDocumentMessageHeader; ***import ***{}com.sap.xi.fica.global.BusinessDocumentMessageID; ***import ***{}com.sap.xi.fica.global.BusinessTransactionDocumentID; ***import ***{}com.sap.xi.fica.global.CashPointOpenItem; ***import ***{}com.sap.xi.fica.global.CashPointOpenItemSummary; ***import ***{}com.sap.xi.fica.global.CashPointOpenItemSummaryByElementsQuery; ***import ***{}com.sap.xi.fica.global.CashPointOpenItemSummaryByElementsQueryMessage; ***import ***{}com.sap.xi.fica.global.CashPointOpenItemSummaryByElementsQueryResponseIn; ***import ***{}com.sap.xi.fica.global.CashPointOpenItemSummaryByElementsQueryResponseInService; ***import ***{}com.sap.xi.fica.global.CashPointOpenItemSummaryResponseByElementsMessage; ***import ***{}com.sap.xi.sapglobal.global.ObjectFactory; ***import ***{}com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl; ***public class ***{}CashPointRunner {{color:#3f5fbf}/** @param args*/public static void main(String[] args) {{color:#7f0055}final* boolean useTO = false; final String ID_OFFICE = "Z01"; final String ID_CASH_POINT = "Z001"; final boolean PRINT_SOAP_MSG = false; final boolean useWSDLEndpoint = false; final String ENDPOINT_ADDRESS = "http://dh4tdc00.wdf.sap.corp:56180/sap/bc/srt/xip/sap/ecc_fkk_cashpnt_opbyelemqr/
800/ecc_fkk_cashpnt_opbyelemqr/ecc_fkk_cashpnt_opbyelemqr_http";
/************************************************{color}
** YOU NEED TO SET THESE BEFORE RUNNING THE TEST!
*************************************************/

final String USER_NAME = ""; final String PASSWORD = ""; final String BP_ID_STR = "5300000032"; try {CashPointOpenItemSummaryByElementsQueryResponseInService service = new CashPointOpenItemSummaryByElementsQueryResponseInService(); CashPointOpenItemSummaryByElementsQueryResponseIn binding = service.getCashPointOpenItemSummaryByElementsQueryResponse_InSoapBinding(); //Add HTTP-Basic information and Endpoint... Map<String, Object> m = ((BindingProvider) binding).getRequestContext(); // The endpoint address comes from the WSDL by default.if (!useWSDLEndpoint) {m.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, ENDPOINT_ADDRESS); }
m.put(BindingProvider.USERNAME_PROPERTY, USER_NAME); m.put(BindingProvider.PASSWORD_PROPERTY, PASSWORD); if (useTO) {HTTPControlInterface hci = HTTPControlFactory.getInterface(binding); // hci.setSocketTimeout(120000); // hci.setSocketConnectionTimeout(120000); hci.setHTTPProxy("10.41.147.111", 8080); }//New SOAP MessaageCashPointOpenItemSummaryByElementsQueryMessage queryMessage = new CashPointOpenItemSummaryByElementsQueryMessage(); //Setup the message header...BusinessDocumentMessageHeader msgHdr = new BusinessDocumentMessageHeader(); XMLGregorianCalendarImpl crDT = new XMLGregorianCalendarImpl(); Date d = new Date(); Calendar c = Calendar.getInstance();

c.setTime(d);

crDT.setDay(c.get(Calendar.DATE)); crDT.setMonth(c.get(Calendar.MONTH)); crDT.setYear(c.get(Calendar.YEAR)); msgHdr.setCreationDateTime(crDT);

BusinessDocumentMessageID bdmi = new BusinessDocumentMessageID(); bdmi.setSchemeAgencyID("1234567890"); bdmi.setSchemeID("1234567890"); bdmi.setSchemeAgencySchemeAgencyID("123"); bdmi.setValue("1234567890"); msgHdr.setID(bdmi); //Add the message header to the SOAP messagequeryMessage.setMessageHeader(msgHdr); // Set up the message body...CashPointOpenItemSummaryByElementsQuery query = new CashPointOpenItemSummaryByElementsQuery(); BusinessTransactionDocumentID pointId = new BusinessTransactionDocumentID(); pointId.setValue(ID_CASH_POINT);

query.setCashPointReferenceID(pointId);

BusinessTransactionDocumentID pointOfficeId = new BusinessTransactionDocumentID(); pointOfficeId.setValue(ID_OFFICE);

query.setCashPointOfficeReferenceID(pointOfficeId);

JAXBElement<java.lang.String> bpId = new JAXBElement<String>(new QName("", "SelectionByDebtorPartyInternalID"), java.lang.String.class, null, BP_ID_STR); // This actually adds the bpID through the getter (it's accessing// the live JAXB object)query.getSelectionByDebtorPartyInternalID().add(bpId); //Add the message body to the SOAP messagequeryMessage.setCashPointOpenItemSummaryByElementsQuery(query); /* * This is useful for debugging!

*/if (PRINT_SOAP_MSG) {{color:#3f7f5f}// Output the SOAP Message...System.out.println("Here comes a print out of the XML request message (without the SOAP envelope)."); ObjectFactory factory = new ObjectFactory(); JAXBElement<CashPointOpenItemSummaryByElementsQueryMessage> element = factory.createCashPointOpenItemSummaryByElementsQueryMessage(queryMessage); // Marshall to a System.out:try {JAXBContext jc = JAXBContext.newInstance("com.sap.xi.sapglobal.global"); Marshaller marsh = jc.createMarshaller(); // NB: Needs access to jsr173_api.jar in build pathmarsh.marshal(element, System.out); } catch (Exception e) {System.out.println("There was an error writing out the request message to XML!"); e.printStackTrace();

}

}//Call the service!CashPointOpenItemSummaryResponseByElementsMessage resp = binding.cashPointOpenItemSummaryByElementsQueryResponseIn(queryMessage);

System.out.println("Here come the Open Items..."); System.out.println("---------------------------"); //Get the open items and print them out.List<CashPointOpenItemSummary> oiList = resp.getCashPointOpenItemSummary(); int size = oiList.size(); for (int i = 0; i < size; i++) {CashPointOpenItemSummary oiSumm = oiList.get(info) ;

List<CashPointOpenItem> ois = oiSumm.getCashPointOpenItem(); int oisSize = ois.size(); System.out.println("There are " + oisSize + " open items for this Business Partner (" + BP_ID_STR + ")"); System.out.println(" "); for (int j = 0; j < oisSize; j++) {CashPointOpenItem oi = ois.get(j);

GregorianCalendar cal = oi.getDueDate().toGregorianCalendar();

System.out.println("***Open Item: " + (j + 1) + "***"); System.out.println("Amount: " + oi.getOpenAmount().getValue() + " in " + oi.getOpenAmount().getCurrencyCode()); System.out.println("Due Date: " + cal.get(Calendar.DATE) + "/" + (cal.get(Calendar.MONTH) + 1) + "/" + cal.get(Calendar.YEAR)); System.out.println("Contract: " + oi.getContractID()); System.out.println("Contract Account ID: " + oi.getContractAccountID()); System.out.println("Contract Account Document ID: " + oi.getContractAccountDocumentID().getValue()); System.out.println(" "); }

}

} catch (Exception e) {e.printStackTrace();

System.out.println(e.getMessage()); if (e.getCause() != null) {System.out.println(e.getCause().getMessage()); }

}

}

}

Future Directions

Future directions for this ES bundle will be market-driven.

Connectivity

The connection between external software and the SAP ERP 6.0 system is done using SAP NetWeaver Process Integration and the services of this bundle.

Third-party applications connect with the services of this bundle by using SAP NetWeaver Process Integration's mapping tool. For example, NTS has connected WinCash with these interfaces using the SOAP adapter.

System Requirements

  • SAP NetWeaver Process Integration (formerly XI) with software component FI-CA 6.02 installed
  • WinCash© or any other cash desk application that can consume the enterprise services

End-to-end Processes Where This ES Bundle Is Used