Application Information Document

Infosys
QUALITY SYSTEM DOCUMENTATION
References

Application Management Services

APAC RETAIL MALL INTERFACE - Fossil
Application Information Document (AID)
INFOSYS LIMITED,
Bangalore.

Document No. : FOSSIL-SAPBW- Version.Rev : 1.00

JUNE22015
Authorized by: Signature/: 1st June, 2015
Date

COPYRIGHT NOTICE
2011 - 2012 Infosys Limited, Bangalore, India. All Rights Reserved. Infosys believes the information in this
document is accurate as of its publication date; such information is subject to change without notice. Infosys
acknowledges the proprietary rights of other companies to the trademarks, product names and such other
intellectual property rights mentioned in this document. Except as expressly permitted, neither this
documentation nor any part of it may be reproduced, stored in a retrieval system, or transmitted in any form
or by any means, electronic, mechanical, printing, photocopying, recording or otherwise, without the prior
permission of Infosys Limited and/or any named intellectual property rights holders under this document.

Infosys Limited
Electronic City,
Hosur Road,
Bangalore 560 100
India.
Telephone: 91 80 2852 0261
Fax: 91 80 2852 0362
Website: http://www.infosys.com

Document Revision History

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

Ver # Date Author Reviewer Comments

1.00 Jayant Sinha Anil Initial Release

Note: Please update Doc ID, other front page details and rev. history upon usage of this template

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

TABLE OF CONTENTS

Contents
1. INTRODUCTION TO THE APPLICATION INFORMATION DOCUMENT....................................
1.1 AUDIENCE.......................................................................................................................................................
1.2 DOCUMENT STRUCTURE AND RECOMMENDED USE.......................................................................................
2. EXECUTIVE SUMMARY..........................................................................................................................
2.1 DESCRIPTION OF THE APPLICATION................................................................................................................
2.2 RISK MANAGEMENT........................................................................................................................................
2.3 CURRENT & FUTURE WORK PLAN.................................................................................................................
2.4 OFFSHORE TRANSITION PLAN.........................................................................................................................
3. INTRODUCTION........................................................................................................................................
3.1 APAC MALL INTERFACES...............................................................................................................................
3.1.1 Overview:...............................................................................................................................................
3.1.2 Data Flow..............................................................................................................................................
3.1.3 Mall Interfaces data Provider................................................................................................................
3.1.4 List of Tables that used in the process:................................................................................................
3.1.5 Program:..............................................................................................................................................
3.1.6 Folder: Where FTP get stored after BW deliver file to XI.................................................
3.1.7 Mall Interfaces:...................................................................................................................................
3.1.8 Process chains.....................................................................................................................................
4. ISSUES & SUGGESTIONS......................................................................................................................
4.1 ISSUES AND PAIN AREAS...............................................................................................................................
4.2 SUGGESTIONS................................................................................................................................................

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

1 Introduction to the Application Information Document

This section describes the intended audience for this document, the organization of sections and the
conventions used for the various flow diagrams.

1.1 Audience
Fossil SMEs and Infosys BW Support Team

1.2 Document Structure and Recommended Use

Aim of this document is to capture all the details shared in KT session on APAC Mall Retail Interfaces.
Details Include Overview of APAC mall interfaces, Flow of data from BW to Malls, involved objects, their
flow.

2 Executive Summary

1.3 Description of the Application

To give an overview of APAC Mall interfaces flow into BW and BW from Malls, issues related to the flow,
support activities and issue handling by the Current users.

1.4 Risk Management

Risk Occurrence Probability Impact Mitigation Plan

1.5 Current & Future Work Plan

Current Work Plan Future Work Plan
Currently Production support (On Call) is Once the Transition is completed it would done both
being done only from Onsite Location from Onsite and Offshore

1.6 Offshore Transition Plan

In progress.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

2. Introduction

Retail Inventory
Domain : Retail
Purpose: APAC Mall Interfaces
Its business activities : Providing files to Malls

