Have you ever missed a search tool in ERP that gives you quick access to the most relevant material information with a few clicks?

I mean: availability in selected plants, prices, customer discount, scales, margin, last sales orders, basic data, purchasing info, etc.

Then the "Material Information"is the answer you have been waiting for!

The transaction MATERIAL_INFO is one of the latest Sales Order Enhancement Series: Overview in SD introduced with Enhancement Package 5. It leverages the great enhancements "Enhanced Material Search with Creation - Part 1: Overview, Enrichment of Search Results with Prices and Stock Availability" and "Sales Order Enhancement Series: The Material View", which are called by the Material Info.

Calling the Material Information

All you have to do is to call the transaction MATERIAL_INFO and fill out the start parameters which are required for calling the "Enhanced Material Search with Creation - Part 1: Overview, Enrichment of Search Results with Prices and Stock Availability" and "Sales Order Enhancement Series: The Material View".

This example is taken from an SAP Retail system, but it runs on every Standard ERP with EhP5. To speed up the entry of start parameters you can save your parameter sets as "variants" (see image). 

You can use the Material Info for purchasing and sales related information. Please note that the Material View only supports the sales side, while the Enhanced Material Search supports both sales and purchasing.

Calling the Material View

When entering a valid material number in the field "Material" (here: article) here you can call the Material View:

Calling the Enhanced Material Search

When entering a valid material number OR a full text search term in the field "Material" (here: article) here you can call the Enhanced Material Search:

Of course within the Enhanced Material Search you cannot create materials, add search results to the sales order or purchase order, because you are not really in a sales/purchase order. The Material Info parameters only simulate an order environment to get the information, not more

OK, how can I get the Material Info?

1. Activate the business functions in ERP 6.0 EhP5:
                       - LOG_MM_CI_3: for MM implementation
                       - LOG_SD_CI_02: for SD implementaton
                       - ISR_RETAIL_ENH_MAT_SEARCH (for SAP Retail; 
                         activates the MM and SD business functions above)
2. Implement the Sales Order Enhancement Series: The Material View and/or
3. Implement the Enhanced Material Search with Creation - Part 1: Overview, Enrichment of Search Results with Prices and Stock Availability (Enhanced Material Search with Creation - Part 2: Catalog Search for Supplier Products is optional)

Now you can use the Material Information application. That's it!

Enjoy and post your experiences with the Material Info!

Best regards,
Dr. Ingo Woesner

Product Manager
On Premise Suite Development
SAP AG

P.S. BPX articles about other Sales Order Enhancements are collected here:
Sales Order Enhancement Series: Overview

Please find an overview about some valuable blogs about Sales Order Enhancements here:
http://scn.sap.com/community/erp/sd/blog/2009/02/22/sales-order-enhancement-series-overview

Enjoy,
Ingo

Funtion modules for credit check:
SD_ORDER_CREDIT_CHECK-->for sales order
SD_DELIVERY_CREDIT_CHECK--->for delivery
SM_ORDER_CREDIT_CHECK-->for service order/CRM

1.Take sales order for example, set breakpoint at SD_ORDER_CREDIT_CHECK->
Enter a new item or change item quantity(cost) to trigger a new check

When FM is hitted, search for the coding for specific check, for example static check
->

* static check                                                       
   if no_check is initial.                                          
     clear rkvbuk-cmpsa.                                              
     if t691f-cmpaa eq true                                           
     and                                                              
     ( update      eq true or                                         
       t691f-cecki eq true or                                         
       t691f-strea eq con_error ).                                    
       perform static_credit_check using  update         <<<<<<<<Set here     

                                                xvbak-kkber                 
                                          xvbak-knkli                 
                                          flg_order                   
                                          flg_delivery                
                                    changing                          
                                      rc_check_a rc_check rc_warning  
                                      rc_error rc_status_set          
                                      rkvbuk-cmpsa.

xvbak-kkber                    1000          -->credit control area
xvbak-knkli                    0000001050    -->credit account
flg_order                      X

2.When above BP is hit, F5 to enter the Form for static check

PERFORM CREDIT_EXPOSURE_GET is to get the exposure
T691F-STVAW and T691F-STVLW are the "open order" and "open delivery" field in OVA8

SCC_OPEN_ORDER    -->open order value
SCC_OPEN_DELIVERY -->open delivery value
SCC_OPEN_INVOICE  -->open invoice value

3.PERFORM CREDIT_DELTA_ORDER is to calculate the current sales order value
Set BP at the next line after this Form and Press F5 to enter this FORM->

CALL FUNCTION 'MCV_STATISTICS_ORDER' -->FM for statistics update for order

