Обновления от Microsoft RUS - NAV: Функционал

Romul · 24.02.2011, 12:01

Есть чистая кронусовая база 2009 R2 RU. Собрался заливать на нее следующие обновления:
- LCU1 (PS59774);
- R2 FP1 (NAVRU6.00.10.01).

Сначала залил LCU, после чего принялся за R2 FP1. Предполагаем, что, раз уж ЗП включена в базовый пакет, LCU1 реализован и в FP1. Но, на всякий случай залил их по отдельности имено в том порядке, который уже описал выше...

Сажусь проверять тулкитом оба пакета в том виде, как они были представлены MS-ом и малость недоумеваю...

1. Ключи в Поставщик Книге Операций - разные (FP1 не содержит ключа из LCU).
2. Один и тот же ID имеют РАЗНЫЕ функции (393-й отчет). В LCU функция SetHideMessage имеет ID 1210000, а в FP1 этот же ID имеет уже функция MakeBudgetPmtJnlLine.

Это в FP1 так быстро изменили функциональность из LCU1? Или это такой "изящный" баг?

Комментарии?

Romul · 24.02.2011, 12:38

Предположение, что "в FP1 так быстро изменили функциональность из LCU1" оказалось неверным: некоторых зарплатных объектов LCU1 в FP1 просто нет...
Другого ответа, кроме того, что это баг - у меня нет...

**GalaM** · 24.02.2011, 14:08

Цитата:

Сообщение от Orwell

некоторых зарплатных объектов LCU1 в FP1 просто нет...

А почему Вы решили, что они там должны быть ?
объекты LCU вошли в состав R2.

FP1 включает исключительно новую функциональность по НДС и должен устанавливаться на R2, поэтому никаих зарплатных объектов там и нет.

Romul · 24.02.2011, 14:16

Цитата:

Сообщение от gala

объекты LCU вошли в состав R2.

Взял стандартный Кронус R2: объектов LCU1 (PS59774) там нет.

Цитата:

Сообщение от gala

Цитата:

Сообщение от Orwell

некоторых зарплатных объектов LCU1 в FP1 просто нет...

А почему Вы решили, что они там должны быть ?
объекты LCU вошли в состав R2.

FP1 включает исключительно новую функциональность по НДС и должен устанавливаться на R2, поэтому никаих зарплатных объектов там и нет.

Хорошо.

Я и не прошу содержания там зарплатных объектов... Соль то не в этом.
Вопрос в другом:
- почему в разных пакетах обновления одни и те же объекты содержат функции с одинаковыми ID? Пакеты взаимоисключающими становятся.
- почему накатив LCU (клиент зарплату хочет обновить), после накатывания FP (клиент еще и новую функциональность по НДС хочет) первое становится неработоспособным? Ответ частично дан в первом вопросе...

**GalaM** · 24.02.2011, 14:56

[quote=Orwell]

ОК, прошу тогда прощения. Вы имели ввиду LCU1, которое было выпущено в январе. А я, то, которо было выпущено в октябре (до R2).

В данном случае Вы правы, оба пакета обновления предназначены для установки на R2 и должны быть самостоятельно "объеденены" партнерами.

На вопрос почему, я не могут тут отвечать, так как пока работаю в MS

.

К сожалению, проблема с обновлениями общая для всех стран (если Вы читали аналоязычный блог про R2). Вопросы подняты, процесс идет. Пока больше ничего сказать не могу.

На локальном уровне пока могу пообещать аккуратное указание исходной версии на которую следует устанавливать объекты в релиз-ноте.

finn · 24.02.2011, 13:10

Что то похожее было..

http://forum.mazzy.ru/index.php?showtopic=14183

Мое мнение:

LCU это в общем вещь в себе и никто не гаранитирует что последущее FP1 включает предыдущее LCU,

Свежие LCU надо объединять (merge) на уровне текстовых объектов и затем импортировать.

Romul · 24.02.2011, 13:31

Цитата:

Сообщение от finn

Что то похожее было..

http://forum.mazzy.ru/index.php?showtopic=14183

Мое мнение:

LCU это в общем вещь в себе и никто не гаранитирует что последущее FP1 включает предыдущее LCU,

О как... И это при том факте, что поддержка стОит явно не 3 копейки "никто не гарантирует работоспособности"???
MS что, уже даже не может не то что объекты корректно аппрувить, но даже толково объяснить в релиз-нотах по апдейтам Что и Куда?
Слов нет...

Цитата:

Сообщение от finn

Свежие LCU надо объединять (merge) на уровне текстовых объектов и затем импортировать.

Стоп... Какие проблемы - в таком случае пишите, что обновления даются AS IS без всякой ответственности за конечный результат. А то ведь как получается: исходя из этого (допустим, Ваше предположение по поводу ручного мерджа верно), я беру на себя не только ответственность за обновление базы клиента, но и фактически за разработанный вендором функционал, который изначально был дан в неработоспособном виде. На любой запрос в MS на тему "Вы тут посмотрите, что за баг... Только я малость смерджил сам руками ваши же объекты, перед тем, как их вливать. Но почему-то ничего не работает..." поддержка ответит: "Сами смерджили - сами и разбирайтесь."