2.1 APAC Mall Interfaces

2.1.1 Overview:
Business Case: In APAC (countries like Malaysia, Singapore, china,
India etc.), some malls accept stores rent in the form of Some fixed
rent + certain percentage of commission based on stores sales.
This is the term which is mentioned and agreed on the rental contract
between tenant and the mall, thus becoming a legal document.
Therefore, we need to share our stores sales information with the mall
(electronically) in certain frequency and format so that mall can
calculate our store rent monthly.

Sharing of Information with mall: In general, for sharing

information with mall, Malls offer three options:
1. Mall Provided POS System: in this case, Mall provides a POS
system to the store and store has to use this POS to record their
sales.
2. 3rd party application on store POS : In this case, mall
provides a 3rd party software application which need to installed
on stores POS System which will transfer all the sales
transaction information to their servers.
3. Share store sells with mall: In this case, Mall provides certain
technical specifications on how the sales information needs to be
sent to their databases.
Here it is the tenants responsibility to facilitate necessary
technical infrastructure to push the data to malls databases.
This is called the APAC BI Mall Interfaces.

Earlier Process: Before the APAC retail go live, we were using option
2, means we used to install mall provided application on our POS
system (LSR system ) by which sales information is shared (Pushed)
directly from our POS system to mall directly.
Current Process: After APAC go live (in 2013), means we move to
SAP, so then our POS system (Wincor system) are come under the PCI
compliance and therefore 3rd party application are not allowed.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

So now we are using the 3rd option, where we send our sales
information to the malls in designated database as per the technical
specification and request format.

2.1.2 Data Flow

As we dont have any standard functionality across any systems, we

have developed our home grown data interface solutions which are
specifically designed to meet each malls technical requirement and
data transfer frequency.

1. Here in the store we have POS system (Wincor system) which will
record sales transaction.
2. Data from POS system will be sent to POS database.
3. From the POS database, data will moved to SAP POSDM system
which will have audit sales information.
4. From POSDM, data will be sent to BRP system (Retail BW) in
every 30 minutes, our BW environment. Here it will go into the
Sales Audit cube (ZSAUDIT).
5. From BW system, we are sending data to the mall. So for that we
have done lot of transformation as every mall has their own
specification, so they used to provide us their particular format
and we used to provide data in that format.
a. We have FTP server, where we put all the files and certain
jobs pick the file from their end and provide the data to Mall.
b. Another method is handshake method where we ping their
server and they provide the EPOCH time. On basis of that we
providing data directly to the mall and we got the feedback
that file is successfully deliver or failed. They will also provide
some specific issue if it is failing with because of some error in
file.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

By the end of 2014, we have 21 live interfaces on BRP (BI retail

system), for some of them we have similar Interfaces
Countries are:
Malaysia
Singapore
India
China
Interfaces are:
MBS
JOHOR Mall
VIVO city mall
Raffle city mall
Somerset mall
ION mall
Suntec mall
Gurney mall
IMM
JEM
SOUZOU
DLF Promenade
Orion mall
Viviana mall
For MBS (EPOCH) and Raffle City (Feedback) mall we are using the 2nd
option to send the data means we are getting feedback about the data
delivery success, fail or failed with error messages.

2.1.3 Mall Interfaces data Provider

Sales data from POS - > POSDM will flow in real time and once the
audit is passed they are picked by BW retail in 30 minutes.

Now on BI, these sales are stored on ZSAUDIT (having global data)
sales Cube at very detailed level and has transaction data which is
mostly mall needed. So, this cubes serves the data to all mall
interfaces either directly (Query on ZSAUDIT or direct use of ZSAUDIT
cube) or indirectly by using next level cube ZMALI_C01 designed purely
for mall interfaces.

ZSAUDIT is the sales cube that is having global sales data, granularity
is very high and has transaction level data. Sales Data is sent to mall
daily.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