SET BP at subroutine->
Program                       SAPLMCS1
Subroutine/Method/Module      OFFENE_WERTE_EINT

Then search for PERFORM cmpre_calculate(saplvkmp)-->program for credit price calculation

4.After CREDIT_DELTA_ORDER is complete DELTA_OEIKW is filled with current sales order

value, it is added to SCC_OPEN_ORDER(open order value)

SCC_SUM_OPENS = SCC_SUM_OPENS + SCC_OPEN_DELIVERY
                               + SCC_OPEN_INVOICE.

Open order, delivery and invoice value is summed up.

IF SCC_SUM_OPENS GT SAV_KNKK_KLIMK.
  PERFORM MESSAGE_EXCEEDED_VALUE USING SCC_FLG_ORDER SCC_SUM_OPENS.
  MOVE CON_RC_NOK TO SCC_RC.
ENDIF.

Then it is compared with the credit limit maintained in FD32.

If the open value is large than credit limit, message is issued to inform user that the credit check failed.
The message type depends on setting in OVA8.

If the issue occurs every time when creating sales document, then customizing setting should be checked first. Please use report check_cm in SE38 and refer to note 18613.typical questions:

Question 1: I didn't assign any credit control area for the payer, why the credit control area is determined for the sales order?
Answer: Please check steps 1-4 of note 18613. You may have maintained credit control area for the company code or sales area.
The priority for credit control area determination is->

1. Userexit->if not used
2. XD03->if blank
3. OVFL->if blank
4. OB38

Question 2: Why the sales order is not blocked although I get the information message saying "*** credit check: credit limit exceeded"?
Answer:Please check the setting in T-code OVA8.
Field "Reaction" and "Status/Block" must be set together.
If not, the sales order won't be blocked even when the credit check failed.

Question 3: What is the proper update group to be set in OB45?
Answer:Default setting for update group is 000012 (delivery-related billing)
Update group 000015 (only S067 will be updated: open delivery and open billing document value. This update group is relevant if the customer doesn't want sales orders to be relevant for the update. Do not use this update group with dynamic credit check since S066 is not updated)
Update group 000018 (only S067 will be updated: open delivery value and open billing document value. This update group is relevant for business processes without a delivery, for example third-party orders, credit memos...)

Question 4: I have set all the settings for credit check, however the credit value is not updated correctly, why?
Answer:The credit check and the update of the credit values are separate processes which are also controlled separately by the respective customizing:
1) credit check is controlled by transactions OVAK and OVA8. Relevant note 18613
2) update of the credit values is controlled by VOV7 or OVA7: "credit acttive" flag.

The 'Credit active' setting only affects the credit update of the SD credit values (open orders, open delivery and open billing documents). This flag has no control on the credit check. So if for an order type, there is no credit check in OVAK and OVA8 but the "credit active" flag is set for the item category, the order will update the credit values even if no credit check is performed for the  order.
If the flag "credit active" is not set, the system will not update the open credit values. On the other hand, the system ALWAYS updates the FI credit value 'Open receivable' when the billing document is transferred to Accounting. So, although you deactivated the "Credit active" flag in OVA7 or VOV7, such an item will increase the 'Open receivables' and thus the credit limit used when the corresponding billing document is posted to Accounting.

This is a blog redux from 2008 during which time I was finalizing a large Order to Cash (O2C) and Finance transformation for a global manufacturer.  While some of the topics and names (e.g. "SafeGuarding") have changed, a Solution Design Review (SDR) remains a very valuable offering for SAP customers to consider and I continue to have these discussions as a way to ensure SAP deployments are maintainable post-go live. - WDN

I’m fond of telling my clients that SAP is a vast, strategic technology platform whereby many business scenarios can be described in a variety of ways.  This is important for SAP as it allows a certain “creative freedom” of the software to address unlimited business needs in the global marketplace.

There comes a time, however, where it is important for an organization to define the best way to articulate its business inside the SAP environment.  This allows for an increase in maintanability once the system is implemented, reduction in overal total cost of ownership (TCO), and simplification of the architectural design.

One way to accomplish this is through a Solution Design Review (SDR) which SAP offers as a part of its Safeguarding® product offering.  Safeguarding® was introduced in 2004 as a way for SAP to understand more clearly how their customers were using the software platform and to provide feedback to the customer.  The net benefit to the customer, particularly in situations where the project is either internally realized or internally managed using contractor resources, is access to very senior and experienced SAP professionals (typically platinum consultants with multiple implementation experiences in a particular domain) on a time-bound, fixed-price exercise.

Not Consulting, Not a Service

