Ansicht
Dokumentation
RNUTROE0 - IS-H: Transport Organizational Units
Vendor Master (General Section) CL_GUI_FRONTEND_SERVICES - Frontend ServicesThis documentation is copyright by SAP AG.
Description
You can use this program to include organizational units (OUs) and their dependent tables in a change request. You can select an existing request or create a new one.
You can select the OUs according to the institution, identification key of the organizational unit, the date on which the organizational unit was created, and the date on which it was last changed.
Please note:
You should only run this program if you are fully aware of the requirements, operation, and consequences. If necessary, contact your consulting partner or SAP Consulting first.
SAP does not accept liability for any damage resulting from the use of the program.
You cannot use the program if the business function SAP Patient Management Rearchitecture BP/OM (ISH_BP_OM) is active in your system.
Selection
OUs that are flagged for deletion are included in the request to allow the flag to be copied to the target system.
The program also takes account of the following:
- SAPscript long texts for the comment field for the selected OUs
- Entries for the organizational hierarchy
- Inter-departmental assignments
- Assignment to building units
- Statistical beds
Generic entries (‘*’, for instance for the statistical beds) are included in the transport request if the identification key of an OU appears directly in one of the dependent tables. This means '*'-'*' entries for statistical beds are never included, but entries such as '*'-'SURG1' are if you select the organizational unit 'SURG1'.
Address data records stored in the central address management facility are not included in the transport to prevent number range conflicts in the target system. This does not pose a problem as long as the OUs are not changed in the target system.
Doors are not included, but are processed by program RNUTRBE0 (Transport Building Units) instead. The identifier table is not included in the transport either. This means that the identifiers have to be redefined in the target system. Change documents cannot be transported.
You also have the option of including the OU/cost center assignments. You do this by selecting the relevant indicator on the selection screen.
When selecting the OUs, bear in mind that the selection conditions are logically linked with an AND operator. This means if you enter a date interval for both the creation date and change date, the OUs that were created AND changed in the specified interval are included. However, if you want to select all OUs that were created OR changed within a given period, you must run the program twice: once specifying the creation date and a second time specifying the change date. The request may then contain duplicate entries, but this is not a problem.
The objects are not actually added to the request in test mode. Instead, the system checks this internally to determine whether they would be added successfully in an update run. If you select Test Mode, you must still always select a request or create a new one. There is no test mode for creating a request.
Requirements
If you want to use the function for transporting OEs to a different client or system, you must ensure that no inconsistencies result, since consistency checks cannot be run during transport.
You should always make changes in one system and then transport them to the other. You should decide on one transport direction: either always from the text system to the productive system, or vice versa, but not one direction and then the other.
Since master data is based on Customizing data, we recommend always transporting the Customizing data first. You should therefore always use automatic recording of Customizing changes.
Inconsistencies can still arise if you have already maintained OUs in the target system that are not defined in the same manner in the source system, for example if they have a different identifier or were created in a different order. The order in which you create the units is important, since address management assigns numbers internally with the result that two identical organizational units in the database can have different address numbers.
Inconsistencies can also arise if you transport OUs without building units, since this leads to inconsistencies in the assignments between the OUs and building units.
The OUs are transported to the target system with the respective release status they have in the source system. In other words, if an OU is not released in the source system and is transported, it is also not released in the target system. Consequently, you should release the building units in the source system prior to executing the transport. You could then run the release program in test mode in the target system to check the result of the transport.
The program is intended for transporting minor changes. You cannot use the program to transport deletions, since only existing entries are added to the transport request. If you make extensive changes or delete objects, we recommend transporting the entire tables by manually adding them to a transport request. Here too, it is vital that you ensure consistency. Contact your consulting partner if necessary.
Output
The following are output:
- Number of the transport order
- Number of the task
- Number of records included per table
BAL_S_LOG - Application Log: Log header data TXBHW - Original Tax Base Amount in Local Currency
This documentation is copyright by SAP AG.
Length: 5942 Date: 20240520 Time: 074125 sap01-206 ( 127 ms )
