Есть ли альтернатива ?

[dima123]

Аха 3.0 , переход на новую в течении 3 лет не рассматриваем
Не хватает лицензий , нужен какой то выход

Вариант
Под WEB делаем формы как используем в АХА
1) SalesTable ( add , change , delete)
2) Stock
a) InventJournalTable (add , change ,view)
b) InventTable (view primary tables )
3) ProdTable (add,delete)

плюс порядка 20 view tables

Есть какие соображения как избежать этого

[gl00mie]

Цитата:

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

Аха 3.0 , переход на новую в течении 3 лет не рассматриваем. Не хватает лицензий , нужен какой то выход

Докупить лицензий - не выход? Или активного плана поддержки тоже нет?

Цитата:

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

Вариант. Под WEB делаем формы как используем в АХА

С т.з. лицензирования такое веб-приложение будет называться proxy, а каждого пользователя, ходящего в Аксапту через proxy, все равно надо лицензировать. Или вы ищете чисто техническое решение? Тогда все намного проще, но и эта тема тогда уже не для данного форума.

[Bega]

Цитата:

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

С т.з. лицензирования такое веб-приложение будет называться proxy, а каждого пользователя, ходящего в Аксапту через proxy, все равно надо лицензировать.

Видимо имеется в виду свой собственный портал, со своей аутентификацией, который будет использовать одну лицензию пользователя.

[dima123]

Цитата:

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

Видимо имеется в виду свой собственный портал, со своей аутентификацией, который будет использовать одну лицензию пользователя.

Приложение будет полностью сидеть на COM обектах и SQL коннекте.

[dima123]

Цитата:

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

Докупить лицензий - не выход? Или активного плана поддержки тоже нет?С т.з. лицензирования такое веб-приложение будет называться proxy, а каждого пользователя, ходящего в Аксапту через proxy, все равно надо лицензировать. Или вы ищете чисто техническое решение? Тогда все намного проще, но и эта тема тогда уже не для данного форума.

Докупит никак , Или активного плана поддержки тоже нет.
Думаю есть ли смысл начинать это.

[gl00mie]

Я бы взглянул на ситуацию иначе. Официальная поддержка трешки закончилась три года назад, уже давно есть 4.0, 2009-я, летом прошлого года вышла 2012-я, для которой в России в этом году закончится TAP-программа и начнутся внедрения. Если верить объявлениям в разделе Рынок труда, многие конторы уже озаботились проектами перехода на ту же 2009-ю, многие уже завершили эти проекты... С этой точки зрения программист, много лет проработавший с 3.0, но не знающий новых версий, их особенностей, нового стандартного функционала, через некоторое время рискует оказаться аутсайдером на рынке труда программистов Axapta. Позиция конторы вполне понятна: она долгие годы всеми силами старалась сэкономить на поддержке одной из своих ключевых информационных систем, теперь начинает пожинать плоды этой экономии и пытается как-то "отсрочить судный день". Но стоит ли участвовать в этом, тратить силы и время на создание, мягко говоря, совсем нестандартного решения "сбоку", единственная цель которого - обойти лицензионные ограничения? Можно ли будет использовать этот опыт в других компаниях? Может, стоит лучше заняться повышением квалификации и изучением новых версий, а руководство "поставить перед фактом"? Я лично в таких условиях не брался бы за создание "web-морды" хотя бы из приведенных выше соображений.

[dima123]

Цитата:

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

Я бы взглянул на ситуацию иначе. Официальная поддержка трешки закончилась три года назад, уже давно есть 4.0, 2009-я, летом прошлого года вышла 2012-я, для которой в России в этом году закончится TAP-программа и начнутся внедрения. Если верить объявлениям в разделе Рынок труда, многие конторы уже озаботились проектами перехода на ту же 2009-ю, многие уже завершили эти проекты... С этой точки зрения программист, много лет проработавший с 3.0, но не знающий новых версий, их особенностей, нового стандартного функционала, через некоторое время рискует оказаться аутсайдером на рынке труда программистов Axapta. Позиция конторы вполне понятна: она долгие годы всеми силами старалась сэкономить на поддержке одной из своих ключевых информационных систем, теперь начинает пожинать плоды этой экономии и пытается как-то "отсрочить судный день". Но стоит ли участвовать в этом, тратить силы и время на создание, мягко говоря, совсем нестандартного решения "сбоку", единственная цель которого - обойти лицензионные ограничения? Можно ли будет использовать этот опыт в других компаниях? Может, стоит лучше заняться повышением квалификации и изучением новых версий, а руководство "поставить перед фактом"? Я лично в таких условиях не брался бы за создание "web-морды" хотя бы из приведенных выше соображений.

