Поставили задачку:
Нужно вести в программе учет маршрутов торговых представителей.
1) За одним клиентом закреплено несколько торговых, по 1 по каждой группе товаров (подразделению).
2) Нужно вести историю, т.е. нужно узнать на определенный момент какие торговые были за клиентом.
3) Маршруты регулярно перекраиваются 2 раза в год серьезные изменения. Проще забить весь маршрут с 0. И если клиент не указан у всех торговых одной группы товаров, то по данным у клиента не должно быть ответственного по этой группе.
4) 1 торговый может ездить к клиенту несколько раз в неделю.

Не могу придумать адекватную схему БД. Варианты использованные раньше рушатся с каждым условием.

периодический регистр сведений, ептыть

РС

(1) Он разрушится.

(1) + 1
да ещё подчиненный Рг

(3) сделать запасной

(4) и хранить их в периферийных базах

не, ну правда ведь мы песдаты адинеснеги :)

(7) нету на мисте больше специалистов. одни тролли!

(8) ответ на сабж дан в (1) а дальше не грех и потроллить :)

(9) эээ, я ж про (13) из v8: Управляемые формы, обработка активизации строки таблицы на сервере.

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

(10) ну там то откровенный тупизм. ему мягким по теплому написано "В обработчике данного события нельзя использовать серверные методы формы с директивой компиляции &НаСервере" - нет он продолжает долбить клювом. хотя полоска под ником не маленькая

(1) Периодический регистр это первое, что приходит на ум, но... нужны уточнения
Маршрут не может меняться чаще чем 1 раз вдень (на самом деле ещё реже)
Как отразить, что торговый не ходит больше к клиенту?
И в этот же день другим документом, что к этому клиенту ходит другой торговый

Хотелось бы предложение по структуре регистра. Уже 3 раз приходится переделывать(((

Ясно, по троллили, по ржали, а советов 0.
Может, всё таки у кого-нибудь, будет идея внятной и рабочей схемы?

(13) делай адекватную периодичность
"больше не ходит" - срез последних с сравнением по дате

(15) Может все-таки кто-то сперва представит свой вариант и пояснит что не срослось?

(17) Попытка улучшить, обычно хуже свежего взгляда, но вот вариант:
РС, периодичность день
Измерения:
 Клиент
 Подразделение
Ресурс
 Торговый
 День посещения

Документ назначение маршрута, при проведении проверяется маршрут с предыдущим, если клиент больше не включен в маршрут, то для (клиент, подразделение), торговый заполняется пустым значением

Хорошо:
1) По клиенту видим всех его торговых (бывших и текущих)
2) По торговому видим всех клиентов, с днем посещения.
3) Если назначить в маршруте клиента, который закреплен ранее за другим ТП, клиент переходит к другому торговому, автоматически.

Плохо:
1) Нельзя сделать несколько раз в неделю
2) Нельзя отметить, что к клиенту торговый ходит раз в 2 недели
3) Если сделать 2 документа установки маршрута с переходом 1 клиента от 1 торговому к другому, то второй документ не проводится, т.к. запись в регистре с такими ключевыми записями существует.

(18) Недостатки 1 и 2 легко устранить, если выделить график посещения в отдельную сущность. И заполнять наперед, как в ЗУПе. Тем более, если меняются раз в полгода.

По 3-му: а зачем два документа, почему не одним?

(19) Как?
Пробовал посмотреть в документе - регистраторе, мягко сказать не удобно.
Вторая мысль - справочник с табличной частью, тут не уверен что всплывет.

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

Как 1-м  документом?
По задумке 1 документ - 1 маршрут.

(20) >Как?
Как лучше описать график, зависит от характера данных. Как вариант, посмотрите на графики в том же ЗУПе - справочник с ТЧ-шаблоном + РС с заполнением на каждый день. Это хорошо работает, если вариантов этих шаблонов существенно меньше, чем представителей. Типа "понедельник-среда-пятница" или "1-е и 15-е число месяца" и т.д.

>Как 1-м  документом?
>По задумке 1 документ - 1 маршрут.
Ну и в чем проблема? Одним документом устанавливаем, что с 1 января к этому клиенту ходит Петров. Другим устанавливаем, что с 1-го июня будет ходить Васечкин. Каждый док сделает по одной записи в РС.

(21) Тогда получается, надо заполнять гафик, как календарь. Т.е. посещаем клиента по таким то числам, но тогда придется регулярно продлевать этот график, что не удобно.

Как обработать такую ситуацию:
Петров ходит с 1-го января, а с 1-го июня не ходит? Т.е. получается период, когда к клиенту не ходит никто.
И как полученное решение срастется с Вашим вариантом.

(0) Касательно п. 2. Т.е. система должна знать на указанную дату перечень торговых, закрепленных за клиентом (в независимости от дня недели посещения и периодичности посещения)? Или система должна знать какие торговые посещают клиента на указанную дату?

