Вобщем дело вот такое..

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

Блин.. не то нажал.. ну ладно.. продолжу тут


Вот таким образом:

А -> Д -> Ц -> Р -> Б

Вот.. и этот путь нужно мне где-то хранить.. может это подчинённый справочник или ещё что.. я не знаю поэтому спрашиваю вас.


А потом уже исходя из этого пути будут создаваться автоматом платёжки. вот..

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

И нужно конечно чтобы пользователь сам мог изменять данные..

Необходимо просто видеть, что эти платежки связаны между собой? Или необходимо контролировать порядок прохождения денег? Или просто это как бы стандартные повторяющиеся операции и необходимо по одной большой кнопке сделать сразу 100 платежек?

справочник с такой логикой:
1. Приемник денег -- это элемент
2. Все папки в которые входит элемент, это путь следования денег. Так, самая верхняя папка: плательщик
3. Иерархия неограничена

у справочника 1 реквизит: организация (для группы и элмента)

(0) а еще, видимо, надо учитывать время прохождения платежки. И чтобы номера при автоматической выписки платежки на через 4 дня не сбивались?

Порядок прохождения контролировать не нужно..

Да 100 платёжек.. но операции то не повторяющиеся.. каждый день разные.. и они основываются исходя из Сабжа..

вариация на тему "без сохранения порядка следования":
1. 2 реквизита: "Приемник" и "Плательщик"
2. ТЧ "Промежуточные узлы".
все реквизиты имеют тип организаций

(7)Тогда надо посмотреть, по каким счетам проходят деньги. Если это счета взаиморасчетов, то наверное есть аналитика типа договора, в котором можно завести реквизит, по которому связывать эти операции.

(9) Нет никакх договоров..
Просто платежи.

Доровора вобщем не причём тут вобще..
Вот в (8) норм да..  но только путь не вегда из одинаковой длинный.. иногда 1,2,3,4 посредника.. вот..

А иногда напрямую.. но это не главное.. мне просто нужно определится как этот путь лучше хранить..

(11) так выбери случайных 4 рандомом, а там просто возможные варианты храни

(4) Вот это вобще лол что ли.. или я просто так плохо объяснил %)

А вообще задачу в целом изложи.

(15) Окей.. сейчас, ждите.. минут 5.

(10)Тогда в платежку реквизит. Отбором по нему получишь искомое.

Итак.. много организаций.. а управляющая компания - Одна.

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

Исходя из реестров, мы выдаём им на их банковские счета определённую сумму денег с основного нашего счета.

И вот путь с нашего счета до счета каждой организации не прямой.. а через посредников..

Примерно так:

ОсновнойСчет - ОС.
СчетОрганизации - СО.

Вот путь от ОС до СО15 допустим
СО - СО2 - Со10 - СО 15

И у каждой организации этот путь есть..

///////////////////////////////////////////////////////////

Я хочу сделать документ.. в котором на каждую организацию заполняется кол-во затрат, то есть сумма денег нужная им.

И после этого по нажатию чудестной кнопки чтобы создавались документы - Платёжные Поручения. Но не одно, а много так как путь не напрямую и чтобы создавались исходят из пути.. вот..

Основной вопрос.. где лучше хранить путь? Я думаю в подчинённом справочние.

Блин.. а есть аналог реквизита с типом значения - СписокЗначений..?

(18) А все это в одной базе?

(20) Люди будут подключаться к базе по ТонкомуКлиенту.. каждый из своего Офиса/Города..

Ну или если 20мегабит/сек не прокатит.. то тогда сервак и RDP

(21) А критерии отбора не подойдут?

(20)
Да, люди будут два раза делать платёжки.. в своих базах.. в учётных и вот в этой базе.. потом напишу каждому перекидывалку.

А может кто-нибудь пояснить про хранилищеЗначений? В нём СписокЗначений ведь можно хранить, да?

Я решил вобщем хранить в табличной части справочника.. вот..

(25) Можно, но оно не гарантирует ссылочной целостности. Так что в топку
(26) нормальный вариант, главное, как ты реализуешь алгоритм создания документов