тут дело не в моих знаниях , я занимаюсь толко на этом заводе и не толко АХАПТои и там руководство не хочет переходить на новую версию
даже дело не в денгах
Просто никто не хочет себе гимороя с новими версиями , да упустили момент не докупили литцензий надо как то выкручиватса.
С точки зрения АХА консультантов конесно надо переходить , но с точки зрения бизнеса это просто 3-4 месяцса проблем, которые
хотят отложить на самыи максимальный срок.

[dima123]

плюс вопрос как по вашему менению
как долго надо сидет на однои версии и руководствуясь чем надо менят версию

[raz]

В данных обстоятельствах Гугл поможет решить проблему.

[Владимир Максимов]

Цитата:

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

Не хватает лицензий , нужен какой то выход

Писать соответствующие модули самостоятельно. X++ вполне можно использовать как средство разработки.

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

Насколько я в курсе, все российские внедрения в обязательном порядке "допиливаются" под конкретного пользователя. И зачастую сложно сказать что проще. "Допилить" стандартный функционал или написать новый.

Кстати, исходный код ведь все-равно есть. Просто он закрыт ключами. Можно попробовать скопировать (дублировать) соответствующие объекты и выбросить из них ссылки на закрытые ключи.

Цитата:

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

плюс вопрос как по вашему менению как долго надо сидет на однои версии

До тех пор, пока она работает.

Цитата:

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

и руководствуясь чем надо менят версию

Исключительно "крутизной загибания пальцев"

Насколько я в курсе, реальных причин с точки зрения бизнеса, для перехода на новые версии просто нет. Все то, что обычно говорят в подобных случаях - это нечто "вокруг" приложения, а не само приложение. Ну, там, сложно найти разработчика, "морально устарел" (ездить еще может, но будут показывать пальцем), не ставится на новой операционке и т.д. и т.п. Вот Вы можете назвать причину перехода, скажем, со старой версии MS Excel на новую?

Лично я так и не видел ни одного аргумента с которым я мог бы прийти, скажем, к главбуху или гендиректору и он тут же согласится выложить кучу килобаксов и повесить себе на шею кучу проблем на ближайший год..два исключительно ради перехода на новую версию

[Logger]

Ну а как же масштабируемость системы, поддержка изменений законодательства и.т.п.
Причины есть конечно.
Но можно спорить о цене, оправданы ли затраты. Но в каждом конкретном случае будет свой ответ.

[gl00mie]

Цитата:

Сообщение от Владимир Максимов

Писать соответствующие модули самостоятельно. X++ вполне можно использовать как средство разработки.

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

Цитата:

Сообщение от Владимир Максимов

Насколько я в курсе, все российские внедрения в обязательном порядке "допиливаются" под конкретного пользователя. И зачастую сложно сказать что проще. "Допилить" стандартный функционал или написать новый.

Вопрос еще в том, планируются ли переходы на новые SP/версии - это очень сильно влияет как на подход к допиливанию, так и на выбор между допиливанием и использованием стандарта.

Цитата:

Сообщение от Владимир Максимов

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

А в технологические ограничения платформы вам не приходилось упираться? В RecId, в ограничения по используемому об'ему памяти, числу процессорных ядер, в ошибки ядра, которые уже никто никогда не исправит, и которые влияют на стабильность работы и целостность данных, в необходимость вводить и печатать в отчетах символы не только из кириллицы и латиницы при отсутствии поддержки юникода? Да и искать тех же программистов, желающих поддерживать устаревшую версию, приходилось?

Цитата:

Сообщение от Владимир Максимов

Вот Вы можете назвать причину перехода, скажем, со старой версии MS Excel на новую?

Поддержка миллиона строк вместо 65 тыщ (очень актуально при работе с кубами), наличие интеграции через .NET вместо СОМ.

Цитата:

Сообщение от Владимир Максимов

Лично я так и не видел ни одного аргумента с которым я мог бы прийти, скажем, к главбуху или гендиректору и он тут же согласится выложить кучу килобаксов и повесить себе на шею кучу проблем на ближайший год..два исключительно ради перехода на новую версию

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

[Владимир Максимов]