Issues:

If Selection Criteria is taken as Calendar day then it will take the last
day data and will update the data. But it may be issue that some data
will not come to the BW from POSDM because of auditing issue, but we
are sending data whatever is coming, so after the correction from audit
team when data will come, it will come with that transaction date so it
will be never picked as we are loading on Cal day. So there will be
mismatch with mall and BW data. Reconciliation will never happen. So
in the new cube ZMALL_C01, we have add one new field loaded on.

ZMALI_C01 is only having those store which is dealing with store

interfaces.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

This is getting loaded on daily basis. Every day on the process chain
get trigger so at the first step so it will take all the stores from ZSAUDIT
and so selection condition here will be ZLOADEDON so it will fetch all
the old and new transaction so it will cover the late posting too.

We use APD workbench to slice the data out of these sources.

Mall Interface APD Design:

1. Select the required data from the source (Query/cube) -> BI
Team
2. Transform and format the data as per malls requirement. -> BI
Team
3. Submit the data to XI proxy. ->(BI Team/XI Team)
4. XI will generate the files on DALLAS FTP server. -> (XI Team)
In some mall interfaces, there is no FTP generation but
data need to be submitted directly on the mall systems
using WSDL and take back the

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

acknowledgement/feedback. Once we have successful

acknowledgement, then only we are supposed to send the
next feed.
The granularity of the data feeds can be Total sales at a
particular Hour or transaction Level. Example: Interface
for which are sending data directly to malls are: MBS, Raffle
city and SUZHOU.
5. Local HK windows job to download these files from DALLAS FTP to
HK FTP. -> (HK PSO Team/HK Infra team)
6. Local HK windows job to send these files to designated Malls
servers. -> (HK POS Team/HK Infra Team)
List of Mall Interfaces APDs on BRP system:
Few mall interfaces are in the pipeline that will go live after the consultation with Malls.

2.1.4 List of Tables that used in the process:

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

1. ZMALI_APD_MASTER: This table basically have the important

fields, it is like a master data table. Some of the interfaces look
up into this table for the selection that used to be the selection
to pull out the data from the cube ZMALI_C01, if they are not
using the query method.

BWLOADEDON: Selection date. When it is loaded to the BW.

RUNDATE: when the Interface get executed.
RUNNR: Its an incremental number, whenever we placed the file on
FTP server we add that number to the file. Based on last run
number we add 1 and used that number in the next file so we can
differentiate between the files. We store that numbers here.
TENANTID: All the mall have assigned some number to their
tenants, so we use this number to the placing file as prefix or suffix
to identify the tenants. It is designed as we get the requirement
from Mall.
Variants: It is a query variants.
Store Name & APD_Process: Description of the Mall Interface and
Technical Name.
Type: Daily (D) or Monthly (M)
Store Number: These are the store number.
Sometimes we use the same interface technically for two stores, it
may be the stores are in the same mall or same IT vendor or service
provider is supporting both the stores so their requirement is
somehow similar. So we dont have to build another interface, we
can use the same interface for both the stores.
Example: Most of the Indian stores located in different mall has the
same service provider so we have option to use the same interface.

2. ZMALI_BIXI_MBS: This table is basically used only by MBS

Interface.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

MBS used the some kind of handshake method, so we send the file for
the 1 hour sale based on the EPOCH time, so when we go and ping
their server, they tell us what is the EPOCH time for which we used to
send the data.
We take that as selection parameter to cutting the data out of cube
and send the information based on that.
If Mall asked for the past sale then they need to reset their timers for
EPOCH time then we can send that.
If because of some reason like information may incorrect or file issue or
data server may busy) data will not get updated and after that if we
will send the data again for the next hour then it will not take the data
as it was expecting the EPOCH time data that it have set, so we need
to update that data first for that particular hour sale then it will move
further.
Use: Every record that we sent, we update this table and look up to the
table and send the data for that.

