When I was doing access sequence configuration for the first time, I was confused by these condition table identified by number.

I would like to find out their corresponding transparent table without using Google.

clipboard1.png


Then I perform a ST05 trace for Access sequence configuration activity and find two series of table T681* and T682*.

clipboard2.png

In table T681 I find what I want: the field KOTAB stores the name of underlying transparent table to store records. Here field KVEWE A means Pricing, and KAPPL V means Sales & Distribution.

clipboard3.png

When changing sales document in transaction MASS with object BUS2032, it is not possible to change field "Ship-to Party's Purchase Order Number"

(VBKD-BSTKD_E) since the field is not defined in field list of the object.

 

Here, I would like to share a solution to solve this problem.

 

1. Call transaction MASSOBJ.

2. Highlight object type BUS2032.

3. Double click on "Field list(optional)" in "Dialog Structure".

4. nput "Work Area" from BUS2032 to BUS2032 then press "Continue".

5. Press "New Entries" button.

6. Input "ObjectType" BUS2032, "Table Name" MASSSDPOSVBKD and "Field Name" BSTKD_E.

7. Save.

 

After these steps, the field should be listed and can be used in MASS change.

 

Hope this information is helpful

The recognition as a Member of the Month took me by surprise, because it came at a time, when I almost stopped participating in the forum.


Now I feel that the right thing to do is to explain why and spoil the initial good impression.


The reason is simple - the decreasing quality of content in the forum space.


I will not discuss the topics about violating The Rules of Engagement - the moderators already do a really good job in keeping the forum clean.

This is about the things that will not result in thread rejection, but still make me close the tab without writing a response.

 

1. Title is important. Make it short and informative.

 

If you are new to SCN, it serves as your business card. Try to make a good first impression as a professional.

 

Don't copy/paste the whole main content as a subject title

 

You know how funny and cute 5 year-olds are, when they rush at you and start telling you a story from the middle?

Except that you are not 5, it is creepy when a grown-up tries to trigger nurturing responses with infant-like behavior, and it is sad that you skipped classes at school.

Yes. It looks that bad.

 

Poor choice of title:

Credit issue


You are either too busy to put an effort and explain the problem or you have no knowledge on the topic.

 

If the first is true - I would prefer to spend my time helping people who value my time as much as theirs.

In the second case - you did not follow the advice in 'The Rules of Engagement' to search before posting. What are the chances that you will take any of my advices - like "read carefully note xxxxx before you make any changes"?

 

Better:

Account balance difference in RFCORR40 


This shows that the OP has identified the issue, but has a problem troubleshooting it.

I could be wrong, but if I have the time, I would read further.

 

Even better:

Account balance difference in RFCORR40 even after balance carry-forward


It appears that the OP has tried to do some troubleshooting and understands the idea behind the report.

I would definitely read the details.

 

I will not spoil you with an example how an excellent choice of title would look like.

 

2. Addressing the audience.

 

Dear Sirs/Dear Gurus

 

I am not in the target group (obviously), but you are either making fun of the people, from whom you seek help (not a wise choice), or you are grovelling (unnecessary).

The best consultants/developers I have met, are highly resistant to such form of flattery, anyway.

And this is not because they are extremely modest or have reached some spiritual level, they simply realize that there is a lot more to learn.

 

If you wish to be treated with respect among professionals, you need to behave as a professional.

 

And if you cannot think of a better way to address the fellow forum members, you can safely omit this part and get directly to the point.

 

3. Main content.

 

Present the problem in a well-structured manner, use paragraphs and additional formatting to make the content more readable.

 

If you wish to bounce ideas for a new business process, describe it as a sequence of business steps.

Avoid using company-specific terminology or at least explain briefly the meaning.

If you do that:

a) you will avoid potential misunderstanding and

b) more people will read your complete post.

If this does not happen, you will get either no responses or low-quality ones, and you want none of these.

 

Don't just copy/paste your client requirements or urgent tickets and expect that people will do all the work for you (consultants).


If you don't try by yourself, you will always depend on the mercy of others and this would not work as a strategy even in a forum full of tolerant and helpful people.

I am guilty of having very low tolerance on spec-dumping, so I would need a compelling reason to "help the needy".

On the second thought - no, I won't do that, sorry. I prefer not to assist you in committing a fraud.

 

Problem tickets posted by end users.

 

I am always glad when an end user wishes to learn more about how things work and will do my best to explain you that "technical stuff" in business terms - you wish to become a better professional and I admire that.

This does not mean that I am willing to act as a free-of-charge help desk. Please contact your support consultant to assist you with solving urgent issues.

 

You company does not wish to spend money on proper support


It is a bad idea to give you an advice based on incomplete information and you can't give me all the details, because you have no authorization to view/change any settings.

Present a proper business case to your superiors, make them listen to your concerns!

When you spend your day on workarounds or manually fixing errors, they are losing money and market share.

 

You just don't get on well with your support consultant


Both of you get paid to do your job. Find a way to work together.

 

Don't ask for step-by-step guides with screenshots or demand to be spoon-fed.


I won't do that to my end users (I ask the key users to prepare end-user manuals, which I have to approve before they are distributed), why would I treat you differently?

Picturing somebody clicking in SPRO/SNOTE with little or no understanding scares me. Please do not do that!

Search the web, read sap notes, use your sandbox.

You would be pleasantly surprised how many of your colleagues would be willing to lend you a book if you ask them nicely.

 

You need help creating a new z-report and post the question here, because the development is SD-related


There are more developers in the ABAP forums working on SD reports than techno-functionals visiting the SD space.

You will increase greatly the chances of receiving helpful replies if you add the proper tags - and it takes less than a minute to do that!

 

Provide the relevant screenshots from customizing and the results of troubleshooting you have performed so far.


Example:


You face an issue with incorrect values in S066/S067:

Share your OVA8 settings and the result of CHECK_CM for a problematic document.

If you use non-standard item categories or document types, people will ask you for VOV7, VOV8, copy control settings.


You wish to get the problem resolved as soon as possible, why would you wait for a forum member to ask you for additional information?

 

Describe what you have tried so far/which notes you have read.


It is pointless that both of us spend time doing the same thing - you have already eliminated several options and, if you share these details, it would definitely speed up the investigation.

 

If you are not a native English speaker and struggle to describe the problem or cannot fully understand the responses.


If you can't get help from a friend/colleague/relative, list the languages, in which you can explain better.

If I happen to speak any of them, even if I am not an expert on the subject, I will do my best to help you as an interpreter via PM.

 

4. When you have not provided all the information I would need to investigate further.


You did your best, but still failed to see something obvious?

Don't feel bad about that - if you already knew that you have to check and provide information also on zzzz setting, you might have already solved the issue without my help.

This is why you posted here - to get a different view on the subject, isn't it?

 

Now here comes the really bad part.

 

Before I ask for additional clarification, I will have a look at your profile.

No, not the reputation tab - your points and badges are absolutely irrelevant in this case.

I will read your previous posts.


If it takes you a week or more to respond to requests for more information or provide feedback


I would have already forgotten what it was all about by the time you respond and will have to start all over.

If you feel comfortable with the idea to leave your customers waiting for resolution for weeks, then why would I push you?

 

If I see a long list of posts with multiple replies and some good suggestions, but none of them marked as helpful/correct


I would probably choose not to participate in your current discussion.

Don't get me wrong - I am not obsessed with getting these 5 or 10 points or acquiring a shiny badge.


C in SCN stands for community. You can't be a good member and just take without giving back.

If you don't have the time or knowledge or are too shy to post content and participate in discussions - I respect your decision.

This does not change the fact that you can still help - all it takes is to mark the posts, which helped you resolve the issue.

The next person who searches the forum would find your thread and try first the option marked as 'correct' before re-posting.


A thank you to the people who tried to assist you, even if you have solved the problem by yourself, is a nice touch. I will remember you being polite and will be even more inclined to help you in the future.

 

What has my previous behavior got to do with my current discussion/This is not fair/This is against ROE


Not much really (unless you believe that everything you do has consequences).

I have never said that it is.

Please read the disclaimer.

 

Disclaimer:

The content represents my personal view on the subject and does not imply or suggest that any other forum member would feel or react in the same way.

The aim of this blog post is not to berate or insult any SCN member, but to share some ideas on how to improve the quality of content posted in the SD space.

Even if you follow 1.-4. there is no guarantee that you will get even a single response. It could be that your question is really difficult to answer. Probably there are very few people in the forum still using BGADDON on 4.6. I wish I could help you somehow, sorry.

If you do the exact opposite of 1-4. you could get replies. There are helpful and generous people who may still choose to help, there are also point-chasers always coming to rescue. I don't belong to any of these groups and will ignore the thread.

The purpose of this Blog is to describe the Variant Configuration in Sales Order Creation. Before posting this blog, I have referred many SDN blogs, threads and other sites for any sort of help ....But no success.


Variant Configuration:

         

      It is a tool which helps to simplify the complex manufacturing of final product with more varieties and Variation of the input Material.


Example of industries relevant to SAP VC:  Auto mobile Manufacturing, Furniture Manufacturing, Aircraft Manufacturing, Personal Computers,Elevator Systems,Bicycle,Cars, Motor Cycles, Pumps etc.

 

Variant Configuration is for manufacturing complex products in which customer determines the features of the product and it also helps the customers or salespersons to put together specification for the product. Objective of variant configuration is to react quickly to customers’ requirements.

                   

         Here it needs not to create separate Material for each variant of a product. When companies introduce variant configuration this often goes beyond a business process re-engineering project.

 

Variant Configuration offers an opportunity to restructure product structures for which then processes are defined. This has a direct impact to the core areas such as marketing and product data management.


               Variant configuration is useful if you have large number of combination of parts that go into a product. It means different Permutations and Combinations of the parts for same material.

                   

For Examples:

  • In a business involving steel manufacturing, the customer may order steel involving different physical properties like tensile strength, diameter, colour etc.
  • A Customer ordering a Motor Bike can choose different combination of accessories and colour.

 

