Proposing Organizational Mappings
Using report /SKYBFR/YAI_DSN_ORG_PROPOSE to find and maintain organizational mappings
Report `/SKYBFR/YAI_DSN_ORG_PROPOSE` finds the organizational fields in your nominated data sources and proposes the mappings needed by *Organizational Authorization for Data Sources*.
It never activates anything. Every mapping it writes is inactive, so no data is filtered until you activate it yourself.
Why not just type the mappings by hand
Because organizational fields are hard to spot reliably, and missing one means that dimension is left unrestricted on that data source.
VBAK has 152 fields. Five of them carry an organizational unit, and one is easy to get wrong in each direction:
| Field | Check table | Dimension |
|---|---|---|
| BUKRS_VF | T001 | Company code |
| VKORG | TVKO | Sales organization |
| GSBER | TGSB | Business area |
| GSKST | TGSB | Business area, from cost center |
| KOKRS | TKA01 | Controlling area |
The company code field is called BUKRS_VF, so looking for a field named BUKRS finds nothing. Meanwhile PA0001 has a field called WERKS which is the personnel area, not the plant — so looking for a field named WERKS finds the wrong thing.
The report therefore matches on the dictionary check table of each field, never on its name. That is a definite relationship rather than a guess.
Running the report
Selection screen
Nominated data source — restrict to particular data sources, or leave empty to examine all of them.
Mode — three options, of which the first is the default:
| Mode | What happens |
|---|---|
| Display only | Nothing is written. You see the proposals and can leave. |
| Change, save by double-click | Nothing is written on start. You choose rows to save from the list. |
| Change, save all unambiguous | Every unambiguous proposal is saved immediately, then the list appears. |
In both change modes you can still save individual rows from the list. Ambiguous proposals are never saved automatically in any mode — see *Resolving ambiguous proposals*.
Transport request
The mapping table is a customizing table, so its entries belong in a transport request. The first time the report saves something in a session it asks you to choose or create a customizing request. Subsequent saves in the same session go to the same request without asking again.
If you cancel the request dialog, nothing is written. The report will not change customizing that cannot be transported.
Reading the result list
The list shows the mapping table’s own columns, so you are looking at exactly what would be written:
Data source · Dimension · Field name · Strategy · Lookup table · Lookup fields · Active
followed by three columns that explain the proposal:
| Column | Meaning |
|---|---|
| Status | What will happen to this row, or what already has |
| Check table | The dictionary check table that produced the match |
| Field description | The field’s own dictionary description |
The lookup columns and Active are always empty. That is informative: the report only proposes Direct mappings, and those are exactly the fields a Derive mapping would need filled in by hand.
Status values
| Status | Meaning |
|---|---|
| Proposed | Not yet in the mapping table. Can be saved. |
| Mapping already maintained | This dimension is already mapped for this data source. Nothing to do. |
| Ambiguous, double-click one to keep | Two or more fields compete for this dimension. You choose. |
| Written as inactive | Saved during this run. |
Resolving ambiguous proposals
A dimension can be mapped to exactly one field per data source. Where two fields of the same data source point at the same check table, the report cannot know which one you mean.
VBAK is the standard example: both GSBER and GSKST point at TGSB, so both are proposed for the business area dimension. GSBER is the business area of the document; GSKST is the business area derived from the cost center. Only one of them should drive the authorization filter.
To resolve it:
- Choose a change mode on the selection screen.
- Double-click the row you want to keep.
- Confirm the dialog.
The row is saved as inactive, and the competing row changes to *Mapping already maintained*, showing that the choice has been made and the alternative is no longer available.
The report never picks for you. Writing an arbitrary one of the two and silently discarding the other is precisely the outcome this behaviour exists to prevent.
What the report cannot find
Two kinds of organizational field are invisible to check-table matching, and both must be added by hand in SM30.
Fields with no check table. VBAK-KOSTL is a cost center, but the field carries no check table, so nothing links it to the cost center dimension. It will not appear in the proposal list.
Derive mappings. Nothing in the dictionary states that a plant leads to a company code, so a mapping that needs translation through a lookup table cannot be proposed. Add these manually.
Treat the proposal list as a strong starting point, not a complete inventory. After running the report, review each data source you intend to restrict and ask whether it carries an organizational unit the report did not find.
After running the report
The proposals are saved but inactive, so nothing is filtered yet. Continue with the setup sequence in *Organizational Authorization for Data Sources*:
- Complete any Derive mappings and add any fields the report could not find.
- Grant the corresponding authorization objects in the roles that need them.
- Activate one data source for one user group and verify the results.
- Widen gradually.
Granting the roles before activating is important. A user with no authorization for a mapped dimension is refused outright once the mapping is active.
Messages
| Message | Meaning |
|---|---|
| No organizational fields found for the selected data sources | Either the data sources carry no matching field, or none are nominated in the selected range. |
| *n* proposals written as inactive | Saved successfully and recorded in the transport request. |
| Nothing to write, all proposals are maintained or ambiguous | Nothing was eligible for automatic saving. Resolve ambiguous rows individually. |
| Display only. Set a change mode on the selection screen to save | You double-clicked a row while in display mode. |
| This row is already maintained | The dimension is already mapped for this data source. |
| No transport request assigned, nothing was written | The request dialog was cancelled, or the request could not accept the entries. |
| Two rows share a dimension, only one can be written | Reached only in the bulk mode when the data is inconsistent. Resolve individually. |
| Proposals could not be written | The database update failed. Check SLG1 and your authorization for the table. |