Добрый день. 8.2 УФ.
Возможно, кто-то сталкивался - не могу придумать вменяемую модель реализации расстояний между филиалами. Подробнее:

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

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

Пока мысль такая - сделать справочник городов, в форме филиала сохранять его город.
В справочнике городов табличное поле с двумя колонками - город, расстояние. ПриСозданииНаСервере(), заполнять это табличное поле всеми остальными городами, подтягивая уже введенные значения (т.е. если в карточке города А введено расстояние до Б, в карточке Б заполнять обработкой расстояние до А). Либо еще как вариант - после заполнения новой карточки в призаписи() обработкой заполнять расстояние во всех остальных городах до новосозданного.

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

Заведи города, а расстояния между ними храни в регистре сведений

(1) Хранить понятно. как эту красоту администрировать? При добавлении города 300 регистров добавлять?:)

(1) администратор пропустит какой-нибудь город, да и вообще умрет их вводить, если не будет таблицы с четко очерченными рамками - чтобы сразу было видно, где незаполненные значения

Запили Яндекс Карты http://infostart.ru/public/88304/

Или Google.Maps http://habrahabr.ru/post/139444/

вводи координаты городов, а расстояния считай по формуле

(0)  1) Справочник городов.
    2) Справочник расстояний, в котором выбирается пара городов и указывается расстояние.
    3) Обработка по контролю отсутствия какой-то пары.

при необходимости можно автоматом создать рс с растояниями иежду городами на основе координат и вручную править, если факт ситьно отличается от плана (дорога кривая совсем)

(1) +1

(2) При добавлении города в нем еще нет филиалов -> заполнять ничего не нужно. При добавлении филиала заполнятся город. Затем проверка, есть ли в регистре расстояния до тех городов, где другие филиалы. Если что-то не заполнено, предлагается заполнить. В любом удобном виде.

Узнаешь / зарегистрируешь расстояния, а дальше что?

(3) Пусть вводят и проверяют те, кому нужен отчет.

Кроме расстояния можно в регистр сведений добавить Маршрут

http://www.sit-trans.com/?action=distance
>> Если вы хотите - можете использовать сервис расчета расстояний на своем сайте.

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

>Общее количество филиалов 300
>В идеале это должна быть двухмерная матрица

Справочник + РС для хранения данных

так что мешает достичь идеала? и заполнять идеал
правда это будет матрица 300х300

или вопрос в другом? как автоматически заполнить эту матрицу?

(0)
Хранить можно в регистре.
После добавления новых городов (для которых не рассчитаны расстояния до других городов) используй API Яндекс карт/Гуглевский/иной API (есть же линеечка в яндексе, которая измеряет расстояния). В чем проблема?

если города далее по ссылке где-нить нужны будут - справочник
если просто информационно - города брать из классификатора
для хранения связки по-любому - РС

можно задать в справочнике (или регистре сведений) расстояние между городами. а 1с будет считать расстояние в графе - минимально возможное

18+ составляя наиболее короткую цепочку

(19) это было бы возможно, если бы города стояли на одной прямой:) а если треугольником?:)

(0)  а в чем предполагается мерять расстояние?

(21) в км. особая точность не нужна.

(20) если всего в базе 3 города, то и в таблице будет 3 записи. конечно можете сделать 300x300/2 записей. но не из каждого города есть прямая дорога в другой. вот я и предлагаю ввести только существующие дороги (расстояния) между городами

непонятно в чем проблема.
Хранить данные в регистра (город-отправитель, город-получатель, расстояние), отчетом выгружать данные в матрицу (хотя бы СКД с группировкой таблица - по горизонтали город отправитель, по вертикали - город получатель), по расшифровке скд открываешь обработку для заполнения расстояния и вуаля

(24) ВОТ!:) Спасибо, этот вариант действительно будет лучшим.

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

(26) да, конечно в справочнике - есть по 5-6 филиалов в 1 городе.

(25) Мы рады, что ты наконец понял (1)!

не понимаю, зачем нужно напрягать пользователя вносить расстояния. дополните справочник филиалов географической координатой и рассчитайте расстояние между ними по формуле http://en.wikipedia.org/wiki/Great-circle_distance
Если хочется чтобы расстояние между филиалами в одном городе было равно 1 - введите атрибут город и простым условием проставьте эту константу

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

(28) :)))))

(28) в (1) прозвучало то же, что я задал в вопросе - я спросил в том числе про реализацию через РС. Однако я задал вопрос про администрирование этих записей - и ответ был только в (24)

Зачем тут СКД? Простых путей не ищем?
Просто отдельную обработку сделать.
Более того - вам наверняка не нужны расстояния между всеми городами.
Создайте справочник "Маршруты" (если такого еще нет).
А в маршруте кнопочку: "Ввести расстояния", чтобы открывалась матрица только по этому маршуту.

(30) Запускай их из 1с в (13).
Данные в 1с должны забивать пользователи, а не программист.

В РС надо хранить координаты городов. Я думаю, их даже откуда нить подгрузить можно будет. А дальше уже считать

(35) Да. Таким способом можно будет рассчитывать географически абсолютно точные и поэтому никому не нужные значения расстояний. :)

(33) у меня так графмик поставок сделан. На СКД проще чем свои формы рисовать

(36) Ну для 300 городов заполнять 90000 строк тоже не айс

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

(38) в каждом из 300 городов заполнят по 300 расстояний, а потом данные сольются в одну базу)))

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

(38) Городов не 300, а около 70. Филиалов 300.
И заполнять тогда не 70*70, а 70!, так как только для первого города необходимо указать расстояние до всех остальных. Для второго - уже на 1 меньше (думаю, расстояние от А до Б будет равным от Б до А:)))

(39) нету от чего оттолкнуться. Точнее есть - от логики пользователя, но это алгоритмизации не поддается:)

(42) нет еще раз 70*70/2, а не 70!
вспомните как выглядит сетка игр в футболе и т.п.

(44) посчитайте 70! и 70*70/2 и найдите между ними разницу:)

(45) ой, это я напутал. не факториал, а прогрессия

(38) А чего делать? Условно по карте расстояние между А и Б 100 километров, только напрямую не проехать, потому что болота, а по трассе - извольте 250 км.

(47) +

(47) Пример - Крым. По прямой 7 км, по трассе - 30.

интересно как на автотранспортных сйтах расстояния считаются и маршруты рассчитываются? я пользуюсь sit-trans.com, прямо вопрос мучает

(50) да, там не кратчайшее, а по трассам. Уверен, что большую часть цифр администрируют вручную - делают промежуточные точки, потом по ним считают. Довольно точно кстати считают.

именно