3. ZMALI_RAFFLE_T01: This is the master data table for Raffle city

and SUZHOU. These two are technically same.

We use this to login to their system and push the record. It is

holding only some kind of credentials.
4. ZMALI_RAFFLE_T02 :

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

It will hold the record for Raffle and SOZHOU city.

We are having here the Unique Key (Store number, posting date,
POS number and transaction number) to make sure that we are not
duplicating with other stores.
Store number
Status: it will let us know that file is successfully or not.
Feed Status: X means successfully sent or blank means failed.
Sent timestamp: time when we have sent the file and sent status: it
is success or fail.
Received at: when we received the file and receiv_stat: success or
fail (we will also get the reason that we update in this table).
We always take 20 to 30 days in selection, means we take the data
from cube for that many day and format the data as they want and
when we submit the data to XI, it check the status it is green or red
so if it is success then it will not send otherwise it will send the data
with correct value (it always not a data issue and it also may
happen because of server issue).
Issue:
In case of data issue, we need to identify the transaction which is
causing issue as it also sent by the XI team which we update in
table. So we can go the source (sales audit team they will correct
the data in POS if wrong data is coming from there) and ask them to
correct the data. We have a 20 or 30 days buffer, so we will get the
updated data.
If we are not aware of the issue and sales audit data is also correct
then we send mail to Mall that we have this data and it is the right
value. So Mall will manage it from their side.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

If there is any issue in our interface related to coding then we need

to check from our side to optimize the code or check.

This particular table is used by four stores. Two of Raffle and Two of
SOZHOU.

Here we are keeping the 3 or 4 month data in table and deleting it

after the reconciliation and when period is closed.
5. Tables ZMALI_UTAESG_T01 and ZMALI_UTAESG_T02 we are
not using. It is obsolete.

2.1.5 Program:

This programs are put as an interface, which we can access via TCode:
ZMALI. These programs are present in the routines of the APDs of the
Interface, therefore, it is automated. This program runs in every loop
i.e. for every transaction.

Below is the Interface:

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

1. Query APD Run Interface

2. CUBE APD Run Interface

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

These are Ad-Hoc interface. For example, in case of failures in the

loads in the middle of the month, we can use these APDs to resend
the data. It is not available for MBS Mall Interface.
For MBS : we are sending data based on EPOCH time, so sometimes
it may happen that sales happen at the POS for a day but that didnt
get updated in POSDM because of some reason so BW also will not
have any sales. So after the load ZMALI_C01 we will have no data.
So the APD interface will update the record with 0 sales. But the
sales has happened so this is the incorrect value get passed to the
Mall. So in reconciliation time, we come to know that there is a
mismatch so here we are sending data based on EPOCH so EPOCH
has moved further so we cant send the data again. So in this case
they have to update their pointer then our interface will pick that
pointer and will update the data.
We have to take care that if they have the selection only for 30 days
and reconciliation happen couple of months ago then we need to
change the selection parameter into the APD filter according to that
so we can deliver the data.
3. Manage Master Interface/ APD data :
Through this we can View, Update and Delete Data.

We need to delete the records as once the store is closed, for those
stores we are not sending the file. Hence, deleting the store
information from the master table.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

4. Manage MBS XI -> BI settings :

This program is update to the table ZMALI_BIXI_MBS. We received one

web link via proxy from XI and by that link the sales information get
updated and dynamic information (EPOCH and time information get
updated).
5. Check/Update sync-point marker :
This program used in the main program, we are getting the EPOCH and
store information and running the load and pushing the data. After this,
the loop will run again after the load and will take the next pointer and
will check and update the table and send the data again. So it is
continuous process.

2.1.6 Folder: Where FTP get stored after BW deliver file to XI.
Dallas FTP Server: \\dalcftpe02\ftpdata-2\it
We have country wise folder which is further categorized based on Mall
and then further to dev, qa and prd.
Live FTP files are available on Prd folder.

