Skip to end of metadata
Go to start of metadata


This document covers frequently asked questions from Consultants, Partners and Customers about New Export/Import for SAP IBP. If you have additional questions that need to be added, please contact the SAP IBP Customer Engagement Team (engage-ibp@sap.com). 

New Export/Import for SAP IBP PDF | Recording

 Q: In a 3-system landscape, will I be able to send a version of a model to quality, and then later transport the same version of that model to production, even if the model had been subsequently changed in development?

A: Yes. This is one of the many benefits of the new transport mechanism. The exports from development can be done independently of when you exactly import into test/QA and then forward to production.

Example: You could do an export on Monday from development system, then do a change in development on Tuesday and export again. You do an import on Wednesday of the export from Monday into test/QA. Then test and forward on Thursday to Production. You also import on Thursday the export from Tuesday into test/QA and import on same day the forwarded export from Tuesday into production. Etc.

When you export a collection, that version will be frozen. So, when you import into the second system, the same version is then forwarded to production - with the elements and configuration state of when you exported it.

 Q: I would like to know what the main benefit we can expect from this. In a 3-system landscape, what will we need to do to have the end results the same as what we are used to now?

A: You will have the same results if you set up your collections as in the old “Transport Model Entities” app (each planning area in a separate collection with master data types, time profile, and attributes, each forecast model in a separate collection, each segmentation profile in a separate collection, etc.). But our guideline proposes to assign the items in IBP to collections in the following way:

  1. one collection with all attributes, time profiles
  2. master data types and planning areas – one collection per planning area
    If you share master data types between planning areas, separate the MD types in the collection from the planning area.
  3. forecast models, operator profiles, etc. – one collection per planning area
  4. planning filters – one collection per planning area
  5. permission filter – one collection per planning area
  6. business roles, attribute permissions
  7. pages and spaces

If you have parallel workstream with different GoLive dates such as Demand in January and SOP in July, you may want to separate items 3, 4, 5, and 6 additionally by workstream.

If you want the same behavior as in the old tool, you can simple not transport the business roles and pages and spaces and just create them manually. 😊

 Q: Items that are not part of an export collection but which are already present in production system, will they be deleted in subsequent transport, or will those items be as is?

A: Items which are not part of the export will not be touched – they will also not be deleted. But creating local objects in target systems (production system; test systems in three system landscapes) is not advisable as you could easily create dependencies in these systems to items which are part of the export. If such dependencies exist only in the target systems, you cannot see implications of a change in the development system and therefore create inconsistencies.

Example: you have a character-based attribute of length 10 in the export, but do not use this attribute in the development system. In the target system you have a planning area and master data with data in it. If you now shorten the attribute to length 5, this will be possible in development. But when imported into the target system, the data might be corrupt.

 Q: In the demo, it shows only items not assigned yet to any collection. Is my assumption correct that an item can only be assigned to exactly one collection?

A: Yes.

 Q: Does the list of items that can be added to a new collection automatically determine based on changes to the system after the last planning area activation?

A: No, not right now. 

 Q: Would there be a tool to create single-item collections out of all IBP components? E.g. if there are 50 copy operator profiles, it'd be required to create 50 collections in order to be able to move single items whenever needed as in today's tool.

A: No, not right now, but you could group the copy operators maybe in groups per planning area. If you have an urgent correction you can use the hotfix process to do that. This of course requires that you do exports once per release, but for inter-release-changes of the operators, you can use the hotfix button and send out just a single-object change.

 Q: So, essentially, you can now export individual objects e.g., a key figure and its dependencies, or do you still need to move the entire planning area?

A: For the key figures and planning levels: they are still part of the planning area in the transport. But you can now more flexibly export time profile, master data types, attributes. There is a customer influence which requests the split of key figures and planning levels out of planning areas: Rework PA transports and PA copy to allow moving only selected components, not whole PA (222464).

 Q: Are you exporting to other IBP System or to S4?

