BBP Ret 005 Pos Interface v1.2

at
Project Name
Business Blueprint Documents

Version No.: 1.120
Effective Date:21.12.2016
Module: SAP Retail

Process: POS Integration
Document No.: BBD_RET_005_POS_Interface
ARVIND / IBM Confidential

Business Blueprint Document – Retail (Module) – POS Inbound
(Process Details)
Document No: BBD_ RET_005 Version No: 1.02 Effective Date:
0621.1112.2016 Project Arvind
Table of Contents
1.0 DOCUMENT INFORMATION.........................................................................................................5

1.1 DOCUMENT VERSION.....................................................................................................................5
1.2 DOCUMENT APPROVAL DETAILS.......................................................................................................5
1.3 REFERENCE DOCUMENT DETAILS (IF ANY).........................................................................................6
1.4 ABBREVIATIONS USED (IF ANY)........................................................................................................6
2.0 BUSINESS REQUIREMENT............................................................................................................6

2.1 APPLICABILITY...............................................................................................................................6
2.2 DETAILS OF BUSINESS REQUIREMENT................................................................................................7
2.3 BUSINESS REQUIREMENT FLOW DIAGRAM (IF ANY).............................................................................9
3.0 POS INTEGRATION.......................................................................................................................9

3.1 POS INTERFACE – OUTBOUND/DOWNLOAD THE MASTER & TRANSACTIONAL DATA TO THE POS............10
3.2 POS INBOUND............................................................................................................................10
3.2.1 POS Transactions (Sales, Tender, Goods Movement & Financial) Management11
3.2.2 POS Inbound Proce...................................................................................................14
3.3 POS MESSAGES..........................................................................................................................14
3.3.1 Inbound Error Message............................................................................................14
3.4 PROCESS MAPS:..........................................................................................................................15
3.5 BUSINESS PROCESS STEPS.............................................................................................................15
3.6 KEY DATA STRUCTURE ELEMENTS...................................................................................................15
3.7 ASSOCIATED MASTER DATA ELEMENTS (IF ANY)...............................................................................16
3.8 INTERFACE MAPS (IF ANY)............................................................................................................16
3.9 REPORTS MAPPING (IF ANY).........................................................................................................16
3.10 PROCESS VARIATIONS / EXCEPTIONS (IF ANY)...................................................................................16
Arvind/IBM Confidential
Page 2 of 29
(Process Details)
4.0 INTEGRATION POINTS (IF ANY).................................................................................................16
5.0 KEY BUSINESS IMPROVEMENTS (IF ANY)..................................................................................16
6.0 CHANGES TO EXISTING ORGANIZATION (IF ANY).....................................................................17
7.0 GAPS...........................................................................................................................................17
8.0 DEVELOPMENT CONSIDERATIONS (RICEFW)............................................................................17

8.1 DATA CONVERSION CONSIDERATIONS.............................................................................................17
8.2 INTERFACE CONSIDERATIONS.........................................................................................................18
8.3 FORM CONSIDERATIONS...............................................................................................................18
8.4 REPORTING CONSIDERATIONS........................................................................................................18
8.5 FUNCTIONAL ENHANCEMENT CONSIDERATIONS................................................................................19
9.0 AUTHORIZATION REQUIREMENTS............................................................................................19
10.0 ANNEXURE (IF ANY)...............................................................................................................19
11.0 Flow Chart Legend..................................................................................................................20
Page 3 of 29
(Process Details)
1.0 Document Information
Document Category Business Blueprint Document

Document Title POS Inbound
Author Chandra
File Name BBP_RET_005_POS Inbound_V1.0
Created On 06.11.2016
1.1 Document Version
Date Version No. Author Change Description

06.11.2016 V1.0 Chandra Initial Release
Post incorporation of changes in
25.11.2016 V1.1 Naina Acharya Blue Print validation workshop
Post incorporation of changes in
13.12.2016 V1.2 Abhijit Nag/Naina Acharya Blue Print validation workshop
1.2 Document Approval Details
Function Name (Designation) Role Sign & Date

Chandra Kumar IBM Team Member 06.11.2016
Prepared By
Abhijit Nag Core Team Member
Naina Acharya IBM Team Lead
Reviewed By
Process Owner
T Sudhir IBM Project Manager
Abel Correa Arvind Project Manager

Approved By
Page 4 of 29
(Process Details)
1.3 Reference Document Details (If any)

Department /
Title of the Document Version No Organization Reference / Remarks
Project Kick off Arvind
Bangalore
1.4 Abbreviations Used (If any)

