с чего начать?

[Yoil]

На самом деле надо и 1) и 2).
Касаемо 1): требуйте, чтоб в списке версий в обджект дизайнере на каждом модифицированном объекте стоял код задачи (например, если объект модифицировался под задачи А01, М23 и ЕН12, то в списке версий должно быть перечисленно А01;М23;ЕН12).
В самом коде в объекте тоже доработки должны быть выделены
Во-первых, в триггере Documentation написано что-нибудь вроде
26/09/07 Mega}{aker V03 Правил функцию CheckCreateAndDestroyAll
Далее, в самой функции CheckCreateAndDestroyAll модифицированный код выделен как-нить наподобие
// V03 26/09/07 Mega}{aker >>
код...
// V03 26/09/07 Mega}{aker <<
А вот в пункте 2), в перечне, должно быть уже описание задачи с кодом V03, A01 и т.д.

Таким образом, из 2) вы будете иметь общие представления о доработках системы, а из 1) будете иметь возможность быстро найти и опознать все эти модификации.
Другое дело, не факт, что поставщики будут все это делать...

[galka]

Цитата:

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

На самом деле надо и 1) и 2).
Касаемо 1): требуйте, чтоб в списке версий в обджект дизайнере на каждом модифицированном объекте стоял код задачи (например, если объект модифицировался под задачи А01, М23 и ЕН12, то в списке версий должно быть перечисленно А01;М23;ЕН12).
В самом коде в объекте тоже доработки должны быть выделены
Во-первых, в триггере Documentation написано что-нибудь вроде
26/09/07 Mega}{aker V03 Правил функцию CheckCreateAndDestroyAll
Далее, в самой функции CheckCreateAndDestroyAll модифицированный код выделен как-нить наподобие
// V03 26/09/07 Mega}{aker >>
код...
// V03 26/09/07 Mega}{aker <<
А вот в пункте 2), в перечне, должно быть уже описание задачи с кодом V03, A01 и т.д.

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

Цитата:

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

Другое дело, не факт, что поставщики будут все это делать...

Ага, если в договоре не прописано, то отказываться будут. Рекомендую ссылаться на стандарты разработки в системе Navision. Есть и такие. Тогда все, что описал Yoil получите.
А список доработок, скорее всего должен быть предусмотрен договором.

[SHiSHok]

Цитата:

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

Рекомендую ссылаться на стандарты разработки в системе Navision. Есть и такие. Тогда все, что описал Yoil получите.

А не могли бы сказать как зовут такой документ в NAV (в AX это Developer's Best Practice Handbook).(а лучше сразу ссылку)