To define the features of a configurable material, you use Characteristics. To enable you to use Characteristics to configure material, you allocate the material to a class of class type 300. Each Configurable object must have a configuration profile. The configuration profile for a material controls the configuration process in the Sales Order.

                

          You use Dependencies to ensure that only allowed combination of features are selected. Dependencies also select exactly the right BOM (Bill of Material) components and operations to produce a variant.


I have a requirement to create sales order with variant configuration materials, in this scenario I am used function module BAPI_SALESORDER_CREATEFROMDAT2.


          The usage of this BAPI is very simple when used to create sales order that do not used configurable materials. But when it comes to creating sales order using variant configuration materials, the logic of filling the structures of this BAPI is a little bit complicated.


There is a SAP note 549563- BAPI: Filling configuration structures which explains how the Configuration structures in the BAPI need to be filled?


              For updating variant configuration (VC) data for sales order item, we need to populate below tables of standard function module or BAPI (e.g. BAPI_SALESORDER_CREATEFROMDAT2).


Sales Order Item Data


ls_item-itm_number       = '000001'.
ls_item
-po_itm_no        = '000001'.
"Should be fill this field
ls_item
-target_qty       = '1'.
ls_item
-material         = 'MAT12'.
APPEND ls_item TO lt_item.


Why the PO_ITM_NO field should be filled because the field POSEX (PO_ITM_NO) to define the connection between the sales order item and the configuration (BAPICUFG-POSEX) (ls_item-po_itm_no = w_sales_cfgs_ref-posex).


     If the item number is 000001, for example ls_item-po_itm_no = 000001 and ls_itemx-po_itm_no = 'X'. so that the configuration is called.


Sales Order Item Data Flags


ls_itemx-itm_number           = '000001'.
ls_itemx
-po_itm_no            = 'X'.
ls_itemx
-target_qty           = 'X'.
ls_itemx
-material             = 'X'.
APPEND ls_itemx TO lt_itemx
.


Schedule Line structure


ls_schedules-itm_number = '000001'.
ls_schedules
-sched_line = '0001'.
ls_schedules
-req_qty    = '1'.   
ls_schedules
-req_date   = '20160120'.
APPEND ls_schedules TO lt_schedules
.


Fill schedule line flags


ls_schedulesx-itm_number      = '000001'.
ls_schedulesx
-sched_line      = '0001'.
ls_schedulesx
-updateflag      = 'X'.
ls_schedulesx
-req_qty         = 'X'.
ls_schedulesx
-req_date        = 'X'.
APPEND ls_schedulesx TO lt_schedulesx
.


The Mandatory Structures filling for Variant Configuration in BAPI are:


    1. ORDER_CFGS_REF
    2. ORDER_CFGS_INST
    3. ORDER_CFGS_VALUE
    4. SALES_CFGS_VK


ORDER_CFGS_REF and ORDER_CFGS_INST tables should have one record per item and combination of CONFIG_ID and ROOT_ID should be unique across line items.


* Filling Configuration Reference Data SALES_CFGS_REF Table
w_sales_cfgs_ref
-posex      = '000001'.”ItemNumber
w_sales_cfgs_ref
-config_id  = '000001'.
w_sales_cfgs_ref
-root_id    = '00000001'.
w_sales_cfgs_ref
-complete   = 'T'.                “GeneralIndicator
w_sales_cfgs_ref
-consistent = 'T'
.  

   APPEND w_sales_cfgs_ref TO lt_sales_cfgs_ref.
CLEAR w_sales_cfgs_ref.


* Filling Configuration Instances SALES_CFGS_INST Table
w_sales_cfgs_inst
-config_id       = '000001'.
w_sales_cfgs_inst
-inst_id         = '00000001'.
w_sales_cfgs_inst
-obj_type        = 'MARA'.
w_sales_cfgs_inst
-class_type      = '300'.
w_sales_cfgs_inst
-obj_key         = 'KL'.         “MaterialNumber
w_sales_cfgs_inst
-quantity_unit   = 'LF'.
APPEND w_sales_cfgs_inst TO lt_sales_cfgs_inst.
CLEAR w_sales_cfgs_inst
.


ORDER_CFGS_VALUE and SALES_CFGS_VK tables we can have multiple characteristics for a material, in that case appropriate records should be inserted and combination of CONFIG_ID and ROOT_ID should be unique across line items.


*Characteristics Values Filling

* ColorCode
ls_sales_cfgs_value_in
-config_id = '000001'.
ls_sales_cfgs_value_in
-inst_id   = '00000001'.
ls_sales_cfgs_value_in
-charc     = 'ZCOLOR'. “Characteristic Name
ls_sales_cfgs_value_in
-value             = 'CHBC'.   “Characteristic Value 
APPEND ls_sales_cfgs_value_in TO lt_sales_cfgs_value.
CLEAR ls_sales_cfgs_value_in
.


* Gauge
ls_sales_cfgs_value_in
-config_id    = '000001'.
ls_sales_cfgs_value_in
-inst_id        = '00000001'.
ls_sales_cfgs_value_in
-charc          = 'ZGAUGE'.        “Characteristic Name
ls_sales_cfgs_value_in
-value          = '24'.           “Characteristic Value
APPEND ls_sales_cfgs_value_in TO lt_sales_cfgs_value.
CLEAR ls_sales_cfgs_value_in
.


*---Filling Configuration Variant Condition Key SALES_CFGS_VK

* ColorCode
         ls_sales_cfgs_vk-config_id    = '000001'.
          ls_sales_cfgs_vk-inst_id        = '00000001'.

           ls_sales_cfgs_vk-vkey           =  'ZCOLOR'.               “Characteristic Name
APPEND ls_sales_cfgs_vk TO ex_cfgs_vk.
CLEAR : ls_sales_cfgs_vk.

 

* Gauge
ls_sales_cfgs_vk
-config_id       = '000001'.
ls_sales_cfgs_vk
-inst_id          = '00000001'.
ls_sales_cfgs_vk
-vkey             = 'ZGAUGE'.    “Characteristic Name
APPEND ls_sales_cfgs_vk TO ex_cfgs_vk.
CLEAR : ls_sales_cfgs_vk.


Finally call your BAPI


  CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'
EXPORTING
      order_header_in    
= ls_header
      behave_when_error  
= 'P'
IMPORTING
      salesdocument      
= lv_vbeln
TABLES
     
return                                  = lt_return
      order_items_in     
= lt_item
      order_items_inx    
= lt_itemx
      order_partners     
= lt_partner
      order_schedules_in 
= lt_schedules
      order_schedules_inx
= lt_schedulesx
      order_cfgs_ref     
= lt_sales_cfgs_ref
      order_cfgs_inst    
= lt_sales_cfgs_inst
      order_cfgs_value   
= lt_sales_cfgs_value
      order_cfgs_vk      
= lt_sales_cfgs_vk
.


It will very helpful for those, who are struggling with Variant Configuration while creating a Sales order using BAPI.


Thanks,

Harikrishna          

Srinivas Kari

Item Proposal

Posted by Srinivas Kari Dec 8, 2015

Hi,

 

I decided to start my blogging journey with Item proposals. Kindly forgive if there are any mistakes.

 

Definition: An Item Proposal is a list of frequently Ordered Materials and Order Quantities.

 

Usage: Saves Order Entry time and effort

 

Path: Logistics -> SD -> Master Data -> Products -> Item Proposal -> Create

 

T-Code: VA51 - Create

             VA52 - Change

             VA53 - Display.

 

Steps for creating and assigning Item proposal.

 

1. Creating Item Proposal

  •      Initial Screen VA51 - Enter Doc type (Ex MS) and Sales Area
  • Overview Screen - Enter Description, Materials and Quantities
  • Click on Save button
  • Note the Item Proposal Number

 

2. Assigning the Item Proposal to CMR

  •     XD01/02 Sales View

 

3. In the Sales Order enter Customer Number and click on Item Proposal Button. Then specify the item Proposal number and press enter button.

 

For the materials which must have a default quantity in the sales order, create a item proposal condition record.

 

Steps:

1. Creating Item Proposal:

     Go to VA51 - create item proposal:

     va51.PNG

Enter Item Proposal Type (ex MS) and Sales Area.

Press Enter.

 

2.PNG

 

Enter Material Numbers. Enter quantities.

Click on Save button.

 

3.PNG

2. Assigning Item Proposal to CMR:

     Go to XD02, select the customer for which you want an automatic item proposal.

In case you have a lot of customers, you can do this via MASS to update multiple customer master records at the same time.

 

4.PNG

Enter Item proposal item number.

Click on Save.

 

3. Create Sales Order:

 

     5.PNG

 

Create a standard order. Enter the customer number.

Click on Item Proposal Icon:

 

6.PNG

 

There are 3 options:

     Option 1: Press Enter button / Default with quantity.

 

7.PNG

System copies all items and quantities from Item Proposal.

 

Option 2: Default without quantity:

 

       System copies all items only and not quantities from Item Proposal:

9.PNG

 

Option 3: Selection List: The system displays the list of items in the item proposal and lets the user select which materials to copy and how much quantity each material should have:

 

In this example, I have changed Item proposal record 50000033 (VA52) and added two materials to be proposed:

13.PNG

 

The user can select which material should be copied (checkbox on left) and how much quantity should be copied.

For example, I am going to de-select material 100-300 and change the quantity for 350-120 to 50 L:

 

14.PNG

Click on copy Quantities:

 

If you click on copy Materials, only the materials will be copied, not their quantities

15.PNG

Press Enter

16.PNG

The list of materials and their quantities as selected in the previous screen are copied into the sales order

 

 

 

The user can manually change the materials and quantity in the line item:

8.PNG

 

Save the Sales Order.

 

Item Proposal Configuration:

17.PNG