A: Only to another IBP system in your cloud landscape.

Q: Can we copy collection versions? Or will we have to select all items every time for export?

A: The collections usually are stable, and you only add new items to them. The export is done on the collection. If you change items which are already in a collection, these items will show that they have been changed and any time you have a good state simply go to that collection and click export.

 Q: Will the items stay in the collection after import as well?

A: On the target / importing system the collections are only used in the import. On the source / exporting system / development system, the items stay in the collections, but their status is updated depending on whether there was a change / deletion.

 Q: If an attribute is assigned to multiple items, does that need to be added to all the collections? That attribute might already be part of another collection.

A: You should add all shared attributes in a single collection which you use as a basic collection you distribute always to all systems.

 Q: Why is it recommended to group all operator profiles? It's basic flexibility to be able to move only changed operators, not all at once.

A: Even if you have all operator profiles in one collection, the import will automatically only take over the changes from the last import. The new transport always takes over the delta only if you import each version. Only if you skip a version or there was no import at all of a collection before, then the full collection is imported.

 Q: If we create collection by different types, we will have to transport all collections together always due to dependencies (as far as I understand). What if we transport only MDT type collection and not attributes collections?

A: Remember that you can mass-import in the target systems, so you can import not only one but several collections with one click. Nevertheless, it may happen that you import a collection which has dependencies to objects which are not yet in the system. In this case the activation will fail, or the operator will not run correctly and return errors. Therefore, it’s important that you manage your dependencies correctly and build the collections as proposed depending in the planning area – maybe you also think about a good naming convention for the collections to reduce such issues. Use the “Extensibility Inventory” app to identify dependencies.

 Q: Collection A and Collection B are created and exported. Then collection C is created as a merge of A and B. Once collection C is exported, is it still possible to export A or B individually?

A: No, the collections A and B cannot be exported any more then. Only collection C can be exported.

 Q: How do you do then bugfixes, when you want to do only partial transports?

A: The transports are usually partial transports as on the receiving side the system identifies whether the last version of the export was already in system and if so, then only imports the items which have been changed/deleted. But in case you only need to send over a single item or a small group of items you should use the hotfix process. This requires that you export/import the collection once per release and during the release you are then able to do exports of single items.

The hotfix process works in the following way if you have already collections and exported the collections in the current IBP release already: you pick a subset of items of the collection and add them to a hotfix. This hotfix can then be exported. The overall behavior of the items does not change: a planning area still contains all key figures, planning levels, etc., but you do not export all changed items of the collection, but only a subset. This is important in case you have several changes in the collection, but you do not want to export all changes.

 Q: Is it possible to automatically import a collection in a test system?

A: No, but there is a customer influence for exactly this topic: Transport Export/Import with Software Collections: import automation by time (257019).

 Q: If export / import is already done for one collection which contains two master data types (example), if in future there is requirement to modify only one of the two master data types: do we need to create a new collection or used the old one (with two master data types)?

A: You will use the collection with the two master data types and just click export. This will then export to the target system. If the target system has the latest version already imported, it will only import the changed master data types.

 Q: It's very rare scenario to export all items of a collection. Forcing each time to export all operators, once a system is live, there's very rarely a situation when you need to export all, huge majority is to export only what's changed and avoid including other work-in-progress items. 

A: The IBP data model is a complex thing. With all the dependencies between objects, the effect of a change is never just a local one. So, if you do a change in a key figure, it must be ensured that all dependent objects are still consistent. And this you usually only ensure if you export the whole context of a change. But remember on the import side, the system will check the delta to the last version and import only the delta – so not all items are touched.

 Q: If you work with more than one planning area that had been built up by a copy with mode "replace with dependencies", you provide a different master data type for each of them. But you use the SAME set of attributes. And as you cannot remove objects later on and would want to transport a planning area for test purposes to quality system only but not to production, that would not work unless you separate attribute collection from master data type collection. 