Your SAP account executive will be the first to tell you that a SDR is not a substitute for consulting or integration services.  It is part of a product offering (Safeguarding®) which can be available to purchase similar to Value Engineering®, software, or maintenance. While there may be SAP professionals front-and-center during SDR activities, similar to maintenance it is a fee-based product offering.

Generally an SDR provides three particular areas of benefit during review activities:

1. A documented “snapshot” of the design of the system, regardless of its position in the ASAP methodology timeline.
2. Business community and executive level involvement to confirm or re-confirm the business outcomes of using SAP in the execution of business operations.
3. Alignment of technical and contractor resources in the design and realization of the system environment so everyone is “in the right seat, on the right bus.”

I recommend using SDR as a way to validate the business blueprint of a new system implementation or for a significant new set of capabilities to be added to an existing SAP environment.  As one CIO commented to me, “given the amount of money we are about to spend on realization activities, the cost of completing an SDR is a rounding error.” 

It also allows SAP as a software company to have a greater awareness of what business solutions and applications its customers are creating in the marketplace.  It creates a greater dialogue, in some cases where dialogue may have been missing or strained between new or long-standing customer project and SAP account teams.  SAP has a “vested interest” during this process, as it can provide documented comment on the risks and opportunities of a program moving forward after SDR activities are accomplished.

An Intensive Process – Not for Everyone

One of the characteristics of SDR that struck me was its similarity to quality assurance and risk audits.  For small and mid-size businesses the use of SDR is questionable.  Similar to quality audit processes, sometimes the commitment to the SDR process can be economically disadvantageous for a company to undertake as it has a noticeable impact to business resource availability.  However for large implementations where dedicated or partly-dedicatd staff are already committed to the SAP program, an SDR can be easily scheduled.  It is an intensive process divided into three activity sets:

1. Pre-review.  During pre-review activities, there is a kick-off workshop typically a full day, scheduled roughly 30 days in advance of the actual SDR.  Prior to this workshop the SAP SDR lead will outline the specific areas, both in terms of SAP function and customer business scenario, that will be included in the review.  During the kick-off workshop, the SAP SDR lead will review the business scenarios and functional areas, propose a basic framework for the review, and meet the relevant business and technical staff that will participate in review activities.  The SAP SDR lead will also review pre-work the program team will need to complete prior to the actual review, and a list of documentation required prior to and during the review.  The lead may also conduct specific interviews with key business and technical (customer and contractor) stakeholders prior to actual review activities.
   
   
2. Review.  The review can vary in length depending upon the nature of the solution considered, but generally allow for a full week (five business days) for the review. There can be multiple tracks of review activities, in one review recently the customer utilized a facilitative approach to have joint sessions of two operational solution reviews meet together in the morning and evening with breakout sessions specific to each operational solution review during the day.  Be prepared to review all business scenarios, including to-be processes, and specific functional expressions of those buisness scenarios.  Be prepared to “defend your position” when asked why the solution is to be expressed in a particular way in the SAP environment, and be prepared to hear of other ways based on the relevant expertise of the SAP SDR lead on how to accomplish program objectives.  At times this can become consultative between SAP and the customer, but the extent of that consultation will be limited to ideas and recommended areas to pursue that will be highlighted in post-review activities.
   
   
3. Post-review.  At the conclusion of the review, the SAP SDR lead and any SAP team members will provide a findings presentation of the review.  This findings presentation will generally provide overall comment and feedback on areas of maintainability and proficiency in the customer solution under review, with a summary as shown in .  It will also provide an action set of areas where the SAP SDR lead may feel are critical to address moving forward, including specific risks that should be addressed moving forward in the SAP program.  The final report typically will include these areas as well as areas to consider the future use of other SAP software capabilities that were not explicitly a part of the review.

From start to finish the SDR process can be completed within 30-60 days, so plan appropriately when to introduce and execute an SDR in the SAP program lifecycle.

Limitations and Expectations

Even for appropriately-sized programs, a SDR has its limitations and these limitations should be considered carefully before embarking on such a review.  First, SAP will only be able to comment with conviction on the use of SAP software.  If you are working in a heterogeneous environment with multiple applications running in multiple business operations or units, I recommend that you focus your expectations on how the SAP SDR team would best suggest you leverage the SAP software platform.  Second, an SDR is not a panacea for correcting a bad design or restructuring a poor SAP program.  While an SDR can, for example, call-out the non-standard use of standard SAP capabilities, the SAP SDR lead and team will not correct those deficiencies for you (remember, it’s not a substitution for consulting).  In fact the review could call into question the appropriate use of the SAP environment, so conducting the review earlier in the ASAP methodology program lifecycle is better than later.  Finally, an SDR is only as valuable as the information used during the activities.  If a customer witholds information, excludes key business stakeholders, or otherwise does not leverage the process accordingly, the review will demonstrate less value.  In these cases SAP SDR leads are pretty experienced and savvy, don’t be surprised if these shortcomings are actually noted in the final review presentation and report.

