Move screen fields between header and line item screens 3.0

[Former Member]

Hi,

Is there a clean way to combine a header and line item screen? So for example I am working with transaction FB01. When you first enter the transaction you have to enter some header level information. There are required fields on the screen so you cannot move to enter the line items until you enter some values. The line item screen is a 'dynamic' table. Meaning the input fields can change based on the data entered in the header screen

• I thought about potentially adding an array to the header screen, removing the save button and adding my own script button that runs the transaction and sends data from my array to the item screen and saves the data
• Or maybe adding some text fields to the item screen that has the header data copied to them. But if the user changes the header data then the validation logic on the header data must be re-run. Maybe it is when the user hits save anyway.

The tough part is a clean way to combine screen fields from two different screens within the same transaction. I have read some of the posts here are about using transparent images etc.... Maybe I am trying to push personas beyond what is designed to do. Maybe I am not seeing the forest through the trees or maybe I am just a head case

If anyone has any thoughts please feel free to chime in

Thanks

Rich

[Former Member · Accepted solution]

Firstly, in Personas 3 you can hide screen objects "properly" in a script - none of the messing about with transparent images needed. That's a big help.

As for the bigger problem, I would say the best approach, if it can be made to work, is to replicate the header data from screen 1 onto screen 2. If you can rearrange the screen elements so that the header fields have the same arrangement on both screens, it could disguise the fact that there are two screens. The detail table would just magically appear when all the header fields are completed.

The tricky part, as you say, is how to deal with the detail take changing structure when the header data changes. The only real way to do that, in this scenario, is to go back to screen 1, change the header data, and then head back to screen 2. That will lose any detail data that's been already entered. You can save that first and re-enter it when you get back. But if the table fields have changed you need to think carefully about how that happens.

Where the detail table doesn't change structure, this is fiddly but certainly possible. And I think you could do it in a way that looks and works seamlessly. That somewhat depends on the underlying transaction, of course. Where the detail table changes structure, I think your biggest problem will be in deciding how any entered data should behave when the structure changes.

Hope some of that helps

Steve.

[Former Member · Accepted solution]

Hi Steve,

I really appreciate your response.

I get what your saying about putting the fields in the exact spot on both screens and 'magically' the detail fields appear. I had thought about that and I think I'll prototype that for kicks and grins.This is for transaction FB01. So another dilemma is getting good data. Posting period is not open for posting etc...(it is a sandbox )

As far as the data that was already entered getting whacked well maybe that is not too much of an issue b/c if the user changes the GL account and the item fields change, well the user probably needed a clean slate to start with any way,

I'll give it a go. Maybe if it goes well I'll write a blog on it.

P.S. I had responded to my original post before you responded but my response is in moderator review. Just in case there was any conflicts to what you posted know that we crossed posts. If that is possibe

cheers!

Rich

[Former Member · Accepted solution]

One of the fun things I find with Personas development is having to properly understand the transactions you are working with, and related transactions also. In your case, OB52 is your friend - open up the whole year and you'll be good for experimenting for a while

I'm looking forward to the blog already. Write it even it this doesn't work - it is helpful to learn from others what doesn't work as well as what does.

Steve.

[Former Member]

OK I am beginning to think this was not the smartest of questions. Maybe I will answer my own question here.

The validation of the header level fields occurs in the PAI of the header screen. Provided that validation is passed, then execution is allowed to flow to the PBO of the item screen. Merging fields across screens could mean having to merge PBO's and PAI's which #1 would never work and #2 could be a real pain in the a...neck to implement, maintain etc.....

Merging across tabs works because at the bottom of the screen stack is one screen (or maybe even the same subscreen) underlying all the tabs.

So I can create my own text fields on the item screen and pass them the header values and work some black magic to get the header validations to run again (switch flavors, call a bapi, etc.....) on save of the item fields or ask the end users to be happy with the two screens and focus my efforts on improving the UX in other areas of the transaction