>Петров ходит с 1-го января, а с 1-го июня не ходит? Т.е. получается период, когда к клиенту не ходит никто.
Торговый = пустая ссылка, например.

(24) Так и сделано, но если вводится в один день маршрут сначала Петрова, потом Васечкина. Тогда Маршрут Васечкина не проводится, т.к. запись с такими ключевыми полями существует.

(23) Не совсем понял, это одно и то же. Если торговый закреплен за клиентом, то он (торговый) к этому клиенту и ходит.
1) Нужно знать, что на 23 ноября, у клиента "ООО Ромашка" по "газ воде" ответственный Пупкин
2) Нужно знать, что по состоянию на 23 ноября Пупкин посещает "ООО Ромашка" по понедельникам четной недели и четвергам нечетной, т.е. следующие посещения: 29 ноября и 3 декабря.

(26) т.е. наоборот 24 и 6

(25) Ну, правильно. И что не нравится?

(28) Не нравится, то, что не проводится документ.

(29) Так в учете косяк, потому и не проводится! Не фиг в один день двоих назначать. А если этот день с посещением, то придут двое один за другим, представь. То что в ЗУПе нельзя человека в один день два раза на другую должность перевести, не смущает?

Обойти-то можно (периодичность - секунда), но это себе бомбу заложить на будущее.

(30) Так то логических нарушений нет. У одного убрали клиента, другому добавили.
В чем проблема?

Другие есть варианты построения регистров? Чтобы не наступать на эти грабли

(26)Тогда один из вариантов
1) график посещения:
Измерения:
Клиент
Подразделение
ДатаПосещения - можно использовать Период, если не требуется хранить дату вступления графика в силу
Ресурсы:
Торговый

2)Изворачиваться с указанием всего необходимого для расчета даты на основании начальных данных:

Измерения:
Клиент
Подразделение
ДеньНеделиПосещения - номер дня недели
ПериодичностьПосещения - Перечисление КаждуюНеделю, КаждуюЧетнуюНеделю, КаждуюНечетнуюНеделю.
Ресурсы:
Торговый

3) Есть начальные данные для расчета как в 2), на основании их заполняется график, например каждый месяц как в 1), который можно подкорректировать. В итоге все данные будут браться из графика.

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

(33) А тогда как быть с если у торгового просто убирается клиент, например закрылся. Тогда этот клиент всё равно будет в маршруте

(34) Например. Есть запись в регистре что с 01.12.12 торговым агентом, который посещает ООО Ромашка по газ. воде по четвергам каждую неделю, является Иванов.
Если с 01.01.13 торговым агентом, который посещает ООО Ромашка по газ. воде по четвергам каждую неделю, станет Петров, то просто вносится запись: 01.01.13, ООО Ромашка, Газ. вода, четверг, КаждуюНеделю, Петров.
Т.е. если набор значений измерений записи одинаковый, то срез последних на этот набор измерений покажет Иванова с 01.12.12; Петрова - на дату с 01.01.13.
Просто так работает периодический РС.

(35) Невнимательно прочитал вопрос в (34).

(34) Если надо закрыть клиента, то тогда вытаскиваем запросом последние данные по этому клиенту
ВЫБРАТЬ
   НашРССрезПоследних.ДеньНеделиПосещения,
   НашРССрезПоследних.ПериодичностьПосещения
ИЗ
   РегистрСведений.НашРС.СрезПоследних(&Дата, Клиент = &Клиент И Подразделение = &Подразделение) КАК НашРССрезПоследних

Перебираем все эти варианты и для них устанавливаем на дату &Дата ресурс Торговый пустым значением.

(37) и снова возвращаемся к (25)

(38) У вас (25) ссылается на структуру описанную в (18). Измерений там не достаточно. Т.е. ключ точно определяет конкретный маршрут.Если использовать структуру из (32) под 2) то такого быть не должно. Естественно, с учетом периодичности РС День, торговый на один и тот же маршрут не должен назначаться чаще чем один раз в день.

(39) + Торговый может быть равен как конкретной ссылке на объект так и пустой ссылке. Это ничего не меняет. Просто пустая ссылка будет говорить, что на маршрут не назначен ни один торговый.
(38) Если в (25) описан случай при котором сначала на маршрут назначили (ввели документ №001) с 26.12.12 Иванова, а потом передумали и решили поставить с этой даты Петрова и пытаются ввести документ №002 от 26.12.12 уже на Петрова, то тогда второй документ не проведётся. Для того чтобы провёлся №002 надо распроводить №001 и это правильно.

(40) "Если в (25) описан случай при котором сначала на маршрут назначили (ввели документ №001) с 26.12.12 Иванова"
Не назначили Иванова, а сняли с маршрута.
", а потом передумали и решили поставить с этой даты Петрова и пытаются ввести документ №002 от 26.12.12 уже на Петрова, то тогда второй документ не проведётся. Для того чтобы провёлся №002 надо распроводить №001"
А вот Петрову как раз назначили. И с точки зрения задачи - это не верно.