Существуют ли недостатки у Axapta

[Pavel]

Цитата:

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

В результате спустя год (!!) вместо решения проблем, в SP4 появились заглушки и все.

Не новый подход. Еще в 2001 году мы обсуждали на форуме вариант использования стандартной международной аксапты с российским меточным файлом как альтернативу корявой локализации.

[komar]

Цитата:

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

Господа, возвращаясь к нашим баранам.
ОЧЕНЬ ОЧЕНЬ ИНТЕРЕСНО, таки проблемы пересчета/закрытия склада Microsoft вообще собирается решать? Я тут почитал переписку своего партнера с MBS, датированную еще началом-серединой 2004 года на эту тему.
В результате спустя год (!!) вместо решения проблем, в SP4 появились заглушки и все. Кто тут говорил про "приоритетность" и все такое?
Хоть каждый день открывай запросы, толку ноль. Одни отмазки, запросы просто закрываются и все.

Насколько я понимаю (пусть меня поправят, если я неправ), но после создания механизма "многопользовательского" закрытия склада никаких других переделок не ожидается. А в какие проблемы вы уткнулись?

[Lazy_Tiger]

18.06.2004 12:45:00 GMT+03:00
1. Складская модель - средневзвешенная на дату
2. Складская аналитика - склад, финансовый склад включен.
3. 1-го числа приходуем 10 штук номенклатуры на склад "Основной" по 50 рублей за штуку (всего 500 рублей).
4. 2-го числа перемещаем 5 штук со склада "Основной" на склад "Магазин".
5. 3-го числа через заказ списываем 5 штук со склада "Магазин".
4. Затем проводим коррекцию приходной проводки на 300 рублей. Разносим ее 1-м числом.
5. 30-м числом месяца делаем пересчет себестоимости.
6. Видим, что у проводок по перемещению и заказу себестоимость стала 400 рублей (верная).
7. Затем закрываем склад раньшей, чем пересчет, датой. Например, 15-м числом. Видим, что в одной из половинок перемещения себестоимость 550 рублей вместо 400 рублей.


Ответ:
бла бла бла... "Указанная в этом Вашем запросе проблема решается комплексно вместе с некоторыми другими проблемами, связанными с пересчетом и закрытием склада, известными в версии Microsoft Axapta 3.0. Ожидается, что исправление для Microsoft Axapta 3.0 SP2 и SP3 будет опубликовано в январе-феврале 2005 года."

На дату ПЕРВОНАЧАЛЬНОГО запроса внимание обратите(!!!)

Состояние: в SP4 сделали залипучку. Не исправили, а именно залипучку сделали. Которая сводится к 1 оператору if()

[mazzy]

Lazy_Tiger, это исправили в международном SP4.
Видео с разъяснениями механизма расчета себестоимости

Цитата:

7. Затем закрываем склад раньшей, чем пересчет, датой

Анекдот:
Купили русские мужики японскую бензопилу. Решили опробовать.
Подсунули доску:
- Вжик, - сказала японская бензопила
- О! - сказали русские мужики.
Подсунули бревно:
- Вжик, - сказала японская бензопила
- О! - сказали русские мужики.
Подсунули железный лом
- Кряк, - сказала японская бензопила
- Э-э-э! - разочаровано махнули рукой русские мужики.

Вообще говоря, рекомендуют отменять пересчеты, которые сделаны ПОСЛЕ даты закрытия... Там еще остались траблы с подчиненными производственными и wms заказами... Насколько я помню... В общем, текущее закрытие должно быть последним.

[Lazy_Tiger]

Цитата:

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

Lazy_Tiger, это исправили в международном SP4.
Видео с разъяснениями механизма расчета себестоимости
Вообще говоря, рекомендуют отменять пересчеты, которые сделаны ПОСЛЕ даты закрытия... Там еще остались траблы с подчиненными производственными и wms заказами... Насколько я помню... В общем, текущее закрытие должно быть последним.

0) в SP4 - не исправили. А поставили залипуху, включив дурочку. При этом судя по переписке в течении года имели все ж совсем другие планы.

1) По поводу отменять - цитату из документации плииз. Она ж у нас первоисточником является?

2) А что делать если себестоимость нормальную хочется иметь не спустя 2 месяца? А то ведь и пересчет и закрытие и самое смешное - ОТМЕНА пересчета и закрытия это операции отнюдь не на 15 минут, а все ж таки на 6-8 часов минимум. А если я полный пересчет запущу за месяц, так она и за 2 суток не посчитает, хоть заоптимизируйся, увы.

Т.е. в течении месяца, желательно каждый день (ну хотя бы раз в неделю) запускать пересчет, а закрывать раз в месяц. Жисть такая.
Сергей, ты знаешь другой способ получить корректный 41 счет? Так что пример про пилу он как бы не к месту нифига.

P.S. Ни производственных, ни WMS-заказов у меня нет.
P.P.S. Отнюдь не обязательно считать по средней как выяснилось, это просто пример такой.

