Transaction and screen varients

hi gurus
need step by step scrren shots for transaction and screen varients
my id :[email protected]
points award is sure
kishor

Dear Rama,
http://help.sap.com/saphelp_webas620/helpdata/en/eb/5fab41d79b11d296190000e82de14a/content.htm
In the SAP Reference IMG, you can create transaction variants. Choose Basis Components -> Application Personalization -> Tailoring of Application Transactions -> Configure Transaction-Related Display Values for Fields (Transaction SHD0). Transaction variants allow you to preset values for fields in a transaction, set field attributes, or hide entire screens.
To execute a transaction variant, you define a variant transaction using the Transaction Maintenance transaction (SE93).
Once you have entered a transaction code and short description, choose transaction type Transaction with variant (Variant transaction).
To define a variant, enter the name of the transaction and the name of the variant. You can then use the new transaction code to start the special variant of the transaction.
Hope this will help.
Regards,
Naveen.

Similar Messages

Create transaction and screen variants

Hello
I want to create transaction variant for VA01 and MM01 in order to simplify the data entry. I know SAP has SHD0 as a tool and Synactive has GuiXT to make all these changes. But I wonder what are the differences between these 2 tools.
Please let me know,
Thanks,
George

Dear Mr.George,
Transaction Variant
You can only create transaction variants for dialog transactions and reporting
transactions.Only "normal" screens, dialog boxes, and subscreens can be
included in the variant.
Screen Variants are automatically created anytime you create a
transaction variant.
Initial Screen
Enter the name of the transaction and the transaction variant on the initial screen. The system creates a cross-client transaction variant. If you want to create a client-specific transaction variant, choose Goto -> Client-specific transaction variants tp branch to the client-specific transaction variant maintenance transaction.
Client-specific transaction variants only exist in the client in which they are created. The field contents of the transaction variant must be available in this client. Cross-client transaction variants are available throughout the system, regardless of the client currently being used. The field contents of these transaction variants must be available in all clients.
Creating the Transaction Variant
Choose Create to create a variant.
The system calls the application transaction that you want to create a variant for. Enter the values you want to use in the in the input fields. Each time an action is completed, a Dialog Box, appears listing the fields of the current screen with their current values. The kind of dialog box called depends on the kind of screen currently being processed (see Requirements).
Here you can determine:
if you want to save the field values you have inserted on the current screen (the "Adopt field values" checkbox)
if you want to hide the entire screen (the "Do not display screen" checkbox). This is only possible if settings are copied to your variant ("Adopt field values")
if field contents are saved (the "With contents" checkbox)
if the ready for input status of specific fields should be revoked (the "Output only" checkbox)
if specific fields should be hidden (the "Invisible" checkbox)
if specific fields should be mandatory the "Mandatory" checkbox)
You may or may not be able to select each of these checkboxes for every field depending on the field's type (--> Requirements).
Screen variants are created automatically for each screen where values have been saved (adopted). Enter screen variant names in the "Name of screen variant" field. These names must be unique. If the system is able to find a unique name for a screen variant it is automatically inserted into this field. The convention reads like so: (< name_of_transaction_variant>_(<client>)_<screen_number>).
Choose the function Continue to proceed. The following pushbuttons are available:
The Cancel function displays the current application transaction screen again. Here you can make changes to your settings.
The Menu functions function displays an additional dialog box wher you can deactivate menu functions.
The GuiXT function allows the user to edit a GuiXT script for the current screen (--> GuiXT).
The Exit and Save function exits and saves the application transaction. A list appears containing all of the screens in the application transaction that you want to save entries for (that is, all screens for which screen variants will be created).
Enter a short text for your transaction variant here.
Display settings can be changed as needed from this list in the future. Settings that require information at application transaction runtime (field values, table control columns) cannot be changed from this list.
Choose "Save". The system saves your transaction variant and the corresponding screen variants. The Workbench Organizer dialog box is displayed for the transaction variant and for each screen variant. Use it to assign each of these objects to a package.
You can also branch to this list using the Change values function during the function selection process.
Deleting Preassigned Values
You can delete all of the values you assigned to fields of a single screen in a transaction variant by resetting (deselecting) the Adopt field values checkbox. This deletes the screen from your variant, even those entries that were transferred to the variant during previous processing.
If a screen variant has already been created for this screen, then the system simply deletes the screen variant's transaction variant assignment; the screen variant itself is not actually deleted.
Individual fields can be deleted from transaction and screen variants by resetting (deselecting) their corresponding checkboxes.
If useful reward points.
Regards
Mangal

Transaction varient and screen varient

Hi all ,
What is the use of screen varient and transaction varient in CRM and What is the difference between them ?

hi there
What you can do with a transaction variant
Insert default values into fields
Change the ready for input status for fields
Hide various screen elements, menu functions or entire screens
Adjust table control settings
Note:
Transaction variants can only be used with dialog transactions.
How to create a transaction variant
Transaction variants are created with transaction: SHD0
In the field Transaction on SHD0 enter the transactioncode for the screen you want tpo modify (E.g. VA03)
In the field Variant on SHD0 enter the name you want to give the transaction variant (E.g. ZVA03)
Press Create
Now the screen for the transaction is shown and you can enter default values in the fields of the screen
Press Enter. Now a screen that enbles you to make further customizing (Hide, Output only, Invisible, Mandatory) if the screen fields is shown.
After you have finished customizing the screen press Enter to go to the next screen or ave and exit to save the Transaction variant
To run the transaction varian, you must create a new Transaction code in SE93 that referes to the Transaction variant. Choose Transaction with variant as Start object.
Note:
The transaction variant can also be called from a program that imcludes a call to function module RS_HDSYS_CALL_TC_VARIANT
Screen variants
To create a screen variant, use transaction SHD0. Use menu Goto -> Screen variants
The process to create a screen variant is similar to creating a Transaction variant. The difference between the two types is that a Transaction variant covers the whole transaction and therefore can have more than 1 screen, while a screen variant only can have 1 screen.
best regards
ashish

Transaction and Screen Variants.

14.10.2008
Hi friends,
I create Sales Orders with different document types. My requirement is, a document type (ZOEX) when accessed using VA02 only a limited number of fields (Ship to Party, Contract end date), Price ..) should be editable, the rest should be in display mode. How do i make use of transaction code SHD0. I would want to test this in my sandbox. Tried various forum messages but still not clear how to use SHD0. Please guide
Regards,
Udaynath.

Hi Shesagiri,
Thanks for your reply.
Using SHD0 , I created Transaction variant ZVA02 for Transaction code VA02 and in the first screen variant ZVA02S1, i made the field WBS element as invisible, continued with subsequent screen and made the fields Sold to Party, P.O number and P.O date as invisible and output only. After saving as local object when i use transaction code ZVA02 i dont find any changes coming up. Can you please guid me further.
Thanks and regards,
uday
Edited by: UDAYNATH KRISHNAN on Oct 16, 2008 12:35 PM
Hi Gurus,
Can someone help me with screenshots on transaction / screen variants. My requirement is the user should not be able to change any fields in the sales order when in change mode (VA02).
Regards,
Udaynath

Transaction and screen variant

Hi,
I've created a transaction in SE93 and i specified a screen variant.
When i execute my transaction, the variant fills the fields of the selection screen and wait for a validation. I don't want that. I want to skip the selection screen and display the next dynpro. Since the variant feeds the selection screen, I don't undersatnd why it asks fo a validation.
I want the same effect than a SUBMIT <program> USING SELECTION-SET <variant>.
Any ideas ?
Thanks

The two values that i pass through my selection screen are two CHAR. There is no control on these values.
When i call my transaction, the variant feeds the fields and then, we need to click on the execution button (with the green clock) to continue and pass to the other dynpro.
I dont know why it stays on the dynpro 1000 as the two have been filled....
Thanks

Transaction and screen variant SHD0

Dear Gurus,
I have created a variant in SHD0, now when i activated it, its working for all user ids.
Can i restrict it to certian users. If yes, how ?
kind regards

Hi Roopali,
May mentioned lick is helpful to you
http://wiki.sdn.sap.com/wiki/display/Snippets/TransactionVariant-AStepbyStepGuidefor+Creation
How to use SHD0?
Rgds
Suma

Call transaction and skip first screen

Hi,
I have a little but I think difficult problem
I have a selection screen and after that I call my dnypro. In this dynpro I can open a dynpro which looks like a popup where I have the possibility to call the same transaction with other input paramters.
the problem is when I make call transaction and want to go back I see the pop up dynpro which calls the transaction. so how can I close this popup dynpro by calling again transaction?

I think I can't eyplain it.
Following. I have:
call transaction trans: selection screen calls dynpro 100, in dynpro 100 button with dynpro 200 with starting parameters.
dynpro 200 calls again transaction trans with skip first screen.
now I have displayed again dynpro 100 with new values. When I now want to go back I can see dynpro 200 which called the transaction. So how can I achieve this that dynpro 200 isn't shown when I go back ?

CALL TRANSACTION AND SKIP FIRST SCREEN to specified tab in TCODE 'IW32'

Hi,
I am using CALL TRANSACTION AND SKIP FIRST SCREEN in ALV Grid Report to call IW32 tcode and it goes to tcode skipping the first screen. But it goes to the default header tab in the tab control. Whereas I wish to go to the specified tab 'OPERATIONS'.
Can any one help me, as to how to resolve this issue ?
Thanks in advance.

Sridher,
I have the similar requirement. but in my case its COSTS tab. Could you please provide the code you have used for this to work?
I used standard "call transaction with mode 'E' ". This seems to be working but I am not pleased by my effort. Is there any proper way that you might have followed ?
Greatly appreciated your help.
Regards,
Reddy

Transaction Variant and Screen Variant

Hi
I have created a transaction variant ZTX for transaction TX.
The First screen of transaction ZTX IS Screen 0100 for example.
The Screen variant is ZSVAR and only for the first screen of the transaction variant ZTX, which is created when creating the transaction variant.
Then, I activated the transaction variant to be a Standard Variant.
Now in my program, if I say,
1. Leave to screen 0100.
Then, it takes me to the initial screen of transaction ZTX but the effect of the transaction variant is not there.
But if i code it as
2. Leave to transaction TX.
I can see the effect of the transaction variant.
Why is this ?
More-over, I cannot code a " Leave to transaction" as I will lose a lot of history.
What could be the remedy ?
I am new to Transaction Variants and Screen Variants concepts.
Thanks in advance for your valuable inputs.
Kind Regards
Prasad

Hello Prasad,
Leave to transaction will be considered as a new dialog process, hence all memory will be cleared. Try look at the standard transaction TX whether it uses parameter ids on it screen fields. In your program, set these parameter ids with the last values you are working on, before you call "Leave to transaction".

No link "Evaluate Transactions and TBOMs" in Test Preparation screen

Hello,
In Test Management (Test Preparation Screen) i have no link "Evaluate Transactions and TBOMs" in the top of the screen.
As i understand from this link can check statuses of Business Processes in BPCA, so how can i find it?

run tcode solar_eval

Creation menu item using transaction varient or screen varient

hi,
Can we create pushbutton or menu item in standard program using screen varient or transaction varient.

No , u cannt . But u can do it by changing its PF-STATUS that to by using user exits.
Regards
Prabhu

Se16n screen varient

I am implementing an ossnote 1082841.
In that i need to maintain entries in T139A table.
so went to se16n then entered the
values specified by the note.
at the time of saving i got a
pop up like "save iniitial screen varient".
In that varient should be entered and there is a check box
user-speciific .
and a short text also need to be entered.
so please tell me what this screen varient means,
and what data i need to enter in that.
now i am doing the changes in development.
how to transfer this changes to production.
thank you so much for all the replies.

Hi Shiva,
A screen variant means a sample set of test data with which you want to execute your program/screen. Once you have entered a sample set of data, give a screen variant name, some description and then save it.
Next time when you want to execute the program you can pick up the same variant and there is no need to enter all the screen data again. Also this variant is saved againt your userid, so if you want to see all the variants for a particular transaction, remove the userid and then execute to check for all the variants.
Hope this clarifies your doubt.
Ashish.

Re: Transactions and Locking Rows for Update

