Все это актуально было в старые времена МПульта, когда велись рукописные журналы вызовов у диспетчера. Было мало компов и не было баз данных и программ учета у обслуживающих организаций (есть кстати до сих пор такие кто ведет бумажный журнал заявок, но и они не заполняют эти поля). Хотя зачем данные КВШ, редуктора и зав. номер ЛБ диспетчеру и тогда непонятно было... Вносились в основном ФИО обслуживающего персонала-прораб (бригадир почему-то?), электромеханик, связист, заказчик (владелец почему-то?), ну и иногда номер регистрационный. В основном использовалось примечание. Опять же это если персонала много, а не один прораб и один связист...как всегда бывает у организаций с небольшим кол-вом лифтов (до 200-300). Кол-во обслуживаемых лифтов было небольшим, как ранее написал, и всё это было полезным при условии что все лифты у организации диспетчеризированы, а это было недостижимо. Это , как понимаете, идеальные условия. Фактически эти справочные данные редко кто использовал.
С увеличением кол-ва лифтов, развитием компьютерной техники и программных средств, организациям приходилось переходить на электронные средства учета т.е заводить свои базы, в которых при необходимости все это было.
В клиент-серверной структуре LKDSDisp справочные данные СПульт стали более актуальны, т.к и лифтов стало больше (а значит и обсл. персонала) и компов, и пользователей программы подключающихся к серверу. Но к этому времени уже были свои программы учета заявок и базы данных. Поэтому в данный момент в Спульт актуальны те поля которые часто необходимы диспетчеру при работе с лифтами на диспетчеризации. Лифты без диспетчеризации или с локальными пультами есть до сих пор и их никак не внесешь в базу Спульт! Основная работа ведется в электронном журнале а вся информация находится в этой же программе учета и с ней работают диспетчера постоянно. Когда происходит вызов то диспетчеру просто удобно сразу посмотреть информацию по связисту и особенностям местонахождения лифта в СПульт, хотя она может это сделать и в программе учета, во время внесения заявки по связи. Т.е потребность в этих справочных данных не такая уж и большая, но при этом каждое всплывающее окно , каждое сообщение появляющееся на экране отнимает время и отвлекает диспетчера у которого 800 и более лифтов на экране, плюс постоянная работа в электронном журнале (внесение заявок и их снятие) и постоянные звонки. По сути , современный диспетчерский пульт это кол-центр с возможностью мониторинга лифтов. Это совсем не те диспетчера, которые сидели в лифтерках у КЛШ (или даже у монитора), ходили иногда на лифты и иногда общались по телефону.
Так вот ценность этих справочных данных для диспечтера большой организации не такая уж и большая чтобы каждый раз отвлекаться на их изменения. Это же не изменение в структуре сети ОБЬ или в адресах лифтов. Их вообще было бы лучше отделить от основной структуры, как я считаю. Тогда и обновляться они могут только во время нового запуска СПульт. Для мобильных девайсов это вообще не проблема т.к. подключение каждый раз новое. Кстати фамилии персонала и некоторые другие данные в LKDSDisp более актуальны именно для мобильных подключений, чтобы оперативно узнать кто обслуживает лифт или кто связист или прораб ну и заказчик может быть востребовано.
Кстати еще одна проблема -это синхронизация справочных данных LKDSDisp и программ учета организации. Вряд ли кто то будет вести две базы и вручную их синхронизировать. В идеале вообще-использование СПультом данных из сторонней таблицы базы, находящейся либо в базе LKDSDISP либо в другой.
, после чего изменяется фон иконы пользователя на бежевый 
после выбора пункта меню по правой кнопке мыши 
в окне 
. 
при выборе которого изменения сохраняются на сервере. Либо при переходе в рабочий режим появляется запрос-подтверждения 
, а остальные параметры лифта неизменны.