Infrastructure team will pick this file and deliver this file to mall. They
have created some window job which will pick this file from here and
will deliver this file to their server.
Right now we have Singapore, china, Malaysia, India. We also have the
requirement from JAPAN but we are not building any interfaces for
japan right now as they have some local language requirement, so
local team has created some interface for them.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

Except Utama all the other malls work in same way. Not sure how
Utama works.
For Gunney mall we are delivering .csv format.

2.1.7 Mall Interfaces:

Ad Hoc APDs : As we dont have that much live data or so much

information in Dev and Quality so we are doing all the testing, new
changes or bug fixing through Ad Hoc version in Production.

Details of Interfaces:
Flow from BW system to Mall Interfaces:
1. ZMALI_APD03_ION_ORCHARD_D_3266 : MallInt/APD03: Ion
Orchard/3266 (Daily)

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

ZMALI_APD09_SGIMM_WSI_D_3273: MallInt/APD09: SG IMM

WSI/3273 (Daily)
Technically both having the same interface.
This is daily consolidated feed. The interface will need to generate a
daily sales transaction file and transmit that file to an FTP site after the
end of each business day.
Explanation is here for the ION_ORCHARD interface:

1. Source:
Query: ZMALI_APD03_ZSAUDIT_POS_Q04
Query is built on Cube ZSAUDIT.
Variants are created in RSRT, it is in 3.x. If we created the variant in BEx
analyzer then it will get updated in the backend table and will not be in
readable format so here we are using old method.
All the variants created in 3.x version are stored in the table.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

The Date field in the variant is filled with customer exit variable, In case the
input is blank then it will run for current day or if we pass some value then it
will run for that particular day.
In Automatic way, it always run for current day.
Customer exit code:

2. Here we are populating the extra field that we need in target. Fields are
Type and Machine Id. This are the fixed value that we are passing to
the field.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

3. As per the above code, the Proxy provided by the XI team is called to
submit the output records. The output and record structure is defined
in the proxy server which is used by the PI team to send the data to
the Mall.
Document Type is Daily Field. Therefore, it is considered as D.
Machine ID is mandatory field and taken as default 9999999.
Below is the code:

This is a single loop as it is one record. For some mall, they want record
by record submission so we use proxy inside the loop and loop run for
each transaction and submit the data and run it again after
confirmation.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

4. Output: Since the APD interface has to be completed with destination

so a Flat file target is created and stored in AL11.
Output file format:

Field No. Type Size Position Field Description

1 Character (1) 1 Document Type D for Daily Transaction File
2 Numeric (7) 2-8 Machine ID Unique identifier assigned to
individual.POS System across the mall.
Format of Machine ID is made up of 7
numeric characters and this ID is
assigned to the tenant by the Mall.
Machine ID should not be hard coded in
the POS software system or Cash
Register. It should be a configurable
parameter in a database table or in an
ini file.
3 Date (8) 9 -16 Transaction Date Date of sales transaction adopting
YYYYMMDD format.
4 Numeric (11) 17 - 27 Sales Amount This is the defined as :Gross Sales
99999999.99 less Discount
plus Service Charges (if any) before tax
(i.e. GST or CESS)

Error Handling
If the Tenants POS system is not operational due to the POS technical problem and is not able to FTP data
from the HQ, the Tenant representative has to update the CMT Management immediately.
2. ZMALI_APD04_ION_ORCHARD_M_3266: MallInt/APD04: Ion
Orchard/3266 (Monthly)
ZMALI_APD10_SGIMM_WSI_M_3273: MallInt/APD10: SG IMM
WSI/3273 (Monthly)
It is same as above, here we are pushing the monthly data so here the
transaction type is T. Everything is same except this.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

Output Format of File:

Field No. Type Size Position Field Description

