The Service Management Experts
Menu

SAP

Home / Archive by category "SAP" (Page 37)

Web Dynpro – Matrix Data

Recently, I started to discover some of the nuances of setting up the layout in a web dynpro view.  The simple detail I discovered is the difference between the (matrix data) matrixdata & matrixheaddata is probably obvious to many, but I fumbled with it for a while trying to figure out what the heck I was doing wrong 🙂

So, here’s the situation, I needed a transparent container to hold a group of input fields and labels.  Because of some of the other things I’m doing dynamically, I chose to use the MatrixData layout.  I gave the Matrix Data 2 columns, assuming that things would automatically just fill in from one field to the next.  Initially, I set the labels and the input fields to be MatrixHeadData.

Everytime I executed the application, it put the label and the input field into the same column, never together in the same row.  After some digging, I finally found that MatrixHeadData will always start a new row, if you want to continue an existing row, you must use MatrixData.  So there’s my learning experience, that I’m passing on to all of you.

Thanks for reading, and hopefully I can save you some time when you start developing our own apps.

Variant Configuration – SCREEN_DEP

If you’ve been doing VC for any length of time, you’re probably very aware of this little trick.  But if you’re new to VC, you might not be aware that you can dynamically control your characteristics.  You can use object dependencies to set a characteristic to invisible, or set it to input or no input.

For me, when I model a product line, I often need to add characteristics that aren’t always available for the user to see or to input.  For this, I will create reference characteristics based on the following table:

Screen_DEP

INVISIBLE

YES

Makes characteristic Hidden (same as checking No display below)

INPUT

YES

Makes characteristic available for input (same as un-checking Not ready for input)

NO_INPUT

YES

Makes characteristic unavailable for input (same as checking Not ready for input)

RESET

YES

Resets all values set by Screen_DEP structure.

Simply create a new characteristic, and on the reference tab enter in the Screen_dep for the table, and one of the fields in the 2nd column as the field.

Now, in your object dependencies, you can simple use your standard logic:

$SELF.INVISIBLE = ‘MY_CSTIC’
IF….

now the only catch to this, MY_CSTIC must be spelled properly.  There is no syntax checking since it’s a literal.  But if you spell it correctly, and if the IF statement is met, MY_CSTIC will be made invisible.

It’s that easy.  Very slick and very powerful.  If you haven’t already, give it a try.

Screen_DEP

INVISIBLE

YES

Makes characteristic Hidden (same as checking No display below)

INPUT

YES

Makes characteristic available for input (same as un-checking Not ready for input)

NO_INPUT

YES

Makes characteristic unavailable for input (same as checking Not ready for input)

RESET

YES

Resets all values set by Screen_DEP structure.

Service Management – Reset Equipment Status

In a previous post I talked about the equipment status.  This field can be very powerful, but at times, it’s very painful.  I have run into issues the status doesn’t get set or reset properly after certain transactions.  Today I want to talk about how to reset equipment status.

blog2-01

Once inside of the equipment record, edit–>special serial number functions –>manual transaction.  The manual transaction is the equivalent of the equipment status reset.  It allows you to force the status (remember, this won’t impact the stock)

blog2-02

that will bring up this nice pop-up window that presents you with the following options:

To stock: ESTO
From Stock: add AVLBTo Customer: ECUS
From Customer: ESTO
Delete Assign to HU: Clears the handling unit
Delete Inv. Assign: clears inventory connection

Save, and should be able to continue with your transactions.
Good luck and thanks for reading.

Variant Configuration – Class Hierarchy Benefits

I just realized, it’s been a while since I talked VC.  Thought tonight would be a good time to add something new for those of you who enjoy the variant configuration posts.  Today I wanted to talk about the advantages of using the class hierarchy when you are modeling.  Often you may have multiple products that are all built on the same platform, but each has it’s own flavor.  In this situation, you will find that often a group of characteristics are shared among all of these product lines, and only a subset differ.  This is perfect for the class hierarchy.  To do this, you build a class with all of the “common” characteristics.  Then you create a second (or multiple) classes that contain the characteristics that are unique to the particular product line.  You then use transaction CL24N, enter in the “common” class, and assign the second class to it.  Now that second class contains all of the cstics of the upper level and the lower level.

