|
| |
Good Ideas Department
Here's a short list of items that I've configured or developed that made
good sense at the time and may do the same for you. To my knowledge - and as
of release 46C - most of these have not yet been replaced or provided in
standard SAP.
Overview
I have not gone into much detail in each description, but anyone with partial
knowledge of the application area shouldn't have too much trouble understanding
what I'm talking about:
Use SD-CAS (Computer Aided Selling) direct-mailing activities to
generate multiple customer orders.
(I've done this for a few customer implementations over the years and it still
works well as of 46C) Standard SAP works by taking the address list and the product
proposal (list of products & quantities) linked to the mass mailing activity
and through an output type, creates a single order with the products
from the product proposal. The idea is that the single order requirement
would cover the products and quantities required to satisfy delivering to all
of the addresses in the address list.
By slightly modifying the output program, it is possible to create a single
order per address entry, which are then shipped using your standard delivery
due process.
Additional modifications can allow you to re-process the address list in that
activity repeatedly (SAP doesn't allow this as standard)
The standard functionality could do with some improvement in terms of
user-friendliness - you can greatly improve it through a single output
configuration (no mod involved here!)
-
Use transaction
output processing for
outbound interfaces
Enormous flexibility for real-time outbound interfaces is the benefit here!
You can use all of the functionality of standard output processing to trigger
if/when the interface should be processed. As secondary benefits, each
SAP document holds the status of the processing run in the output (or
messages) screen (as well
as any custom messages in the output processing log). You can also (with
a copy of a slightly changed - 1 line - RSNAST00) re-process the interface output
programs for relevant documents in a batch run.
Note that in some cases, interfacing a document to a custom bolt-on or
interface requiring SAP's document number via a userexit is not possible.
At that stage, SAP has not yet assigned the document number to the transaction. In
these cases, output processing is a very attractive solution as SAP has determined the
document number and saved the transaction to the database when output processing is
processed.
-
Develop a report to
list specific pricing conditions used in
sales order/billing transactions at condition access level.
SAP provides no way (up to 46C) to report down to condition and access level.
Example: To clarify: You have a standard price ZP01 that defines
a material price to a ship-to based on one of two accesses in a pricing access
sequence:
Access Sequence
010 SalesOrg, Distr Channel, Business transaction type,
Ship-to, (Material, Price,...)
020 SalesOrg, Ship-to, (Material, Price,...)
Now let's say that we have the following condition records:
Condition/ Access 010
| Sales Org |
Distr Ch |
Bus Trans Type |
Ship-to |
Material |
Unit Price |
|
9001 |
10 |
1 |
845601 |
990001 |
10.25 |
|
9001 |
10 |
2 |
845601 |
990001 |
11.44 |
|
9001 |
10 |
3 |
845601 |
990001 |
12.66 |
Condition/ Access 020
| Sales Org |
Distr Ch |
|
Ship-to |
Material |
Unit Price |
|
9001 |
10 |
|
845601 |
990001 |
14.01 |
Now try and answer the following query: What document items
received a special price for a material based on Bus Transaction type over the
past 3 weeks? Add to that "what was the breakdown?".
As of 46C, SAP doesn't provide a standard report to list this information.
YOU CAN report on what bus transaction type, material and ship-to were used in
any set of transactions, but how do you know if any condition was found that
specifically matched Business Transaction type and ship-to?
I may include the logic to read the pricing at a later stage, but the results
of the (ALV) report could look something like this:
| Doc# |
Sales Org |
Distr Ch |
Bus Trans Type
|
Ship-to |
Material |
Count |
Unit Price |
| 120023 |
9001 |
10 |
1 |
845601 |
990001 |
1 |
10.25 |
| 120123 |
9001 |
10 |
1 |
845601 |
990001 |
1 |
10.25 |
| 120127 |
9001 |
10 |
1 |
845601 |
990001 |
1 |
10.25 |
| Sub-Total |
|
|
1 |
|
|
3 |
30.75 |
| 121330 |
9001 |
10 |
2 |
845601 |
990001 |
1 |
11.44 |
| 130011 |
9001 |
10 |
2 |
845601 |
990001 |
1 |
11.44 |
| 131031 |
9001 |
10 |
2 |
845601 |
990001 |
1 |
11.44 |
| 132001 |
9001 |
10 |
2 |
845601 |
990001 |
1 |
11.44 |
| 132500 |
9001 |
10 |
2 |
845601 |
990001 |
1 |
11.44 |
| 132510 |
9001 |
10 |
2 |
845601 |
990001 |
1 |
11.44 |
| Sub-Total |
|
|
2 |
|
|
6 |
68.64 |
| Grand-Total |
|
|
|
|
|
9 |
99.39 |
To summarize, you can see the following things from a report like this:
1. How often a specific condition is used
2. Compare how often a different price is given for the same
material and ship-to
3. Quantify the revenue impact of your pricing structure and
4. Provide a base for adopting different pricing approaches.
Once you have this level of information, you can make further decisions about
whether your pricing structure works and what changes could be made to
streamline your pricing approach.
| |
|