1 Character (1) 1 Document Type T for Total after adjustment Transaction
File
2 Numeric (7) 2-8 Machine ID Unique identifier assigned to individual POS
System across the mall. Format of Machine
ID is made up of 7 numeric characters and
this ID is assigned to the tenant. Machine ID
should not be hard coded in the POS
software system or Cash Register. It should
be a configurable parameter in a database
table or in an ini file.
3 Numeric (6) 9 -14 Transaction Month Date of sales transaction adopting
YYYYMM format.
4 Numeric (11) 15 - 25 Adjustment Amount Total Amount after adjustment before Tax
99999999.99 (GST / CESS)

3. ZMALI_APD01_STDSOMERSET_D_3267 : MallInt/APD01:
Somerset FOS/3267 (Day/Hour/In/out)
ZMALI_APD02_STDSOMERSET_D_3268: MallInt/APD02: Somerset WSI/3268
(Day/Hour/In/out)
ZMALI_APD11_SGJEM_WSO_D_3272: MallInt/APD11: SG JEM
WSO/3272(Day/Hour/In/out)
ZMALI_APD14_SUNTEC_FOS_D_3271: MallInt/APD14: SUNTEC FOS/3271
(Day/Hour/In/out)
Above 4 technically having the same interface.
Interface:
Snapshot of APD: ZMALI_APD01_STDSOMERSET_D_3267

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

1. From Queries which is based on cube ZSAUDIT, we are pulling the

sales, Traffic and Receipt count (how many transaction has been done)
data on different filter with the help of variant.
2. In first transformation we are formatting the data in the required
format and assigning value to target field and determining Cal day.
3. POS Sales data: In 2nd transformation, we are creating 24 record as
Somerset except hourly, it may have sales or not. So if we are not
having business then we need to create the record and KFs value will
be 0 as these data in not in BW. As BW only having business data.
Code: Looping at source table checking for entry where SALHOUR = CNT, If such an entry is found
then CNT is increased by 1 and value of ZCK change to Y. If value not found then value to target is
assigned and KF value is assigned as 0 and count increased by 1. Loop will run 24 times.
Store traffic data:
Code:
Loop at source table
Concatenate location and Cal day into string X5.
Checking for entry X5 = X6 (where X6 is blank)
Loop at source where
If we find such value then salhour = tc and concatenate location and cal day into string X6, move
source to target and determine Cal day, append source into target and increase the TC value by 1.
If such value not found then assign salhour = tc and 0 to KFs value, determine the Cal day and append
source into target and increase the TC value by 1. Loop will run 24 times.
POS receipt count: Here we are determining Total count of receipt within the hour.
Code: Loop at source table and moving corresponding to target.
Value of salhour assigned to variable S1.
Checking if X2(location) = then assigned X2 = 1.
Checking if S1 = S2, if true then incrementing X2 by 1 if not then X2 = 1.
Assigning receipt count = X2.
Determining calday.
Appending source to target.

4. We are merging data from all the sources.

5. Again doing some formatting in the data to make sure that format is
fine.
Code: If REC_COUNT > 0 then determining the value of KFs and appending data to target.
Deleting the data from target if Rec_count = 0 and with KFs values are 0.
6. We are assigning the file number and this file number we are getting
from the table. It is having incremental number and will update the file
number in table again and will push the data to XI proxy.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

7. Placing flat file on application server.

Output File format:

4. ZMALI_APD05_JOHOR_D_3471 : MallInt/APD05: JOHOR/3471

(Daily)
ZMALI_APD15_JOHORWSO_D_3474: MallInt/APD15:
JOHORWSO/3474 (Daily)

Interface:
Snapshot of ZMALI_APD05_JOHOR_D_3471: MallInt/APD05: JOHOR/3471 (Daily)

