Как правильно вести разработку в условиях, когда часть кода закрыта от изменения - Sys-слой в аксапте, закрытые codeunit в навике, extensions в MS CRM

[sukhanchik]

Ну т.е. получается - будет одна "большая дырка", через которую будут делать все .
Я конечно утрирую, но все определит количество доступных разработчику event-ов.
В рамках поставленной mazzy задачи - если будут event-ы на PriceDisc*-классах, то "врежемся" туда. Если будет event только на строке заказа при подстановке цены - то "врежемся" туда. Если оставят "дырку" только на этапе разноски заказа - то значит там будем менять цену.

Будет спрос на event что-нибудь типа "при старте системы", в который будет загружаться своя форма, свой код и дальше будет работать "свой extension". Который не будет мешать MS-у обновлять свой никем не используемый код ))))

Я шучу конечно, но общий смысл такой - если есть какой-то объект в системе, который все постоянно модифицируют, то после закрытия такого объекта - будет проще его вообще не трогать, а закодить копию (копию по сути) этого объекта "на стороне".

Ну т.е. есть к примеру, заказы на продажу. Их закрыли на изменение. Я пошел и добавил свой объект "акты оказанных услуг" . Естественно добавил туда только то, что мне надо. И пусть MS обновляет эти заказы...

[trud]

Цитата:

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

Ну т.е. есть к примеру, заказы на продажу. Их закрыли на изменение. Я пошел и добавил свой объект "акты оказанных услуг" . Естественно добавил туда только то, что мне надо. И пусть MS обновляет эти заказы...

А вот кстати вопрос - так можно с точки зрения лицензионных соглашений? т.е. можете ли вы продублировать функциональность системы поставив еще дополнительно у дублируемых меню айтемов(они же ваши, новые) более дешевый тип лицензии(например task вместо enterprise)

[sukhanchik]

Цитата:

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

А вот кстати вопрос - так можно с точки зрения лицензионных соглашений? т.е. можете ли вы продублировать функциональность системы поставив еще дополнительно у дублируемых меню айтемов(они же ваши, новые) более дешевый тип лицензии(например task вместо enterprise)

Ну тут-то как раз как мне кажется просто. Если я дублирую функциональность, то ... я ее в программном плане не дублирую, а реализую лишь уже то, что реализовано в узком смысле, то, что нужно мне. Всяко функциональность заказов на продажу будет больше по объему функциональности моего "акта об оказанных услугах". Я еще могу "облениться" и просто нарисовать свой интерфейс, который даже напрямую в General Journal* не будет лазить, а просто будет создавать ЖГК.
Т.е. быстро, просто и под меня. С т.з. программного кода - там даже и не будет пахнуть идеей заказов на продажу. С т.з. философии системы / Best Practice - это неверно. Но... проблему с обновлениями я решил. А с лицензией - еще надо как-то доказать, что мои Task-и "заслуживают" Enterprise . Конечно, если я явно буду использовать ЖГК - то наверное это будет явно и видно. А вот если я задействую лишь архитектуру АХ... то на архитектуре как бы не стоит тип пользователя

В общем - MS-у мне кажется придется прописывать какие-то более четкие правила использования типов лицензий (используешь в коде класc DimensionStorage - все, значит Enterprise. Пишешь ручками джойны - Task) ))))))))