Now,this sounds like a lot of work, but for maintenance purposes, whenever a new common characteristics needs to be added to all of the product lines, simply add it to the upper level class, it will automatically be added to everything that is below it.  The other huge benefit is that if use constraint nets, you can define the constraint to talk to the “Common class”, and thus you don’t even need to re-write the constraint for the lower level classes 🙂

There is a downside, and this is usually experienced the most in the development phase.  This is the ability to delete cstics from the common class becomes more challenging once they are inherited.  For that, you need to be sure to use transaction: CL6K to delete a cstic from the common class.  Typically, you don’t encounter this once you move the model to production, but often in the development phase you change your mind or find that you picked a characteristic that doesn’t belong or is replaced with something else.

But in my opinion, the upside far outweighs the downside.  Happy Configuring and Thanks for reading.

Service Management – Intercompany Billing

I recently learned a cool trick when dealing with inter-company in-house repairs.  One of the scenarios in service management I’m seeing more often is having one facility bill for a repair while another company performs the repair.  There are 2 common ways of transacting this intercompany billing in the system.

1.  Create a repair sales order in both the billing and the repairing facility.  While this method provides the greatest flexibility, it also requires the greatest amount of transactional data to be entered.

2.  Create a single repair order with the main line item in the billing plant, and the receiving/repairing lines in the repair facility.

The biggest challenge with option 2 is billing the “billing plant” for the repair.  Sounds simple, but with only a single sales order, how can you invoice the customer and the “billing plant”.

That’s where I discovered this SAP provided report: RVIVAUFT that generates an inter-company invoice from the customer invoice.  it’s pretty simple and pretty slick.  there is however one drawback to this approach.  You can’t invoice the “billing plant” until after you invoice the customer.  Typically this shouldn’t be an issue, but depending on your business process it is something to be aware.

Hope you find this as useful as I did.

Basis – Debug Authorization

Here’s another chance for me to add to my notebook.  Adding debug authorization is a trick I often have to do in my development projects.

When you have your own system, one of the first things to figure out is how can I get the authorization to debug a program, or in my case a Web Dynpro application.  Now, you can certainly assign yourself the role of SAP_ALL.  But what happens when you want to test with a real user???  Well, you need to narrow down that Authorization.

So, simply add this authorization:
S_DEVELOP
Then fill in the following attributes…
OBJTYP: DEBUG
ACTIVITY: 1 & 2 & 3

I know, not really exciting, but I never know if it might help you…  it certainly is something I’ve used multiple times.

 

Service Management – Equipment History and how to get it

Well, I recently started helping a new client to revisit their current service processes across multiple organizations.  My first observation with all of their processes is that in many places things are disconnected because they aren’t using some of the functionality that is native to SAP.  This made me wonder, are there other places that aren’t connecting things in the system?  So I thought I’d do a post on serial number / Equipment history.  I think there will be follow on for connecting other documents later 🙂

So, on with the show.  the serial number history is an amazing resource, but only if you use the serial number properly.  If you are using standard SAP, in your equipment record there is a tab called serdata.  This magical tab is by far my favorite on the equipment record.  it gives you the material, serial number, if it’s currently in stock and of course the history button:

Now this is a sample history of a single serial number.  This becomes invaluable because if you look at the legend that included in this screenshot, you’ll see a huge list of documents that will be shown in the history, but only if you add the serial number to them.

Some of the biggest culprits are the SD delivery, especially if you do in-house repairs.  if you don’t add the serial number to the inbound delivery, it won’t show up anywhere in the document chain.  You can manually add it to the SD repair sales order (using the menu extras->technical objects), then even the sales order will show it.  Now, keep in mind, your serial number profile will define where the serial number is allowed and where it is required.  I’ll be doing a post soon talking about the serial number profile to give you more details.  the important detail to take away from today’s post is that everywhere you can put a serial number you should.  If you include it in a document, it will show up in the history and give you a complete picture of everywhere the number has been used.

This will be an ongoing post with more details, so don’t be upset that I’m keeping this kind of vague…  have to start somewhere 🙂

Service Management – Equipment Status and What it Means.