[Lazy_Tiger]

... а вообще из этой же переписки создается впечатление что задача стоит не решить мою проблему, а отмазаться от нее. Т.е. открываем запрос, закрываем запрос, снова открываем, снова закрываем... ПРО ОДНО И ТОЖЕ.

[mazzy]

Цитата:

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

Сергей, ты знаешь другой способ получить корректный 41 счет? Так что пример про пилу он как бы не к месту нифига.

Ясно. Извини, что вмешался. Я думал, ты решение ищешь...

ОК.
Да-да... Майкрософт маздай... Пошел за попкорном.

[Lazy_Tiger]

Цитата:

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

Ясно. Извини, что вмешался. Я думал, ты решение ищешь...

Сергей, это не решение. Это то, что они называют workarround, т.е. обходной маневр типа Т.е. ВРЕМЕННОЕ решение. "Временное" в моем понимании означает 2-3 раза потерпите, затем все будет в шуколаде. Как то за год и 3 сервис-пака шуколад не образовался. А теперь его образование и не планируется. А ведь обещали и тому у меня есть письменное подтверждение

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

Да причем тут мастдай. Речь о том, что заявления ДО ПРОДАЖИ это одно, а как до КОНКРЕТНОГО дела доходит, так помощи никакой. И мне как клиенту, хочется, чтобы проблемы (а это именно проблема, а не прихоть и хотелка) решались, причем желательно не за наш счет. Потому что в текущей ситуации у меня нет выбора иначе как платить за решение этой баги партнеру.

[mazzy]

Цитата:

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

Сергей, это не решение. Это то, что они называют workarround, т.е. обходной маневр типа Т.е. ВРЕМЕННОЕ решение. "Временное" в моем понимании означает ...

Да-да-да.
Я понял. Майкрософт маздай!

Еще раз извини, что влез.

[Lazy_Tiger]

Цитата:

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

Еще раз извини, что влез.

а по существу если?
Про удаление пересчетов перед закрытием я знаю, к сожалению не вижу возможности использовать, в основном по временным ограничениям.

Другие решения?

[mazzy]

Цитата:

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

а по существу если?
Про удаление пересчетов перед закрытием я знаю, к сожалению не вижу возможности использовать, в основном по временным ограничениям.

Другие решения?

Я не знаю других решений.

Я знаю только анекдот.
Анекдот готов повторить.

Анекдот:
Купили русские мужики японскую бензопилу. Решили опробовать.
Подсунули доску:
- Вжик, - сказала японская бензопила
- О! - сказали русские мужики.
Подсунули бревно:
- Вжик, - сказала японская бензопила
- О! - сказали русские мужики.
Подсунули железный лом
- Кряк, - сказала японская бензопила
- Э-э-э! - разочаровано махнули рукой русские мужики.

[Recoilme]

Цитата:

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

а по существу если?
Про удаление пересчетов перед закрытием я знаю, к сожалению не вижу возможности использовать, в основном по временным ограничениям.

Другие решения?

Попрограммировать немного

Если пересчет не будет оставлять следов в инвенттрансе (ну кроме поля костэмаунтэджастмент естепственно) и прочих местах - не нужно будет его отменять
Я не очень туманно выразился?
ЗЫ: а если потратить ещё месяц-другой работы и скад за год по 8 миллионам проводок закрывается за 8 часов

[EVGL]

Цитата:

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

Да-да-да.
Я понял. Майкрософт маздай!
Еще раз извини, что влез.

Иногда стоит выбор: кто должен мастдай - компания, осуществляющая внедрение, или менеджер в MS? У нас тут был случай, когда мы стояли на грани закрытия, клиент угрожал судом. Ведь ему все равно, кто там виноват.

Производственная компания, переносы между складами, чешская функциональность. Т.е. закрытие склада сплетается в один большой баг. Консультанты инвестировали свыше 3 чистых человеко-месяцев, чтобы понять, в чем дело, почему по ГК и по складу не сходится ни одна цифра. Результат - свыше 13 (!) запросов в сервисной системе.

В SP4 было представлено решение, к которому, правда, нужно было добавить пару хотфиксов. Чешскую функциональность порекомендовали в итоге вообще отключить, а нашего консультанта приглашали в офис MS в Чехии на лекции.

К сожалению, разобраться в проводках было уже невозможно. Было принято решение: для InventTrans, InventSettlement я написал эвристические процедуры, которые обновляли данные до достижения правдоподобности. После этого стирал (!) все накопленные проводки ГК, идущие из производства, и создавал заново (!!) на основе правдоподобных данных.

На Рождество после того, как все закрытия были отменены и созданы заново, все эвристические процедуры отработали (это длилось 3 дня процессорного времени), и было потрачено еще неделя чистого времени, чтобы доказать честность результатов, проблема была решена.

