Skip to Content

My first Personas project joined together a lot of transactions – 23 in total – into a single package designed to simplify SAP interactions for a relatively small group of users. You can read about that project here – Putting everything together – the finished Personas project. My second project is very different – simplifying just two transactions for a much larger group of users. Those users are department heads and senior managers, and pretty much all they do on SAP is release purchase orders and billing blocks on sales orders. I started by looking at the transactions to do this and at how they might be simplified. However, one thing I learned from the first project was that our users very much appreciate the “launchpad” design where the transactional nature of SAP is hidden as much as possible. In many cases tasks are carried out directly in the launchpad screen without ever being aware that an SAP transaction is being executed at all. So I changed my approach and looked at how to do the same for PO and SO releases. So far I’ve just implemented PO release, but I think the design works well and hides many aspects of SAP that our infrequent users find confusing. First, everything happens on the launchpad screen, and second, there are no release codes in sight.

 

Before I describe the implementation, here’s what it looks like. I’ve skipped the login process and we pick it up just as the initial launchpad is being rendered. On the left side is a list of all the POs waiting for release for the current user. You can push a button to see more detail over on the right hand side, and if the PO has multiple lines you can scroll through the line item details. If necessary you can also hit the “Display” button to see the whole PO (using ME23N). Once you’re happy that the PO is OK, you hit the “Release” button and you are asked for confirmation before the PO is released. After release, the left hand list is updated.

 

 

The most complex part of this implementation was the scrolling list on the left. The implementation of this is described in detail in this blog – Creating a custom table in Personas. It isn’t pretty but it does work well. You may notice that the table scrolls more slowly in the video in that blog than it does in the video in this one. My new implementation uses an interesting technique to improve performance – I’ll describe it in a separate blog. This table contains all of the POs that can be released by any release code the use has access to. I use the “OnCreateHandler” property of the screen to build the list automatically when the screen is rendered, so that when a user logs in the list is right there waiting for them. You’ll notice through this entire process the user needs to have no knowledge of release codes, or that they even exist.

 

Once a PO is selected and the details displayed, things get a lot more straightforward. The details for the selected PO use the quick lookup technique to run ME23N and copy the necessary details back to the launchpad screen. Scrolling through the line item details again calls ME23N for each scrolling action. I’m actually considering replacing that section with a second table of line item details. I think that will perform better and the users will prefer it. The right hand side will then effectively be a cut down ME23N. The “Display” button obviously runs ME23N to display the selected PO. Coming back via the “Home” button is interesting. You may have noticed that if you navigate away from a screen and then return, any custom fields you have added to that screen typically lose their values. In this case, since the “details” section on the launchpad contains values that originally came from ME23N, I simply make the “Home” button copy them all back!

 

To achieve the “Are you sure?” effect, I have a text label consisting entirely of spaces and positioned in front of the Yes/No buttons so that it hides them. The “Release” button simply changes the value of that label to be blank, revealing the buttons. The release operation is carried out by the “Yes” button. Here I use a WebRFC to carry out the release but scripting ME28 to release a specific PO should be a simpler option.

 

This is still a work on progress. It hasn’t yet had any significant end-user input and that is important. As a result the final version may well be a little different from this. And obviously I still need to add SO billing block release to the bottom half of this screen. I’m hoping it can be done in a similar way.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Tammy Powlas

    Thank you for sharing.  The video is helpful too. 

    It is nice to simplify a commonly-used screen to help users do their job better.

    (0) 
  2. Patrick Pelluault

    Steve,

    to give a little bit of context it would be interesting to know why you are not following the HTML5-Gateway path for providing this kind of User Experience improvement (I am translated FIORI applications).

    I do appreciate all your blogs on SAP Screen Personas as you find innovative approaches on the product use.

    Regards,

    Patrick

    (0) 
    1. Steve Rumsby Post author

      That’s a very good question. The main attractions to me of Personas are much reduced development and testing time. Personas flavors are largely built from SAPgui transactions. Those are quite large building blocks and as a result development times for simple Personas flavors can be quite short. Testing effort during EHP and support pack projects is also much reduced since those SAPgui transaction building blocks need to be tested anyway for regular SAPgui users. The extra testing that comes from a Personas development is small in comparison.

      This is less true as you start building more complex flavors like this one. Even so, the ability to just pop into ME23N to display a PO and not have to replicate that functionality saves a lot of development effort. Also, I don’t want to have to deal with multiple development technologies and development environments. I’d rather have one that I can use for most things rather than 2 or 3 of differing complexity, and with different UIs.

      We took our decision almost 12 months ago about which UI technology to use. If we were to take that decision again now it would be a harder decision. UI5/Gateway might have won out, especially given the cost difference. We would need more time and resources for our developments in that case, though, so it really isn’t clear to me how that decision would turn out.

      I’m still happy with our choice.

      Steve.

      (0) 

Leave a Reply