Abbreviation Description
Point of Sales
POS
Process Integration (middleware)
PI
Intermediate Document
IDOC
Application Link Enabling
ALE
Electronic Data Interchange
EDI
2.0 Business Requirement
2.1 Applicability
The process described in this document details POS Integration processes necessary for for enabling
ARVIND’s various business processes defined under Business Blueprint Document for retailing process.
The document is applicable for following business verticals of Arvind group:
Page 5 of 29
(Process Details)
Business Vertical Applicability (Yes/No)

Yes
The Arvind Stores
Yes
Fashion division
Yes
Sports division
Yes
Arvind True Blue Ltd
Yes
Arvind Premium Retail Ltd
Yes
Arvind Ruff and Tuff Ltd
Yes
Arvind Internet Limited
Yes
Garment export division
2.2 Details of Business Requirement
Business Requirements Description Comments

A customer orders in Store or online but wants it to ship
to customer. A customer walks in a store, orders the
article at store or customer orders online, and wish to
pick up from Store, which is fulfilled by same store but
shipped to customer location. Tender can be cash,
Omnichannel / credit card, Gift voucher, Promotional voucher, Credit
INSTORE/ Online/ note, Loyalty cards, Cash/Card on delivery, Net banking
Sales and Advance payment. The sales from SOM needs to
come to POS as AIL sales and be created. Tender will be
send separately based on VAT and CST and also marked
as AIL sales and posted in POS. From POS the data will
be aggregated based on date, store , division(brand) ,
style , code and quality ( to understand the barcode)
Omnichannel / In A customer orders in Store or online and ships to
Store /Online/ Sales Customer from warehouse . warehouse. Order is
fulfilled by warehouse and shipped to customer
location. When order is created online in NNNOW.com
or instore in SOM, Shield will first check the inventory of
the article in warehouse and create a customer order
which will be sent to warehouse ERP system and will
create a sales order for warehouse customer. There is a
Page 6 of 29
(Process Details)

virtual WH POS which is called capsule warehouse. (Our
Process is a slightly different. I believe, you would have
to incorporate the same in the document)Stock
Transport Order will be created to transfer articles from
warehouse to warehouse virtual POS. Outbound
delivery will be created automatically. Thereafter
picking, packing happens and goods will be transferred
to the selling area of the warehouse. Now GRN will be
done at the WH POS and the inventory will go up. The
article will be physically dispatched to the customer
location. Simultaneously the sales is confirmed in SOM
and is replicated in POS as AIL sales.
Tender can be cashbe ,cash, credit card ,card, Gift
voucher ,voucher, Promotional voucher ,voucher, Credit
note ,note, Loyalty cards ,cards, Cash/Card on delivery,
Net banking and Advance payment. The sales from SOM
needs to come to POS as AIL sales and be created.
Tender will be send separately based on VAT and CST
and also marked as AIL sales and posted in POS. From
POS the data will be aggregated based on date , store ,
division(brand) , style , code and quality ( to understand
the barcode)
A customer orders in store or online, dispatch to store
from warehouse and pickup in store Orderstore Order
is fulfilled by warehouse and shipped to customer
location. When order is created online in NNNOW.com
or instore in SOM, Shield will first check the inventory of
the article in warehouse and create a customer order
which will be sent to warehouse ERP system and will
create a sales order for warehouse customer.. Stock
This needs to be configured
Omnichannel / In Transport Order will be created to transfer articles from
in SAP FMS as per standard
Store /Online/ Sales warehouse to store where there will be a pick up.
SAP.
Outbound delivery will be created automatically.
Thereafter picking, packing happens and goods will be
transferred to the store. Now GRN will be done at the
store and the inventory will go up. The article will be
physically be picked by the customer. Simultaneously
the sales is confirmed in SOM and is replicated in POS
as AIL sales at the store. Tender can be cash , credit
card , Gift voucher , Promotional voucher , Credit note ,
Page 7 of 29
(Process Details)

Loyalty cards , Cash/Card on delivery, Net banking and
Advance payment. The sales from SOM needs to come
to POS as AIL sales and be created. Tender will be send
separately based on VAT and CST and also marked as
AIL sales and posted in POS. From POS the data will be
aggregated based on date , store , division(brand) , style
, code and quality ( to understand the barcode)
A customer orders in store A or online and wants to
pickup from store B. Once the order is placed in store A,
the order id gets created in SOM. An intimation is sent
to store B , SOM showing that there is an order to be
fulfilled by store B. The store B has to accept it within
30 minutes. Then it is replicated to POS of store B. The
Omnichannel / In
sale is created in POS. Tender can be cash , credit card ,
Store /Online/ Sales
Gift voucher , Promotional voucher , Credit note ,
Loyalty cards , Cash/Card on delivery, Net banking and
Advance payment .If it is cash on delivery , once the
payment is realized and the order is confirmed in SOM ,
the sales transaction will be created in POS. The tender
details will be posted separately in POS.
***Changes in version 1.2