1. Getting data from Query for the required Mall with the help of variant.
2. Here we are lookup on the table ZMALI_APD_MASTER. Every time we
load the data we increment the date into the table and based on that
we are picking the load. First transformation, we are preparing Header
line and record structure data for 101(Header record for each
transaction) and 111 (Information of the items sold including void
items).
3. Second transformation, we are preparing record structure data for 121
(footer record of a transaction that stores all Tax, Cess, Service Charge
and Discount details. Cess and Service Charge are used for F&B only)
and 131 (This is the footer record of a transaction that stores the
payment medium, currency code and amount tendered or changed).
4. We are preparing the last line of file (Footer line).
5. Pushing data to XI via proxy.
6. Placing flat file at application server.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

Output file format:

Here we are having transaction information, item information, tender information and payment
information. If something is not filled that it means we are not providing that information as we are only
providing mandatory information.

5. ZMALI_APD20_DLF_FOS_D : MallInt/APD20 DLF India/3874

(Daily)
It is somewhat similar to JOHOR and it is a daily file. Output structure is
almost same.
Here we are using the Cube at the place of Query. In future all the APDs
will get data from Cube only.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

1. Getting data from Cube.

2. Having filter on the Mall Interface and Cal day. Here we are taking 20
days of data as audit will be done in approx. 2 weeks so we will also
cover the backdated posting.

3. Here we are lookup on the table ZMALI_APD_MASTER. Every time we

load the data we increment the date into the table and based on that
we are picking the load.
4. First transformation we are creating the header and footer line and
record structure for 101 and 111.
5. Second transformation we are creating the record structure for 121 and
131.
6. We are pushing file to XI and updating the table ZMALI_APD_MASTER
with last run date so next time it will take data after that.
Output File format:

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

7. ZMALI_APD06_GURNEY_D_3468 : MallInt/APD06: GURNEY/3468

(Daily)

1. Getting data from Query for the required Mall with the help of variant.
2. We are putting the data into the target format and assigning Type as D
(as it is daily file).

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

3. Here XI create the CSV file instead of .txt file.

4. Placing flat file to application server.

8. ZMALI_APD12_VIVO_EA_D_3210 : MallInt/APD12: SG VIVO

EA/3210 (Daily)
Here, just in case if we dont have any sales on a particular date so when mall interface will run it will
not pick any data. So for other mall interface if there is no data then its fine to them. But if it is
happening with VIVO then they want files if they are not having sales too.

1. Here, we have two part in interface. First part will not work if they will
not have any sales but we need to generate files with the data that
there is no sales so we are generating that with the below part.
2. In the first part, we are fetching data from query and transforming it to
the target format.
3. In the 2nd part, if we are not having any sales then we are preparing the
file with 0 value.
4. When we push the data to XI then XI will check whether we have sales
or not. If there is sales then it will delete the part which say that there
is no sales otherwise it will send the data with one record that there is
no sales.
5. Placing flat file to Application server.

9. ZMALI_APD17_ORION_D: MallInt/APD17: IN Orion Mall (Daily)

ZMALI_APD18_PALLADIUM_D: MallInt/APD18: IN Palladium Mall
(Daily)
ZMALI_APD21_PHOENIX_D: MallInt/APD21: IN Phoenix Mall
(Daily)

Snapshot of Interface ZMALI_APD17_ORION_D:

Here, these 3 malls from India and all these malls have same vendor so their requirements are same.

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

1. It is using the cube and at the filer we are taking 40 days data means
current day-40 days and the specific retail location.
2. Here we are transforming the data as Target needs. Here we are
proving data that the transaction is sales or return. Return is refund
here. So they are having different cases for Refund. Refund case can
be of three types:
a. Exchange with same value watch. It may be different watch or
different color watch. So in this transaction value will be 0. It is
still sales.
b. Total Refund: I this case customer can ask for full refund so it will
be return.
c. Exchange with higher value match: it may be the case customer
come back and buy a higher value watch in exchange of
previous one. So this transaction will come under the tender
value. It can also be the case that they will insist for lower value
watch but we dont entertain such cases but if customer insist
then we give them lower value watch but we dont return the
money.
3. If there is no sales then files will be generated as 0 value.

