|
странно все это.
есть уже РАБОТАЮЩАЯ система, в которой на алгоритмическом уровне заложены проверки (например, упомянутый мной выше TESTFIELD). да, сообщения об ошибках там кривоваты НА ПЕРВЫЙ ВЗГЛЯД ("Сумма должно быть отрицательно, таблица ... первичный ключ ..."), но после первого полугода работы в поддержке они мне стали гораздо более милы, нежели "тут нечего учитывать" или отсебятина, вроде "Вы внесли не все реквизиты. Пожалуйста, внесите все реквизиты".
2 zub
именно ERROR, а не EXIT(FALSE), который не ловится дебагером и на то, чтобы понять, почему функция НЕ ОТРАБОТАЛА и НЕ ОТРУГАЛАСЬ или отругалась мессейджем, уходит от получаса и более.
помним, что ERROR откатывает всю транзакцию, что тоже немаловажно.
2 Destroyer
обязательные для заполнения поля в карточке - моветон. ибо обязательные для заполнения поля можно настроить напрямую в SQL (никаких обходных путей! пока не заполнил - сиди дальше в строке!), но Navision так не работает, поскольку ЗАПИСЬ СОХРАНЯЕТСЯ сразу после определения номера из серии номеров. ты еще название поставщика не ввел, а запись уже сохранена в таблице. проверять заполнение полей нужно не на выходе из карточки, а при попытке использовать эту карточку в документе.
забыл указать Поставщик Учетную Группу - фиг тебе, а не заказ покупки!
это в конечном счете только дисциплинирует пользователей.
безответственных пользователей никакая информационная система со всеми запретами и проверками не вылечит. у них всегда останется простор для маневра перепутать количество и цену.
простите что так длинно
спасибо тому кто осилил
|