Цитата:
Изначально опубликовано Anais
(1) Я - программист и совет "старайтесь не программировать" - ну никак не ко мне 
Не готов согласится.
Этот совет - именно программистам, именно вам.
В Аксапте решайте задачи пользователей, а не свои.
Так например, "список Тех.Мест - очень большой, но зато - четырехуровневый. Обязательно нужно иерархию, чтобы было удобно"
Четырехуровневая иерархия может быть сделана в одной таблице "универсальной" иерархией, а может быть сделана в одноуровневые четыре таблицы.
Теперь смотрите, пользователям как правило будет абсолютно все равно как вы это реализовали.
НО
Если вы реализуете это как "универсальную" иерархию, то вам придется программировать ВЕЗДЕ, где вы будете сталкиваться с этим своим чудесным объектов. Обратите внимание на слово ВЕЗДЕ. Это не только ввод и лукап. Это и фильтры, это и ОТЧЕТЫ.
Теперь посмотрите, что произойдет, если вы выберете четыре одноуровневые таблицы. Ввод, фильтры, лукапы работают как обычно. формы и отчеты накидываются простым drag'n'drop'ом. Массово программировать не придется.
Именно это я и имею в виду в призыве "не программируйте".
Теперь самый главный вопрос - можно ли в вашем случае использовать четыре одноуровневые таблицы вместо универсальных?
Вот это и есть ключевой момент. Если вы будете решать проблемы ваших ПОЛЬЗОВАТЕЛЕЙ, то вы обязательно должны разобраться в задаче, понять какие случаи являются ключевыми и существенными, а какие нет. Вы обязательно должны понять где будет бесконечное число вариантов, а где число вариантов строго ограничено. (Пример неправильного подхода в некоторых системах: ставки НДС сделаны жестким перечислением (enum), а признак пола м\ж сделан таблицей).
Если же вы решаете свои ПРОГРАММИСТСКИЕ задачи, то конечно же надо делать самый универсальный способ. Это же так интересно! Заставить работать иерархию в реляционной базе данных! Это же какая победа программиста! Любой программист это оценит, ей богу. Так и рождаются универсальные построители sql запросов, когда есть query, так рождаются динамические формы с произвольным числом реквизитов произвольного типа и т.п. Беда только в том, что ПОЛЬЗОВАТЕЛЮ это нафиг не нужно. Пользователю нужно решение ЕГО проблем. Желательно понятными для него способами.
Ваш пример также является типичным: Где в вашем задании было сказано, что вам нужно построить иерархию с бесконечным числом уровней? Мало того, я сильно подозреваю, что у вас в техзадании прописано назначение каждого уровня. Почему же вы начали делать именно "универсальную" иерархию, заранее зная, что это будет тяжелый" объект и заранее зная, что будут проблемы с правами доступа? Вы уверены, что решаете задачу пользователей, а не свою?
Вы считаете, что иерархия может поменяться в любой момент? Может, это всего лишь значит, что вы (или ваши постановщики) не до конца разобрались в задаче?
Anais, я конечно же могу ошибаться. Заранее приношу свои извинения.
Надеюсь, что у вас происходит правильное программирование.
В частности у вас очень хороший третий вопрос: "Модуль ТОРО в Axapta и без программирования? Очень, очень интересно. Честно. А на каком стандартном функционале его тогда реализовать?"
Да, действительно очень интересно.
Для начала давайте определимся с терминологией.
Итак что вы подразумеваете под термином TOPO? Что вы хотите от него получить?