Dale,
Sounds like you either need an "optimistic locking" scheme, usually
implemented with timestamps at the database level, or a concurrency manager.
A concurrency manager registers objects that may be of interest to multiple
users in a central location. It takes care of notifying interested parties
(i.e., clients,) of changes made to those objects, using a "notifier" pattern.
The optimistic locking scheme is relatively easy to implement at the
database level, but introduces several problems. One problem is that the
first person to save their changes "wins" - every one else has to discard
their changes. Also, you now have business policy effectively embedded in
the database.
The concurrency manager is much more flexible, and keeps the policy where
it probably belongs. However, it is more complex, and there are some
implications to performance when you get to the multiple-thousand-user
range because of its event-based nature.
Another pattern of lock management that has been implemented is a
"key-based" lock manager that does not use events, and may be more
effective at managing this type of concurrency for large numbers of users.
There are too many details to go into here, but I may be able to give you
more ideas in a separate note, if you want.
Don
At 04:48 PM 6/5/97 PDT, Dale "V." Georg wrote:
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save'button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
>
>
>
>
====================================
Don Nelson
Senior Consultant
Forte Software, Inc.
Denver, CO
Corporate voice mail: 510-986-3810
aka: [email protected]
====================================
"I think nighttime is dark so you can imagine your fears with less
distraction." - Calvin

We have taken an optimistic data locking approach. Retrieved values are
stored as initial values; changes are stored seperately. During update, key
value(s) or the entire retieved set is used in a where criteria to validate
that the data set is still in the initial state. This allows good decoupling
of the data access layer. However, optimistic locking allows multiple users
to access the same data set at the same time, but then only one can save
changes, the rest would get an error message that the data had changed. We
haven't had any need to use a pessimistic lock.
Pessimistic locking usually involves some form of open session or DBMS level
lock, which we haven't implemented for performance reasons. If we do find the
need for a pessimistic lock, we will probably use cached data sets that are
checked first, and returned as read-only if already in the cache.
-DFR
Dale V. Georg <[email protected]> on 06/05/97 03:25:02 PM
To: Forte User Group <[email protected]> @ INTERNET
cc: Richards* Debbie <[email protected]> @ INTERNET, Gardner*
Steve <[email protected]> @ INTERNET
Subject: Transactions and Locking Rows for Update
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for
any
ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
------ Message Header Follows ------
Received: from pebble.Sagesoln.com by notes.bsginc.com
(PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm))
id AA-1997Jun05.162418.1771.334203; Thu, 05 Jun 1997 16:24:19 -0500
Received: (from sync@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11825 for forte-users-outgoing; Thu, 5 Jun 1997 13:47:58 -0700
Received: (from uucp@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11819 for <[email protected]>; Thu, 5 Jun 1997 13:47:56 -0700
Received: from unknown(207.159.84.4) by pebble.sagesoln.com via smap (V1.3)
id sma011817; Thu Jun 5 13:47:43 1997
Received: from tes0001.macktrucks.com by relay.macktrucks.com
via smtpd (for pebble.sagesoln.com [206.80.24.108]) with SMTP; 5 Jun
1997 19:35:31 UT
Received: from dale by tes0001.macktrucks.com (SMI-8.6/SMI-SVR4)
id QAA04637; Thu, 5 Jun 1997 16:45:51 -0400
Message-ID: <[email protected]>
Priority: Normal
To: Forte User Group <[email protected]>
Cc: "Richards," Debbie <[email protected]>,
"Gardner," Steve <[email protected]>
MIME-Version: 1.0
From: Dale "V." Georg <[email protected]>
Subject: Transactions and Locking Rows for Update
Date: Thu, 05 Jun 97 16:48:37 PDT
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: quoted-printable
Sender: [email protected]
Precedence: bulk
Reply-To: Dale "V." Georg <[email protected]>

Transactions and Locking Rows for Update

I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
[email protected]------------------

I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
[email protected]------------------

How to create transaction or screen variant for custom tcode in module pool

Hi,
I have one module pool program with custome tcode ,i want to create transaction or screen variant for this tcode.Next time when we run this tcode we need a variant for this tcode.
I tried by using of SHD0 but it is working only for standred tcodes.Is there any possibilty please help me.
thanks,
Lavanya.

Hi,
you created a Custom Tcode for ur module pool Pgm..if u execute the Tcode in the output screen give the input details and press Save Option then variant will be created. Then you can use that variant.
otherwise.. while creating a Tcode..
select an option for Tcode type Tranasction With variant ..there u will provide the variant for ur Tcode ( which is already created ).
Regards,
PraVeen.

Transaction and screen varients

Similar Messages

Maybe you are looking for