Nagesh Venkata Satya Nooka
Sr. SAP Technical consultant
Mobile: +91-9742033633
+91-9742763633
Skype ID – cute_ishanth
Emai...
 Developed field mapping templates for all the ALE/IDoc Interfaces.
 Developed BAPI and ALE/IDoc programs for the new re...
I have ensured excellent client satisfaction and helped ABI LATAM receive a rating of 6.5 out of 7 from the client
team.
A...
Project’s Summary
Company Client Project Start Date End Date
Accenture AT&T Aristos Gemini - Operations & Development 10/2...
Payroll evaluation is performed bi-weekly and processed alternately on every other week time frame for
non-management empl...
An incentive Pay file will be received from Client on schedule date once in a month to update the IT0015.
This fill will b...
This IDOC will be used for sending following messages to PI:
1. Order number and Notification number on successful creatio...
5. Interface for Stock Transfer Requisition: The planning of Stock Transfer Requisition is not always fully
covered by the...
Based on the proof of delivery or on the physical goods receipt the GR document is posted in the SAP system
at the Local b...
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 ...
 WebDynpro Components :
 Goods receipt Exceptions report :
This report will provide the ability to view the exceptions r...
of 11

Nagesh SPA Technical Lead

Published on: Mar 3, 2016
Source: www.slideshare.net


Transcripts - Nagesh SPA Technical Lead

  • 1. Nagesh Venkata Satya Nooka Sr. SAP Technical consultant Mobile: +91-9742033633 +91-9742763633 Skype ID – cute_ishanth Email: nvsn1410@outlook.com nvsnpoori@gmail.com Profile Summary 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 & Espresso tools. Professional Summary  Onshore Experience:  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 realization phase.  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.  Offshore Experience:  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.
  • 2.  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.  Technical Lead  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.  Project Management  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.  ABAP Trainer  Successfully completed trained 5 GFT batches in SAP ABAP for ASEs at Accenture. Awards 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
  • 3. I have ensured excellent client satisfaction and helped ABI LATAM receive a rating of 6.5 out of 7 from the client team. 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.
  • 4. Project’s Summary 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 IBM British Petroleum – IBM Operations 08/2003 06/2005 Vista Info Tech deputed to Altos Origin P&G - Altos Origin Operations 03/2003 07/2003 NIIT Board of Intermediated Education – AP Application Development & Implementation 05/1998 08/2001 Operations: 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. 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.
  • 5. 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 payroll processing. 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
  • 6. 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 PA0015. 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 PA0003. Developments: 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 interface. 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 orders) 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.
  • 7. 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 number exists Successful creation of Order / Notification Value exists in Order number and Notification number and reference number exists Unsuccessful updation of Order Order number exists and reference number is blank Unsuccessful updation of Notification 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 BAPI_GOODSMVT_CREATE.
  • 8. 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 match completely. 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 selected. 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 system.
  • 9. 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 number details. 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 MV45AFZZ. 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
  • 10. 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, successfully implemented. 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.
  • 11.  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 device. 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.

Related Documents