Ansicht
Dokumentation

BE_BEA_ITEMCDET_FCAT - Maintain Field Catalog

BE_BEA_ITEMCDET_FCAT - Maintain Field Catalog

Fill RESBD Structure from EBP Component Structure   ROGBILLS - Synchronize billing plans  
This documentation is copyright by SAP AG.
SAP E-Book

In this step, you can define flexible criteria for advanced item category determination.

You must have defined a data element in the ABAP Dictionary for the new field.

Always check first to see if there already is a field in the field catalog that you could use for your purposes.

In the field catalog, you specify which fields of CRM Billing can be used for determining the item category.

If you wish to use a field in order to determine the item category, you must add this field to the field catalog and assign the appropriate attributes to it. These attributes are described in more detail below.

The field catalog contains the fields that may be used for defining condition tables.

The screen for maintaining the field catalog is divided into 3 areas:

  1. Field catalog area
  2. Field and data element details (can be shown or hidden)
  3. Log details (can be shown or hidden)

Field Catalog Area


The field catalog area is the principle element in the transaction - this is where you can create new fields and edit existing ones. Go into Change mode, and maintain the following fields:

  1. Type of Subcommunication Structure (you can only enter a value in this field if you have selected the 'All Fields' option - otherwise, a specific type of subcommunication structure will be defaulted):
    1. Header: fields that almost never change during a processing session.
    2. Item: fields that change at the billing due list item level.
    3. Header/Item: fields that are used in billing due list items but which are identical for many items.
    4. Fields Not Included: fields that can be contained in condition tables but which are not contained in the communication structure. Fields of this type could, for example, be supplied with values from other fields in the access.
    5. All Fields: overview of all previous subgroupings.
  2. Field:
This is where you enter the field name. Please remember that this must begin with Y or Z (the namespaces reserved for customers) - all other namespaces are reserved for exclusive use by SAP.
  1. Virtual:
This attribute determines how a field may be used. At present, you can choose from the following options:
  1. A = Internal use only (never appears on the user interface)
  2. B = External use only (never appears in a condition record)
  3. C = Internal and external use
  4. D = Access field only (does not appear either on user interface or in condition record)
Fields of type A are used internally to display values such as the unique internal product ID; fields of type B are used externally to display values such as the product number. If the values displayed by a field are the same when used internally and externally, then the field is a type C field.
Fields of types A, B, and C can always be included in condition tables, whereas fields of type D are only ever used in the communication structure for accesses. During access, a field of type D is assigned to a field in the condition table - the local currency field to a currency field, for example.
  1. Selection Type:
    This attribute determines how the field is used for selecting condition records. At present, you can choose from the following options:
    1. A = Any type of selection possible
    2. B = Several single values possible
    3. C = One single value possible
    4. D = Not used for selection
  2. Data Element:
The data element shows the business concept underlying the field in question, and also determines the data type of this field. Theoretically, you can select any data element that exists in the system.
When you enter the data element, the system displays the field label, data type and field length in the other columns of the table control (these columns are not ready for input).
Important! A data element can occur only once in the field catalog.

You can use the following functions in the field catalog area:

  • Select
  • Select Block
  • Deselect
  • Position

Field and Data Element Details


This area can only be maintained for one specific field that has been selected from the field catalog. You access this area by choosing the Details icon (icon with the magnifying glass) for the selected field.

  1. Relationships
Here, you can maintain relationships between the selected field and other fields. Relationships are particularly useful if the internal and external use of a field are different.
Example:
The field PRODUCT (unique product ID) is only used internally. If the corresponding information is to be displayed externally, the fields LOGSYS (logical system), PRODUCT_ID (product) and PRODUCT_TYPE (product type) are concatenated and used for this external display. Therefore, these 3 fields should be entered as 'relationships' of the PRODUCT field.
Relationships should only ever be defined for internal fields (that is, fields of type A as per the 'Virtual' column in the field catalog area). You can then enter external fields as 'relationship' fields for the field in question. If the uses (that is, external and internal) do not match up, the system issues an error message to this effect.
You can only maintain relationships to fields from the global field catalog (table /SAPCND/T681FF).
  1. Dependencies
Here, you maintain dependencies between the data element of the field selected and other data elements. These dependencies are checked when condition records are processed.
You can only select data elements that are in the global field catalog and define these as dependencies.

Log Details

This area displays the application log that was created when Save and/or Generate was executed the last time the transaction was called.

You can use the standard functions of the application log here.

The logs are stored in the following object of the application log: COND_TECHNIQUE (subobject FIELD_CATALOGUE).

You can display all logs by calling transaction SLG1 (Evaluate Application Log). You can use transaction SLG2 (Delete Out-of-Date Logs from Application Log) to delete logs that you no longer require.

You can use the following functions in all screen areas:

  1. Save
When you save the field catalog, entries are written to (or deleted from) tables /SAPCND/T681FA, /SAPCND/T681FF and /SAPCND/T681F.
When you maintain relationships, changes are written to table /SAPCND/T681FR.
When you maintain dependencies, changes are written to table /SAPCND/T681FD.
  1. Delete
The lines selected in the field catalog, relationships or dependencies area are deleted.
When you delete fields, the corresponding relationships are also deleted. The dependencies of the corresponding data element are only deleted if the data element has no further relationship with another data element.
If the field you wish to delete is used in condition tables or accesses, the system issues a warning. You should only delete the field if the tables and accesses in question have not yet been used in the production system.
  1. Generate
When you execute this function, the system generates the communication structures relevant to the field catalog. Here is a list of these communication structures:
  • BEAS_CND_ACS_H (header fields)

  • BEAS_CND_ACS_M (items fields that are mostly the same for all items)

  • BEAS_CND_ACS_ICOM (items fields that are mostly different for all items)

  • BEAS_CND_ACS_TOTL (the entire structure used to communicate with the data determination service)

  1. Transport
Changes to the field catalog are transported using a transport object (name /SAPCND/CUSTOMIZING, transaction SOBJ) of type T (individual transaction object). When you save data, the system retrieves a transport request to record the changes.
Only entire, consistent logical objects are transported - in other words, the relationships and dependencies of a field (if there are any) are transported along with the field. The consistency of a transport request is checked using the transport methods assigned to the transport object:
BEFORE _EXPORT - method for checking the consistency of the table entries before they leave the source system
AFTER_IMPORT - method for generating the dependent objects in the target system
It is also possible to transport the entire field catalog for an application manually.






rdisp/max_wprun_time - Maximum work process run time   BAL Application Log Documentation  
This documentation is copyright by SAP AG.

Length: 10049 Date: 20240608 Time: 015640     sap01-206 ( 139 ms )