To Review or Not to Review

To restate my recommendation, an SDR is not for everyone.  It is time-consuming, intensive, and rigorous.  But it may be the insurance policy that an organization needs to commit to a significant undertaking, both from a stakeholder buy-in and from a technical quality assurance perspective.  In an age where most SAP program fail due to non-technical reasons, this may be a good insurance policy indeed.

the third-party order process overview

Third-party Order Operation Step:

1. Maintain Purchase information record in SAP ME11/ME12/ME13

2. Maintain Source List for Material in SAP  ME01/ME02/ME03

3. Create OR with sold to party as end customer   

• Item Category: TAS.
• Schedule line Category: CS
• A purchase requisition is automatically created in purchasing when you save the sale order to the database.
• In the sales order, you can make subsequent changes to the quantity and delivery date for a third-party order item. The changes you make are sutomaticalyy copied into the respective purchase requisition.

4. Realse the requisition ME28

5.  Create the Purchase order for the purchase requisition  ME58.

• When a purchase order is created, the system automatically adopts the address of the goods recipient from the respective sale order as the delivery address.
• The order text in the sale order for each item will be copied into purchase order.
• Third-party order items in purchase orders are marked with item category S.

6. Goods Receipt

• Logistics->Materials Management->Inventory management->Goods Movement ->Goods Receipt->For Purchase order->PO Number Known
• Since no goods flow takes place in your company, the goods receipt posting serves solely as a value update for your system.

7. Enter Invoice

• Path :Logistics->Material Mangement->Logistics Inoice Verification->Document Entry->Entry Invoice (MIRO)

8. Create the Billing

• Path: Logistics->Sales and Distribution->Billing->Billing Document-Create
• Document: Document number of the sales order
• As sson as the invoice receipt is recorded in the system, the customer is billed.

Customize Configure Step

1 Define Item Category

Item Category: TAS.

Billing Relevance: F

• If the billing-relevance indicator in Customizing is set to F, the system includes the order in the billing due list only when the vendkr invoice has been received and entered into the system.
• In the coping control for sales document to billing document, the standard setting for the third-party order item category defines that the quantlty from the invoice receipt document, not the order quantity, for example, is copied into the billing document(Billing quantity field)
• If you choose entry "B" instead of "F" for the relevance for billing, the order would be in the billing due list immediately following its entry.

2.Assign Item Categories

You can assign the item category group BANS("third-party item") to materials whose sales are processed soley as third-party orders.The item category assignment in the standard system triggers off automatic determination of the item category TAS.

3. Define schedule line category

Schedule line Category: CS

The schedule line category CS in Customizing does not contain a movement type and is not set as being relevant for delivery.

CS contain the specification of a document type for the purchase requisition (NB) , Item catagory ( 5 "Third-party")  and the account assignment category.

4.Assign Scedule Line Categories

5. Copying Control: Sales Documents to Billing Documents

Target:F2 -Source :OR

Choose Details for items Category TAS.

S060 Infostructure

Contains accumulated values from the rebate-relevant invoices created after the creation of the agreement.

When invoice is sent to accounting:

S060 is filled from XKOMV-KWERT (KWERT_K)

                                XKOMV-KAWRT (KAWRT_K)

Program: RMCSS060.

To rebuild S060: SDS060RB

See note 116638 Upgrade of info. structure S060 in Release 4.*

Info structure S136

filled when invoice is released

S136 is updated if condition is present in the document

S136 is used for drill down list in the new rebate procedure

Contains invoices which have a rebate condition set.

• to verify the table : se16 with the field KNUMH

                 xvake-knumh or KNUMH (find out Nr. in debugging)

• omo1 :                   update 1 synchronic

IF OMO1 >S136 is ACTIVE  it means you are using New rebate procedure.

Hi All,

when you have a dynamic Horizon in your credit management, the horizon period will be accounted if the line item's material availability date is within this specified Horizon Period. explained as below.

horizon Period : 1 month ( 30 Days from 29th July 2013, hence 30th August 2013).

Sales order with Requested delivery date : 25th September 2013.

lets assume that the material availability date for this sales order line is 29th August, as it was around 25+ days of route.

then on such cases this order will be relevant for credit management calculations as per the current date on 29th July.

Hence material availability date is the key parameter to decide on horizon period & not the customer requested delivery date.