I’ve come to realize that I haven’t talked much about a very important aspect of service management, that’s serial numbers.  If you haven’t checked out my SDN post on the serial number profile, I recommend it.  It will help you understand this coming post even better.  Today I wanted to continue talking about the serial numbers, but today I want to focus on the system status’ you will encounter and what they mean to you.  Like everything in SAP, there are a lot of possible status’ out there, but I’m going to concentrate on the common ones you will see, and the some of the headaches you may encounter because of them.  Here’s the most common equipment status you’ll encounter:

  • AVLB:  This is the easiest one to deal with, but the least informative.  This status is pretty much the same as saying I exist, but I don’t know where.  If you have the status AVLB, then you use it in scenarios from or to the customer.  Typically this status is assigned if you manually (or in mass) create the equipment record and it hasn’t been assigned to anything yet.
  • ECUS:  This means that the equipment is at the customer.  If this status has been assigned, then you won’t be able to use it for outbound deliveries, or material movements (at least if you have stock checking turned on).  The only thing you can do with this status is an inbound delivery or Lock it.  You may also see this status combined with EDEL (which means that it is customer owned and on a delivery).
  • ESTO: This means that the equipment is in stock at your facility.  it could be any plant or location, but it is now in stock, and you can no longer perform an inbound delivery, but you can do material movements on the serial number and you can do an outbound delivery.
  • EDEL:  This means that it is on a delivery.  If you have an open delivery that has not been PGI’d or PGR’d, then you will see this status with either ECUS or ESTO (which will tell you if it’s an inbound or outbound delivery).  This can be a particularly nasty status.  I’ve seen many instances where deletion of a delivery does not always reset this status.  (Next post I’ll talk about how to fix things that get messed up).
  • ELOK:  This is the same as marking the equipment for deletion.  Once you set this status you can’t do anything with the serial number.  If you need it, you can unlock it again, but as long as this status exist, the serial might as well NOT exist =)

I hope this helps explain the status’ a little better on the equipment.  Next time I’ll explain how you fix the status when SAP gets “Confused”.  ha ha ha.

 

Web Dynpro – Learning to Control the Web Dynpro Layout

Well, last night was spent on playing with the layout to attempt to make the new views in Web Dynpro look the same as the BSP views I generated so long ago.  So, what have I learned so far.  Web Dynpro layout can be a royal pain…

1.  Transparent_Container – so far this has become my best friend.  it allows you to group certain elements and apply whatever formatting you need just for those elements.  Plus you can embed the containers inside of other containers, so using this feature has finally allowed me to start reproducing the look and feel I was hoping to get.

2.  Text_View – this is “so far” the best option I’ve found for titles.  What I don’t like about it is the limited number of formats you can apply.  So this means you can’t directly control the font/size.  From my google research, this appears to work as designed, so you just have to accept.  Now I have seen mentioned to the formatted text view, but I have yet to try this.  I’m sure that will come up in my experiments soon 🙂

3.  Attributes inside of any container are very powerful, but you need to play with them to truly understand how they work.  For example, stretching an element will only behave how you expect it if the container above it is also stretched to accommodate the entire screen.  This may have to do with the inherit value, but again… I’m still learning this 🙂

4.  Grid Layout vs. Flow Layout vs. Matrix vs. Row layout.  This is still a little nebulous for me.  I’ve got down the flow logic and grid logic, but haven’t quite figured out when to use row layout or matrix layout…  so I’ll continue to experiment on this.  However, Flow layout will just keep adding objects to the row until it runs out of space, and start a new row.  Grid layout lets you select the number of columns for each row, and it will place an element into each column, then start a new row.

Well, that’s my AWDP tidbit for the day,  I hope that my fumbling might make your life easier in the future 🙂

Web Dynpro – Using the Code Wizard

Well, I believe I mentioned it in a previous post, but I’m still struggling with the differences between BSP and Web Dynpro.  AWDP is a fun tool, and I like it the more I get into it, the learning curve is still killing me 🙂  Today the Code Wizard is one of my recent discoveries.

For example, I figured out the whole context model, why you do it, etc.  But I had a hell of a time figuring out how to get the value into or out of the context variables I created.  I finally discovered the Web Dynpro Code Wizard…  which, with a few clicks, generated all of the code I needed to read or set the context node.  So simple, yet I hunted on-line for an hour, and eventually found it in the ABAP Web Dynpro book I purchased.

It turns out, you click the wizard button, select the node you want to work with, then tell it if you want to read it, set it, append it, etc…  hit the green check mark.  And magically, all the code I needed was inserted into my method.  Who knew it could be that easy.  LOL.

Anyway, if you’re playing with AWDP, take advantage of the code wizard.  it won’t create your whole application, but it’s great at the little stuff =)

thanks for reading,

Mike