Creating tax groups can be very useful to handle the tax calculation in Brazil for different taxes (on Sales Orders, PO's and etc) , such as ICMS, IPI, PIS, COFINS, ISS, Tax Substitution, Withholding taxes and etc.
As taxes rates, bases and other taxes matters are very dynamic in Brazil, you will for sure need to have tax groups maintained in your SAP.

First you have to create the tax groups, then go to transaction J1BTAX (or you can go to SPRO - Financial Accounting (New) - Financial Accounting Global Settings (New) - Tax on Sales/Purchases - Calculation - Settings for Tax Calculation in Brazil - Tax Rates -Define Tax Groups for Dynamic Exceptions)

J1BTAX

Then, select the Country BR

Country BR

At J1BTAX, go to Menu: Tax Calculation - Maintain Tax Group

Maintain Tax Groups

Before you select “New entries” let me explain what those fields on J_1BTXGRUOP means:

Tax Groups

In the Red Box – TAX GROUP – You can define groups in the range from 10 to 89. The numbers between 0 and 9 as well as between 90 and 99 are reserved for SAP. These groups should not be deleted. SAP delivers the groups 1, 5 and 97 to 99.
When looking for a tax dynamic exception, SAP will start from the smallest Tax Group to the Higher and stop searching then the 1st combination is found. Take this in consideration, building your groups from the most complex (smallest groups) to the less complex (higher groups)

The table below explains the usage of the tax groups delivered by SAP:

Tax Group Usage
1 MM: ICMS base reduction carrier
SD: ICMS base reduction customer
ISS rates (material-dependent)

5 ICMS, IPI, S.T. material-dependent exceptions
MM: ISS exceptions (dependent on ship-from, ship-to, material)

97 SD: IPI tax laws (based on NCM code)

98 IPI standard taxes (based on NCM code)
SD: IPI tax laws (based on country)
ICMS standard tax rates (based on ship-from and ship-to)
S.T. standard tax rates (based on ship-from, ship-to, S.T. group)

99 Default taxes (based on country)
SD: IPI tax laws (based on tax code)

In the Orange Box – TAX GROUP FIELDS 1, 2 and 3 – You can use between none and 3 possible keys combination to build the tax exception. The fields that are available are:

ASNUM- Service Number
MATNR- Material
NBM- NCM Code
MATKL- Material Class, Material Group
MWSKZ- Tax Code
LIFNR- Vendor
KUNNR- Customer
BRSCH- Industry Sector
CITYC- City Code
OIHMTXGP- Tax Group (Oil)
OIHVGROUP- Customer Tax Group (Oil)
OIHCGROUP- Vendor Tax Group (Oil)
USAGE- Tax Calculation: Material Usage
LOC_PR- Location of Service Provider
LOC_SE- Location of Service Provision
LOC_SR- Location of Service Customer
BUKRS- Company Code
WERKS- Plant
MTUSE_MARC- Material Usage (Material Master Record)
MTORG- Origin of Goods
CNAE- CNAE Code
CRTN- CRT Number
ICMSTAXPAY- ICMS Tax Payer
INDTYP- Industry Main Type
TDT- Tax Declaration Type
COMSIZE- Company Size
DECREGPC- Declaration Regimen for PIS/COFINS
LEGALNAT- Legal Nature
EXTWG- External Material Group
PRDHA- Product Hierarchy
GPART_KK- Business Partner Number

In the Green Box – CALLING APPLICATION – The ones that are valid for using are:
SD Sales and Distribution - it means that the exception will be valid only for the SD applications, like Sales Orders or Billing Documents for Example.
MM Material Management - it means that the exception will be valid only to the MM applications, like Purchase Orders or Invoice verification.
General - it means that, no matter if it is MM or SD, the exception for this group will be applied.

In the Blue Box – TAXES CHECKBOX - Here you select what are the taxes that the tax group can be used for a tax exception.

The screen above is just one example. You have to figure out with your tax department what would be the best combination to the key fields.

To create a new group, hit “new entries”:
New Entries Tax Groups

Map tax Rate tables to Cond. Tables
Once you have created the tax groups you have to assign tax groups to the condition tables. Go back to the J1BTAX main screen and then to the menu Condition Setup - Condition Mapping - Map tax Rate tables to Cond. Tables:
Map tax Rates to Condition tables

When you maintain Brazilian tax tables, the system generates or changes condition records automatically. In this activity, you specify which condition tables are to be used for a specific tax table. In the case of dynamic exceptions, you additionally specify the condition table per tax group. The system then knows for which condition table (which must be contained in the access sequence) condition records are to be generated.

The assignment of tax tables to condition tables is done with reference to a tax group for: dynamic exceptions for IPI, ICMS and Sub.Trib.; always for ISS, PIS, COFINS and withholding taxes.
Tax rate tables Tax Condition tables

* SAP does not deliver standard Customizing of dynamic tax exceptions. If you create new tax groups, you must specify a new entry for each group you use. In SAP’s standard concept, the condition table is the same for all tax groups. However, in case you need to follow a different concept of Customizing access sequences you can specify different condition tables per tax group. We recommend staying with the standard concept of one tax group per table.

** You can find these entries in the overview page of the Tax Manager’s Workplace (transaction J1BTAX). There you define tax rates for several kinds of taxes.

Let’s take a practical example on how to fill the J_1BVIEWMAP table:
I created the tax groups and I did select 9 of these groups to be relevant for COFINS Values Dynamic Exceptions:
Tax Groups CheckBox

Then, I created 9 entries to map the Tax Rate tables to the Condition tables, each one representing one tax group. You will notice that, the tables that has no tax group assigned, they will have one entry each table and they never change.

Every time when a new tax group is created and if the COFINS checkbox is selected, a new entry has to be created as below:
J_1BVIEWMAP

This idea is valid for all the following tables:
J_1BTXCOF –COFINS
J_1BTXIC3 – ICMS
J_1BTXIP3 – IPI
J_1BTXISS – ISS
J_1BTXPIS – PIS
J_1BTXST3 – ST
J_1BTXWITH - WHT

That means, if you have the check box activated to the taxes above, you will have to create one entry to each tax group in this table assigning the table name to the tax group and the correct condition table (349, 346, 382 and so on).

Migrate Tax Groups in Access Sequences
Now it is time to Migrate the Tax groups that you created into the access sequences.
Using the method of Tax Calculating via condition based (CBT), every time a new tax group is created, it must be added in a certain access sequence, automatically by the system through the transaction J1BTAX. The same should occur whenever changes are performed in the tax groups, or even it is deleted.

Go back to J1BTAX main screen and reach the menu: Condition Setup - Migration - Tax Groups in Access Sequences

On the program selection screen, you enter the tax group that you want to include in the update. You can simulate the results of the program by setting the Simulate Only indicator. This is extremely important, since the program makes cross-client changes to your data.

Additionally, you need to specify what type of conversion is to take place:
a. Update access sequences - if you want to update existing steps in the access sequences
b. Insert into the access sequences - if you want to include new steps in the access sequences after creating a new tax group
c. Delete from access sequences - if you want to delete existing steps from the access sequences

If you are creating all groups at once, it is easier select the range from 10 to 89 and you may want simulate first, just to make sure that there are no errors.
Tax Group Into Access Sequence

If it is all green, that means can run without the “simulate” check box active and the tax groups will be added to the access sequences:

You can use the report J_1B_EXT_ACC_SEQ to automatically update access sequences after you have created or changed tax groups for dynamic exceptions. You need to be authorized for cross-client Customizing if you want to modify the access sequences. It is important that you ensure that tax groups are not customized differently in different clients because with each conversion to access sequences, the previous Customizing settings will be overwritten.

The should looks something like this:
Migration Access Sequence results

The result of the run above, is that all access sequences will be updated automatically, check for example below where the different tax groups were added to one specific access sequence:
Acess Sequence MM

Migrate Tax Tables to Conditions
Now you have to migrate the tax tables to conditions to create the condition records. Go back to J1BTAX main screen and reach the menu Condition Setup - Migration - Tax Tables to Conditions. This is the execution of the program J_1B_MIGRATE_TAX_RATES.
Migrate Tax Tables to Conditions

First you have to select the application:
- TX (Material Management)
- V (Sales and Distribution)

Then you will have to select the the Conversion Options:
- Overwrite existing condition records
- Ask in case of existing condition records
- Never overwrite existing condition records

And then finally select the tables, one by one to run the migration.
Note that, the tax groups that you selected as MM will be the only ones that you will be able to run to the application TX and the tax groups that you selected as SD, you will have to run to the application V. the ones that are general, or the tables that has no Tax Group, you will run for both (some exceptions apply).
Table Migration Select Table

The result will be something closer to the screenshot below:
Result of Taxes Migration

Leandro da Pia Nascimento

After several years as a SAP consultant, sometimes I find myself guilty of trying to tackle a seemingly difficult problem by first going through SAP notes, then searching the online documentation and checking SMOD for a possible solution. Back in the days, when I did not have any previous project experience, armed only with the .CHM SAP help version, I might have handled the situation differently and surprisingly – better. It may seem illogical at first, but gaining more experience could act as a ‘blind spot’ and instead of going through SPRO and master data (as you probably did as a junior), you find yourself rushing to an ABAPer with a new development specification, which looks stunningly similar to the specifications you wrote during your previous 5 projects.

 

Returnable containers exchange, which I will use as an example, is a very common scenario in the beverage business. In some companies it is realized by complex developments, in others – it is left out as a purely manual process. There is a good reason behind each of the possible methods – external systems involved, agreed project scope and budget, availability of resources, project deadlines, the level of process standardization in the company, the possibility of change management and so on.

 

There is also this really simple and cheap alternative that a junior consultant could have come up with.


A junior consultant does not refer to the person’s position neither implies inferior skills – it describes a person who is relatively new to a certain area.


Business case:


The usage of refillable containers for produced products in beverages industry has not only environmental benefits, but also substantially reduces the costs-per-filling compared to one-way RGB bottles, one-way PET bottles, carton packaging.  In case a product in returnable container is sold, the company charges a deposit to the customer, which is returned on receiving back the empty containers. A very common business practice is after the initial delivery to establish a process where the customer returns the same quantity and type of empty containers as the quantity of purchased products.

 

Benefits for the producing company in RC exchange scenario:

  • Timely collection of containers which can be used for further refilling;
  • Reduction of transportation costs (the empty crates when returning from customer visit occupy the same space as the delivered FG).

 

Benefits for the customer:

  • After the initial delivery he is basically charged only for the ‘liquid’. Deposits from customer’s perspective are money that he cannot use for investing in his own enterprise.

 

Challenges:

 

If the company is not able to deliver the FG on time (insufficient stock or temporary credit issue) no separate visits for empties collection and for FG delivery should be scheduled – the current order should be fully rejected and a new order for empties return should be created and planned (as a part of the order cleaning procedure). The reason behind the decision for no separate visits is to have a better utilization of truck capacity and lower transportation costs.

The company needs to track the containers per type both by value and quantity for each domestic customer and to be able to perform reconciliation between the quantity and value of the containers and the balances on the deposit account/accounts. 

This idea aims to minimize the effort in ERP during order entry and route settlement process and to cover most of the described company requirements without an additional development.

The purpose of showing some of the customizing settings is not to create a general ‘how to configure the process’ and there are no revolutionary discoveries presented (you would not expect too many revolutionary discoveries from a fresher, anyway). They simply illustrate what you can achieve by applying some basic SAP knowledge in a slightly different manner to address a customer requirement – something that a junior consultant could do.

 

Setup for standard sales order


Item categories:


Item category of the main item (FG)

Notable fields: the item is pricing and billing-relevant, schedule lines allowed = ‘X’, credit active = ‘X’, structure scope = ‘B’ and application = ‘SD01) (I will use multi-BOM explosion and sales BOM); create delivery group = ‘A’ (to ensure that both implied and returned empties are kept together).