There are instances when user wants to alter sale terms for a material. We can enable the user to enter quantity conversions directly in sales order by configuring relevant condition types. In V/06, go to Changes which can be made section for the condition type and choose Qty relation indicator. User will now be able to directly enter quantity conversions in sales order without maintaining the same in material master.  If sale unit is EA and user wants to specify price per KG, the same can be entered directly in sales order pricing without maintaining conversion in material master. Condition type has to be set with ‘No limitations’ or ‘Manual entry has priority’ along with ‘Qty relation’ as allowed.

I maintained EA as base unit of measure for material and Gross weight as 10 Kg. If I require to change my rate of conversion, I can do so directly in the sales order. I enter price per KG and System prompts user to enter conversions and user can specify, say 1 EA = 25 Kg.

However, there is little control over user input and this can lead to user errors. This can be used where both product pricing & packing is as per demand or sale conducted.

***

How Status Functionality in SAP helps professionals to control different activities:

• SAP status profile functionality which is basically a workflow enabled functionality
• Status profile is enabled by assignment to the sales order type (header level) or item category(item level)
• Every activity will be defined by status number
• With the help of the status number you determine the sequence in which the user statuses are activated.
• You can assign lowest and highest number to status number so that particular activity can work within that number
• you can track all activities performed for particular document based on updated statues
• it can also be used for reporting purposes.

How to configure status profile in SAP and enable for Sales documents:

1. Define Status Profile:

SPRO--------- Sales and Distribution---------- Sales >Sales documents ---------- Define and Assign Status Profile------------Define Status profile

2.Assignment of Status profile at order type at below path:

SPRO--------- Sales and Distribution---------- Sales >Sales documents ---------- Define and Assign Status Profile------------Assign order type/Status profiles

3.Assignment of Status profile at item category at below path:

SPRO--------- Sales and Distribution---------- Sales >Sales documents ---------- Define and Assign Status Profile----------- Allocate status profile to item categories

4.Set Status controls based on business requirements.

Go to Transaction control screen and enable below functionality

:

5.Enter Authorization code to change the status:

t-code BS02 can be used also

Details about User Status:

Status Number:

It is the number which is assigned per activity and it is unique to every status.

Status:

This is the text  which will flow to sales document once it is activated and update as per business activity mentioned in the configuration.

Initial:

whenever sales document is created by default this status will be activated to it.

Lowest Status No:

This will ensure that particular activity will be performed within this lowest number and once that activity is performed this will get deactivated.

Highest Status Number:

all activities will be performed till this number and it will block other activities or status updation having below status number than this.

Position:

it will give you at which place this status can be activated.

Priority:

if several status have same priority then status which has highest priority will have preference.

Step by Step usage of Status in Sales Document  status tab and approval process:

1.Based on initial Status ,order will have status A001 as per configuration

2.Update User exit logic based on business requirement and call function to change the user status and it will change to A002 as pending for approval

3.Use Authorization object to approve or reject, it will again call function to change the status as per maintained in the status profile and after approval it will change to A003

4.Once it is rejected ,it will have status A004 as below:

Conclusion:

• Status profile functionality is useful to track activities in a sequence and create workflow based approval process.
• Statuses can be used to control and communicate.  Statuses can be used in reporting.

• How to analyse the status during results analysis in tx. KKA3
• Although the status of sales order is completed, it still catched status REL as status for valuation method in KKA3.

Check it in sales order. Sales order is completed fully delivered, but system status shows: REL and not FNBL.

How to analyze it, what is the reason?

• In document flow status overview you can see already that the delivery status is not complete.
• Delivery status is "Being processed"

• Status delivery -> partially invoiced

An invoice was already created to the customer, but an other is missing. Which invoice and why it is missing? Check it in debugging mode and

set breakpoint to FM  SD_ORDER_GET_DATA :

Here you can see again, everything is invoiced. And fields ch_all_issued and ch_all_posted are getting value "X".

Where this value will be deleted and status FNBL is not set ?

• Here will be deleted, because the sales order is an intercompany scenario and IV invoice is missing !
• IV invoice status is not processed ("A")

• Where does da_intercompany "X" come from ?
• How can I analyze an intercompany process?
• Check table LIKP with the following selection fields:

Solution:

• Create IV invoice in this example, with company code "5100".
• Delivery will be full invoiced after that.
• Run tx. KKA3 again.

Question

Why Field WBS Element (COBL-PS_POSID) is not displayed at the Sales Order Line Item?

1. Go tx. VA02
2. Select item and go to tab: Account assignment

Reason and analysis

Once  the KZVBR is determined on sales order line item with 'E' so after entering the plant the field WBS element is not displayed.

Please check your customising:

1. In the sales order, check the requirements type (VBAP-BEDAE).