Omnichannel / In
For Arvind FASHION/FOOTWEAR /ATBL
Store /Online/ Return
/ATBL/APRL/ARTPL, all the returns are processed at the
shield (AIL or SOM), with a pick-up or store-drop options
For Arvind
& with online refunds, all customer returns are sent
FASHION/FOOTWEAR
back to the AIL Warehouse, instead of having returns at
/ATBL
the store POS.
/ATBL/APRL/ARTPL
***End of Change
Customer walks into Store ‘A’ Returns to Article.

Quality inspection stock -> Return sales order -> Credit
Note/CC/Net Banking to Customer->Update SOM ->
Omnichannel / In Update Inventory Records (POS) -> Update Return Stock
Store /Online/ Return to Blocked Stock (POS) -> Create Returns Order ->Create
IST (POS)-> Create Return Delivery-> Update Inventory
WH (POS) ->Record good in Transit (SAP) -> GRN->
Update Inventory Records (EDW)
For Arvind FASHION/FOOTWEAR /ATBL
Page 8 of 29
(Process Details)

/ATBL/APRL/ARTPL, the AIL Warehouse, instead ofe
store.
Return sales order -> Quality inspection stock -> Credit
Note/CC/Net Banking to Customer->Update SOM
Omnichannel / In ->Update Inventory Records (POS) -> Move Stock to
Store /Online/ Return Unristricted Stock (POS) -> Create Returns Order
->Create IST (POS)-> Create Return Delivery-> Update
Inventory Store (SAP)
Quality inspection stock -> Credit Note/CC/Net Banking
to Customer->Update SOM ->Update Inventory Records
(POS) -> Update Return Stock to Blocked Stock (POS) ->
Create Returns Order ->Create IST (POS)-> Create
Return Delivery-> Update Inventory WH (POS) ->Record
Omnichannel / In
good in Transit (SAP) -> GRN-> Update Inventory
Records (EDW)
Finance ->Credit Memo -> Update Journal -> Adjust

Store B & AIL Cash account->Update Sales Return &
Allowance (Store A)-> Post in Accounts Ledger
->Update Inventory Records (POS) -> Update Return
Omnichannel / In
Stock to Blocked Stock (POS) -> Create Returns Order
->Create IST (POS)-> Create Return Delivery-> Update
Inventory WH (POS) ->Record good in Transit (SAP) ->
GRN-> Update Inventory Records (EDW)
Quality inspection stock -> Credit Note/CC/Net Banking
to Customer->Update SOM ->Update Inventory Records
(POS) -> Update Return Stock to Blocked Stock (POS) ->
Omnichannel / In
Create Returns Order ->Create IST (POS)-> Create
Return Delivery-> Update Inventory WH (POS) ->Record
Records (EDW)
Omnichannel / In
Page 9 of 29
(Process Details)

Omnichannel / In
Store /Online/ Return ->Create IST (POS)-> Create Return Delivery-> Update
Update Inventory Records (POS) -> Update Return Stock
Omnichannel / In to Blocked Stock (POS) -> Create Returns Order ->Create
Store /Online/ Return IST (POS)-> Create Return Delivery-> Update Inventory
Finance ->Credit Memo -> Update Journal ->Sales Return
& Allowance (Store A)-> Update Accounts Ledger
Omnichannel / In
Omnichannel / In to Blocked Stock (POS) -> Create Returns Order ->Create
Store /Online/ Return IST (POS)-> Create Return Delivery-> Update Inventory
Finance ->Credit Memo -> Update Journal ->Sales Return
& Allowance (Store A)-> Update Accounts Ledger
Omnichannel / In
Page 10 of 29
(Process Details)

Omnichannel / In
->Update Inventory Records (POS) -> Update Return Stock
to Blocked Stock (POS)/-> Move Stock to
UnristrictedUnrestricted
Omnichannel / In
Stock (POS) ->
Store /Online/ Return If Blocked Stock (POS) -Create Returns Order
->Create IST (POS)-> Create Return Delivery->
Update Inventory WH (POS) ->Record good in
Transit (SAP) -> GRN-> Update Inventory Records
(EDW)
Return sales order -> Quality inspection stock ->
Credit Note/CC/Net Banking to Customer->Update
SOM ->Update Inventory Records (POS) -> Update
Return Stock to Blocked Stock (POS) -> Create
Returns Order ->Create IST (POS)-> Create Return
Omnichannel / In
Delivery-> Update Inventory WH (POS) ->Record
Records (EDW)
Store B & AIL Cash account->Update Sales Return &
Allowance (Store A)-> Post in Accounts Ledger
Return sales order -> Quality inspection stock ->
Credit Note/CC/Net Banking to Customer->Update
SOM ->Update Inventory Records (POS) -> Update
Inventory WH (POS) -> Move Stock to Unristricted
Omnichannel / In
Stock (POS) -> Update Inventory Records (EDW)
Finance ->Credit Memo -> Update Journal -> AIL
Cash account->Update Sales Return & Allowance
(Ware House Store )-> Post in Accounts Ledger
Omnichannel / In Customer walks into Store ‘A’ Returns to Article.
Page 11 of 29
(Process Details)

to Blocked Stock (POS) -> Create Returns Order ->Create
IST (POS)-> Create Return Delivery-> Update Inventory
Store AIL Cash account->Update Sales Return &
Allowance (Warehouse Virutal Store/AIL)-> Post in
Accounts Ledger
We use POS Interface Outbound function to link up the POS system (Xstore) to send the below business data
from ERP SAP FMS to Xstore.
Our level our interface would be different than the ALBL. Refer the separate file attached with this email
named – “CR-XSTORE INTEGRATION_24_Nov_2016”. This file will cover all the valid scenarios applicable for
AFBL/ASPOL.
Outbound Interface Interface Description Comments

ExchangeRate Currency Exchange Rate This needs to send once in a day from ERP SAP
FMS to POS Xstore
Expiry Product Details Expired Product Details This needs to be send once in a day for
Sepphore brand only
Item Item Master This needs to send once in a day from ERP SAP
FMS to POS Xstore
Merch Hier Merchandise Hierarchy Master This needs to send once in a day from ERP SAP
FMS to POS Xstore
MMRP Multiple MRP Data This needs to be send once in a day for CK
brand only
Org Hier Organization Hierarchy Master This needs to send once in a day from ERP SAP
FMS to POS Xstore
Supplier Supplier Master This needs to send once in a day from ERP SAP
FMS to POS Xstore
Tax Master Tax Master This needs to send once in a day from ERP SAP
FMS to POS Xstore
Transporter Transporter Master This needs to send once in a day from ERP SAP
FMS to POS Xstore
Page 12 of 29
(Process Details)
Outbound Interface Interface Description Comments

WAC Weighted Average Cost Data This needs to send once in a day from ERP SAP
FMS to POS Xstore
Warehouse Warehouse Master This needs to send once in a day from ERP SAP
FMS to POS Xstore
Warehouse SOH Stock on Hand Data This needs to send once in a day from ERP SAP
FMS to POS Xstore
IST AUTH Inter Store Transfer This transactional data needs to be send in
Authorization real time
PO Purchase Order This transactional data needs to be send in
real time
RTV AUTH Return to Vendor This transactional data needs to be send in
Authorization Data real time
RTW AUTH Return to Warehouse This transactional data needs to be send in
Authorization Data real time
WHD Warehouse Delivery Data This transactional data needs to be send in
real time
WHD-Cancellation Cancelled Warehouse Delivery This transactional data needs to be send in
Data real time
We use POS Interface inbound function to link up the SAP FMS to send the below business data from POS
(Xstore) to SAP FMS.
Inbound Interface Interface Description Comments

Footfall Footfall
AIL Sales AIL Sales Data AIL sales data will be send by POS Xstore as a POS
invoice sales transaction at every 3 hours.
Aggregation needed at Store/Posting
Date/Article/ style/ grid /Quality/ VAT or CST
level.
PEDDetails PED Data

Sale_SaleReturn Sales Return Data POS invoice (Sales & Return) transactions will be
send in every 3 hours from Xstore to SAP FMS via
SAP PI & CAR. Xstore will send separate document
type for Sales & Return transaction.
Aggregation needed at Sotre/Posting
Date/Article/ style/ grid /Quality
Gift Card Sales needs to be post in separate G/L of
Arvind’s accounting since this a legal entity.
Tender Details Tender Data Currently
Page 13 of 29
(Process Details)
Inbound Interface Interface Description Comments