image001.jpg

Schedule line assignment = ‘CP’.

 

Item category for the implied empty:

image002.jpg

Important fields: the item billing relevant, pricing for empties, credit exposure should be updated, schedule lines are allowed.

Assignment to schedule line = ‘ZX’ – no goods movement, no ATP, no requirements transfer, relevant for delivery. The item is used to collect the deposit and track empties at the customer’s premises. The goods issue for implied empties is performed during production order confirmation.

 

Item category for return empty:

image003.jpg

Notable fields: pricing for empties, no weight/vol. relevance, billing-relevant, schedule lines allowed, returns = ‘X’, update credit exposure.

Incompletion procedure assignment: copy of 20 without weight checks.

Schedule line assigned = ‘DN’ (movement type 651, no ATP, no requirements transfer, relevant for delivery).

 

Item category assignment:

image004.jpg

(ZARN is used for BOM-relevant products with % discount based on manual setting of KVGR1 to a specific value).

 

Pricing:


Main item – relevant for base price, discounts, VAT.

Implied empty – relevant only for deposit, value collected in CMPRE.

Return empty – also relevant for deposit, value collected in CMPRE.

Pricing requirement for deposit condition – checks for pricing relevance = ‘A’ (to be on the safe side).image005.jpg

Credit management settings:

image006.jpg

Delivery item categories specifics:


Main item: relevant for picking, determine storage location, storage location required, check quantity 0, check over delivery dismissed with error.

Implied empty – no storage location required, no picking relevance, check quantity 0 and check over delivery dismissed with error.

Return empty – determine storage location, storage location required, check quantity 0 and check over delivery dismissed with error, not relevant for picking.

Copy control VTLA, VTFL for all item categories.

The tracking of returnable containers is achieved by using empties update functionality in billing.

Prerequisite: you need to have EA-CP active in SFW5 to use empties update.

The settings relevant for the process are in SPRO->Sales and Distribution->Billing->Empties Update.

 

Empties management settings:


  1. Material types that determine empties – set the material type used for RC (in the standard system this is LEER, in my case this is a separate material type for non-valuated materials with quantity update for the valuation area).
  2. Billing types without empties update – maintain all proforma types and intercompany billing types to avoid incorrect empties movement registration.
  3. Maintain empties account holder – SAP suggests a choice for account holder between payer, sold-to, ship-to, bill-to party as account holder, but it is also possible to set a custom partner function and in this way to be able to group several customers for reporting purposes. I chose to use 3A – Customer chain, which I have set up as a level in the customer hierarchy. This partner function is transferred to the respective sales document types.

image007.jpg

Log empties update – a useful feature to track each step of empties update in a greater detail during the test phase. It should be switched off for productive environment. The log is in table /BEV1/EMLGFS:

image008.jpg

4. Manage empties fields – the defaults provided by SAP are sufficient for most companies, but in case you have a requirement for a more detailed reporting, you can use additional quantity and value fields.

image009.jpg

5.  Calculation matrix for empties – this is where the main logic for empties balance is defined. It is extremely important in case you define additional empties fields to update them correctly into the respective formula, otherwise it will be impossible to perform reconciliation between the empties register and the deposit account balance.

image010.jpg

6 Assign item categories for empties – settings for the exchange process:

image011.jpg

Here only the assignment for some of the item categories for the process is displayed– you also need to assign the item categories for debit/credit memos (only for value fields update), free deliveries and returns to get an accurate representation in the empties register.

7. You can maintain empties groups in case you wish to group several materials with the same deposit price for reporting and printing purposes.

 

How empties management works?

 

Empties update is performed at the time of billing document generation, when certain requirements are fulfilled.

  1. The billing type should be relevant for empties update. If it is not relevant for update, the billing document is stored in table /BEV1/EMLOGFS with LGOF = ‘F’ – suppression of update using billing type.
  2. The partner function for account holder should be present in the billing document. In case of missing partner function the document is recorded in table /BEV1/EMLOGFS with LGOF = ‘P’– suppression of update as partner not found.
  3. It is possible to restrict empties update for a specific customer by setting the indicator Empties Update from = ‘X’. Such billing documents are recorded in /BEV1/EMLOGFS with LGOF = ‘D’– suppression of update using indicator on customer.

image012.jpg

 

4. The material type of the item should be specified as empties material.

5. The item category for empties should be assigned to the fields for quantity/value.

When all of the prerequisites are fulfilled, the billing document items containing empties are stored in /BEV1/EMLGBDP with the Q and V fields updated with the logic from the empties matrix and the pricing data of the document, reference documents for the billing, billing date etc.

In addition the data from V and Q fields is stored in aggregated form in /BEV1/EMLGBSD – per account holder, month and material number. It is used to prepare empties balance confirmations for the customer and for internal reporting purposes.

Calculation example:

  image013.jpg

ZAR is excluded from the calculation based on material type.

ZAI and ZRU are checked against the assignment to empties fields.

ZAI should update Q1 and V1.

ZRU should update Q2 and V2.

Q1, Q2, V1 and V2 are part of the formulas defined in /BEV1/EMMATRIX_V (calculation matrix for empties).

ZAI updates V13 – difference del./returned value

As V13 is part of the calculation of V14 – individual price /vs quantity, we are updating it as well, similar logic for V16 – total value for delivered empties in the new period.

ZAI also updates quantities – Q13 for calculating difference between returned and delivered,

Q16 total delivered quantity for the new period; it influences the result in V14 (also in the quantity part of the calculation).

Result in /BEV1/EMLGBWDP for RECHNR = billing document number:

  image014.jpg

In addition to the empties account holder number, the payer, ship-to and sold-to parties are also recorded in the table, which allows performing also detailed analysis for empties transfers.

Updates in /BEV1/EMLGBSD:

