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 mappings by hand
Because organizational fields can be hard to identify reliably, and any missing field can mean that a certain 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 never matches on a field’s name. It matches on what the dictionary says the field is.
The two matching rules
Check table. The field’s dictionary check table matches the one recorded for a dimension. VBAK-BUKRS_VF has check table T001, so it is the company code regardless of what it is called. This is a definite relationship rather than a guess, and it is the stronger of the two rules.
Domain. The field’s dictionary domain matches the one recorded for a dimension. This finds fields that carry no foreign key at all, which check-table matching cannot see: CDS view fields, custom tables typed on a plain data element, and standard fields such as VBAK-KOSTL, which is a cost center but has no check table.
Domain matching is broader, and broader means it also finds fields that carry an organizational unit without governing access to the row. RBUKRS and SBUKRS both carry the BUKRS domain, but they are a partner and a sending company code. Mapping one of those instead of the company code that owns the document would filter on the wrong thing.
For that reason the two rules are kept apart. Each proposal shows which rule produced it, domain matching can be switched off on the selection screen, and only check table matches are ever saved without being reviewed.
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 check table proposal is saved immediately, then the list appears |
Also match on domain — on by default. Switch it off to see check table matches alone.
In both change modes you can still save individual rows from the list, including domain matches. 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 the columns that explain the proposal:
| Column | Meaning |
|---|---|
| Status | What will happen to this row, or what already has |
| Matched by | Which rule produced the proposal: check table or domain |
| Check table | The field’s dictionary check table, if it has one |
| Domain | The field’s dictionary domain |
| 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 |
| Dimension has no active source | No authorization object grants this dimension yet. Cannot be saved |
| Written as inactive | Saved during this run |
A mapping written against a dimension with no active source would refuse every user the moment it was activated, so those rows are shown but cannot be saved. Register a source in /SKYBFR/YAIOSRC first.
Resolving ambiguous proposals
A dimension can be mapped to exactly one field per data source. Where two fields of the same data source match the same dimension, 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.
Domain matching makes this more common, since a table with a partner or sending organizational unit now shows both. That is the intended behaviour: the alternative is that the report quietly picks one.
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.
Where the row you are keeping was found by domain matching, the confirmation dialog says so and asks you to confirm that this field governs access to the row. Read that one rather than clicking through it.
The report never picks for you. Writing an arbitrary one of the two and silently discarding the other is precisely the outcome this behaviour is meant to prevent.
What the report still cannot find
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 in SM30.
Fields with neither a matching check table nor a matching domain. A calculated column in a CDS view, or a custom field typed on a domain of its own, has nothing for either rule to match. 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.
The framework will also tell you
You do not have to rely on the report alone to catch an omission. Where a data source is read and carries a column that matches a dimension by check table or domain, but has no active mapping for that dimension, a warning is written to the application log on every read.
That covers the case the report cannot: a data source nominated after the report was last run, or a mapping someone deactivated. Check SLG1 periodically for these warnings.
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
- Confirm any domain matches you intend to keep
- 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 check table proposals are maintained or ambiguous | Nothing was eligible for automatic saving. Save domain matches and 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 |
| Maintain an authorization source for this dimension first | No object grants this dimension yet. Register one in /SKYBFR/YAIOSRC |
| 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 |