GRN-IST GRN data for Inter Store Transfer
GRN-PO GRN Data for Purchase Order
GRN-WHD GRN data for Warehouse Delivery
Inventory Adjustment Inventory Adjustment Data
POD-IST Proof of Delivery - Inter Store
Transfer
Proof of Delivery - Purchase
POD-PO Order
POD-WHD Proof of Delivery - Warehouse
Delivery
Return To Vendor Return to Vendor Data
Return To Warehouse Return to Warehouse Data
Store Transfer Inter Store Transfer
2.3 Business Requirement Flow Diagram (If any)

3.0 POS Integration
This section describes the POS Outbound & Inbound functionality and how it maps to the Arvind’s business
processes and requirements.
3.1 POS Interface – Outbound/Download the Master & Transactional Data to the POS
We use the POS interface – outbound to provide Arvind’s store POS systems (Xstore) with all the relevant
data that the external systems require to handle the store processes independently.
The ALE (Application Link Enabling) technique enables all the messages (interface for business data) that can
be exchanged between ERP Systems (SAP FMS) to be sent to store systems. In distributed retailing,
independent application systems are asynchronously linked, enabling business information to be exchanged
at different periods and for different events. Settings are made to define which applications run on which
systems and which information (messages) is exchanged in the form of intermediate documents (IDocs).
Checks are made to ensure that the data arrives even if the receiving system cannot be accessed when the
data is sent. Distributed retailing is used, for example, to exchange information via the POS interface. You
can regularly supply the POS systems in the stores with current data (master data, such as EANs, conditions,
and merchandise categories) via the POS interface – outbound.
Page 14 of 29
(Process Details)
The following data can be distributed via the POS interface – outbound:
 Article - All the information that is required in Sales for the POS, such as texts, prices, EANs.
 EAN references - The additional EANs for the main EAN of an Article are prepared here for
the POS so that the POS does not have to keep a complete master record for each EAN.
 Merchandise categories -Merchandise categories (assigned to a store) and merchandise
category hierarchy levels above the particular merchandise categories are prepared
 Exchange rates - All the exchange rates in a configurable exchange rate type for the local
currency are prepared. Always all relevant exchange rates are transferred.
 Tax Master - The tax rates of the store country are always transferred in full.
3.1.1 Initialization in POS Outbound

Initialization in the POS interface – outbound supplies the stores with all the necessary POS data when
outbound processing is triggered for the first time. All the data that you can send using the manual request is
sent, although you cannot make any further selections except for the stores at which you want to carry out
the initialization.
3.1.2 Manual Selection of POS Outbound
Unlike initialization, manual selection allows you to specify explicitly which data you want to send to the
store; for example, at one store the Article information is not correct. Then you can download only this
Article to this specific store immediately (on request).
To decide what you want to download to the store, various levels of detail are available from the
merchandise category, and the EAN right down to the individual Articles or groups.
3.1.3 Creating Change message in POS Outbound
You schedule the change message periodically to provide the stores with information on changes to master
data. For this purpose with transaction BD52 you maintain the required fields that have to be considered
when changes are made. The relevant fields are specified here together with the tables that contain these
fields. After the fields have been included in this list and the relevant message types for generating change
pointers have been activated in transaction BD50. You can use the change message to determine which
Page 15 of 29
(Process Details)
changes were made in the central ERP System and to send the changed data through IDoc to the relevant
stores.
3.1.4 Assortment List
Retail companies are rarely organized along strictly uniform lines, which mean that there are often variations
in size between the individual stores. Some stores form legal, independent units with the status of an
external customer or company, or take on the function of a wholesaler, for example. All these different parts
of the same company or group must be kept up-to-date with changes that affect them. Stores that replenish
stocks by manual inspection require up-to-date information about the Articles they carry in their assortment
(for example, the merchandise category to which an Article belongs or the vendor from which an Article can
be procured). Stock planners often find it useful when planning new orders to have information about the
last order placed. This information often has to be made available in a variety of media (printout, PC file, or
EDI message) for all Articles in an assortment, for Articles for which changes have been made, or for an even
more specific subset of data. To allow for these different uses, the assortment list in SAP Retail is a standard
solution that can be configured with a high degree of flexibility.
 Different assortment list types can be defined (such as core, essentials and fashion)
 Assortment list profiles can be assigned to Sites
 Different creation and transmission cycles can be defined
 The assortment list can be output using different media (printout, EDI, file transfer)