10. ZMALI_APD07_MBSFOS_D_3269 : MallInt/APD07:

MBSFOS/3269 (DAY/HOUR)
ZMALI_APD08_MBSWSI_D_3270: MallInt/APD08: MBSWSI/3270
(DAY/HOUR)

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

Here we are using the handshake method. We are directly pushing the information to their server and ping
their server and get the EPOCH time and on this EPOCH time we receive the other record.
Once we submit the record to the server then we ping them and we ask for confirmation and then they give
us the next EPOCH time which we maintain in table, on the basis of that EPOCH time it will fetch next set
of data.
Here we are sending data hourly basis for a day.
1. Here we are getting data from cube and having filter on it for 20
days from current day and for retail location.
2. 1st transformation, we are requesting the date for which we need to
fetch the data. EPOCH will get updated into the Table
ZMALI_BIXI_MBS. We also have validation that it will not run for
current day.
3. 2nd Transformation, It will get the EPOCH time from table and then
will fetch the data for that period. It will fetch the data till EPOCH
time from the filter as we have given in filter and will delete the
record that is not needed.
4. After the Submitting data to proxy, we will again ping to their server
and will confirm that data is submitted so we will get the next
EPOCH time, and it will update into our table. If it is not submitted
successfully then it will not update the next EPOCH time then data
will go again for that time.

11. ZMALI_APD13_RAFFLE_FOS_D: MallInt/APD13: CN Raffle

City (Daily/All Stores)
ZMALI_APD19_SUZHOU_FOS_D: MallInt/APD19: CN SUZHOU
(Daily/All Stores)

Here, we have 4 stores, it also kind of handshake method. We dont generate any FTP, we put directly
to their server but we dont use EPOCH time here.
Store:
3748: SHANGHAI RAFFLES CITY ACC
3790: BEIJING RAFFLES CITY ACC
3793: SUZHOU VILLAGE OUTLET
3794: SUZHOU VILLAGE WSIO

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

1. Here we are getting data from cube and having filter on Cal day,
location and transaction number.
2. In transformation, we are creating unique code by concatenating
location, Cal day, POS number and transaction number so we dont
deliver the same file again if feed is successfully posted to their server.
3. In first transformation, we are creating Unique Id, determining payment
details as per mall requirement, Item number and other derivation like
sales header, sales item, return sales and doc currency.
4. In 2nd transformation, we are assigning value of KFs retail sales, tax
amount and Discount value by calculation for sales item number.
5. In 3rd transformation, we are assigning value of KFs discount value,
sales quantity, retail sales, tax amount and normal sales value on the
basis of scope and transaction number.
6. While submitting proxy, we are
Determining Master data from master data table (ZMALI_RAFFLE_T01)
Determining sales total value which includes sale/discount/tax and
managing it into the format that we are submitting to proxy
Determining Items level information includes sales/discount/promo/tax
and managing it into the format that we are submitting to proxy
Determining tenders and delivery information and managing it.
Avoiding duplicate feed on the basis of Unique code and the feed
status = X
We are updating status table before submitting to proxy
Updating status table with proxy feedback.
Maintaining 90 days data in log table.
7. We handover the record to XI, XI will submit the file to them and they
will give the feedback at the same time about it success or failed, it will
also certain information like issues if it failed. Means it is input and
output proxy.

2.1.8 Process chains

Technical Name Description

Z_APAC_ZMALI_C01_PC01 APAC Mall Interfaces based on ZMALI_C01
Z_APAC_MALI_META APAC Mall Interface Meta chain

Snapshot of Z_APAC_ZMALI_C01_PC01:

Snapshot of Z_APAC_MALI_META:

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

3. Issues & Suggestions

The following are the existing issues/suggestions that can be considered for this application

3.1 Issues and Pain Areas

2011- 2012 Infosys Limited, Bangalore, India

 Application Information Document

3.2 Suggestions

2011- 2012 Infosys Limited, Bangalore, India