Цитата:

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

А в технологические ограничения платформы вам не приходилось упираться?
(...)
Поддержка миллиона строк вместо 65 тыщ (очень актуально при работе с кубами), наличие интеграции через .NET вместо СОМ

Очень показательная аргументация. Упор делает только и исключительно на последние версии продуктов. Тот факт, что 3..4 предшествующих версий этими свойствами не обладали - игнорируется.

Т.е., во-первых, из этого следует, что переходить на каждую новую версию продукта - нет необходимости (не все из них обладают такими нововведениями). А, во-вторых, напрочь игнорируется тот факт, что старые версии ведь как-то решали описанные проблемы. Да, возможно "самопальными" средствами, но решали!

Цитата:

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

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

Вот это я и называю "загибание пальцев". Разговор "ни о чем". Слова - "заклинания". Смысл не очень понятен, но звучит внушительно.

Имеем некую старую версию Axapta, которая много лет "допиливалась" под нужды конкретного бизнеса. Естесственно, в ней вносилось куча исправлений, чтобы обойти разные баги, глюки и ограничения ядра. Откуда в работающей и отлаженной системе возьмутся эти самые "косяки и риски"? Неоткуда им взяться. Все давно выловлены.

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

Другими словами, риски не только не снизятся, но наоброт, возрастут! От чего хотели уйти к тому и пришли

Цитата:

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

Хотя если контора не развивается, не растет, и ей ничего, кроме экономии затрат, не интересно, то да, там ловить нечего, но вопрос - стоит ли тратить на такую контору свое время и силы.

Это, конечно, аргумент. Только вот к вопросу перехода на новую версию никакого отношения не имеет

[Владимир Максимов]

Цитата:

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

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

А... Был не вимателен...

Если не ошибаюсь, в 3.0 еще можно было провернуть фокус с копированием AOS. Два независимых друг от друга AOS обращающихся к одной и той же базе данных. Т.е. если всего, скажем, 50 лицензий, то 50 на один AOS и 50 на другой.

[fed]

Единственный известный мне аргумент перехода на новую версию лежит в плоскости, никак не связанной со свойствами самой новой версии. Когда внедряется ERP-система, она внедряется под определенную модель работы компании. Распределение функций между отделами, учет, товарную гамму, вообще бизнес-модель в целом. Пскольку бизнес любой компании со временем меняется (даже если компания особо сильно и не ростет), внедренную систему приходится переделывать под изменения. И поскольку изменения обычно происходят достаточно хаотически (нельзя с первого раза запустить новые бизнес-процессы в идеальной форме), доработки системы тоже обычно достаточно хаотичны и непродуманы (не от дурости разработчиков на поддержке, а от естественных ограничений процесса). Спустя какое-то время (типа лет 5 после запуска) количество корявых заплаток в системе достигает критического порога, при котором собственность сопровождения становиться сопоставимой с новым внедрением. В этот момент необходимо попросту заново внедрить ERP-систему. При этом, обычно, выгоднее внедрять не совсем постороннюю систему, а просто новую версию текущей системы, поскольку и люди уже обучены, да и из старой версии можно какие-то наработки и данные перенести. Конечно можно извратиться, и попытаться внедрить заново старую версию системы (типа Axapta 3.0). Но это уж совсем маразм, поскольку все-таки любая новая версия в чем-то лучше старой.
НО: Мне не приходилось сталкиваться с ситуациями, при которой внедрение новой версии было бы реально экономически обосновано ее новшествами или лучшей поддержкой. Всегда переход был вызван тем, что старая система становилась слишком уж дорога в поддержке после многлетнего перелопачивания и полировки...

Возвращаясь к теме заданой топикстартером: Я один раз видел внедрение, где пытались использовать внешнюю систему (это была комбинация MS CRM и какой-то самописки на Sharepoint) как frontend к Аксапте (как раз с целью экономии стоимости лицензий). Проект провалился, потому что стоимость разработки интерфейса между внешним приложением и Аксаптой начала выливаться в такую сумму, что клиент тупо докупил лицензий на Аксапту, а CRM/самописку по большей части выбросил (попутно потеряв деньги, потраченные на лицензии Business Connector User). При этом дело это было в Румынии, где ценник на аксапту примерно такой же как в России, а стоимость разработчика - раза в полтора пониже чем в Москве... Вот и думайте - выгодно писать фронтенды к Аксапте или нет...