An assortment list can be easily tailored to your individual company requirements.
Conventionally, an assortment list is produced as a printout. SAP Retail also supports assortment list output
in the form of an electronic message for distributed retailing purposes (when a store-based merchandise
management system is in place).
The most important part of an assortment list is the “assortment list message”, which involves retrieving and
preparing Article-related data. After a message has been prepared, it can be sent directly to other systems.
Messages created in the assortment list function are structured as intermediate documents (IDocs) with
segment hierarchy. The intermediate document provides the interface to other systems.
Report RWDBBMAN_HPR (transaction WDBM_HPR) is used to request Articles for dispatch manually as part
of the assortment list and to send them to the selected stores
Page 16 of 29
(Process Details)
3.2 POS Inbound

We can use the POS interface – inbound to receive transaction such as sales, purchase orders, goods
receipts, or changes regarding additional GTINs, from your stores.
3.2.1 POS Transactions (Sales, Tender, Goods Movement & Financial) Management
SAP Customer Activity Repository uses the Point of Sale Data Management (POS Data Management) to collect
point-of-sale (POS - Xstore) transaction data from connected stores. POS transaction data is received by the
repository in the form of transaction logs (TLOGs), which are processed by the POS Inbound Processing Engine
(PIPE). Once the POS transactions are received, PIPE performs several processing activities, such as master
data verification, sales auditing, POS transaction data summaries, and sending of POS transaction data to
follow-on applications.
Integration: PIPE uses processing tasks to send POS transaction data to the SAP ERP FMS.
 Sales data using IDoc IDoc WPUUMS, and IDoc WPUTAB

 Financial transaction data using IDoc WPUFIB
 Goods movement data using IDoc WPUWBW
Page 17 of 29
(Process Details)
Feature:
 The POS Data Management software component allows you to do the following:
Collect and process transactions posted from individual stores using PIPE and PIPE can process the
following data:
- Sales and returns including the related tax data and discount information
- Means of payment data
- Financial transactions
- Goods movements
- Totals records and cashier statistics
Page 18 of 29
(Process Details)
POS data can be received by PIPE in different formats such as IDocs of message types WPUBON,
WPUUMS, WPUTAB, WPUWBW, WPUFIB and WPUKSR or also in BAPI format. Furthermore, you can
generate POS transactions manually using the POS Workbench.
 Verify POS transactions against master data.

PIPE verifies POS transactions against master data available from a source SAP ERP system. PIPE
accesses this master data using views included in SAP HANA Live for SAP ERP and SAP HANA Content
for SAP Customer Activity Repository.
 Perform checks.
PIPE checks for the following:
- Duplicate Transaction Numbers
- Gaps in receipt numbers
- Balanced sales and tender totals
- Receipt data as compared to cash desk totals
- Credit card data
 Perform sales auditing.

POS Data Management includes the POS Workbench, which allows you to perform the following sales
audit activities:
- Manually verify POS transaction data transfer
- Analyze error and other messages
- Display transaction processing history and follow-on documents
- Search for POS transactions
- Edit POS transactions
3.2.1.1 Generation of POS Transaction
You wish to create POS transactions in the PIPE in order to check them in the PIPE and to be able to forward
the related data to the linked follow-on systems.
There are several ways to generate POS transactions:
Page 19 of 29
(Process Details)
 Use of the BAPI /POSDW/BAPI_POSTR_CREATE

 Use of IDocs
 Generation Using the POS Workbench
3.2.1.2 Aggregation of Transaction
In this process, the data of POS transactions are summarized (aggregation). Then you can send this aggregated
data to other systems. This significantly reduces the data volume generated. At the same time, the transfer of
aggregated information improves performance and saves time.
3.2.1.3 Outbound Processing of Aggregates

In this process you send the data, summarized in the form of POS aggregates and updated to the database, to
follow-on systems in order to be able to process it further there.
Process:
The outbound processing of a POS aggregate can be split into the following components:
 Closing the aggregate: This way no further update of data to the aggregate is allowed. Closing of an
aggregate means that, during a subsequent aggregation of data, a new aggregate is generated
automatically.
 Starting the outbound processing for the aggregate: The aggregate records are split into packages.
This step cannot then be undone.
 Processing of the individual packages of an aggregate.
 Receipt of package confirmations of recipient system (if planned in Customizing).
 Following processing of all packages, the aggregate receives the status Completed
Page 20 of 29
(Process Details)
3.2.1.4 Sending data to SAP FMS

