SAP Customizing - Field Display Characteristics

1.4. Field Display Characteristics
1.4.1. Global Field Display Characteristics
1.4.2. Configure application transaction fields

Field Display Characteristics



Field Display Characteristics
Field display characteristics can be defined globally or for a transaction. This technique was developed to hide the complexity of the SAP System from the user when possible. The user is spared from entering data in fields that are always the same.

By defining global field characteristics (or "global fields") certain fields in screens can be influenced in all the transactions where they appear. Ready-for-input screen fields can be preset with a value. They can be set so as not to accept field entries, and they can be hidden.

Using transaction-related field characteristics ("transaction variants") you can preset fields occurring in a transaction, define characteristics of fields, or hide whole screens in a transaction if they are not required there.

Example of the use of a global field:
Your company only uses one company code, 0001, in its SAP System. You do not wish to hide the company code from the users, but they should not have to decide what to enter in this field. You can use a global field to preset the company code to 0001 in all screens in every transaction. You can also determine that the field should not be ready for input.

For extra differentiation, global fields can refer both to domains or data elements. For example, a distinction could be made between the "sender" and "receiver" company codes at data element level.

Example of the use of a transaction variant:
Your company uses just one order type on the purchase requisition, NP for normal purchase order. You want to preset the value in transaction ME21 so no employees use the wrong order type or need to decide which order type to enter. To do this you create a variant of transaction ME21 that has the order type preset to NP and the field set to not ready for input (or assigns the "hidden" characteristic to the field).\

 Global Field Display Characteristics

SAP Customizing - Guide - Set Currencies - Calender

1.2. Set Currencies
1.2.1. Check currency codes
1.3. Set Calendar
1.3.1. Maintain calendar


-->Set Currencies

 

 Check currency codes

The currency table must have entries for all currencies which occur in your business transactions.

Standard settings

In the SAP standard recipient system, all currencies are defined according to the international ISO standard.

SAP recommendation

SAP recommends that you use the ISO standard for your additional entries.

If your entries do not correspond to the ISO standard, you will not be able to use data exchange in international communication (e.g. bank clearing transactions).

Actions

1. Check the currency entries for completeness.

2. Add the missing currency entries as required.

3. Use the ISO standard for your additional entries.

 

 

Set Calendar

SAP – Customizing Guide - General Setting

1. General Setting
1.1. Set Countries

1.1.1. Define Countries
1.1.2. Set country–specific checks
1.1.3. Insert regions

-->Set Countries


-->Define Countries
You must include all countries with which your company has business relationships. You need the following
information for each country:

• General data
• Foreign trade characteristics
• Further test data

This data is then checked during master data maintenance.

Standard settings
In the SAP standard delivery system, all countries are defined according to the international ISO standard.

SAP recommendation
SAP recommends that you use the ISO standard for your additional entries.
If your entries do not correspond to the ISO standard, you cannot implement data exchange in international
communication (e.g. payment transactions with banks).

Activities
1. Check that the country entries are complete.
2. Add the missing countries, if necessary.
3. Use the ISO standard for your entries.
4. For each country, maintain the associated detail screen. In the detail screen you must, for
example, create test data.

-> Set country–specific checks

IDOC - Displaying - Debuging - Editing

IDOC Testing

T-Codes.

 WE19 Test tool
 WE12 IDoc test: Inb. Proc of Outb. File
 WE16 IDoc test: Inbound File
 WE17 IDoc test: Inbound status report

If you want to reprocess IDOCS

Ø  BD87 Process inbound IDocs

Ø  BD88 Process outbound IDocs

To Display the executed IDOC to check the status of idoc.

Ø  WE02      

Ø  WE05

WE19

Debugging an IDOC

Workflow Concepts - Tasks - Binding - Containers - Business Objects - Workitem

10: For this demo example, you will trigger the event by writing a custom code. 

The starting point of a workflow is the object/event trigger. Without this the possibility of building a workflow is ruled out. The triggering of events is achieved through a number of mechanisms some of them are listed below:

Events can be created in the following ways:

Change document

Status management

Message control

Custom code: The function module SWE_EVENT_CREATE is used to trigger the event. Don’t forget to write a commit work after the function module call.

11. A Single Step Task.

By now you have defined a Business Object with key fields Company code, Accounting document number and Fiscal year. You have created a method and an event for the Business Object. You have also defined the Task for linking the method and event and also defined containers and performed the binding definition. You have also defined the custom code to trigger the event. Now, your objective is to display financial document using CALL TRANSACTION ‘FB03’, when the event is triggered. For this you must put the following piece of code inside the method of the object and generate it.

  

Check that you have given your username in the agent assignment section of the task. Now when you execute the custom code the event will be triggered, so the key fields will be inside the event container, from there it will pass on to the task containers you have defined. This transfer is controlled by the binding definition you established before activating the task. From the task container the key fields will be available inside the Business Object. Thus they will be assessable inside the Object Method, where you use them to display the financial document.

12. Some Workflow Concepts

What is Workflow: Workflow is a tool to automate business process

Workflow can be single step or multiple steps.

Single step workflows are “Tasks” and multiple step workflows are “Templates”.

Workflow determines which tasks are executed, when, under which conditions and by whom.

Workflow definition is made up of individual steps. When creating a step in a workflow definition, the step type must be specified first.  Specify the step type as Activity here.

Activity can be a single step task with basic business functionality

     Can be a multi-step task, which reference to a workflow definition

What are the different elements of Workflow:

         Tasks: Activity in which an object method is carried out.

Business Objects: Identifiable specific instances of an object type.

         Work Item: A work item is an actual representation of a task.

Agent: An agent is an executor of a work item. Types of agents:

Possible agent

Deadline agent

Notification agent

Methods:

Events

Containers:

Containers are used to store field values, multi-line lists of field values, object references and multi-line lists of object references.

All import/export parameters of the workflow tasks/workflow templates are specified as elements of the workflow container.

Containers only contain control information for the workflow system.

Containers do not contain application business data.

Binding:

Binding definition executed at runtime

Used for transferring data from one container to another container

Used for assigning values to container elements

Binding is always performed with reference to the elements of a container.

Data flows between the workflow components as follows:

1)  Triggering event is created in application.

2)  The workflow receives the application data from the event.

3)  The workflow step transfers application data from the workflow to the synchronous customer/standard task.

4)  The task transfers application data from the task to the object method parameters.

5)  The execution of the object method may change the application data.  The object method parameters transfer data to the task.

6)  The task transfers application data back to the workflow.

7)  The workflow step transfers application data from the workflow to the synchronous customer/standard task.

8)  The workflow step transfers application data to the standard role parameters.

9)  The task transfers application data from the task to the object
method parameters.

10)            The execution of the object method may change the application data.  The object method parameters transfer data to the task.

11)            The task transfers application data back to the workflow.

12)            The workflow step transfers application data from the workflow to the asynchronous customer/standard task.

13)            The task transfers application data from the task to the object
method parameters.

14)            The terminating event transfers application data to the task.

15)            The task transfers application data back to the workflow.

The dataflow between the application and workflow container elements and between the elements of the workflow container, event containers, task containers, role containers, and method parameter containers is controlled by a set of rules called the binding definition.