Во время этой эпопеи многие, и я в том числе, задумывались как минимум о смене поставщика, как максимум - места работы. И вот тут стало обидно: почему какие-то пешки, летающие в США, чтобы принять участие в каком-нибудь очередном семинаре на тему "Эскалация запросов или как правильно отмазаться от назойливого партнера", своими действиями или бездействием оказывают влияние на МОЕ финансовое положение и ставят под угрозу средства МОЕГО существования?

[ppson]

То есть закрытие склада хоть и стало правильным но не совсем ?
Ё!
Придеться продолжать врать клиентам о том что в аксапте аналитический учет совпадает с синтетическим , либо вообще склад закрывать втихушку ...
P.S. EVGL, извини за прямоту, а ты летал на эти семинары ?

[EVGL]

Цитата:

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

EVGL, извини за прямоту, а ты летал на эти семинары ?

Нет. Я и раньше, и сейчас отказываюсь от бессмысленных командировок, даже если речь идет о субтропических островах. Раньше и система поддержки была несколько другая в Navision: запрос не закрывался как минимум до тех пор, пока программист в Дании не исправил запрос. Была эскалация, порой очень длительная, но наивного перекладывания ответственности было все же меньше.

А вот еще пример. Восточноевропейская версия. 3-Tier. Открываем форму CustInvoiceJour, опять получаем ошибку времени выполнения в \Classes\Global\allowEditFieldsOnFormDs_W. В августе писал предложение 8281846: добавьте "if", поскольку _dataSource.object(idx) может и не существовать. Ответ умника из разработки (VALU, не иначе, его стиль) достоин цитирования:

Цитата:

[The] code is absolutely correct, because for each field in table we have FormDataObject on form datasource. After adding new field on table you should logoff from system and then logon. In some case you have to repeat this procedure some times. Proposed solution doesn't solve any problems. It won't be added to the next Microsoft Axapta release.

Без комментариев. Умник из разработки даже не знает, что "in some cases" не помогает даже остановка AOS, не то что перезапуск клиента. Ок, я у себя проблему уже решил, хотел помочь бывшим коллегам делать их работу лучше, в ответ получаю не просто ложный, а наглый ответ.

[ppson]

Хм. Если программист в Дании исправит ошибку...
А как программисты в России исправляют ошибки? А как "фича" признается "багом"?
Мне все было как то туманно представлять все эти передаресации запросов. И понятно, что полномочия рядового сотрудника службы поддержки не позволяют ему ответить самостоятельно на вопросы - "это ошибка?" "Это будет исправляться?" и так далее.
Несколько лет назад я долго переписывался по одной ошибке в модуле, разработанным Навиженом с службой поддержки.
В конце концов после очередной итерации получил ответ что эта "фича" признается ошибкой, но исправляться не будет и в планы по "развитию" модуля включена не будет . Клиенту само собой это "фичу" исправили, но с тех пор я как то отошел от общения с МБС, поняв что разговаривать с радио бесполезно, могут и белый халат одеть .

[EVGL]

Цитата:

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

Клиенту само собой это "фичу" исправили, но с тех пор я как то отошел от общения с МБС, поняв что разговаривать с радио бесполезно, могут и белый халат одеть.

Разговаривать все-таки надо, чтобы мир по чуть-чуть становился лучше. Хотя иногда и хочется послать собеседника куда подальше.

[glibs]

Цитата:

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

...Раньше и система поддержки была несколько другая в Navision: запрос не закрывался как минимум до тех пор, пока программист в Дании не исправил запрос. Была эскалация, порой очень длительная
...

Ну да, изнутри не наблюдал, но снаружи примерно так выглядело.

По крайней мере было видно, что отвечают в Дании (или туда и не отправлялось). Процесс эскалации был прозрачен. Иногда приходилось бороться с испорченным телефоном. Одно время писал запросы на английском, и был неплохой эффект.

У меня тут гадкая мысль закралась по поводу новой концепции системы поддержки.

Нам в Аксапте 4.0 обещали так называемый "zero bug release". Под последним понималось отсутствие зарегистрированных багов.

Про Аксапту уже можно забывать (теперь у Микрософтра "новый" продукт Динамикс...). А вот отсутствие зарегистрированных багов не задумали ли часом решить за счет истребления запросов, а не багов?

PS. А вообще я тут захлебываюсь от эмоций глядя на то, как один из разработчиков локализации оценивает продукт, к работе над которым был причастен (вклад EVGL в локализацию Аксапты недооценить сложно). Оказывается, во всем виноват сапорт.

[EVGL]

Цитата:

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

Оказывается, во всем виноват сапорт.

Не надо приписывать мне то, чего я не говорил. Я утверждаю, что виноват новый внутренний распорядок. Тебе доводилось работать со мной напрямую: я порой обходил систему, чтобы быстрее предоставить результат.

[glibs]

Цитата:

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

...Не надо приписывать мне то, чего я не говорил...

Извините, это была моя эмоциональная оценка происходящего.

Цитата:

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

...Я утверждаю, что виноват новый внутренний распорядок...

Можете обосновать, в чем то, что я сказал, противоречит вашему утверждению? Ведь распорядки по разработке/продаже вы не критиковали.