• Sales order (VA02) check requirement type on tab "Procurement" :

2. In OVZH, check the requirement class assigned to the requirements type.

3. In OVZG, for the requirement class, check the "Account Assignment Category" (V_T459K-KNTTP).

4. In OME9, check the "Consumption posting indicator" (V_T163K-KZVBR).

If you want the WBS element (COBL-PS_POSID) to be displayed in the sales order item, this "Consumption posting indicator" should not be E or P.

Summary of Transactions:

OVZI:  Assign the requirement type to the item category

OVZH: Assign the requirement class to the requirement type

OVZG: Customize the requirement class (select the Acct.assig.cat)

OME9: Customize the Account Assignment Category (select the  consumption posting indicator VBAP-KZVBR)

More information about account assignment you can read in SAP note:

459734:  How does the order account assignment work?

Scenario: Company ABC manufactures very high value equipments. these are sold across the country through their own dealer network. Dealers are free to place orders for any product and quantity. Company provides credit facility to dealers for buying equipment.

ABC Company runs its business on SAP which is used for procurement, production, sales and logistics activities, for dealers they have DMS system (Non SAP) which is use for Purchasing, inventory management, service and sales to end customers.

Sales Orders are created via. Interface in SAP from DMS. Delivery processing and shipping planning starts parallely, because of no credit shipping process should not stop. So update group 15 is used so that the deliveries are considered to calculate credit exposure. There is also a legal requirement to create one invoice per equipment.

Considering the above business requirement the IT team proposed to create delivery with one material and one quantity.

Now let’s see how to fulfill the business requirement in SAP.

Mostly deliveries are created using due list transaction here lets take example of VL10E.

Navigate to the below given path

Click on configure list profile copy 0201 and give a new name e.g. Z800

Make changes as above in red.

Change Cumul. Rule to 9 use exit LV50R_VIEWH19.

In user exit set the value of cf_kumng = 1

In Field “SplitSchedLine” set value to “1 Deliver only one schedule line”

(This will deliver only one schedule line for selected item e.g. for item 10 there are 3 schedule lines and when all three are selected for delivery, system will create delivery for the first schedule line out of all)

Once the delivery is created the cumulative quantity is set to original cumulative qty. as per order confirmation, so the log settings are changed to show on the same screen. Upon pressing any button the refresh will get activated and the exit is called again to set qty. to 1.

Now choose “Assignment of List Profile to Delivery Scenario” in IMG and assign as shown below

To have a split based on item number pass sales order item number (POSNR) to LIKP-ZUKRL in copy controls.

Handheld (legacy system ) to SAP  Sales Process overview

In today scenario we have many company using SAP for tracking SD (sales & distribution ) . SAP interact with Different Legacy system (non SAP) for normal process to intregate SAP and SAP or SAP and Legacy systems .

In a handheld scenario , we have Sales represenative ideally use a HH (handheld ) device to take on Sales order and Add basic master data like new customer for any route etc . The Handheld will provide mobility in terms of the sales representatives for different manufacturing / retails companies will goto any route and take up sales orders for the customers for any routes . In case they see and meet new customer who are willing to purchase or place and order . The sales represenatative will capture sales orders for these new customers also through HH . They would have shell customer or new customer template that they will map the new customers to . Once they are verified they will be authorized to bill and supplied their Order placed . Before authorization , to avoid duplicate Customers setup for any route , the customers are placed in a block and Sales order in SAP will have Hard incompletions .

Once the Sales order is saved in HH . The Sales Rep add these HH to network ports and do a send . Once the SO from the HH are put on service network , they all are saved in a flat file which is sent to SAP via Middleware . Once the flat file reached SAP , A customized program will break up these File into Inbound IDOCS and each idoc will create a Sales orders corresponding to the Flat file created earlier ( HH related Sales order created . )  . Since interaction is with legacy system and SAP . we do send an update as an outbound idoc to HH system again for the sales rep to be aware that the Sales order has been created in SAP also . This is done through an output from SO which send the idocs to HH system . this will ensure that idocs / SO are not missed inbetween SAP and HH system and a 2 way communication is set up correctly , as required .

HH devices can be configured to be more flexible to interact to SAP for more functions , as per business requirements .

when the sap system give us the message "VE217 Error in quantity/value determination"  of the VPRS, we can check the error according to the following master data and configurement:

1、Check whether the "Value and Quantity updation" of  “Material Type” has been set;

TCode:  OMS2- Value and Quantity updation have been checked

2、Check whether the "Determine cost" of  "Item category" has been set;

TCode:　VOV7- Determine cost had been checked in item category

3、Check whether the fields of conditon type VPRS have been set as the following;

