Задублировались ID объектов при обновлении MS Dynamics AX 2009

[Kostiki]

Обновил аксапту. Поставил kb3102031, которое вышло в ноябре. Сверху залил слой sl2 от FP37 который вышел в феврале. Сравнил слои со старыми и офигел. Extended_Data_Types в количестве 3 штук задублировались по ID. То бишь. В аксапте теперь присутствует два разных EDT с одинаковым ID:
19824. На GLP это CadastralValue_RU, в Sl2 - RPayTaxDeducted
19826. На GLP это RoomCadastralNum_RU, в Sl2 - RPayTaxExemptions
19822. На SYP это TaxReportCashAccountingRegime_ES, в Sl2 - RPayIncomeAmount
Как такое возможно? И к чему это приведет при работе? В АОТ видны оба EDT и у каждого из них один и тот же ID.

Второй вопрос. Слой GLP. С ним прилетело обновление по формированию книг покупок и продаж и декларации по НДС. Чета в планах разработки я не видел, что Майкрософт планирует переделать формирование, ну да ладно. Волнует такой вопрос: таблички TmpLedgerVATDeclaratoinHeader_RU и TmpLedgerVATDeclaratoinLine_RU. Обе стандартные на GLP слое. В обе в обновлении были добавлены новые поля. И ID всех новых полей превышают 50000. Если не ошибаюсь, эти ID выделены для юзерской разработки. Получается Майкрософт начал разрабатывать в юзер слое? Аналогичная бадяга была летом, когда выпускали обновление по книгам покупок/продаж.

Люди добрые, объясните. что происходит с разработкой в MS?

[gl00mie]

Спокойствие, только спокойствие MS всегда разрабатывал на usr-слое, просто обычно перед выпуском модифы переносят на "нужный" нижележащий слой, однако, иногда делать это забывают Всё это диагностируется, почти всё это лечится, см. также

• Трудности перехода: опыт переноса модификаций с AX 3.0 SP5 EE на AX 2009 SP1 RU5 EE с пункта "Собственно обновление приложения"
• DAX2009: поля таблиц стандартного приложения с идентификаторами из диапазона usr-слоя

[Kostiki]

Ну с usr слоем фиг с ним. А что делать с EDT, которые макрасофт так подло задублировал ID?
Было поле RoomCadastralNum в RAssetTable типа RoomCadastralNum_RU который string, а теперь аксапта чудесным образом его начала считать типом RPayTaxExemptions который Real. И естественно синхронизация таблицы RAssetTable вылетает с ошибкой.

[Maxim Gorbunov]

Есть два подхода. Условно назовём их "хакерский" и "пользовательский"

Независимо от подхода, сначала надо построить перекрёстные ссылки.

Хакерский подход

1. Находим девелоперский ключ на слой SL2.
2. Заходим на этот слой.
3. Экспортируем все EDT, которые перекрывают EDT со слоя SYP/GLP
4. Удаляем эти EDT со слоя SL2
5. Импортируем их обратно без ID
6. С помощью перекрёстных ссылок находим все ссылки на только что импортированные EDT, и восстанавливаем их (после шага 4 все объекты, которые ссылались на EDT со слоя SL2, будут ссылаться на EDT со слоя SYP/GLP с теми же ID).

Пользовательский подход

Так как у большинства пользователей ключа на слой SL2 нет, то нам ничего не остаётся, кроме как заново создать перекрытые EDT со слоёв SYP/GLP на нашем слое разработки (BUS/CUS/USR).

1. С помощью сравнения слоёв, создаём проект, в который собираем все EDT, которые были перекрыты на слое SL2
2. Экспортируем этот проект, с выбором слоя SYP/GLP
3. Импортируем проект на наш слой разработки без ID
4. С помощью перекрёстных ссылок находим ссылки на эти EDT. Ссылаться объекты будут уже на EDT со слоя SL2, так что надо будет разобраться, какие из этих ссылок правильные, а какие нет. Ошибочные ссылки исправляем и восстанавливаем связь с оригинальным EDT.

[Kostiki]

Все это хорошо. Для одного EDT я примерно так и сделал. Но вот для RoomCadastralNum_RU я так сделать не могу. Там изменился тип данных. Поле в таблице RAssetTable которое ранее ссылалось на етот EDT должно быть string, но после обновления оно стало real. И теперь у меня нет возможности для него указать восстановленный тип данных типа string

[Maxim Gorbunov]

В таком случае, боюсь, что без ключа на SL2 не обойтись. Впрочем, буду рад ошибиться. Посмотрим, может у кого-то ещё будут идеи.

[Maxim Gorbunov]

Вот такая идея появилась: а что, если поменять EDT для поля в RAssetTable перед установкой слоя SL2. Укажите временно любой другой EDT типа String или вообще уберите привязку к EDT. А после установки SL2 и пересоздания типов привяжите обратно к правильному EDT.

[Kostiki]

Была такая мысль. Она однозначно сработает. Только приложение сильно кастомизировано и при обновлении приложения было убито дофига времени на анализ и модификации чтобы обновление нормально влилось в наше приложение. Чета заново это делать сильно не хочется. На текущий момент ситуация такая - поля, на которых изменились типа данных были убиты в SQL. Таблицы синхронизировались, естественно с полным убиением данных в этих полях(благо не сильно важные и не сильно нужные в текущий момент). Работаем, радуемся жизни и ждем ответа от Майкрософта по данному инциденту.