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

[SHiSHok]

Существует внедрение NAV 4 (точнее еще идет) на предприятии. С чего лучше и эффективнее начать изучение NAV программисту (новичку в NAV, но c опытом в Axapta) чтобы в более сжатые сроки самостоятельно обслуживать предприятие. Используются финансы (ГК, расчеты с клиентами-поставщиками, налоги, ОС) и дистрибуция (управление запасами,складом). Предположим поставщики сдадут все "под ключ" в рамках поставленной задачи.
Т.е. интересует какие курсы стОит пройти, какие существую качественные материалы для самостоятельного изучения, чего потребовать от поставщиков?

[galka]

Цитата:

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

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

От поставщиков потрубуйте максмально возможную по условиям договора документацию на изменения программного кода. Что бы были описаны все изменения, которые они делали (зачем сделали, какие объекты затронуты), желательно, что бы описывались не отдельные изменения объектов, а доработка в целом.
Какие объекты модифицированы легко понятть по галке в поле "Modify" (правда ее можно снять ) и сравнении даты компиляции объекта с датой компиляции БД, которую Вы только -только установили с дистрибутива...

Попробуйте организовать краткий курс разработки со своими поставщиками решений. Если Вы понимаете в программировании хоть что-то и знаете Паскаль, то, мне кажется, больше и не надо. В системе есть неплохая документация по разработке: справочник функций, свойств и пр. с примерами использования....

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

[SHiSHok]

По количеству кода и фич АКС на перевом месте однозначно (в NAV всего то 6 типов обьектов). На Delphi параллельно задачки пишу, посему с паскалем проблем не наблюдается. С поставщиками все понятно (в аксапте немного легче - код поставщиков на отдельном слое обычно и его можно выделить).
Может всетаки какая ценная литература имеется по NAV?

[apanko]

Получите доступ на CustomerSource.
Там были все доступные книги http://forum.mazzy.ru/index.php?showtopic=332.

[SHiSHok]

2galka & all:
Как вы думаете, в каком виде лучше поставщикам предоставить документацию относительно разработки? мне пока в голову приходит следующий вид документации:
1) комментарии в коде включающие: условный код проекта, дату, краткое назначение кода
2) перечень реализованых задач с детализацией по разработанным, модифицированным обьектам, т.е. проект.

Самое сложное, я думаю, это комментарии - их никто не любит ставить
PS: Может кто поделиться какие варинты документирования проекта реально предоставляют поставщики?

[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).(а лучше сразу ссылку)