После обновления ERP в BI при загрузке данных из ERP стали возникать ошибки - данные из ERP просто не приходят, в мониторе пишет, что ошибка возникла в исходной системе.
Выяснили что рекомендуют переактивировать исходные системы в BI. Переактивировали в D, создалось несколько запросов на перенос и в D всё поехало. Перетаскиваем в Q - переактивируем исходные системы в Q и тут вылетает ошибка - Неправильный Idoc-тип ZSCB014 в ALE-определении исходной системы.

Кто-нибудь сталкивался с такой проблемой? Самое странное что в D системе работает, а вот в Q нет.

Если что то на ERP ставили EHP 6

Предлагаю на на стороне BW произвести операцию восстановление исходной системы (правой кнопкой на исходной системе -> восстановить), при этом при корректно настроенном соединении между системами вам будет предложено зарегистрироваться с правами администратора на стороне ERP, после чего будут созданы новые idoc'и для обмена данными между системами (при этот мандант ERP должен быть открыть на изменения).
В случае неудачи может понадобиться удалить старые idoc'и, обычно этим заведуют базисники, потому как у них есть на это соответствующие права.

Была такая мысль. Вопрос про последствия - не придётся ли переактивировать все экстракторы используемые в системе?

Осмелюсь предположить, что при обновлении мандант D системы был открыт для настроек-изменений (в том числе D-OLTP, D-BW) , поэтому система отработала корректно, а вот Q система обычна закрыта для изменений, поэтому изменения автоматически не прокатили.

Ну да Q закрыта от прямых изменений, только туда обновления в виде запросов должны были приехать. Хотя возможно это не касается активаций/переактиваций внешних систем.

Кстати вопрос вдогонку - я правильно понимаю что эту операцию нужно делать в D системе, а потом запросами тащить до Q?

правильно, только смотрите внимательно журналы активации.
Однако в Вашем случае изменение касается скорее всего двух систем BW и R3. Настройки партнеров должны быть в двух системах.
Активация на стороне R3 могла пройти локальной или вообще, по смыслу не подлежит переносу.
В вашем случае сравните настройки ALE партнеров (D-BW + D-R3 ) с (Q-BW +Q-R3) и поймете, где лежат грабли.

Собственно в D, как это ни странно, и так уже всё работает, вся эта чехарда с восстановлением получается нужна исключительно для восстановления работоспособности Q системы, а затем, после патча продуктива ERP, продуктива BI.

В этом моменте не соглашусь, ибо мы делаем данную операцию на каждой паре систем без переносов.
На определенном шаге данной операции система спросит про активацию структур переноса, и, выбрав фоновую активацию и подождав определенное время, вы получите то что хотите без каких либо переносов данных.
Вообще, это вещь весьма стандартная, часто делается при обновлении тестовой системы ERP с продкутивной, что, как вы понимаете, никак не связано с системой разработки и не требует каких-либо переносов.

В каждой системе создаются открытые транспортные запросы с импортируемыми объектами?
Если в каждой системе создаются открытые запросы, то в последствии эти запросы будут блокировать другие переносы?

Если речь про BW систему - да, складываем объекты в перенос. Объектов немного, структуры переноса, активируемые фоном, в запрос не ложатся, соответственно и блокировать данный запрос ничего не будет (плюс его можно деблокировать и удалить).

Если речь про ERP систему - обычно открывают таким образом, что запись изменений в запрос не происходит (соответствующая настройка в scc4/se06).

Всем спасибо.
Открыли систему Q в BI на изменение и запустили восстановление внешней системы, т.к. при закрытой операция падала с ошибкой.
В результате система активировалась и экстракторы заработали.