Горькая ирония заключается даже не в том, что это нормально залить клиенту невозможно. А в том, что эти обновления не могут нормально лечь даже на ЧИСТУЮ кронусовую базу...

artkashin · 24.02.2011, 13:34

Цитата:

Сообщение от finn

Что то похожее было..

http://forum.mazzy.ru/index.php?showtopic=14183

Мое мнение:

LCU это в общем вещь в себе и никто не гаранитирует что последущее FP1 включает предыдущее LCU,

Свежие LCU надо объединять (merge) на уровне текстовых объектов и затем импортировать.

Жесть. Просто жесть.
С такой политикой обновлений, например, Windows мы бы регулярно видели BSOD.

Alterant · 24.02.2011, 17:47

Цитата:

Сообщение от finn

Что то похожее было..

http://forum.mazzy.r...showtopic=14183

Мое мнение:

LCU это в общем вещь в себе и никто не гаранитирует что последущее FP1 включает предыдущее LCU,

Свежие LCU надо объединять (merge) на уровне текстовых объектов и затем импортировать.

Алексей, я наверно соглашусь с вами насчет мерджа двух LCU, но FP - это, на мой взгляд, гораздо бОльшее обновление и просто обязано быть накопительным. Неужели последовательные сервис-паки тоже нужно мержить?

finn · 24.02.2011, 18:32

Цитата:

Алексей, я наверно соглашусь с вами насчет мерджа двух LCU, но FP - это, на мой взгляд, гораздо бОльшее обновление и просто обязано быть накопительным. Неужели последовательные сервис-паки тоже нужно мержить?

FP больше LCU и меньше SP. SP это то что реально идет от предыдущего SP или базового релиза и его можно сверху.
Выпускается SP редко (На 5.0, на 6.0 было пока по одному SP). FP чаще. LCU еще чаще.

FP - это набор фич. Он отталкивается от реперной точки R2 скажем. Так же и LCU может от нее отталкиваться. Или от R2 + FPXXX.
Тут проблема в том, что FP1 и LCU1 шли параллельно от R2.
Хотелось бы конечно чтобы все update были последовательны, но не получается по факту.

Раньше была накопительная база Express c ней попроще было. Реперная точка смешалась постоянно вперед.
Может и сейчас это реально.... Но по любому привносить код руками так или эдак придется.
KB article когда применяем, из него же коррекцию привносим руками… и ничего.

Русские парни разработчики много делают, чего не делают другие страны, но и им все update делать по rollup (накопительной) схеме думаю не по силам пока.

Romul · 24.02.2011, 21:25

finn
Возможно, выходом станет некое разграничение диапазонов в тех или иных объектах на уровне LCU, FP, SP...
Вот так вот сходу не вижу препятствий для этого даже при наличии параллельной разработки в рамках локального функционала. Имхо, но все упирается в организационные вопросы, но не в технические проблемы.

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

По поводу разных LCU - спорить не буду... Ручной мердж - так ручной мердж. Но тот факт, что FP, фактически, может затереть некую функциональность предыдущих критикал апдейтов, очень настораживает.

В данном кокретно примере - все прозрачно и мердж будет быстрым. В ссылке, указаной вами выше, Андрей (apanko) говорил о более серьезных вещах (12-й, например).
Может пора выводы делать?

RedFox · 25.02.2011, 12:59

Цитата:

Сообщение от finn

FP больше LCU и меньше SP. SP это то что реально идет от предыдущего SP или базового релиза и его можно сверху.
Выпускается SP редко (На 5.0, на 6.0 было пока по одному SP). FP чаще. LCU еще чаще.

FP - это набор фич. Он отталкивается от реперной точки R2 скажем. Так же и LCU может от нее отталкиваться. Или от R2 + FPXXX.
Тут проблема в том, что FP1 и LCU1 шли параллельно от R2.
Хотелось бы конечно чтобы все update были последовательны, но не получается по факту.

Раньше была накопительная база Express c ней попроще было. Реперная точка смешалась постоянно вперед.

Извините, но вопрос "блондинки" - ну почему нельзя делать или хотя бы мержить все в 1 базу?? Тогда партнеры бы получали 1 базу! А не думали-ломали головы что же делать, чтобы все "новые фичи" все-таки заработали на 1 базе!

P.S. Я даже готов скинуться на версин-контрол.. для MВS RU (хотя наверное хохляцкие гривны никому там не нужны..)

Alterant · 06.09.2011, 16:42

В продолжение темы. Тем, кто мерджит 2009 R2 FP1 с LCU12 (PS60060).

Цитата:

Сообщение от finn

Свежие LCU надо объединять (merge) на уровне текстовых объектов и затем импортировать.

Может кто подскажет каким образом можно смерджить объекты menusuite? NAV не позволяет модифицировать menusuite с ID 30 и 1030. Заливать их в текстовом виде, естественно, тоже. Вынести изменения в клиентский ID можно, но как-то не правильно, на мой взгляд. Готов даже выслать текстовый файл, чтобы мне прислали fob.

P.S. Тем, кто верит, что LCU12 (PS60060) - накопительное. Это не совсем так. Код не сверял, но то, что в нем нет формы 17497 из LCU01 (PS59774) - факт.