Configure Custom Fields скачать в хорошем качестве

Configure Custom Fields

Step-by-Step Configuration Process Step 1 — Define the Fields in Customizing Includes Before you can select custom fields in the BIT class configuration, you must first create the field definitions at the ABAP Dictionary level. The course specifies three Customizing includes, one for each record type that supports customer fields: • CI_FKKBIXBIT_IT — for custom fields on main items • CI_FKKBIXBIT_PY — for custom fields on payment data items • CI_FKKBIXBIT_TX — for custom fields on tax items The course explicitly states: "To use customer fields in the configuration of billable item classes, you must first add these fields for each record type in one of the following Customizing includes." This is an ABAP development task. You would use transaction SE11 (ABAP Dictionary) to add your field (e.g., "SPEED" as a CHAR or NUMC type) to the appropriate include structure. In the Speed example, since the field is needed on the main item, you would add it to CI_FKKBIXBIT_IT. An important caveat from the course: "SAP does not deliver customer includes. You have to generate them, before you can use them." This means the include structures must be created first if they don't already exist in your system. Step 2 — Select Customer Fields in the BIT Class Configuration Custom field selection is step 2 of 6 in the overall BIT class configuration sequence that the course outlines: 1. Select interface components 2. Select customer fields (optional) 3. Manage tables of billed items 4. Manage tables of billed items for simulation 5. Activate configuration 6. Generate interfaces for billable item classes You perform this in Customizing under: Financial Accounting (New) → Contract Accounts Receivable and Payable → Convergent Invoicing → Basic Functions → Billable Items → Billable Item Classes → Maintain Billable Item Classes. Within the BIT class maintenance screen, after choosing your interface components, you select which customer fields from the includes should be part of this particular BIT class. Not every BIT class needs every custom field — the Speed field might be relevant for a data services BIT class but irrelevant for a voice telephony BIT class. Step 3 — Automatic Work Structure Synchronization This is a critical step that the system handles partially on its own. The course explains: "To ensure that customer fields are included in the processing of billable items, the system checks the completeness of the work structures when the configuration of the billable item class is activated. The system automatically adds any missing customer fields to these structures. These fields are added in the related Customizing includes of the work structures." Work structures are the in-memory structures that the billing engine uses at runtime. Fields defined in interface components (and customer fields) must be present in these work structures, otherwise data may be lost during processing. The system performs this check automatically upon activation, but you can also verify consistency manually using report RFKKBIXBITSTRUCCHECK, which compares the fields of the work structures with those of the interface components and displays any inconsistencies. Step 4 — Activate the Configuration Once customer fields are selected, you activate the BIT class configuration. The system validates that the class is internally consistent and error-free. Only one active version can exist at a time. If the class is already productive, adding customer fields is still permitted — the course notes that even for classes with configuration status "Released as Productive," you are allowed to "Add new fields" as a compatible enhancement. Step 5 — Generate Interfaces Using transaction FKKBIXBIT_GEN, you regenerate the interfaces. This step physically creates or modifies the database tables and RFC function modules to include your new customer fields. The generation process creates the actual columns in the database tables where the custom field values will be stored, and updates the data transfer function modules so that external systems can pass values for these fields when loading billable items. The course warns about generation behavior depending on the productive status of the interface: for non-productive or productive (test) interfaces, the system deletes and regenerates all objects, causing data loss. For productive interfaces, the system only regenerates objects that are new or modified, preserving existing data. Since adding a customer field to a productive class is considered a compatible enhancement, existing data should remain intact.