Nagesh SPA Technical Lead
Published on: Mar 3, 2016
Transcripts - Nagesh SPA Technical Lead
Nagesh Venkata Satya Nooka
Sr. SAP Technical consultant
Skype ID – cute_ishanth
I am having 13 years’ experience at the implementation and operations of ERP systems. I have worked in 5 SAP
implementation projects, 4 SAP upgrade projects, and SAP 7 Support and maintenance projects. I have a good experience
on SAP CRM technical and worked in 1 project. I have worked in different roles from SAP technical consultant to Technical
Team lead and was involved in all aspects of project phases.
At Early 1998 I have started working at Board of Intermediate Education, Andhra Pradesh, India as an Application
developer. In March 2003, joined in Vista InfoTech, Bangalore as a full time contractor and deputed to Altos origin as SAP
technical consultant. After that I have joined in Magna InfoTech, Hyderabad in Aug’2003 and deputed to IBM, Bangalore
as SAP Technical consultant. From March 2005 have worked in Wipro Technologies, Chennai where I have completed 4
years 5 months. Currently working in Accenture, Bangalore as System Analyst from 25th Jan 2010 to 23rd Dec 2015.
Sap Technical Capabilities:
RICEFW developments, Enhancements, BADI Implementations, ALE / IDOC, Smartforms, Script, LSMW, Change
pointer events, Interfaces, OOPs, ALVs, Switch Frame work, Business transaction events, Routines, BDC, ABAP
HCM, AIF, BADI, BAPI.
Involved in Technical developments for SD, MM, PM, QM, IS-OIL, EHS, IS-Media, IS-Retail Modules and HCM.
Incident / Issue Tracking Tools:
I have worked on issue/tracking tools in different projects like HPQC, RTC and in MAC OS system RADAR &
Good experience at onshore working with client site Wales & West Utilities for 3 months in Cardiff, UK at the
initial stage of Realization phase. As SAP technical consultant and involved in designing execution plan for
I have worked for the client APPLE, Cupertino, California, US for period of 3 months. And involved in designing
global process for Configure to order (CTO) and implemented successfully.
In Aug 2007 worked in Japan for the client All Nippon Airlines for a period of 7 months. Involved in upgrading
the existing system from 46c to ECC 6 and done successful go-live.
At offshore have worked in different SAP projects in different roles from Technical consultant to Project
Management and was involved in all aspects of project phases.
Roles & Responsibilities:
Technical Consultant :
BPDD [Business Process Definition Document] preparation for the project.
Developed field mapping templates for all the ALE/IDoc Interfaces.
Developed BAPI and ALE/IDoc programs for the new requirements in SAP modules like PM and PS.
BDC interfaces in all SAP modules, dialog and user exit programs.
Played a crucial role in preparing the test data for the entire team in PM and PP functional areas, Technical
Specifications for the team and coordinated with the Web Development team in the integration.
Participated actively in Bug fixing during the integration testing.
Reviewed other team member’s code and document deliverables to ensure.
Analysed existing Gap and giving multiple solutions to fix it.
Involved in Completing Gap Document with various alternative solutions.
Creating High Level Document and Technical Specification for the approved Gaps.
Involved in Peer review Process and assisting others in their development.
Involved in handling tickets by using tools HPQC, RTC, MAC – RADAR &Espresso tools.
Responsible for defects / ticket tracking and management.
Responsible for all deliverables for defects / tickets raised for offshore.
Designing plan to execute pre & post technical activities in upgrade projects.
Responsibility for SPDD & SPAU plan & execution.
Defining RICEF objects correction policy.
Controlling deliverables from Onsite / Offshore.
Owner for Unit testing.
Supporting for Unit testing, Functional Testing, System Testing and User acceptance testing.
Defects tracking and handling using HPQC tool.
Schedule planning for deliverables.
Responsible for Resource planning as per the plan.
Generating Project metrics to stake holders.
Planning and Projecting Revenue recognition for the project to all stake holders.
Responsible for executing the project as per plan.
Check project plan and make necessary changes when & where required.
Daily project status report publishing to the stake holders.
Successfully completed trained 5 GFT batches in SAP ABAP for ASEs at Accenture.
1. (ACE Award) Accenture Celebrates Excellence award for FY13 Quarter 2.
Leading the ABI LATAM test support team comprising of 10 members. I have led the team from the front and has
taken lead to become the IDC POC for all test support functions in ABI LATAM.
Ensured delivery excellence by:
• Successfully triaging over 500 defects in last 3 months
• Resolving 289 defects in 2 months
• Working on test support functions for 6 continuous weekends during GO-LIVE preparations
• Ensuring zero missed defect report deadlines
• Helping other teams in ABI LATAM to succeed by providing them support during critical phases
I have ensured excellent client satisfaction and helped ABI LATAM receive a rating of 6.5 out of 7 from the client
Always-ready-to-help attitude and jovial disposition has earned him accolades from his team and other teams alike.
Deep technical knowledge and end-to-end ownership has ensured that he and his team are always on top of any
issues and are enabled for successful delivery.
2. Factory performance award:
I have been awarded Quarterly Factory Performance Award contribution towards guiding the team of 15 to deliver the upgrade
fixes on schedule and guided 5 junior resources to handle defects with minimal assistance.
Company Client Project Start Date End Date
Accenture AT&T Aristos Gemini - Operations & Development 10/2014 12/2016
Accenture Loblaw Support 04/2014 10/2014
Accenture SABMiller R3C Release 10/2013 03/2014
Accenture ABI LATAM ECC Upgrade 04/2012 09/2013
Accenture Nokia Nokia MADO Lean Implementation 03/2012 04/2012
Accenture SAP - IS Media Capability Asset Development 11/2011 02/2012
Accenture AstraZeneca EERP Implementation 12/2010 09/2011
Accenture DOW Chemicals ECC Implementation 02/2010 11/2010
Wipro Technologies Associated Press ERP Implementation 04/2009 01/2010
Wipro Technologies All Nippon Airlines ECC upgrade - ANA GAIA 07/2008 03/2009
Wipro Technologies Apple Support & Maintenance 03/2007 06/2008
Wipro Technologies Nike Tire II Support 10/2006 02/2007
Wipro Technologies Wales & West Utilities Implementation 05/2006 10/2006
Wipro Technologies Cadbury Shw eps Operations 03/2006 05/2006
Wipro Technologies Copper Pow er Systems Upgrade 06/2005 02/2006
Magna InfoTech Deputed to
British Petroleum – IBM Operations 08/2003 06/2005
Vista Info Tech deputed to
P&G - Altos Origin Operations 03/2003 07/2003
NIIT Board of Intermediated Education – AP Application Development & Implementation 05/1998 08/2001
I worked as an Offshore POC / payroll buddy to manage regular SAP HCM payroll activities for a client AT&T.
Activities of Payroll buddy:
monitor Prelim and Final Payroll runs
On Final payroll, work with EMAS PSC Tier 1 (scheduling team)
re-schedule cancelled RPCALC/RPCIPE jobs
evaluate errors (rejected pernrs) and determine corresponding action
update Onshore and Offshore Payroll/TGF teams of the monitoring status
1. Prelim & Final Payroll Process monitoring:
The primary objective of the monitoring is to oversee the jobs that are being processed and watch out for
delays or abends that can disrupt the daily eLink Payroll processing cycle. Payroll monitoring is a two-part
process – the Prelim payroll monitoring and the Final payroll monitoring.
Scheduling team (EMAS PSC) schedules and executes the jobs that run during payroll run. On Prelim
payroll run, their involvement is minimal, in that they are the primary escalation point at times when there
are job delays. On Final night however, they monitor the completion of all payroll batch jobs alongside a
Payroll buddy monitor the jobs for cancellations, terminations or abends. A payroll buddy is tagged as the
primary point of contact, who updates the leadership team of the monitoring results.
Payroll evaluation is performed bi-weekly and processed alternately on every other week time frame for
non-management employees. For management employee’s payroll is evaluated semi-monthly based on
determined pay periods.
Initial payroll simulation is executed before the prelim run to identify errors that will be encountered during
Prelim payroll processing cycle runs the night before final payroll cycle starts. It evaluates what has been
entered in the system till date and updates RT table. At the end of the processing errors will be corrected
by payroll office before the final processing.
While in the process, an email should be published to all stake holders with high level set of results of
rejected pernrs for both Prelim and Final processing. Payroll office will do the necessary corrections for all
rejected pernrs before Final payroll processing.
Payroll buddy is the responsible to publish the results of final processing to payroll operations (client team)
functional and technical teams. It should contain RPCALC, RPCIPE errors and whether pay results have
been deleted, Direct deposit and pay checks information.
2. Infotype 0003 update utility:
This is an utility program to update the infotype 0003 record with dates indicated on the selection screen.
Updates are performed either through BDC session or call transaction method using PU03. At End statistics
will be provided.
3. Hewitt Eligibility outbound file interface:
This is a daily outbound interface that creates a file containing employee indicative data. The file is sent to
Hewitt Associates and the third party administrator.
This process not considered contract employees.
The outbound interface is currently scheduled to run in two ways i.e. First run of the month and daily
schedule. For first run of the month is manual scheduled due to the request made by the client for audit
purpose. It is important to be aware that there may be scheduled jobs running in production for Hewitt
eligibility file. Therefore, precautions should be taken before triggering any manual jobs.
For first run of the month will be scheduled on the first business day of the month who qualify for having
rolling 12 months paid commissions included for life insurance purpose. 10 jobs will be created and
produces 10 files. All these 10 files merged into on1 file and sent to the destination server immediately.
4. EOY Overpayment recoveryprogram:
Employees who receive wages more than they are entitled to are responsible for repaying the company
their overpayment. The collection of the money is done through infotypes 0014 and 0015 with pre-tax wage
types. At the end of the year, if the full amount is not recovered from the employee, the pre-tax wage types
should not be deducted from and post-tax wage types are to be created for the next year with the remaining
balance. This program is to mechanically change and create infotype 0014 records which would alleviate
the Payroll Office to manually handle these situations.
The program needs to run after the last payroll evaluation of the year for each payroll areaand before the
first payroll evaluation for the next year.
5. File Loads to Infotypes 0015 / 0267 / 2010
An incentive Pay file will be received from Client on schedule date once in a month to update the IT0015.
This fill will be encrypted and forwarded to us for upload / update. A program used to upload/update records
in IT0015 initially in test mode to find any error pernrs. Once 0 rejected pernrs identified, program will be
executed in real mode to update IT0015. Validate the record / employee in PA20 infotype 0015 or in table
6. File load to update infotype IT0003
Program updates Earliest MD change in infotype 0003 using the records in the file. This program executed
in background using SPM access. Validate the record / employee in PA20 infotype 0003 or in table
I have been involved in developing interfaces in different modules of SAP.
1. Interface for Order Creation: The objective is to provide interface solution to client for creating Maintenance
Orders in ECC. Request gets created in local system for Placement, Removal, Transfer and Refurbishment of
coolers. Once the request gets approved maintenance orders needs to be created in SAP with the help of this
All required data for creation of maintenance orders and notifications will be made available in local system
before approving the request. Data is received from local system with the help of inbound interface by means
of an IDOC and this is used for creating the Orders and Notifications in SAP using function module
BAPI_ALM_ORDER_MAINTAIN and BAPI_ALM_NOTIF_DATA_ADD. Standard transaction for creating and
changing orders is IW31.
2. Inetrface for Order Teco and Completion: In local system requests for Breakdown, Preventive Maintenance
and Refurbishment is updated manually after completing the job. Once the job gets over local system sends
Order related details to SAP by an interface. This enhancement updates the order in SAP based on the data
received through interface and carries out TECO (Technical Completion) the Breakdown and Preventive
Maintenance orders with the reference date received from the local system.
Only the fields, which needs to be modified in order needs to be sent to SAP along with reference of Order
number. Few key fields like Order number, Operation number etc., shall not be considered for modification as
they will be unique identifiers. Local system to send some indicator to specify whether the IDOC data sent is
for creating the order or for changing the order along with request details.
Receive IDOC containing Order details, that needs to be updated in SAP by means of an Inbound interface
from local system. Data received in this IDOC is used to update following in Breakdown (Order type ZC02) ,
Preventive Maintenance (Order type ZC01) or Refurbishment Order (Order type ZC15).
a. Updae order header details
b. Update the order with Operation related details
c. Update the order with Component related details
d. Update the order with Partner related details
e. Carry out Technical completion of the order (only for Breakdown and Preventive Maintenance
Use BAPI ALM_BAPI_ORDER_MAINTAIN for updating and TECOing the order.
3. Outbound Interface for error Handling: The objective is to provide interface solutionto transfer order
number, Notification number or error message to Local system as an outbound interface.
If the order is created successfully from data received in IDOC through inbound interface, the order number
will be send through this outbound interface. If order creation is failed, the error code and error message will
be send. This outbound interface will be triggered while creation of order by another inbound interface.
Similarly this outbound interface will also be used for sending error message along with message number on
unsuccessful updation of Order and Notification.
This IDOC will be used for sending following messages to PI:
1. Order number and Notification number on successful creation of Order and Notification.
2. Error message on unsuccessful creation of Order and Notification.
3. Error message on unsuccessful updation of Order
4. Error message on unsuccessful updation of Notification.
Since single IDOC will be used for error handling for various events, following logic will be used to
differentiate the IDOC’s.
Condition Logic used for differentiation in IDOC
Unsuccessful creation of
Order / Notification
Order number and Notification number is blank and reference
Successful creation of
Order / Notification
Value exists in Order number and Notification number and
reference number exists
Unsuccessful updation of
Order number exists and reference number is blank
Unsuccessful updation of
Notification number exists and reference number is blank
4. Local to Central Post GR interface: When customer creates a Goods Receipt a message must be created
and send via SAP PI to supplier. Changing Goods Receipt in the source system will be handled by counter
posting (it means GR cancellation - e.g. movement type 102 will be sent, if original GR was posted with
movement type 101) and posting of new (changed) GR. This message will be triggered automatically after
the goods receipt has been created/cancelled. There are two options for triggering the IDoc, first one is using
a BADI (MB_DOCUMENT_BADI method MB_DOCUMENT_UPDATE) and the second one is using
condition records. The process will use the SAP Standard IDOC type WMMBID02 on the customer side and
proxy service on the central system side.
The message will contain the standard Goods Receipt information (at least mandatory fields described in
this document) Complete list of mandatory fields needed by Central system is provided below.
In the PI system formal check of the incoming data takes place. Email will be generated and sent to resp.
person, if data doesn’t pass this check (message will be cancelled in PI to prevent backlogs):
1. Values in mandatory fields missing.
2. Values for PI data mappings are missing.
In the central system during proxy processing formal check of the incoming data takes place. Email will be
sent to resp. person, if data doesn’t pass this check:
1. Central system PO number or item doesn’t exist.
Email will be generated and sent to resp. person (during proxy processing), if BAPI call ends with any error
provided in return table.
Process will use standard IDoc WMMBID02. BADI or Condition records will be used for IDoc creation. For
BADI option, implementation MB_DOCUMENT_BADI using interface IF_EX_MB_DOCUMENT_BADI
method MB_DOCUMENT_UPDATE will be used.
Outbound IDoc : Basic type WMMBID02, Message type WMMBXY
Outbound IDoc will be mapped in PI to ABAP Proxy.
In the central system, ABAP Proxy will handle incoming message, map data to BAPI structure and call FM
5. Interface for Stock Transfer Requisition: The planning of Stock Transfer Requisition is not always fully
covered by the Deployment Plan and it is necessary to create manual STRs. In addition, the Deployment Plan
published into AP rounds to the pallet the planned quantities, making the requirements in SAP and AP not
The analysis of open STRs in the system can also allow to see that a daily publish of the Deployment Plan is
not required for all the materials.
In order to guaranteed the availability of Empties for the Scheduled Production and perform the Empties
deployment plan, the planner requires full information about how much Empties are consumed in the
Packaging process, how much are returning from trade and how is the stock situation for the containers.
For the Repacking activities it is essential that the planner reviews during the day how much FG were moved
to Repacking activities in order to perform some changes in the Deployment plan to follow the Repacking plan.
For all these reasons, a new interface is needed to help the use have a pre-analysis of the current open STRs
in the system, both manually and automatically created through the Deployment Plan publish. This tool will
allow the planner to follow the full picture of the Packaging Process (Packaging in Lines and Repacking)
avoiding disruptions in the plan that can drive to stock outs and stoppages in the production lines.
It should be possible to trigger the interface via custom report ZBGM_APS_DWLD. This report needs to be
enhanced with an additional radio button for ‘Stock Transfer Requisitions’ that will run the interface when
Additionally it should be possible to run the interface in Test Mode using transaction ZBGM_TEST_EXT which
will not generate an XML file but will display the output on the screen in ECC.
6. Interface Automatic GR Creation: The Automatic Goods movement would be posted in the SABMP system
reference to Goods Receipt, Goods return, Goods Reversal (Cancellation of the goods is captured as Goods
Reversal in Local Breweries).
After the final GR posted in the local breweries, when no other deliveries are expected, the Customer PO line
item will be closed - i.e. flagged as Delivery Complete. This is would get captured in the SABMP GR against
the SABMP PO.
Before initiate the Goods Receipt transaction, based on the local PO the SABMP PO would be determined
from the SABMP PO item details.
Goods Receipt posted in the local breweries against the Planned Costs in the Customer PO which are not
relevant for SABMP will not be posted in SABMP system.No goods in transit will be tracked as part of the pilot.
The moment the GR of the Customer PO is done by the Customer at the local breweries. The GR of the
SABMP PO should be done automatically in the SABMP. Map the SABM PO based on local PO received via
proxy. Retrieval of SABM PO- Fetch ‘EBELN’ from EKPO table where ebeln = proxy-ebeln and werks = proxy-
werks. Retrieval of trade contract- Fetch ‘TKONN’ from WBHK table where BSTNK = proxy-ebeln. Pass the
trade contract number ‘TKONN’ to function module. BAPI_TRADINGCONTRACT_GET_FLOWand read the
PO number from the DOCUMENTFLOWOUT structure. Compare the PO received in FOLLON_DOC field.
The above step is done to validate that the SABM PO which we got is the correct one for which GR needs to
be done. Call BAPI ‘BAPI_GOODSMVT_CREATE’ to create &post goods receipt document.
7. Enhancement - Tracking of Supplier Batch Numbers: In standard SAP solution, the batch number is
generated automatically whenever a Goods receipt is made for Batch Managed Materials. In Buy/Sell process
we have a requirement to capture the vendor batch, when the Batch Management is not active in SABM
Procurement central system. To achieve this requirement at the time of Automatic GR creation proc ess via
WMMBXY, standard Goods receipt transaction should be enhanced using a user exit. This user exit allows
capturing the vendor batch in the Goods Receipt even when the Batch Management is not active in the SABMP
Based on the proof of delivery or on the physical goods receipt the GR document is posted in the SAP system
at the Local breweries. Map the SABM PO based on local PO received via proxy. Retrieval of SABM PO-
Fetch ‘EBELN’ from EKPO table where ebeln = proxy-ebeln and werks = proxy-werks. Pass the trade contract
number ‘TKONN’ to function module BPI_TRADINGCONTRACT_GET_FLOWand read the PO number from
the DOCUMENTFLOWOUT structure. Compare the PO received in FOLLON_DOC field. The above step is
done to validate that the SABM PO which we got is the correct one for which GR needs to be done. Call BAPI
‘BAPI_GOODSMVT_CREATE’ to create & post goods receipt document. If batch details have not been
updated via bapi successfully than we need to call user exit ‘EXIT_SAPMM07M_003’ to update the batch
8. Enhancement – Update return goods movement table during Vl09 :it is required to capture delivery wise
information for movement of RC material in terms of value and quantity at time of PGI/PGR. An enhancement
need to be created in the include MV50AFZ1. If goods movement is reversed with VL09 transaction, the same
should be reversed in basic custom tables.
9. Enhancement – Update Custom tables for MEP Customers in Sales order processing: The main
requirement of this object is to create/update a delivery block whenever a sales order is processed for MEP
customers based on the following condition – the Value of the returnable goods in the Sales order is greater
than credit limit. Logic has been implemented in USEREXIT_SAVE_DOCUMENT_PREPARE’ and
10. Outbound Order Flow Visibility - Planning center (DC) requires constant access to the information of
outbound deliveries created in SAP for accurate capacity planning. Such information is also needed for
tracking missing orders from SAP to TMS/WMS for various reasons. In order to obtain this content, a number
of tables need to be joined with certain conditions. Therefore, an automated report is required.
SAP Upgrade / Migration from 4.7 to ECC:
I have involved in 4 upgrade projects from older versions to ECC version.
1. Upgrade / Migration for Client ABI
Recently I have executed upgrade end to end process in all phases for client ABI Inbev LATAM geography.
I am responsible for end-end process from offshore. ABI is currently running on a two standalone instances of SAP
on version 4.7; one each for LAN and LAS. Inventory contains 1400 objects.
ABI is also having SAP Global Template G-ERP system with SAP ECC 6.0 version, sourcing existing functionalities
of Global template. This global template is already implemented in some countries of the Europe and Canada.
The technical scope of the project is –
Migrate and adapt the CUSTOM solutions of current LAN and LAS 4.7 systems to Global template ECC 6.0.
Doing the necessary corrections as per the Unicode enablement and obsolete function modules.
Changing the naming standards of custom developments as per the G-ERP standards.
Doing the the language translation to English / Spanish / Portuguese.
Developing new functionalities in business process FSCM, DSD, New GL and Business planning and consolidation
according to the system LAN or LAS.
Project go-live will have 3 phases for LAN and 2 phases for LAS.
1. 1st phase of go-live is for Guatemala - LAN
2. 2nd phase of go-live is for HILA (Peru, Equator and Republic Dominican) - LAN
3. 3rd phase of go-live is for Brazil - LAN
4. 4th phase of go-live is for Argentina and Chile - LAS
5. 5th phase of go-live is for Bolivia, Paraguay and Uruguay - LAS
2. Upgrade for Client ANA:
I have executed end-end process of upgrade from 4.7 to ECC for client ANA Japan. I have played an onshore-
offshore co-ordinator role in this project. We have done the upgrade corrections around 1000 objects, which are
not compatible in ECC. I have prepared inventory for all impacted objects and planned for delivery. I have clos ely
worked with client site and updated the information timely to onshore / offshore team members.
We have done all Unicode corrections and obsolete statements / Function module corrections in the objects. I found
some of the objects which are not compatible in ECC due to upgrade activities and made the changes to the code,
SAP IS-MEDIAAssets Development:
I have been involved in building assets using ABAP in SAP IS-MEDIA module in Accenture Media LAB for period
of 4 months.
Advertisement bookings for various editions are being done with the unit of measurement (UOM) Square
Centimetre. The standard SAP system IS media version supports the unit of measurement Column Centimetre or
Column Millimetre. Thus to accommodate the clients requirement the unit of measurement needs to be changed
from Column Centimetre to Square millimetre ( mm2). This requirement has been done by using an enhancement
JHTD0002 – IS-M/AM: Convert Advertisement Sizes.
In IS-M/AM, while booking an Advertising Sales Order, depending on the booking-unit deadline, in the bookingunit
master, we have to define the Number of Days buffer to be allowed before the Printing deadline. In Standard SAP,
a message pops-up at the item level and allows the user(s) to proceed further on clicking the option “YES”. On
selecting YES, it will allow the user(s) to proceed with the advertisement booking order for SAVING. To disallow
user(s) for such erroneous bookings, an enhancement is made for which a message pops-up at the time of SAVING
the Order at the HEADER-LEVEL and a clearance needs to be given for the same by a Front Office Supervisor.
This requirement has been done by using an enhancement JHA10001 – IS-M/AM – Read, Save Initialize Orders.
Not to allow saving of an advertisement Sales order, with ZERO value. To allow SAVING of an advertisement
Sales order only at Header-level with a value.In IS-M/AM, while booking an Advertising Sales Order, at the time of
ORDER SAVE, it should not allow the user(s) to SAVE the Order with ZERO value. This requirement has been
done by using an enhancement JHA10001 – IS-M/AM – Read, Save Initialize Orders.
In IS-M/AM, an Advertising Sales Order, after the material is assigned to the Line Item at Ad Spec Level, the status
of the Line item reflects as “Technically Incomplete”, which denotes the status level as (10) and the status color as
(RED) at the Line Item Level. Thus, even after publishing and Billing of the Sales Order the status level and color
remains unchanged. This gives an incorrect picture of the Sales Order in terms of the level in which the Line item
is actually visualized in terms of being complete. On making changes in the user exit(s), a complete visualization
of the Sales Order in terms of status level and status color is seen. This requirement has been done by using
an enhancement JHA10001 – IS-M/AM – Read, Save Initialize Orders.
In IS-M/AM, while converting a Standard Sales Offer to a Standard Sales Order using Transaction Code : jha6,
while converting the same, at the HEADER Level in the “Your Reference” Field the Standard Sales Offer does not
get populated, therefore for tracking or linking purpose, the scheduling department will not get a correct picture of
the Standard Sales Order that has been converted from the Standard Sales Offer. This requirement has been
done by using an enhancement JHA10001 – IS-M/AM – Read, Save Initialize Orders.
WebDynpro Components :
Goods receipt Exceptions report :
This report will provide the ability to view the exceptions related to Goods Receipts (GR) done at Stores. The
report should be available via SAP Retail Store Desktop.
This report will be used to highlight exceptional GR transactions that require store management attention.
Following exceptions have been identified:
• Goods received without reference to PO
• DC shipment received by outbound delivery/PO, instead of HU
• Goods received using subsequent listing functionality
• The Goods Receipt exceptions report will be an online and on demand MIM report.
• At the store level, colleagues will be able to run the report pertaining to the specific login store. They will
not be able to see the goods received by other stores.
Perishables Planner Report :
The current process of ordering perishables in the store using a specific handheld application referred to as
Perishable Order Guide (POG) will be discontinued once store are on SAP. SAP stores will place manual orders
for perishables using the same handheld device they use to place any orders. As an optional aid, they will have
a detailed report that may be used as a perishables planning tool. The store may use this report as an order
guide to help them plan the article quantities required. Once the quantities are determined and recorded on the
report manually, the store will enter the orders into the system using the Manual Order process on the handheld
The report include:
The perishable articles information.
For each day, 4 week average of sales history on that day is presented.
A free text field at the bottom of each page for store use as needed
Indicate promotional quantities on any delivery buckets planned to arrive on any of the days shown.