TCode:　V/06

- Cond. class:----B

- Calculat.type:----:C

- Cond.category-------:G

- Qty conversion-------X

No access sequeance has been assigned to VPRS

4、Check whether the price of material has been maintained;

TCode:　MM03;

5、Chech whether the pricing procedure is correct;

TCode: V/08

VPRS has been mentioned as statistical condition, Subtotal- B and reqt-4 has been mainatined

6、Check the delivery plant of order has been input；

Relation notes:

381348 - Using user exit, customer exit, VOFM in SD

Requirement:

Solution:

Configuration:

OV3Z - Assigning Procedure to Information structure

OV4Z - Control Product Allocation

Other configurations needed are:

1. OV5Z – Consumption periods
2. OVZ0 - Activate Allocation for Requirement Class
3. OVZ8 - Activate Allocation for Schedule Line Category
4. MC61 – Create Planning Hierarchy
5. OV7Z - Generate Masking Character
6. MM02 – Assign Product Allocation Procedure on Basic
   Data 1 Tab

1. Preparation
2. Supplier Products / Long Tail product handling in SAP ERP(for professional sales reps and buyers)
   • Variant: using a central Supplier Product Data Provider(e.g. in a Cooperative Business / Franchise(ees) environment)
3. Supplier Products handling in SAP Retail InStore MIM(for occasional/remote users)
4. Long Tail business in a Web Shop using an SAP ERP Backend (for end customers and business partners)

Preparation: Supplier Products - Data Import and Management

Realization Concepts

1) Supplier Products / Long Tail product handling in SAP ERP

1. The user calls the Enhanced Material Search (EMS) function from within the SAPGui based order
   • SD: Sales Order va01, quotation, inquiry (from ERP 6.0 EhP2)
   • MM: Purchase Order me21n, purchase requisition me51n (from ERP 6.0 EhP5)
2. Within the Enhanced Material Search screen the user performs a search for supplier products (called "Catalog Search"). The Search Engine that holds the supplier products index provides the results back to EMS. Before the results are shown the EMS triggers an existence check in order to identify supplier products which are already maintained as master data, by comparing the search results with the information of purchasing info records in ERP.
3. The Catalog Search results are displayed. The users selects a search result line and presses the button "Create Material"
4. Based on the material creation method the EMS creates a material master with Basic Data, Sales Data (MVKE), Plant Data (MARC), a purchasing info record and (optional) carries out a pricing to calculate the sales price out of the purchasing price which was given in the search result. This is done either in the background within seconds (Simplified Material Creation method), or with a user interface allowing the sales rep to control and change fields manually.
5. A new material has now been created, has a material number and the user can order it like any other existing material.

1. The user calls the Enhanced Material Search (EMS) function from within the SAPGui based order
   • SD: Sales Order va01, quotation, inquiry (from ERP 6.0 EhP2)
   • MM: Purchase Order me21n, purchase requisition me51n (from ERP 6.0 EhP5)
2. Within the Enhanced Material Search screen the user directly presses the button "Create Material", without selectiong a search result.
3. A Material Creation UI is shown based on the EMS material creation customizing.
4. The user selects a vendor and some start parameters, enters the product data based on the EMS material creation customizing. At the end the user saves the new material.
5. The EMS creates a material master with Basic Data, Sales Data (MVKE), Plant Data (MARC), a purchasing info record and (optional) carries out a pricing to calculate the sales price out of the purchasing price which was given in the search result.
6. A new material has now been created, has a material number and the user can order it like any other existing material.

1. The user calls the Enhanced Material Search (EMS) function from within the SAPGui based order
   • SD: Sales Order va01, quotation, inquiry (from ERP 6.0 EhP2)
   • MM: Purchase Order me21n, purchase requisition me51n (from ERP 6.0 EhP5)
2. Within the Enhanced Material Search screen the user performs a search for materials (with material numbers, called "Material Search"). The Search Engine that holds the material index provides the results back to EMS.
3. The Material Search results are displayed. The users selects a search result line and presses the button "Create Material"
4. A Material Creation UI is shown based on the EMS material creation customizing.
5. The user changes the product data where it differs from the material used as template. At the end the user saves the new material.
6. The EMS creates a material master with Basic Data, Sales Data (MVKE), Plant Data (MARC), a purchasing info record and (optional) carries out a pricing to calculate the sales price out of the purchasing price which was given in the search result.
7. A new material has now been created, has a material number and the user can order it like any other existing material.

Variant of scenario 1: Central Supplier Product Data Provider

2. Supplier Products handling in SAP Retail InStore MIM

3) Long Tail business in a Web Shop