You can send the data from POS transactions to SAP FMS in order to generate follow-up documents there or
to process the data in other ways. The following options are available for sending POS transaction data to SAP
FMS:
 Sending Sales Data via IDoc WPUBON
 Sending Sales Data via IDoc WPUUMS
In this process you can send the sales data of multiple POS transactions, summarized, to SAP FMS. You
can use the IDoc WPUUMS for this to transfer the following POS transaction data:
Header data:
o Store
o Posting date
o Transaction currency
Data of sales items
Discount information
Tax information
 Sending Means of Payment Data via IDoc WPUTAB
In this process you can send means of payment data of multiple POS transactions (summarized) to SAP
FMS. You can use the IDoc WPUTAB for this to transfer the following POS transaction data:
o Header data: store, posting date, department, POS number, and cashier
o Means of payment data
 Sending Financial Transaction Data via IDoc WPUFIB
 Sending Goods Movement Data via IDoc WPUWBW
Alternatively, you can also supply SAP Retail with data by generating aggregates and carrying out the
corresponding outbound processing.
3.2.2 Aggregated Sales Processing at SAP FMS

In this step you define how data sent by the SAP CAR is to be processed in SAP FMS system inbound IDOC
WPUUMS. First we need to process the WPUUMS (Aggregated Sales data) Idoc processing, to do this program
RBDAPP01 either RWPOS_PARA_ENQUEUE needs to be run by batch job. After the processing of aggregated
sales data, program will generate the Article document (update the stock), Billing Document & Accounting
document. We can monitor the processing of aggregated sales by transaction WPER (POS Interface Monitor)
Page 21 of 29
(Process Details)
3.2.3 Aggregated Tender Processing at SAP FMS

In this step you define how data sent by the SAP CAR is to be processed in SAP FMS system aggregated tender
inbound IDOC WPUTAB. First we need to process the WPUTAB (Aggregated tender / means of payment data)
Idoc processing, to do this program RBDAPP01 either RWPOS_PARA_ENQUEUE needs to be run by batch job.
After the processing of aggregated means of payment data, program will generate the Billing Document &
Accounting document. We can monitor the processing of aggregated sales by transaction WPER (POS Interface
Monitor)
3.3 Process Maps:
3.4 Business Process Steps
Sr.
Activity TCode Input Output
No.
1. Initialization in POS Outbound WPMI
2. POS Monitor WPER
3. Manual Selection for POS Outbound WPMA
4. Displaying Created IDocs in POS Monitor

WPER
5. Creating Change Message in POS Outbound

WPMU
Page 22 of 29
(Process Details)
6. Displaying Created IDocs in the IDoc list

WE02
7. Initialization Assortment List

WDBI_HPR
8. Creating change message Assortment List

WDBU_HPR
9. Download of Merchandise Categoriy Information

WPMA
10. POS DM Workbench

/posdw/mon0
11. Partner profile

WE20
3.5 Key Data Structure Elements

Key Data Structure Elements required to configure the business requirements in the SAP System:
 Sales Organization
 Distribution Channel
 POS profile - Inbound
 POS Profile – Outbound
 Assortment List Profile
 Partner profile for POS Outbound
 Partner Profile POS inbound
3.6 Associated Master Data Elements (If any)

The required master data elements in the SAP System:
 Article Master
 Site Master
 Tender Type
 G/L Master
 Discount conditions
 Net Price Condition
Page 23 of 29
(Process Details)
3.7 Interface Maps (If any)

For Outbound Process:
Sender System – SAP FMS
Middleware – SAP PI
Receiver System – POS (Xstore)
For Inbound Process:

Sender System – POS (Xstore)
Middleware – SAP PI
Receiver System – SAP CAR & SAP FMS
Page 24 of 29
(Process Details)
3.8 Reports Mapping (If any)

(Detail the SAP Standard reports which is planned to address the business requirements in the SAP
System).
3.9 Process Variations / Exceptions (If any)

(Detail the process variations / exceptions which is planned to address the business requirements in the
SAP System).
4.0 Integration Points (If any)

(Detail the integration of other modules, other application data’s, etc. in the SAP System).
Page 25 of 29
(Process Details)
5.0 Key Business Improvements (If any)

(Detail the business improvements in addressing the requirement in the SAP System).
6.0 Changes to Existing Organization (If any)

(Detail the changes which need to be adopted by the organization)
7.0 Gaps
Process Reference / Description of Recommendation to fulfil
Reference No. Details Functional Deficits the Gap
8.0 Development Considerations (RICEFW)
Page 26 of 29
(Process Details)
8.1 Data Conversion Considerations