A: The IBP data model is a complex thing. With all the dependencies between objects, the effect of a change is never just a local one. So, if you do a change in a key figure, it must be ensured that all dependent objects are still consistent. And this you usually only ensure if you export the whole context of a change. But remember on the import side, the system will check the delta to the last version and import only the delta – so not all items are touched.

 Q: In which system is the "forward" done?

A: The forward is done in each system which has a “next” system in the transport route. For a three-system landscape with dev, test, prod, you do the forward in the test system.

 Q: (a) Can we transport the planning area without collecting the master data types, time profile and key figures, or it is mandatory to collect these objects as well? (b) Is this function only available between systems, or will it also be possible to move between different planning areas on the same system?

A: (a) If you keep the planning area in one collection, the master data types in another one, the time profile in a third, then you can export these three collections independently. You of course also need a collection for the attributes. The key figures are part of the planning area and cannot be transported individually (same as in “Transport Model Entities” app).

In the target system, it is of course important that you import in the correct order and activate in the correct order. Otherwise this will lead to inconsistencies and possibly also non-working processes or jobs.

(b) This is only for export/import of items between systems within one landscape.

 Q: I still see “Transport Model Entities” in IBP 2011 release, can we not use that to transport? 

A: Yes, as long as you have not been configured for the new transport, the “Transport Model Entities” app is the way to go. After the configuration change, the “Transport Model Entities” app will be read-only. This is an effect from the configuration change to the new export/import mechanism. Once the change is done, the old app is read-only.

 Q: When does this become mandatory? 

A: We will migrate most of our customers during the usage of IBP 2011 – until February. There might be exceptions, but Fiori 3 usage and extensibility have the new export/import as prerequisite. We will do the migration in waves and will of course inform beforehand.

 Q: Will the data be affected through the new export/import?

A: This is the same as with the “Transport Model Entities” app. Depending on the change, the data could be affected (change of data type of an attribute), but usually the answer is no.

 Q: Will there be an external API for this which will allow us to develop custom controls which link to our change control systems?

A: At the moment, there is none, but a customer influence was created for you to vote for this: Public API for export and import of software collections (257603).

 Q: Is there a way to provide access to perform forward in the “Import Collection” app limiting the access to only allow forwarding and NOT importing? Is there a possibility to distinguish via access who can import and who can forward in the “Import Collections” app?

A: The “Import Collection” app does not distinguish between the import and forwarding action from authorization point of view. If you have access to the app, then you can do both. But remember that on the target side there again has to be somebody authorized to do the actual import. The forward action does not actually do any change in the target system.

 Q: I was not aware of SAP having three systems dev, test/QA, and prod in the Cloud for IBP. We have two systems. What is better?

A: Of course, a three-system landscape is better to make sure development and test are separate and independent in their release / working cycles. The three-system landscape is currently the proposed landscape for normal customer scenarios. If you only have limited usage of SAP IBP, you can of course still go with a two-system landscape. But make sure to adhere to the best practices in the model configuration by having independent planning areas for the different lifecycle states.

The IBP Applications come with 1 IBP Production system and 1 IBP Test system (a 2-tier landscape). Additional systems (aka tenants) must be purchased separately. To obtain additional systems, please contact your sales rep.

 Q: Can I export from production to test system if someone deletes the planning area in test system?

A: In this case you should revert to a backup to ensure that dependent data is also available again. Reversing the transport routes is not possible. Backups are automatically be taken by SAP and can be requested to install back via OSS message.

 Q: Currently we use Transport Model entities to transfer changes from test tenant to production tenant. We can use still use Transport Model entities for transporting changes from test to prod, correct?