In export sales order, system does not block delivery even if sales order value exceeds license value. For example licence value is 6000. My sales order value is 7000. System still allows to create a delivery. Where as it should block for delivery.

You view the legal status in VA02 -> extras -> export license - > log

and the System status in Item -> status shows:

Overall status       Open

Reason for rejection

Delivery status      Not delivered

System status        REL  EXLS NoMP       <<<<<  system status Export control is there!

When an order fails the item user status id set to EXLS or FTC5.

But if you go to tx. BS23 and check system status: I0275 - EXLS (Export control)

Here you can see that to create Material purchase requisition, create delivery or a post goods issue is allowed and not forbidden.

It is the reason why you could create a delivery without any block.

Related function modules:   RV_EXPORT_CONTROL_DELIVERY

                                         RV_EXPORT_CONTROL

Hi All,

when you have a dynamic Horizon in your credit management, the horizon period will be accounted if the line item's material availability date is within this specified Horizon Period. explained as below.

horizon Period : 1 month ( 30 Days from 29th July 2013, hence 30th August 2013).

Sales order with Requested delivery date : 25th September 2013.

lets assume that the material availability date for this sales order line is 29th August, as it was around 25+ days of route.

then on such cases this order will be relevant for credit management calculations as per the current date on 29th July.

Hence material availability date is the key parameter to decide on horizon period & not the customer requested delivery date.

I am sharing my experience in dealing with many inconsistent issues, number range issues,
express document/update fails.

Sometimes user may come across a temporary or inconsistent short dump while executing a process step or a particular transaction.

These inconsistent issues impact completion of activity (can be test /support/implementation activity)

Below method supports to analyze such issues at an earlier stage &resolve the issue wherever possible at users end itself.

~ Detailed analysis of short dumps or runtime errors using transaction ‘ST22’ helps
in understanding & resolving the root cause of the issue by highlighting
problem triggering code line, tables & fields.

~ Based on the information available on short dump trigger point, user can navigate to the
relevant tables & find the reason for inconsistency.

~ If available, perform necessary customizing settings to rectify the issue.

There are two kind of inconsistent issues I have seen:

1. Issues which triggers dumps in ST22
2. Issues without triggering dump in ST22

Example: where dump is triggered in ST22

Delivery number not being updated at table level

In given example, user is trying to create a delivery in transaction ‘VL01NO’.
After entering all necessary data when user saves the delivery document,   a delivery number is assigned based on
number range configuration & a success message appears with delivery
number.

  However, in this particular example, on exiting the transaction a ‘Express information’ message appears with information “Update was terminated” which indicates that though a delivery number has been assigned to earlier transaction still the delivery doesn’t exist & the database is not updated with delivery information.

To analyze the issue, click on Inbox button, which navigates you to Business Workplace Inbox.  Look up the latest document with subject ‘Update was terminated’ & check the details relevant to update termination.

For detail analysis of the issue, run transaction ST22, select today’s dump & search
appropriate dump based on user name. Go to the Source code Extract:

As highlighted, choose the code line which triggered short dump. In this example,
the problem is occurring at the insert statement. You can discuss this with
your abaper too from here.

Based on the table information at problem triggering statement, check table VBPA, which stores the value with sales document number & partner function. In data browser, check the table entries for sales documents as highlighted.

The delivery document number which was assigned in earlier transaction & following
numbers are already available in database. This indicates, there was a duplicate insert happening in this transaction at database leading to generate a short dump/update termination message.

This clearly directs to the root cause of issue to be a customization issue having a wrong
number range customizing set up for the delivery document. Based on delivery type customizing, choose appropriate number range & update the number range status to most latest available number.

After correcting number range customizing for delivery, repeat steps for delivery
creation with same data. User will be able to create delivery documents successfully;
the delivery number will be updated in table VBPA.

The new Delivery has been created & saved in the table.

Example 2: when there is no dump in ST22

Change Pointer ID already Exist

In given example, user is trying to create a MPO (material Planning Object) in transaction ‘/ISDFPS/MPO’. After entering all necessary data when users save the document and exit the transaction. The termination pop up appears.

User does not find a log in ST22 as there is no short dump generated. In this case user
should check the SM21 (System logs).Double click on the system log and check the details for fail.

Navigate to transaction SM13 for more details

To find out the details of update termination, check SM13 (Update Requests)

Solution to correct this:  after searching with “Material_Write _Document” update fail, I
found a note: 1700295 which solved the issue.

Check the Number range for change pointers in transaction BDCP

The reason for update termination: Write Operation is failed. We can search with these search terms for Notes.

Similar sort of issue was occurring in transaction VK11 & it’s been solved in following discussion

http://scn.sap.com/thread/3278000