Description of the Data Conversion Method
Objects / Data to be (like LSMW, iDoc, BDC, Reference Development
Reference No. converted etc.) Specification No
8.2 Interface Considerations

Description of the System / Reference Interface Specification
Reference No. Process to be interfaced Document Number
8.3 Form Considerations

Reference Form Development
Reference No. Description of the Forms Specification Document Number
8.4 Reporting Considerations

Description of the Report Reference Report Development
Reference No. Requirements Specification Document Number
Page 27 of 29
(Process Details)
Description of the Report Reference Report Development

Reference No. Requirements Specification Document Number
8.5 Functional Enhancement Considerations

Description of the Functional Reference Functional Enhancement
Reference No. Enhancement Requirements Specification Document Number
9.0 Authorization requirements

Authorization to the transaction codes in the SAP System will be based on the role played by the person in
the organization.
Below table is an example of the Authorization Matrix. The users (super user, middle level user, end user)
are assigned with a role in the SAP System.
Transaction Code will be detailed in the Authorization Matrix.
Role 1 Role 2 Role 3

SAP T.Code Transaction Description (Role Name) (Role Name) (Role Name)
Page 28 of 29
(Process Details)
10.0 Annexure (If any)

 Annexure-1 – KDS Document
 Annexure-2 – BPML Document
11.0 Flow Chart Legend
(Process Description)
Start/ End
SAP Process
(Responsible Department/ Role)
SAP Background
Process
Manual Process
(Outside SAP)
Decision
Printout/ Form
Other Defined
Process
Page 29 of 29

BBP Ret 005 Pos Interface v1.2

Uploaded by

Copyright:

Available Formats

BBP Ret 005 Pos Interface v1.2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BBP Ret 005 Pos Interface v1.2

Uploaded by

Copyright:

Available Formats

at

Business Blueprint Documents

Module: SAP Retail

ARVIND / IBM Confidential

1.0 DOCUMENT INFORMATION.........................................................................................................5

2.0 BUSINESS REQUIREMENT............................................................................................................6

3.0 POS INTEGRATION.......................................................................................................................9

4.0 INTEGRATION POINTS (IF ANY).................................................................................................16

5.0 KEY BUSINESS IMPROVEMENTS (IF ANY)..................................................................................16

6.0 CHANGES TO EXISTING ORGANIZATION (IF ANY).....................................................................17

8.0 DEVELOPMENT CONSIDERATIONS (RICEFW)............................................................................17

9.0 AUTHORIZATION REQUIREMENTS............................................................................................19

10.0 ANNEXURE (IF ANY)...............................................................................................................19

11.0 Flow Chart Legend..................................................................................................................20

1.0 Document Information

Document Category Business Blueprint Document

1.1 Document Version

Date Version No. Author Change Description

1.2 Document Approval Details

Function Name (Designation) Role Sign & Date

Abel Correa Arvind Project Manager

1.3 Reference Document Details (If any)

1.4 Abbreviations Used (If any)

2.0 Business Requirement

Business Vertical Applicability (Yes/No)

2.2 Details of Business Requirement

Business Requirements Description Comments

Business Requirements Description Comments

Business Requirements Description Comments

***Changes in version 1.2

Customer walks into Store ‘A’ Returns to Article.

Business Requirements Description Comments

Finance ->Credit Memo -> Update Journal -> Adjust

Return sales order -> Quality inspection stock -> Credit

Business Requirements Description Comments

Omnichannel / In Customer walks into Store ‘A’ Returns to Article.

Business Requirements Description Comments

Outbound Interface Interface Description Comments

Outbound Interface Interface Description Comments

Inbound Interface Interface Description Comments

PEDDetails PED Data

Inbound Interface Interface Description Comments

2.3 Business Requirement Flow Diagram (If any)

3.1.1 Initialization in POS Outbound

3.1.3 Creating Change message in POS Outbound

3.2 POS Inbound

 Sales data using IDoc IDoc WPUUMS, and IDoc WPUTAB

 Verify POS transactions against master data.

 Perform sales auditing.

3.2.1.1 Generation of POS Transaction

 Use of the BAPI /POSDW/BAPI_POSTR_CREATE

3.2.1.2 Aggregation of Transaction

3.2.1.3 Outbound Processing of Aggregates

3.2.1.4 Sending data to SAP FMS

3.2.2 Aggregated Sales Processing at SAP FMS

3.2.3 Aggregated Tender Processing at SAP FMS

3.3 Process Maps:

3.4 Business Process Steps

1. Initialization in POS Outbound WPMI