For each combination of empties partner, sold-to, ship-to, bill-to, payer and material number for a specific sales area a separate line is recorded per period (MMYYYY).  There are separate V* and Q* fields for the balances of the old and new period. My customer is a new one, so I have zeroes for the old periods (non-zero values only in TO* (total) and BN* (new balance) fields:

  image015.jpg

Note: Empties tracking in general will not work very well with the standard approach for Advanced Returns Management, since it relies on billing documents for empties register updates. Still it is possible to record the returned containers by using a dedicated billing type without FI postings (with the assumption that ARM is used as originally intended – returning of products  from the customer for the finished product (e.g. due to quality issues) and not for value adjustments of the returnable containers).

 

Empties management functionality observations

 

The good part:

It is extremely easy to set up empties management update in SD and fulfill the customer requirements – you need:

  • to understand the different properties of item categories in the sales processes (basic SD knowledge);
  • knowledge of basic arithmetic operations (skill obtained during 1st -2nd  grade at school)
  • only the standard authorizations granted to functional consultants.

A nice ALV report for empties balance (most users prefer this type of representation).

Balance confirmation printout - SAPScript is delivered by default, it is technically possible to use a smartform or a PDF form as well for empties balance confirmation (with an additional development).

Archiving functionality is provided.

It is easy to correct the empties balance in case the reason is a missing partner or incorrectly assigned/not assigned item category.

Despite what the name suggests, you can use this functionality to track not only returnable containers, but also all kinds of fixed assets at the customer’s premises without having equipment master data in the system.

 

The bad part:

The idea behind and the functionality for empties tracking is good, but does not have the look and the feel of a finished product. While most of the customers’ requirements could be covered by what is provided as standard, it would be good to have the option to switch on logging of empties update for a specific partner in the productive environment without flooding the database with thousands of records for all other partners (when you cannot reproduce some issue in the development client).

You cannot get empties update for NLCC originating documents per empties code without an additional development (because PO/STO BOM explosion is not provided in standard). It seems a strange design decision to deliver a sample BAPI for BOM explosion with hardcoded account assignments instead of providing some customizable logic that can be used out-of-the-box.

 

The really bad part:

In case you need to change empties calculation matrix after the initial implementation in the productive environment, the process is extremely difficult (when it is possible at all), not straightforward (you have to figure it out by yourself considering what you change, when-number of documents affected, archived data, usage of balance confirmations, what is the current and the future setup). Even SAP advises not to do that, because this will cause inconsistencies in the database.

In the unlikely (or not so unlikely, judging by the number of notes and available correction reports) event of corruption of the empties tables, the reconstruction process takes a lot of time, involves running several reports in a certain sequence with specific selections, you have to ensure that no empties updates occur in the meantime (this essentially means to stop all billing activities, which is considered as a serious business disruption).

605075 - Documentation for reconstruction Beverage empties tables

 

Q: Can we simply achieve this traceability with a list of all billing items with specific item categories in a SQ* query? You do not need a developer to do that.

A: Yes, but it will be slow, because the data is not aggregated. And you will not have balance confirmation printouts. It would be better to use BW for such kind of reporting instead of queries.

Q: Could this be achieved with LIS?

A: Yes. You will still need a developer to produce some professionally-looking balance confirmation forms, though. The forms are quite simple, so the effort estimation will not be really high.

Q: Could this be done with a custom development instead?

A: Yes, you can create your own logic to populate z-tables, create reports and print balance confirmations that use the data from these z-tables, set authorizations for the new transactions, create service reports for the support team to fix potential problems etc. You will need to consider the archiving aspect and as well. Depending on the skill of the developer and the quality of the solution proposal, the end product could be a really great and reliable functionality. It will also be a very expensive one, which requires a lot of effort in development and testing. 

 

Master data specifics:

Customer master data:

‘Empties Update from’ should be ‘ ‘ – we do not need exceptions from empties update for any trade customers.

Credit master record exists with risk category maintained for the credit control area and document credit group with activated dynamic credit check.

Material master data:

FG – separate item category group for BOM-relevant materials in order to determine a different item category than TAN.

The implied empty uses LEER item category group.

The materials involved should be extended for the relevant plants and storage locations.

BOM setup:

There are 2 bills of material used for the process. Both are with usage 5 – Sales and Distribution.

FG BOM with implied empty code:

Material code – FG product, component – implied empty code for sorted bottles. For the implied empty we need to have quantity correlation.

image016.jpg

BOM for exploding the returned empty code:

  image017.jpg

Material code – sorted implied empty.

Item 1: the same material code for sorted bottles (recursiveness allowed = ‘X’).

In case the customer returns unsorted empties of the same size and the same deposit price, you can use a separate material code for the second BOM - then recursiveness is not needed.

 

 

Document processing:

Order entry:

Upon entering the material code of the FG, the implied empty and return empty are exploded with quantity dependent of the FG quantity.

Default view – 1:1 exchange

image018.jpg

Processing variant 1: first fill or no available empties for return – delete the ZRU item

 

Credit control:

In case of credit block the exposure is not updated at all.

In case of partial confirmation – the credit price for the FG is taken from the confirmed quantity, ZAI and ZRU with material 122 offset each other (so the fact that they are not relevant for ATP does not cause a problem for credit price).

image020.jpg

Delivery creation result:

  image021.jpg

Due to the correlation the quantity of material 122 is adjusted to the FG quantity.

As all items are relevant for delivery, the value from S066 (open orders) is moved to S067-OLIKW (open delivery quantity).

Only the FG is relevant for picking.

No specifics for this process related to transportation planning.

The process is intended to be used mainly in the context of paper-based DSD pre-sales scenario.

When selling products directly from the plant there is not a very significant benefit of using such technique apart from the initial credit price calculation, since the warehouse personnel could update directly the actually returned containers as a manual item in the outbound delivery upon customer arrival, post goods movement and handle the final invoice.

 

Delivery execution:

In the DSD process at shipment completion no material documents are posted.

Shipment output DSDP is used to trigger the printouts of the outbound deliveries, which are assigned to proforma billing type (this is used to print valuated delivery notes, which in case of no changes to the delivery execution are the ‘official’ documents received by the customer.

The proforma billing types are excluded from updating the empties register.

 

Route settlement:

The settlement clerk receives copies of the valuated notes signed by the driver and the customer, which serve also as acceptance protocols. In case of changes to the delivery quantities indicated on the printed documents, the items are updated manually in the delivery execution tab.

During FSR (final settlement run):

  1. New orders are created or the original orders are updated (for example the billing block is reset, new items are added – depending on the settings of the determined customer sales transaction type). For my case the original orders are updated with correction items and the billing block is reset.
  2. New deliveries for correction postings are created.
  3. Goods movement is posted for all selected deliveries (original and new).
  4. Billing is executed.
  5. In case of cash collection clearing is also performed.

At point 4 the empties register is updated.

Important note on DSD CSTT determination – with sap note 1701162 - Incorrect processing of returns items SAP changed the logic for determination of whether a delivery item change should be treated as an increase or decrease and considers /DSD/HH_RADELIT-TA_CODE values (which affects the customizing related for RC exchange).

Related sap notes for DSD:

1819489 - Incorrect processing of new returns items

1823436 - No customer sales transaction type for new items

1971555 - DSD: Incorrect processing of new returns items

 

Billing:

image022.jpg

  image023.jpg

Reporting for returnable containers:


Balances for the deposit account (FS10N):

image024.jpg

Empties evaluation report (/BEV1/EMS):

image025.jpg 

 

Details per account holder/material:

  image026.jpg

Documents without empties update (table /BEV1/EMLOGFS)

 

The table can also be used as a basis for creating a query with an optional authorization check per sales area. It is used in case discrepancies are discovered between FS10N and /BEV1/EMS.

  image027.jpg

In the example all documents with billing type IV are excluded from empties update based on the customizing settings for empties update. Billing document 90038179 is not updated because of missing empties partner (the customer was not added yet to the customer hierarchy at the time of billing document creation).

 

Process variant 1: No agreement for empties exchange (yet) with some of the customers


As the company does not have a unified approach for a specific process, this will be at the cost of additional master data maintenance. It is possible to create a separate document type, but it will result in additional effort for setup (including the adjustment of authorization roles) and a higher learning curve for the employees. Even in the case of pure custom development to check for a specific customer property there should be some criteria in the master data or a z-table that somebody maintains and reviews.

 

  1. Create a new item usage – ZNEX – No empties exchange.
  2. Create a new item category for the FG as a copy of ZAR and change only the structure scope:

image028.jpg

 

3. Set up item category determination:

image029.jpg

4. Create customer-material info record and set only the new item usage:

image030.jpg

  As a result: during sales order creation the information is first read from the CMIR (setting in VOV8 Read infor record = 'X'). Usage ZNEX is determined and we get ZARX for the finished good and only ZAI for the implied empty.

 

Process variant 2: Empties exchange process is acceptable only in some of the locations


Some distribution centers do not have a dedicated warehouse to store empty crates. This means that the agreement for empties exchange can be valid only when the customer orders from a production location or a DC, which can store the returned empties.

When creating the BOMs for the plant, maintain only the first BOM (for the FG and implied empty).

Note: in case of CRM order creation, the approach cannot be used, because you can have only one BOM per product.

When you create a sales document item for a certain quantity and a certain date, you expect that the system should confirm the item on the requested delivery date, but instead a new schedule line gets generated with a proposed delivery date.

 

Delivery date postponement (a.k.a the generation of a 2nd schedule line) can be the result of:

  •   delivery scheduling (in case the system performs forwards scheduling)
  •   transportation scheduling (in case the system performs forwards scheduling)
  •   availability check.

 

In order to disable the determination of a new delivery date, delivery scheduling, transportation scheduling AND the availability check needs to be deactivated.

 

Scenario 1 - Delivery scheduling turned OFF | Transportation scheduling turned ON | ATP check turned ON:

 

If delivery scheduling is switched OFF, but transportation scheduling remains active, AND the system switches to forwards scheduling, the material availability date/time (MBDAT/MBUHR), the transportation planning date/time (TDDAT/TDUHR), the loading date/time (LDDAT/LDUHR), and the goods issue date/time (WADAT/WAUHR) will be the same, but a new delivery date/time (LFDAT/LFUHR) will be determined based on the route relevant settings. If ATP check is also active then the system will check whether the requested quantity is available on the material availability date (MBDAT) calculated by transportation scheduling. If the material is available on the calculated material availability date then no further calculation will be performed. If the material is not available on the calculated material availability date then the system will check what is the closest availability date of the material. If the material can be available on a later date than this date will be found and be taken over as the new MBDAT by function module SD_SCHEDULING_ATP_CALC where the system will perform forwards scheduling.

   

Scenario 2 - Delivery scheduling turned ON | Transportation scheduling turned OFF | ATP check turned ON:

  

If transportation scheduling is switched OFF, but delivery scheduling remains active, AND the system switches to forwards scheduling, the material availability date/time (MBDAT/MBUHR), the transportation planning date/time (TDDAT/TDUHR), the loading date/time (LDDAT/LDUHR), and the goods issue date/time (WADAT/WAUHR) will be calculated based on the shipping point and/or route relevant settings. Also, a new delivery date/time (LFDAT/LFUHR) will be determined that is going to be the same as the goods issue date/time (WADAT/WAUHR). If ATP check is also active then the system will check whether the requested quantity is available on the material availability date (MBDAT) calculated by delivery scheduling. If the material is available on the calculated material availability date then no further calculation will be performed. If the material is not available on the calculated material availability date then the system will check what is the closest availability date of the material. If the material can be available on a later date than this date will be found and be taken over as the new MBDAT by function module SD_SCHEDULING_ATP_CALC where the system will perform forwards scheduling.

  

Scenario 3 - Delivery scheduling turned OFF | Transportation scheduling turned OFF | ATP check turned ON:

 

If delivery and transportation scheduling are both switched OFF, but availability check remains active, the system will not carry out scheduling at all, but will check whether the requested material is available on the requested delivery date. In this case, the requested delivery date (LFDAT) will be the material availability date (MBDAT). Please note that ERP/ATP is only accurate to the day, so only the date is considered, the time is not.

    

In order to prevent the calculation of a proposed delivery date, you need to disable the ATP check (transaction VOV6, field ATPPR; OR transaction OVZG, field ATPPR; OR transaction OVZ2, field VERPN) AND you need to:

 

  • disable delivery scheduling (transaction OVLY, field VSTRM) AND forwards scheduling (transaction OVLY, field TENUR)

OR

  • disable transportation scheduling (transaction OVLY, field TRTRM) AND forwards scheduling (transaction OVLY, field TENUR)

OR

  • disable delivery scheduling (transaction OVLY, field VSTRM) AND transportation scheduling (transaction OVLY, field TRTRM)

OR

  • disable forwards scheduling (transaction OVLY, field TENUR).

The replenishment lead time represents the total period of time which is required to procure or manufacture an item. The replenishment lead time is mainly used by the availability check to calculate the material availability date. In order to enable the calculation of the replenishment lead time for availability check, the field 'Check without RLT' (V_441V-OWBZP) in the scope of check (transaction OVZ9) must be empty.

 

OVZ9_1.jpg

RLT calculation is performed in form END_OF_RLT_CALCULATE which is called from function module AVAILABILITY_CHECK / form AVAILABILITY_CHECK_R3.

 

RLT_1.jpg

 

Key variables:

 

S_MTWZT = In-house production time

S_WEBAZ = GR processing time

P_ATPMATX-PLIFZ = Planned delivery time

P_ATPMATX-WZEIT = Total replenishment lead time

P_ATPPLANTX-BZTEK = Purchasing processing time

S_FKDAY = Factory calendar day

S_GKDAY = Gregorian calendar day

 

1 - Calculation of the Replenishment Lead Time in case of externally procured materials ==> Material Master, MRP 2 view, Procurement type (field BESKZ) = F:

 

For externally procured materials, the replenishment lead time gets calculated based on:

  •   the purchasing processing time (transaction OPPQ, Material Planning Run section, External Procurement button, field BZTEK)
  •   the planned delivery time (transaction MM02, MRP 2 view, field PLIFZ OR transaction ME12, Purch.org.data 1 view, field APLFZ)
  •   the GR processing time (transaction MM02, MRP 2 view, field WEBAZ).


In case of the purchasing processing time, the system considers factory calendar days, a.k.a working days of the plant.

In case of the planned delivery time, the system considers standard calendar days.

In case of the GR processing time, again the system considers factory calendar days (working days of the plant).

The sequence of RLT calculation is:

  •   1st = purchasing processing time
  •   2nd = planned delivery time
  •   3rd = GR processing time.


EXAMPLE 1:

Actual date = 09.03.2015 (Monday)

Requested delivery date = 09.03.2015 (Monday)

Available quantity = 0 PCs

Requested quantity = 10 PCs

Purchasing processing time = 2 days

Planned delivery time =  5 days

GR processing time = 3 days

 

Since the requested quantity is not available for the required delivery date, the system calculates the RLT as follows:

 

09.03.2015 (Monday) - Requested delivery date

10.03.2015 (Tuesday) - Purchasing processing time | DAY 1

11.03.2015 (Wednesday) - Purchasing processing time | DAY 2

12.03.2015 (Thursday) - Planned delivery time | DAY 1

13.03.2015 (Friday) - Planned delivery time | DAY 2

14.03.2015 (Saturday) - Planned delivery time | DAY 3

15.03.2015 (Sunday) - Planned delivery time | DAY 4

16.03.2015 (Monday) - Planned delivery time | DAY 5

17.03.2015 (Tuesday) - GR processing time | DAY 1

18.03.2015 (Wednesday) - GR processing time | DAY 2

19.03.2015 (Thursday) - GR processing time | DAY 3

 

Based on the above described calculation the end of replenishment lead time will be 19.03.2015.

 

EXAMPLE 2:

Actual date = 09.03.2015 (Monday)

Requested delivery date = 09.03.2015 (Monday)

Available quantity = 0 PCs

Requested quantity = 10 PCs

Purchasing processing time = 2 days

Planned delivery time =  3 days

GR processing time = 3 days

 

Since the requested quantity is not available for the required delivery date, the system calculates the RLT as follows:

 

09.03.2015 (Monday) - Requested delivery date

10.03.2015 (Tuesday) - Purchasing processing time | DAY 1

11.03.2015 (Wednesday) - Purchasing processing time | DAY 2

12.03.2015 (Thursday) - Planned delivery time | DAY 1

13.03.2015 (Friday) - Planned delivery time | DAY 2

14.03.2015 (Saturday) - Planned delivery time | DAY 3 -----> The system performs an extra check to see whether the end date of the planned delivery time is a working day at the plant. If it is not, the end date of the planned delivery time will be moved to the next possible working day.

16.03.2015 (Monday) - Planned delivery time | DAY 3

17.03.2015 (Tuesday) - GR processing time | DAY 1

18.03.2015 (Wednesday) - GR processing time | DAY 2

19.03.2015 (Thursday) - GR processing time | DAY 3

 

Based on the above described calculation the end of replenishment lead time will be 19.03.2015.

 

2 - Calculation of the Replenishment Lead Time in case of internally produced materials ==> Material Master, MRP 2 view, Procurement type (field BESKZ) = E:


For internally produced materials, the replenishment lead time gets calculated based on:

  •   the in-house production time (transaction MM02, MRP 2 view, field DZEIT)
  •   the GR processing time (transaction MM02, MRP 2 view, field WEBAZ)
  •   OR the total replenishment lead time (transaction MM02, MRP 2 view, field WZEIT).


In case of all the above mentioned figures, the system considers factory calendar days, a.k.a working days of the plant. If the total replenishment lead time (field WZEIT) is maintained, and the in-house production time (field DZEIT) or the GR processing time (field WEBAZ) are also maintained, the system will only take the total replenishment lead time into consideration.

The sequence of RLT calculation (if the total replenishment lead time is not maintained) is:

  •   1st = in-house production time
  •   2nd = GR processing time.


EXAMPLE 3:

Actual date = 09.03.2015 (Monday)

Requested delivery date = 09.03.2015 (Monday)

Available quantity = 0 PCs

Requested quantity = 10 PCs

In-house production time = 3 days

GR processing time = 2 days

Total replenishment lead time = 0 days

 

Since the requested quantity is not available for the required delivery date, the system calculates the RLT as follows:

 

09.03.2015 (Monday) - Requested delivery date

10.03.2015 (Tuesday) - In-house production time | DAY 1

11.03.2015 (Wednesday) - In-house production time | DAY 2

12.03.2015 (Thursday) - In-house production time | DAY 3

13.03.2015 (Friday) - GR processing time | DAY 1

16.03.2015 (Monday) - GR processing time | DAY 2

 

Based on the above described calculation the end of replenishment lead time will be 16.03.2015.

 

EXAMPLE 4:

Actual date = 09.03.2015 (Monday)

Requested delivery date = 09.03.2015 (Monday)

Available quantity = 0 PCs

Requested quantity = 10 PCs

In-house production time = 3 days

GR processing time = 2 days

Total replenishment lead time = 8 days

 

Since the requested quantity is not available for the required delivery date, the system calculates the RLT as follows:

 

09.03.2015 (Monday) - Requested delivery date

10.03.2015 (Tuesday) - Total replenishment lead time | DAY 1

11.03.2015 (Wednesday) - Total replenishment lead time | DAY 2

12.03.2015 (Thursday) - Total replenishment lead time | DAY 3

13.03.2015 (Friday) - Total replenishment lead time | DAY 4

16.03.2015 (Monday) - Total replenishment lead time | DAY 5

17.03.2015 (Tuesday) - Total replenishment lead time | DAY 6

18.03.2015 (Wednesday) - Total replenishment lead time | DAY 7

19.03.2015 (Thursday) - Total replenishment lead time | DAY 8

Since the total replenishment lead time field is maintained, the system will not take the in-house production time and the GR processing time into consideration, so the end of the replenishment lead time will be 19.03.2015.

 

3 - Calculation of the Replenishment Lead Time in case of materials maintained for both procurement types ==> Material Master, MRP 2 view, Procurement type (field BESKZ) = X:


If a material is maintained for both procurement types, during RLT calculation the system will consider it as a material, which is internally procured. This means that the purchasing processing time and the planned delivery time will not be taken into consideration, not even if these are the only RLT relevant fields maintained.

Working on ERP/ATP related issues made one thing quite clear: many of the end users still use the wrong transaction(s) when they try to check the availability of certain materials. End users often refer to transactions like MD04 or MMBE, but in fact, these transactions are not suitable for checking ATP quantities.

 

In order to check the availability situation of materials, transaction CO09 must be used. This is the only transaction which takes into consideration not just the

different stock levels, but inward and outward stock movements as well. Other transactions (like MD04 and MMBE) does not have this functionality, these transactions were designed for completely different purposes.

 

Here is a simple example which shows the difference between how these transactions handle quantities.

 

In this situation we have:

  •   a material (AC_1)
  •   a plant (AC1)
  •   three storage locations (AC1, AC2, AC3)
  •   a planned order created for 23.09.2015 about 100 PCs (storage location determined in the planned order is AC1).

 

Transaction CO09:


CO09_1.jpg

 

In transaction CO09 the system shows the most important data which are considered by the ATP check, including:

  •   the material availability date
  •   the MRP element related data
  •   the required / requested quantity
  •   the confirmed quantity
  •   the cumulated ATP quantity (quantity still available after the confirmation is made).


Also, the created sales and delivery requirements, as well as the production and purchasing documents are shown on all the concerned storage levels, meaning that:

  •   if only the plant is given in the document, the MRP element will be shown only under the plant section
  •   if both the plant and the storage location are given, then the  MRP element will be shown under the plant stock and the storage location section as well.


In CO09 it can be seen that after 23.09.2015 we have 100 PCs available. These 100 PCs can be confirmed in sales or delivery requirements.

Now, what can we see in transaction MMBE?


MMBE_1.jpg

 

In short: nothing. From an availability perspective this transaction is not useful at all. MMBE does not consider inward / outward stock movements. If someone checks MMBE to find out how many pieces are available of material AC_1, he/she will think that this material is currently not available (which is true) and will not be available in the future (which is wrong).

 

Let's take a look on transaction MD04 next.

MD04_1.jpg

 

In the current situation, MD04 shows the same available quantity that CO09 does, but there is a catch here. Transaction MD04 calculates with requested quantities, not with confirmed quantities.

 

To see what this means in terms of availability, let's create a sales requirement (a sales order) in which the requested quantity is 50 PCs. The system could confirm these 50 PCs for 23.09.2015, but let's change the confirmed quantity to 20 PCs manually (which can be done on the availability control screen) before saving the sales order.

 

In this case, CO09 will look like this.


CO09_2.jpg


Again, as I have already mentioned, the sales requirement will be displayed under all the relevant storage levels (in our case, under the plant section and the storage location section as well). Since the requested quantity was 50 PCs, but we confirmed only 20 PCs, the cumulated ATP quantity (the quantity which remains available after the confirmation is done) will be 80 PCs at 23.09.2015.

 

Now, what does MD04 tell us?


MD04_2.jpg


As it can be seen above, MD04 uses the requested quantity for the calculation, not the confirmed quantity, that is why column 'Available Qty' shows that 50 PCs are still available (which is not true).

 

In summary, as it has been represented, material availability related questions cannot be answered by using transaction MD04 or MMBE, the transaction that has to be used is CO09.

This is a continuation of Mass update of route determination with LSMW. See Mass update of route determination with LSMW

 

Due to restriction of amount of images loaded in previous post, this part continues with the LSMW upload for the TROLZ upload.

 

TROLZ upload

 

Now the TROIZ entries have been loaded, we can load the entries for shipping conditions and loading group.

 

Create a new object in transaction LSMW with different name.

trolz1.png

Goto Maintain Object Attributes and create a new recording as described in the TROIZ load. Also use transaction 0VRF. In the first transaction we now press the button "Position" first. A popup appears and enter the Country of departure, Zone, Destination Country and Destination zone.

trolz2.png

Then select the line and press the button "route determination w/o weight group".

trolz3.png

In the next screen press button "New Entries"

trolz4.png

Then SAVE the entries and the popup of the transport request appears again.

troiz6.png

Confirm and return to the batch input overview using the BACK button.

Then change the values here as shown in the screenshot - like the TROIZ steps.

trolz5.png

Enter the name of the recording in the attributes.

trolz6.png

Then maintain source structure as described in the TROIZ upload.

 

Then goto Maintain Source Fields and enter the following fields.

trolz7.png

Then maintain structure relation as described in the TROIZ upload.

Then goto Maintain Field Mapping and Conversion Rules

Same steps as in the TROIZ upload. Map the source fields to the structure.

trolz8.png

Then goto Specify Files.

Source file should look like in Excel.

trolz9.png

Save the file as a .CSV. Make sure the leading zero's don't get lost.

Then enter the file details like the TROIZ upload.

trolz10.png

Then execute the same steps as the TROIZ load (see Mass update of route determination with LSMW).

- Assign Files

- Read Data

- Convert Data

- Create Batch Input Session

- Run Batch Input Session

After running the batch input session in background the entries in 0VRF are now completed.

trolz11.png

Note that the generic entry is also created. In this example it would be sufficient to load only the generic entry. Then you only need to load the 'exceptions'. This saves some maintenance and amount of entries in the customizing table.

This completes the steps for loading route determination via LSMW.


This blog is to explain the steps for uploading route determination without weight group via LSMW.

 

During several rollouts or redefinition of routes we need to upload new route determination in the system. If the amount of records are not that many, best approach is to do it manual. However with a lot of records, we can use the LSMW tool for this activity.

 

Prerequisites:

  • Routes must be available.
  • Shipping conditions must be available.
  • Transportation groups must be available.
  • A basic knowledge of using LSMW tool.

 

Generic route determination:

 

In this post, I also load entries with a generic route determination. Refer to notes 386105, 414250, 656444 for this functionality. For the route determination maintenance in the Customizing, it is possible to generate entries for which shipping condition, transportation group, weight group are initial (generic). When entering a generic key, it will take the generic route entered in that key. So you only need to maintain the exceptions with an actual key. This can save a huge amount of records to be loaded.

 

2 step approach:

 

The route determination is contained in 2 tables:

  • TROIZ (keys for country from/to and departure zone from/to)
  • TROLZ (keys for shipping condition, transportation group, weight group (not used in this blog) and actual route)

 

To make it easy for the LSMW we load the records for each table so we need to have 2 LSMW's.

 

Note: Before starting, go to transaction 0VRF and change/update one entry in the route determination table so a transport request is created. This transport request is used in the LSMW's.

 

TROIZ upload

 

Goto transaction LSMW.

 

Create new project/subproject/object

 

Here we create a new load for the route determination load of the TROIZ table.

troiz1.png

Maintain Object Attributes

 

This is the most important step of the LSMW, we create a recording for the TROIZ table. Using a batch input recording.

troiz2.png

Next popup needs a transaction code. Enter transaction 0VRF

troiz3.png

Next screen appears and press button "New Entries".

troiz4.png

Enter one key that does not exist in the route determination table. Else you get error message and have to start over.

troiz5.png

Press the SAVE button. The transport request we created before starting comes up.

troiz6.png

Confirm and go back with green arrow a couple of times so that the recording screen is shown.

troiz7.png

Now double click on the fields ALAND, AZONE, LLAND, LZONE and TRKORR one by one and give the following names. I normally delete the default value and only keep the field name + description. The transport request number do not change.

troiz8.png

SAVE the recording and enter the recording name in the previous screen (object attributes).

troiz9.png

Then go to menu option source structure. Enter something similar below.

troiz10.png

Then enter Maintain Source Fields.

troiz11.png

Then enter Maintain Structure Relations.

troiz12.png

Then enter Maintain Field Mapping and Conversion Rules.

 

Note: In the menu --> Extra's --> Auto-fieldmapping will do the mapping more quickly. Else select the fields one by one and pressing button source field to assign the source fields manually.

troiz13.png

Then goto Specify Files

You need to create your input file first. In Excel the source looks like this:

troiz14.png

I normally save the Excel as a .CSV file (comma separated) for usage in the LSMW.

 

Note: always check if the keys are the same as in the Excel file. Sometimes the leading zero's get lost in the conversion.

troiz15.png

Then goto Specify Files select Legacy Data and double click on that node.

 

Enter:

    • File name on your computer
    • Description (any)
    • Delimiter as Comma (we use .CSV)
    • Field names at start of file checked.
    • Field order matches source structure definition checked.

 

          SAVE the entries.

troiz16.png

Then goto Assign Files:

troiz17.png

Then goto Read Data

troiz18.png

Execute this transaction (F8) and you get overview of loaded entries. When it shows read = written it's ok. When not written there is something wrong. You should check your file or mapping when this is the case.

troiz19.png

Then goto Convert Data

troiz20.png

Press Execute (F8). The transactions read - written should be the same.

troiz21.png

Then goto Create Batch Input Session

 

Screen should show the following, I always select 'keep batch input'.

troiz22.png

Execute this transaction (F8)

troiz23.png

Then goto Run Batch Input Session

troiz24.png

Select the line and press button "Process". Select Background and press button "Process".

troiz25.png

This will result that the from/to route determination is loaded in your system. In transaction 0VRF all records are now loaded.

troiz26.png

This is the end of the first LSMW load.

 

TROLZ upload

 

Please refer to next link for the upload of the TROLZ entries.

Mass update of route determination with LSMW part 2

Some customers tried to re-update their pricing in intercompany billing but failed.

 

From price analysis, the following message is listed:

 

Access Message Description

05     108      Condition record exists, but has not been set

10     230      Access has not been executed due to previous access

 

Then we checked further and found the condition category KNTYP for the affected condition type is blank in V/06.

This is actually the standard behavior that condition type with KNTYP blank is not redetermined in intercompany billing, neither with pricing type B.

 

It is also specified in SAP Note 33487.

......

In the case of invoice type IV...

    • repricing SHOULD NOT occur for condition types with the condition category = ' ' (blank) or the condition category = 'G' (Cost).

......

 

Here in the blog I will introduce the responsible coding during the pricing update:

 

LV60AU24
RV_INVOICE_PRICE_PBO
...
*   Verrechnungspreise und TP nicht neu ermitteln
ENHANCEMENT-POINT RV_INVOICE_PRICE_PBO_01 SPOTS ES_SAPLV60A.
    IF tkomp-kaend_typ = space.
      IF tkomk-vbtyp NA vbtyp_fkiv.         << not intercompany
        tkomp-kaend_typ = 'Gbh..'.
      ELSE.                                              << intercompany
        tkomp-kaend_typ = 'Gbh .'.
      ENDIF.
    ENDIF.
* jetzt käme der PRICING_DIALOG
  ELSE.
* Kopfpreisfindung
ENHANCEMENT-POINT RV_INVOICE_PRICE_PBO_04 SPOTS ES_SAPLV60A.
...

 

Remark to the coding above:
tkomp-kaend_typ contains the condition categories that will not be redetermined regardless of the pricing type.

 

Hope it will do you some help.

Dear All,

 

Blog is just to explain how we have  implemented Discount and Free goods on Customer Group  with Pricing Condition


Business Scenario


 

This was one of our client requirements who are into FMCG business and company wanted to give Discount and Free Goods on following Levels

 

    A.Group 1 ASM Area Sales Manager one who handling entire State-State Level -Customer Group 1

    B.Group 2 TSM Territory Sales Manager one who Handling 2 or 3 district- Multiple Districts/zone Level-Customer Group 2

    C.Group 3 TSE Territory Sales Executive one who handles single District-District/City Level-Customer Group 3

    D.Group 4 Modern Trades like Reliance fresh, Lulu, More, Big Bazaar, Spencer’s etc. - Customer Group 4

                                  

Capture25.PNG


We are maintaining 3 Distribution Channels


10 Direct Channels

20 Distribution Channel

30 Modern Trade (Reliance Fresh, More,Lulu, Big Bazar etc….


Now into Requirements Let’s says

 

1.The company wants to give a discount to Chennai alone.

2.The company wants to give discounts in 3 Districts alone.

3.The company wants to run a sales promotion campaign for particular TSM or TSE Alone to boost his business.

4.The company wants to give Free goods on Particular TSM or TSE Alone

5.The company wants to give a discount on particular material group in ASM, TSM and TSE level.

 

                                                                                        Configuration Settings

 

1.Customer Group

 

SPRO-Sales and Distribution-Master Data-Business Partner –Customers-Maintain Reserve Fields In Customer Master

 

customer GRP.png

Customer Group 1 at State Level

customer GRP.png

Customer Group 2 at District(Multiple Districts/zone)  Level

  customer GRP.png

Customer Group  3 at  District/city  Level

customer GRP.png

 

Plz note  that  since Chennai is big  territory so I am dividing Chennai into two i.e. Chennai 1 and Chennai 2.

 

                                                                                                    Customer Group 4 Modern Trade

customer GRP.png

 

2.Customer Master Data

 

Got to customer master data  under Sales area  tab above menu Bar Extras click on  additional Data

 

Fill all relevant data according to your requirements. Plz note that  Customer Group is 4 not applicable, since this customer is belongs to Direct Channel in  my case it is applicable only for Distribution channel  3 i.e. Modern Trade.

customer GRP.png

3. Pricing Configuration Part

 

Got to Pricing, pricing control Field catalog

 

Customer Groups fields are not added in the Field Catalog so add  the field catalog

 

customer GRP.png

Before you create a new condition table, you should check whether the fields listed in the field catalog meet your requirements. If you require a field in pricing which is not intended for this usage in the standard system, you must enter it in the field catalog. You can only enter fields from tables KOMG, KOMK or KOMP.


If you want to use a new field in the field catalog, you must add the field to KOMP or KOMK in the following INCLUDES:


                                                              Header data in INCLUDE KOMKAZ in KOMK

                                                              Item data in INCLUDE KOMPAZ in KOMP

 

The routines for assigning values to the new fields in order processing are found in member MV45AFZZ and new fields in billing are found in member RV60AFZZ. Use the following user exits:

                                                        USEREXIT_PRICING_PREPARE_TKOMK (header fields)

                                                        USEREXIT_PRICING_PREPARE_TKOMP (item fields)


                                                User Exit For Discount and Free Goods



Capture23.PNG



Capture26.PNG




Condition Tables

 

customer GRP.png

 

 

customer GRP.png

 

 

                                                                                                        Access sequence


Copied Standard Access Sequence and created new Access sequence call IFPR

customer GRP.png

 

Condition Types

 

Copied Standard Condition type and created new Condition Type call IFPR

customer GRP.png

 

Pricing Procedure

customer GRP.png

 

Creating a Discount for TSM Level in VK 11

 

We have different Material Group, for Example PK-Lime Pickle, SP-Chilli Powder, and WS-Kashmiri chilli so we can give discount on Particular group alone for ASM, TSM and TSE level

customer GRP.png

 

Plz Map your customer according to your ASM, TSM and TSE located in different State, Zone and District. customer GRP.png

customer GRP.png

 

 

customer GRP.png


4. Free Goods  Configuration


Business Scenario

 

  1. The company wants to give Free goods on Particular ASM, TSM, TSE Zone and District level Alone

 

        Condition Table Group 1

 

customer GRP.png

customer GRP.png

                                    

Access Sequence

 

customer GRP.png

Condition Table

customer GRP.png

            Creating Free Goods records in VBN1


customer GRP.png

 

customer GRP.png


I am Nothing in this SAP Ocean  just learning day  by day , so please share your ideas and suggestions with me.Thanks in Advance.


Thanks&Regards

Thomson


The chess grand masters analyze hundreds and hundreds of chess games!

Constant studying of threads will give SD consultants the much needed "richness and density"...making them better consultants!

Below is a list of threads related to Returns. Study these regularly, make notes, practice in IDES and with time, you will become a MASTER!

 

 

 

1. important:

  • Implementing RE process gives the most learning and experience! a new order type or a new item category. When you get an opportunity to create a new RE order type or item category grab it with both hands!
  • Understand the processes before and after returns. After return order creation, there could be re delivery, re credit memo or SDF. For what business scenario should we design SDF?
  • Flow of goods can be forward and backward (i.e. sale and return), document category is one of the important settings which determines how a process will behave, how data will be stored, how SAP will keep track of data. OTC and RE cannot be in the same sales order!
  • For promotional sale, customer can not return the goods, below link - Design of promotional sale process. If copy control does not exist between sale and re process, then RE order cannot be created with reference. Understand copy control - at header and item levels.
  • "Mixing and matching" document types of different processes. Example below ZCR (credit memo request) > ZRE (return billing type). This is not the way it should be configured

 

OTC and RE cannot be in the same sales order!

Functionality - Document category
Two delivery types in one sales order

 

Post go live, a temporary issue

Functionality - Reference mandatory

Understanding the issue - is it related to transaction data OR related to configuration?

SALES RETURN for the material sold before SAP implementation

 

Promotional sale, customer can not return the goods

Block sales order items for return orders

 

Business process related ticket

How to handle "after" goods are returned to the company? Give credit to customer, supply the goods free of charge

Functionality - SDF, key configurations in SDF - no billing, delivery block, any pricing? , copy control related to creation of SDF order

Sale return of Component of Fin Prod

 

ZCR > ZRE , not recommended

For credit memo process there is a dedicated billing type G2

Output to trigger header ship in return order

 

2. important:

  • Understand for what business requirements you need a new/different RE order type and for what requirements you need a different item category.

 

change the item category in RE order, instead of the default item category - If re order is created with reference, then the particular re item category can populate automatically with copy control (item level). If re order created without reference, then manually the "correct" item category needs to be input (in place of default, coming from item category determination table T184)

 

Functionality - Billing relevance

Return Sales order - update of Item category change

Complaint Processing -

 

3. Business does not want any major changes

Functionality - copy control

Userexit, enhancement

Propose order quantity in return sales order

 

4. View selected Order reasons in VA01/2

Functionality - make order reason a "mandatory" field in RE process, useful for reporting

Userexit, concept of Ztable (important and used frequently)

Order reason codes - specific to sales order type

 

User Exits In Sales Document Processing - System Modifications - SAP Library

Side comment: For a SD consultant to understand, identify the appropriate user exits that can be used for a requirement is very helpful.

 

5. important:

  • Visualize the flow of goods. Most of the times, business wants to have clear distinction between sales goods flow and re goods flows.


Functionality - Shipping condition for returns process

different shipping point for returns delivery

Discussed in point 3, below, configuration

 

6. Should returned goods be part of Salable stock or not?

Functionality - Movement type 651, 653

sales returns

Movement type for Sale return

Return Delivery from Customer with Movement type 653 - Toolbox for IT Groups

 

Important - DN is the schedule line category provided for return process, in standard. VOV6

 

7. Business process and enterprise setup

Functionality - Enterprise structure > assignment > Sales org, distribution channel to delivering plant. An important step in SD

Intercompany Return Process Error

 

8. Pricing - what components to refund to customer? should tax component be refunded? should freight be refunded?

Functionality - Pricing

Return process

Side comment: In every aspect of SD design/tickets, mentally check - is there any impact on pricing?

 

9. Flow of goods in return direction, to which plant should goods be returned?

Functionality - Delivering plant (receiving)

Return order

Good example of a business requirement


10. Quantity in return order, compared to quantity in sales cycle

return order

Return order with reference to the Billing Document

 

11. (09Aug15 updated) 11 merged with 1

 

12. Functionality - Billing block

Generally in returns, credit, billing block is setup. Billing block can be setup at different levels (header, item) in RE order

Below thread touches on authorization also.

Unable to remove biling block return sales order

Billing block

Important is to read the error message carefully, it gives clues, for solution

 

13. Functionality - REN, item category

Item category in a return order

 

(added on 08DEC2014) 14. Functionality - Billing (return credit note) created with reference to return delivery

(In standard, RE bill is created with ref. to RE order)

SANJIT BHATTACHARYA

asked to include this. In few of my projects, companies have RE credit note created with ref. to RE delivery (and not order). There could be few business reasons to this process:

- The business would like to inspect the goods in their warehouse and then give refund, if applicable

- Quantity in delivery could be different from that in the RE order, so refund is given on the actual quantity that the business receives.


From configuration point,


14.1. copy control VTFL: RE delivery to RE bill is same as LF to F2,

and at item category level, copy control of REN is same as and item category TAN


14.2. item category REN, billing relevance should be A (delivery related billing)


Delivery Related Billing rather than Order Related Billing in Return Sales

SD BILLING(CREDIT MEMO) AGAINST PGR


Returns in standard SAP:


1. Return order created with reference to billing document

RE order can be created without reference or can be created with reference to sales order. But best practice is to create with reference to invoice

At item level of copy control configuration, pricing type is an important functionality - should prices be copied unchanged or any other way. The business requirement dictates pricing type. VTAF

1.copycontro.jpg


2. Return document type

In several projects, I have noticed that field Reference mandatory has played an important role. Take note: when creating any custom reports, the SD document category is H, at transaction level, in order VBAK-VBTYP; at configuration level, in order type TVAK-VBTYP.

Different number ranges are given to RE orders, for easy recognition and reporting purposes. VOV8

2.doctype, reference mandatory.jpg


3. Continuing with order type, shipping condition can play an important role. Also billing block given here, then in sales order, at header level billing block will be set automatically. Business has to remove the billing block from the sales order in order to create a RE credit memo. If business does not want to give RE credit note, then a reason for rejection can be put

3.doctype, shipping condition, billing block.jpg


4. Item category

In addition to field billing relevance, also note field Returns has to be activated for all return processes including credit memo, check G2N. VOV7

4.itemcat.jpg


5. Schedule line category

Movement type is an important field. 653, 655, 657 Availability check and Transfer of Requirement has been deactivated, as these functionalities are not required for goods coming into the plant. VOV6

5.schedulelinecat.jpg


6. Delivery item category

The item category name REN remains the same in sales order, delivery and billing

Relevant for Picking in deactivated as goods are coming into the plant. Document category is T, sometimes needed for analysis in VTFA. 0VLP (zeroVLP)

6.dlvitemcat.jpg


7. Billing type

The RE credit can be cancelled, for that SAP standard cancellation billing type is S2. Additional requirements can be setup, conditions where cancellation is permitted in copying requirements. Does a company want the option to cancel the RE credit memo is a business decision. VOFA

7.bill.jpg


All the screenshots are from SAP, copyright by SAP AG.


typewriter

 

Career Center

Actions

Filter Blog

By author:
By date:
By tag: