MM-SRV Interfaces

M-SRV Interfaces
Overview

o o

MM-PUR Interface Purchase requisitions Purchase orders MM-IM Interface MM-IV Interface CO Interface (commitments) PM Interface Report MEDEBUG

Service Purchase Requisitions (MM-PUR Interface)

Interface components

Function module: MS_SERVICE_PACKAGE Function group: MLSP Communication structure: COMSRV Global accounting table (internal): ACC_TAB Transaction ME51 Main MM-PUR program: SAPMM06B subroutine: DIEN_MAINTAIN Transaction ME51N Main MM-PUR program: SAPLMEGUI Function module: MS_SERVICE_PACKAGE_PBO External requisition processing Main MM-PUR program: SAPLEBNE subroutine: DIEN_MAINTAIN External process creates purchase requisitions via function module ME_REQUISITION_EXT Examples: BAPI_REQUISITION_CREATE; Transaction IW31, IW32 (PM Orders), CN21, CN22 (Networks) How to check BAPI problems: Function module: BAPI_REQUISITION_CREATE Execute SE37 with BAPI in test mode using test data directory (note 420331 describes how to fill BAPI structures) Breakpoint in BAPI_REQUISITION_CREATE at "PERFORM requisition_create_data", check XESLL, XESKL, XESUH Breakpoint in program LEBNEF04 (CREATE_SRV_POS), check the delivered data from function module MS_FILL_TABS_FROM_EXT_DATA

Breakpoint in program LEBNEF17 (form DIEN_MAINTAIN

Service Purchase Orders (MM-PUR Interface)

Interface components

Function module: MS_SERVICE_PACKAGE Function group: MLSP Communication structure: COMSRV Global accounting table (internal): ACC_TAB Transaction ME21 Main MM-PUR program: SAPMM06E subroutine: form DIEN_MAINTAIN Transaction ME21N Main MM-PUR program: SAPLMEGUI Function module: MS_SERVICE_PACKAGE_PBO

Debugging and message processing hints

o o o o o o

Account assignment of requisition or PO item is wrong: breakpoint in function module MS_SERVICE_PACKAGE -> check entries in internal table ACC_TAB -> if ACC_TAB is correctly filled, the error must be searched in MM-PUR, otherwise in MM-SRV How to find entries in table ESLL: use view ML_ESLL with document and item number Service account assignment or services are missing by copying services from requisition: check entries (item number, document number, package number) in table ESLH -> correction report RMPRKONT How to check BAPI problems: Function module: BAPI_PO_CREATE or BAPI_PO_CREATE1 (since 46C) Execute SE37 with BAPI in test mode using test data directory (note 420332 describes how to fill BAPI structures) Breakpoint in include LMEWPF01 (form PO_ITEM_GENERATE), check CESLL, CESKL, CESUH Breakpoint in function module ME_CREATE_PO_ITEM, check returned entries in XESUC, XESLL, XESUH, XESKN from function module MS_FILL_TABS_FROM_EXT_DATA

Service Entry Sheet Acceptance (MM-IM Interface)

MM-PUR Interface Purchase requisitions Purchase orders MM-IM Interface MM-IV Interface CO Interface (commitments) PM Interface

Report MEDEBUG

o o

Material document is created via ML81N or ML81 not possible to use transaction MIGO (MB01) for service items transaction MBST is also not allowed (due to an error it was possible in the past, corrected with note 323521) Delivery costs are not supported for services (consulting note 381030) In case of GR-Based IV the number of lines in the material document corresponds to the number of lines in table ESKN In case of Service-Based IV the number of lines in the material document corresponds to the number of lines in table ESKL Function group: EINR Function module: ME_READ_ITEM_GOODS_RECEIPT subroutines: XEBEFU_AUFBAUEN_DIEN XEBEFU_AUFBAUEN_DIEN_L in case of PO items with service based GR"-Flag content of internal table XEBEFU is taken over to MM-IM Important internal tables XEBEFU: item information for GR (more than one entry per item XESLL: service package XESKL: mapping account assignment to service line XESKN: total account assignments POT: PO items (EKPO) KNT: PO item account assignment Debugging hints Main question: is this a MM-SRV or a MM-IM problem ? Breakpoint in function module ME_READ_ITEM_GOODS_RECEIPT (EINR) and check entries in internal table XEBEFU If XEBEFU is ok > MM-IM problem If XEBEFU not ok > MM-SRV problem possible)

Errors during acceptance Breakpoint in program LMLSRF0W (form ACCEPTANCE) at call function MB_CREATE_GOODS_MOVEMENT' ". In EMKPF can be analysed which field is wrong or empty.

Invoice Verification (MM-IV Interface)

o o o o o

MM-PUR Interface Purchase requisitions Purchase orders MM-IM Interface MM-IV Interface CO Interface (commitments) PM Interface Report MEDEBUG

Function group: EINR Function module: ME_READ_ITEM_INVOICE subroutines: XEK08R_AUFBAUEN_DIEN XEK08R_AUFBAUEN_DIEN_L in case of PO items with service based GR"-Flag XEK08R_AUFBAUEN_REPL in case of PO items with invoicing plans Internal table XEK08RN contains the suggested values to MM-IV Important internal tables XEK08RN: item information for IV TEKSEL: Table of selected purchase orders, gets populated with function ME_SELECT_DOCUMENTS

 o o o

XESLL: service package XESKL: mapping account assignment to service line XESKN: total account assignments POT: PO items (EKPO) KNT: PO item account assignment

Commitments (CO Interface)

MM-PUR Interface Purchase requisitions Purchase orders MM-IM Interface MM-IV Interface Commitments (CO Interface) PM Interface Report MEDEBUG Prerequisites Commitment update for controlling area must be active (Transaction OKKP) cost objects must be active for commitment (Transaction KOT2 for orders, KS02 for cost centers) Unit of measure used at item level must be set up for value based commitment (trx. CUNI), otherwise the commitment reduction will be wrong (notes: 93951, 38744) Commitment is created for purchase requisitions and purchase orders

Function group: EINS Function modules: ME_STATISTICS_RKO (PO commitment) ME_STATISTICS_EBAN_RKO (requisition commitment) subroutines: DIEN_BEREITSTELLEN (PO commitments) Internal table XEKBP contains the suggested values to CO in case of PO commitment Internal table XEKPR contains commitment values in case of requisition commitment Commitment reduction Purchase requisition commitments will be reduced by PO's created with reference to this requisition PO commitments will be reduced by GR postings in case of valuated GR PO commitments will be reduced by IV postings in case of non-valuated GR PO commitments can be completely reduced by setting the final delivery flag (for valuated GR) or by setting the final invoice flag (in case of non-valuated GR) Report RKANBU01 rebuilds the commitment

Important tables and fields

o o o o o o o

The commitment values can be found in table COOI Important fields in table COOI: REFBN - document number (PO or requisition) RFPOS - item number BLDAT - document date ORGWTH - total commitment value in local currency WHGBTR - rest commtiment value in local currency Table COSPA contains the sum values for PO's and requisitions Report RKACSHOW can be used to see the commitment values

Interface PM/PS
MM-PUR Interface Purchase requisitions Purchase orders MM-IM Interface MM-IV Interface Commitments (CO Interface)

PM Interface Report MEDEBUG Transaction IW31 Main program: SAPLMLSP subroutine: INT_ORDER_PBO Function module: CO_IH_MMSRV_INFO_GET (information from PM), CO_IH_MMSRV_INFO_SET (information to PM), ME_REQUISITION_EXT (to create/update requisitions)

Report MEDEBUG

Debugging help tool Execute report MEDEBUG via SE38 For each topic (grouped in tab titles) several breakpoints possible After setting the breakpoints it is not necessary to restart the transaction

Important tables in MM-SRV -1-

Important tables, views, and structures in MM-SRV -2-

SAP FI-MM-SD INTEGRATION

Attachments:1 Added by Rajesh Banka, last edited by Alon Mizrahi on Nov 07, 2011 (view change) SAP FI-MM-SD INTEGRATION Link Between SAP SD, MM and FI

The link between SD and MM :1. When you create sales order in SD, all the details of the items are copied from Material master of MM. 2. MRP and availability check related data is also taken from MM although you control this data in SD also. 3. While you create inbound/outbound delivery with reference to a sales order, the shipping point determination takes place with the help of the loading group, plant data, shipping conditions etc. This also refers to Material Master. 4. The material which you are entering in a sales order must be extended to the sales area of your sales order/customer otherwise you cannot transact with this material. There are many such links between SD and MM.

Now the link between SD and FI :1. Whenever you create a delivery with reference to a sales order, goods movement takes place in the background. eg. In case of standard sales order, you create an outbound goods delivery to the customer. Here movement 601 takes place. This movement is configured in MM. Also, this movement hits some G/L account in FI. Every such movement of good s hits some G/L account. 2. The accounts posting in FI is done with reference to the billing documents (invoice, debit note, credit note etc) created in SD. Thus this is a link between SD and FI 3. Tax determination: In case of a tax determination also, there is a direct link between SD and MM SD Integration points with other modules SD module is highly integrated with the other modules in SAP. Sales Order Integration Points Availability Check Credit Check Costing Tax Determination Transfer of Requirements Delivery and Goods Issue Integration Points Availability Check Credit Check Reduces stock Reduces Inventory $ Requirement Eliminated Billing Integration Points Debit A/R Credit Revenue Updates G/ L Module FI/ CO FI/ CO FI/ CO Module MM FI MM FI/ CO PP/ MM Module MM FI CO/ MM FI PP/ MM

(Tax, discounts, surcharges, etc.) Milestone Billing PS

Return Delivery and Credit Memo Integration Points Increases Inventory Updates G/ L Credit Memo Adjustment to A/R Reduces Revenue SD Transaction Code Flow: FI FI FI FI Module MM

Inquiry / Document type IN Transaction code for creation VA11,VA12,VA13. tables VBAK,VBAP Quotation / QT Transaction code for creation VA21,VA22,VA23. tables VBAK,VBAP Sales Order OR Transaction code for creation VA01,VA02,VA03. tables VBAK,VBAP Delivery LF Transaction code for creation VL01,VL02,VL03. tables LIKP,LIPS Billing F2 Transaction code for creation VF01,VF02,VF03. tables VBRK,VBRP Excise Invoice (Only for India - Manufacturing Scenario) Transaction code for creation J1IIN. Note: Tables for Document Flow VBFA

Re: SAP MM Functional Specs -Help Required

Balaji Genupur Nov 12, 2007 7:11 PM (in response to James jayaraj)
Hi James,,, Functional Specs differs from client to client how they use it. Anyways from ur client u can take the specs it shd be in the Process Database. In general the Spec has the following info .... 1. Process Owner. 2. Requested by : 3. SAP MM consultant incharge( Ur Name ) 4. Abaper, If required. 5. Integration Team Members. 6. AS- IS & TO- BE 7. If any User exits or enhancements needed then mentiion in details. Insense the config & Tech part need to be developed shd be mentioned clearly. Regards Balaji

Scheduling agreement configuration??

This question has been Answered.

MM team Feb 10, 2010 8:15 AM hii Can anybody explain me on below things 1.Scheduling agreements configuration steps..??

Configuration steps for below process: Without release documentation (in the standard system, document type LP)..?? With release documentation (in the standard system, document type LPA)..??? Thnaks SAP-MM

Correct Answer by Pardeep Malik on Feb 10, 2010 9:00 AM Hi, As per my previous reply.... Define Document Type ifu want your own and assign number range. Also , assign that document Type to PO document type with category allowed.

Regards,

Pardeep Malik
See the answer in context

1767 Views

Average User Rating (0 ratings)

Re: Scheduling agreement configuration??

Pardeep Malik Feb 10, 2010 8:25 AM (in response to MM team) Hi, First Define Time Dependent or Not Depenedent via In the case of scheduling agreements and quotations, the document type determines whether time-dependent or time-independent conditions can be created. You can set the Time-Dependent Conditions indicator in Customizing for the document type to enable time-dependent conditions to be maintained in scheduling agreements and quotations. Define time-dependency in scheduling agreements and quotations: SAP Customizing Implementation Guideu2192Materials Managementu2192Purchasing u2192 RFQ/Quotation or Scheduling Agreement u2192 Define Document Types and document type is Define document types for scheduling agreement: SAP Customizing Implementation Guideu2192Materials Managementu2192Purchasing u2192 Scheduling Agreement u2192 Define Document Types For release u can create Release profile Create release creation profile: SAP Customizing Implementation Guideu2192Materials Managementu2192Purchasing u2192 Scheduling Agreement u2192 Maint. Rel. Creation Profile for Sched. Agmt w. Rel. Docu. You can use release creation profiles to define the criteria for the creation of SA releases (you can influence the quantities and delivery dates/times to be transmitted to the vendor, for example). Whether or not you can generate both forecast and JIT delivery schedules against a scheduling agreement with release documentation is determined by the JIT delivery schedule indicator in the material master record. In order for you to be able to work with JIT schedules, the JIT delivery schedule indicator must be set in the material master record (Purchasing or MRP 2 view) and in the additional data for the scheduling agreement item. No JIT delivery schedules can be created unless this indicator has been set.

Hope Help U !

Regards, Pardeep Malik

Report Abuse

o o
Re: Scheduling agreement configuration??

Like (0)

MM team Feb 10, 2010 8:48 AM (in response to Pardeep Malik) hii Can u tel me , waht are the configuration data has to be created for SA. Like document type ...???? Thanks SAP-

Correct AnswerRe: Scheduling agreement configuration??

Report Abuse

Like (0)

Pardeep Malik Feb 10, 2010 9:00 AM (in response to MM team) Hi, As per my previous reply.... Define Document Type ifu want your own and assign number range. Also , assign that document Type to PO document type with category allowed.

Regards,

Pardeep Malik Re: Asset Procurement Cycle need info in sap mm

Prabhaharan Manickam

Jul 22, 2011 11:00 AM (in response to paramesh pasupuleti)

steps to process the procurement of Assets: 1. Create requisition ME51N 2. Release PR if release procedure applicable- ME54N 3. Create Asset Master by Finance department.- AS01 4. Create PO (ME21N) with ref to the requisition. Ensure that you select the Account assignment category as 'A'. Enter the asset number, in account assignment tab. The PO can be created without material or if it with material to keep a track on the stock, you can use Non-valuated material type. 5. Release PO - ME29N or ME28 6. Print PO (ME9F) 7. Carry out GR against the PO (MIGO) 8. Advise finance to update the Asset Master (AS02) Re: Asset Procurement Cycle need info in sap mm

Mallinath Patil Hi,

Jul 22, 2011 11:02 AM (in response to paramesh pasupuleti)

Create the respective Asset master record through T-code AS01 for more information contact your FI team.. The Material master record , the material has to be declared for Asstes in J1ID.With material , plant , Chapter ID combination. Create a PO with "Account assignment category" "A" with material and asset master. Do the GRN through MIGO_GR , capture and Post the excise invoice through J1IEX (here only 50% OF Cenvat you avial initial and 50% in coming financial year) and Invoice verification thorugh MIRO.

What are Functional Specifications?

By: rekha | 25 Aug 2007 7:24 am Functional specifications (functional specs), in the end, are the blueprint for how you want a particular report and transaction to look and work. It details what the report will do, how a user will interact with it, and what it will look like. By creating a blueprint of the report or transaction first, time and productivity are saved during the development stage because the programmers can program instead of also working out the logic of the user-experience. It will also enable you to manage the expectations of your clients or management, as they will know exactly what to expect. A key benefit of writing up a Functional Spec is in streamlining the development process. The developer working from the spec has, ideally, all of their questions answered about the report or transaction and can start building it. And since this is a spec that was approved by the client, they are building nothing less than what the client is expecting. There should be nothing left to guess or interpret when the spec is completed. Functional Specification A functional specification (or sometimes functional specifications) is a formal document used to describe in detail for software developers a product's intended capabilities, appearance, and interactions with users. The functional specification is a kind of guideline and continuing reference point as the developers write the programming code. (At least one major product development group used a "Write the manual first" approach. Before the product existed, they wrote the user's guide for a word processing system, then declared that the user's guide was the functional specification. The developers were challenged to create a product that matched what the user's guide described.) Typically, the functional specification for an application program with a series of interactive windows and dialogs with a user would show the visual appearance of the user interface and describe each of the possible user input actions and the program response actions. A functional specification may also contain formal descriptions of user tasks, dependencies on other products, and usability criteria. Many companies have a guide for developers that describes what topics any product's functional specification should contain. For a sense of where the functional specification fits into the development process, here are a typical series of steps in developing a software product: Requirements: This is a formal statement of what the product planners informed by their knowledge of the marketplace and specific input from existing or potential customers believe is needed for a new product or a new version of an existing product. Requirements are usually expressed in terms of narrative statements and in a relatively general way. Objectives: Objectives are written by product designers in response to the Requirements. They describe in a more specific way what the product will look like. Objectives may describe architectures, protocols, and standards to which the product will conform. Measurable objectives are those that set some criteria by which the end product can be judged. Measurability can be in terms of some index of customer satisfaction or in terms of capabilities and task times. Objectives must recognize time and resource constraints. The development schedule is often part or a corollary of the Objectives. Functional specification.: The functional specification (usually functional spec or just spec for short) is the formal response to the objectives. It describes all external user and programming interfaces that the product must support. Design change requests: Throughout the development process, as the need for change to the functional specification is recognized, a formal change is described in a design change request. Logic Specification: The structure of the programming (for example, major groups of code modules that support a similar function), individual code modules and their relationships, and the data parameters that they pass to each other may be described in a formal document called a logic specification. The logic specification describes internal interfaces and is for use only by the developers, testers, and, later, to some extent, the programmers that service the product and provide code fixes to the field. User documentation: In general, all of the preceding documents (except the logic specification) are used as source material for the technical manuals and online information (such as help pages) that are prepared for the product's users. Test plan: Most development groups have a formal test plan that describes test cases that will exercise the programming that is written. Testing is done at the module (or unit) level, at the component level, and at the system level in context with other products. This can be thought of as alpha testing. The plan may also allow for beta test. Some companies provide an early version of the product to a selected group of customers for testing in a "real world" situation. The Final Product: Ideally, the final product is a complete implementation of the functional specification and design change requests, some of which may result from formal testing and beta testing. The cycle is then repeated for the next version of the product, beginning with a new Requirements statement, which ideally uses feedback from customers about the current product to determine what customers need or want next. Most software makers adhere to a formal development process similar to the one described above. The hardware development process is similar but includes some additional considerations for the outsourcing of parts and verification of the manufacturing process itself. Re: I need building block Numbers for Stock Transport Orders [SAP MM]