A: I assume you are speaking of a three-system landscape. After the switch to the new export/import, this will not be possible like this anymore to create a new transport in test tenant (for example realignment projects or merge of planning areas). You will import always the export from the development system – regardless of whether this is the test system or production system. There is no need any more in the test system to create again a collection / export. This way it’s ensured that what you exported from development is tested and reaches the production system.

 Q: So far, we couldn't transport Business Roles. With the new app it seems to be possible. For that I need initially to export from prod system to dev system. Is there any possibility? The presentation is saying it will not be possible. 

A: You could use the file download in prod and upload to dev before you start using the transport.

 Q: How does CPI-DS (aka HCI) support three-system landscapes?

A: That is a question not covered here, but it is supported via so called suborganizations that you can request via ticket for the CPI-DS solution.

 Q: A bugfix for only a single item in a collection must wait and cannot be exported/imported and solve the problem, it must wait for the whole collection to be “finished” which might be a long-term time consuming. Is there any solution for this?

A: If you adhere to the best practices here, then you will have a consolidation planning area which is the one also used in production. This consolidation planning area will get ONLY bugfixes usually. The consolidation planning area receives bigger changes only after the configuration planning area has been tested and can be seen as “done”. Here the guideline for two systems:

For three systems the same scenario would look like this:

If you adhere to this, then the collections can be used for the export of the bugfixes and will not contain any “unreleased” or “intermediate” status.

 Q: Is it possible to rollback already imported collections (e.g. in test/QA system when an issue is found during the testing) or only a new collection version has to be created in development system and then re-imported to test/QA?

A: It’s the latter: you fix the issue in the development system and export the collection again to test/QA. A rollback of an import is not possible at the moment.

 Q: Is this new export/import integrated into SAP Solution Manager or SAP Cloud ALM?

A: Not yet, but you can vote for it via Planning area Transport Management with Solution Manager ( CTS+ for IBP ) (250697).

 Q: Is there a possibility to schedule an import so it can happen automatically out of business hours without human intervention?

A: Not yet, but you can vote for it via Transport Export/Import with Software Collections: import automation by time (257019).

 Q: If an object is assigned to a collection, it remains there forever?

A: Yes, but you can vote for it via Rework new Transports design - adding object to multiple collections, allow unlinking (257079).

 Q: Can we import/export Analytic Charts, Process Templates or Dashboards? I think I read in the What's New for 2008 that it was feasible with the Transport App.

A: The list of possible types from the old app is fully covered in the new export/import. In the new export/import there are additionally the business roles and Fiori pages and spaces available for export/import.

 Q: Is it an all or nothing switch from “Transport Model Entities” app to new export/import?

A: Yes. But the “Transport Model Entities” app will still be available in read-only mode.

 Q: Is there a plan for a “compare” app between systems?

A: No, but it might be worth creating a customer influence for this. 

 Q: What is the recommendation for exporting collections where data is not synchronized with upper environments (e.g. planning filters) but are used in application jobs and shared across user groups?

A: Over time more and more types will be available in export/import. We added dashboards and analytics recently and we will continue this path. As soon as new types are available in export/import, make sure you create them in the development system and add them to collections. This is unfortunately a manual process. For business roles there exist download/upload functionality with which you can first move them from production to development, before you start the transports.

 Q: Suppose in one planning area, we are using Demand & IO. What specific things can be clubbed together for Demand & IO respectively?

A: Adhere to the mentioned guideline for collections. In your case this would mean the following:

  1. one collection with all attributes, time profiles
  2. one collection with master data types and planning areas
  3. forecast models, operator profiles, etc. – one for inventory optimization and one for demand management
  4. one collection with all planning filters – one for inventory and one for demand (they are often on different planning level and have different filter)
  5. one collection with all permission filter – one for inventory and one for demand (they are often on different planning level and have different filter)
  6. one collection with all business roles, attribute permissions – one for inventory and one for demand (there are often different teams working with different readiness at the same time)
  7. one collection with all pages and spaces

 Q: Where can I find more information?

A: Check out the IBP Webinars, especially Meet the Expert: New Export/Import for SAP IBP PDF Recording



  • No labels