Проверка полей на обязательность заполнения NAV 2017

[nicotine]

Коллеги, добрый день!

Наша компания (Uque) реализовала небольшой функционал по проверке обязательности заполнения полей в NAV 2017.

Особенность решения - то, что оно никоим образом не затрагивает стандартный функционал.

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

Код, как всегда, находится в общем доступе, плюс есть небольшое описание.

http://uque.ru/solutions/UqueCheckFields.html

Скачивайте, пробуйте!

[Sancho]

у меня тоже есть решение по проверке полей (и не только, правда не бесплатное) для NAV 3.7 - NAV17

также флоуфилдов
также условная проверка (если код склада СИНИЙ, то дата отгрузки не раньше послезавтра)
также настраиваемые сообщения об ошибке
кстати мультиязычные
и еще результат проверки может быть как запрет, так и предупреждение (для админов, например)

если интересны подробности - пишите в личку.

[IGG]

Что-то адрес фирмы знакомый.
БСА ребрендинг провел что ли?

[nicotine]

Не БСА, но находимся примерно рядом с ними.

[IGG]

Цитата:

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

Не БСА, но находимся примерно рядом с ними.

Понятно. Удачи :-)

[Александр Ермаков]

Наверное, нужно бы каких-нибудь дополнительных маркетинговых слов написать, зачем это нужно и какой бенефит. А то есть стандартное свойство поля пэйджа "ShowMandatory = True", многие пользователи могут задаваться ненужными вопросами, ещё не скачав...

[ena_ax]

Цитата:

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

Наверное, нужно бы каких-нибудь дополнительных маркетинговых слов написать, зачем это нужно и какой бенефит. А то есть стандартное свойство поля пэйджа "ShowMandatory = True", многие пользователи могут задаваться ненужными вопросами, ещё не скачав...

Предлагаете модифицировать стандартные объекты?

[Александр Ермаков]

Ну это смотря что называть модификацией. Так можно и выведение нового поля на пейдж модификацией посчитать )). Это дело терминологии или даже вкуса. Я в целом сторонник использования стандартного функционала и по возможности минимума доработок. Так и дешевле в итоге для всех. ИМХО, изменить свойство поля на пейдже - это скорее настройка, чем модификация; загружать в систему сторонний тул, который позволяет управлять свойством, которое уже есть - это бОльшая разработка. Хотя она тоже, в определённых сценариях, может быть необходима - собственно, и предлагается автору добавить немного бенефитов в описание )).

[nicotine]

Цитата:

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

собственно, и предлагается автору добавить немного бенефитов в описание )).

Александр, согласен по поводу красивых слов. Постараюсь)

Стандартный функционал NAV имеет несколько возможностей указания обязательности заполнения полей в документе или справочнике.
Это свойство Mandatory Field, которое влияет только на внешний вид (с условиями) и не контролирует значение поля, и свойство NotBlank, которое контролирует значение поля, но не может контролировать заполнение данного поля в зависимости от условий (например, значений других полей).

Наше решение позволяет контролировать заполнение полей в документах и справочниках в зависимости от условий (значений других полей).
Список обязательных для заполнения полей может быть разным для каждого условия.
Например, для российских клиентов обязательно заполнение поля ИНН, в для иностранных клиентов обязательного заполнения поля ИНН не требуется.

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

[nicotine]

Цитата:

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

Ну это смотря что называть модификацией. Так можно и выведение нового поля на пейдж модификацией посчитать )). Это дело терминологии или даже вкуса. Я в целом сторонник использования стандартного функционала и по возможности минимума доработок. Так и дешевле в итоге для всех. ИМХО, изменить свойство поля на пейдже - это скорее настройка, чем модификация; загружать в систему сторонний тул, который позволяет управлять свойством, которое уже есть - это бОльшая разработка.

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

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

[Sancho]

да, но запуск ф-ции проверки все равно надо будет где-то прописать.
ждем 18-го Нава с его экстеншенами

[nicotine]

Цитата:

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

да, но запуск ф-ции проверки все равно надо будет где-то прописать.
ждем 18-го Нава с его экстеншенами

В сабскрипшинах, в расширении workflow откликов и событий.

Это не затрагивает стандартные объекты

[Александр Ермаков]

Цитата:

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

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

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

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

Однако, система NAV высоко ценится как раз за удобство и простоту кастомизации, и при внедрении нужно соблюдать разумный баланс. Вам в любом случае не удастся избежать "модификаций", прежде всего - хотя бы при настройке внешнего вида пэйджа под всех пользователей или под конкретную роль: какие-то поля будут скрыты, какие-то не выведенные - выведены. Строго говоря, это тоже "модификация" )). Однако, повторюсь, я лично не считаю это модификацией, критически отражающейся на обновлении (как в целом модификации пэйджей я считаю намного более "лёгкой" с точки зрения апгрейда кастомизацией, чем модификация например таблиц или их кода).

Также, пока свойство ShowMandatory нельзя изменять через Extension, оно не входит в список доступных (несколько свойств, тем не менее, доступно) - но это пока )). Если очень захотеть, можно передать пожелания продуктовой группе, возможно, его включат в следующем релизе.

[Sancho]

2 nicotine
еще для расширение возможностей вашего прототипа неплохо было бы контролировать наличие измерений и вложений
контролировать оформление подчиненных справочников, строк документа например.
и возможность запускать те или иные группы контроля как при согласовании, так и при, скажем, изменении какого-то поля, установки галочки "действующий" в договоре.