Sambit Mohanty

Jul 18, 2009 10:03 AM (in response to Hari Reddy)

Please check the following Building blocks for STO J51 - Internal Procurement (Stock Transfer With Delivery) J52 - Internal Procurement (Stock Transfer without Delivery) J53 - Internal Procurement (Cross-Company Stock Transfer) Re

Re: tickets on movemrnt type mm

Rajesh Banka

Jan 20, 2007 9:40 PM (in response to anilkumar patreddy)

SAP Tickets - What Is That? Handling tickets is called Issue Tracking system. The errors or bugs forwarded by the end user to the support team are prioritized under three seviority High, Medium and Low. Each and every seviority as got its time limits before that we have to fix the error. The main job of the supporting consultant is to provide assistance on line to the customer or the organisation where SAP is already implemented for which the person should be very strong in the subject and the process which are implemented in SAP at the client side to understand,to analyse,to actuate and to give the right solution in right time.This is the job of the support consultant. The issues or the tickets(problems) which are arised is taken care of on priority basis by the support team consultants. The work process in support projects are given below for your reference. 1. The customer or the end user logs a call through any tool or by mail (RADIX). 2. Each one of the support team is a part of support group. 3. Whenever a customer logs a call he /she has to mention to which work group (by name). 4. Once the calls came to the work group the support consultant or the team need to send an IR (Initial Response) to the user depending upon the priority of the calls. (Top,High,Med,Low,None) 5. Then the error is fixed, debugged by the support consultant or the team. Then after testing properly by generating TR(Transport Request through the basis admin) 6. Then it is informed to the end user/customer/super user about the changes which have moved to the production server by CTS process. These are the process. In summary, what I understand is that if any configuration or customization is required to solve the issue, then the consultant have to work on DEV Client, then the end user will test it in the QA client and after approval the BASIS consultant has to transport it to the PRODUCTION client. An example: Tickets in SD can be considered as the problems which the end user or the employee in the company face while working on R/3. Tickets usually occur during the implementation or after theimplementation of the project. There can be numerous problem which can occur in the production support and a person who is working in the support has to resolve those tickets in the limited duration, every ticket has the particular deadline alert so your responsibility is to finish it before that deadline. To begin with , we should give "TICKET" to you for not knowing it. Here is an eg of a ticket raise: End user is not able to 1. Create Sales order for a customer from a New plant , since shipping point determination is not happened . ( Without Shipping point the document becomes INCOMPLETE and he will not be able to proceed further like DELIVERY, BILLING). He raises a ticket and the priority is set in one of the below: 1. Low 2. Medium 3. High. Now you need to solve this ticket. You would analyze the problem and identify that the SP configuration has to be done for the new plant. You would request a transport for DEV CLIENT to BASIS. You do the change and Request one more Transport to BASIS for QA client. The End user will test the same by creating a sales order for the new plant and approve it. Finally, you request a transport to move the changes to PRODUCTION. Once the change is deployed in production the TICKET is closed. What I have given is a small example. You would get some real issues with severity HIGH in your day-day support.