Why not help your end user through the day by hanging on to relevant information by means of defaults ?
Here's some ins and outs
Parameters can be set, fetched or both using an option on PARAMETER
fields. Hanging on to the last purchase order that the user worked on makes the job of using the system much easier. Your end user will become accustomed to parameter settings and standard SAP applications feature it in almost every corner of the system. Check out the system's help text on the PARAMETERS
and/or SELECT-OPTIONS
statement option MEMORY ID pid
.
Setting (or getting) parameter settings without actual selection screen ? Check out the help text on the SET PARAMETER
and GET PARAMETER
Statements.
Creating your own parameter ID can be very handy if you want to allow your user to do something extra, e.g. if a "mass change" functionality is restricted to say 100 entries, your end user may want to lift this restriction in some cases. As a "Backdoor" a parameter ID could be created and checked. Here's how:
- Create the parameter ID via transaction
SM31
with table nameTPARA
, name it e.g.ZPO_BACKDOOR
- Fetch parameter settings (which are user-specific) with:
get parameter id 'ZPO_BACKDOOR' field g_parameter_po.
- Instruct your end user (preferrably on the message longtext of the message that is thrown for the restriction).