Параметры клиентов в разрезе компаний

[Eldar9x]

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

[ice]

почему не использовать в качестве "ссылки" ключ таблицы для которой задаются параметры?

[sukhanchik]

Мы делали дополнительную таблицу, не включали ее в виртуальную компанию и связывали ее со справочником клиентов 1:1 (правда по Inner Join, т.к. хотелось иметь сортировку). Минус всего этого - приходилось заботиться о создании записи в таблице при создании клиента.

Мне кажется - это самый простой и правильный способ. Связка по RecId не есть здорово.

[Eldar9x]

Цитата:

почему не использовать в качестве "ссылки" ключ таблицы для которой задаются параметры?

таблица может быть любая, ключ может быть комбинированный, непонятно как строить лукап

[Eldar9x]

Цитата:

Минус всего этого - приходилось заботиться о создании записи в таблице при создании клиента.

а таблицу эту выносили в отдельную кнопку?

[sukhanchik]

Не. Есть 3 пути:
1. Прилепливание таблицы к форме клиентов и связь по Inner Join.
+ Есть сортировка и фильтрация
- Надо заботиться о создании новой записи
+ Все данные видны в одной карточке
2. Прилепливание таблицы к форме клиентов и связь по Exists Join (кажется)
- Нет сортировки и фильтрации (для новой таблицы)
+ Не надо заботиться о создании новой записи
+ Все данные видны в одной карточке
3. Добавление кнопки
+ О сортировки и фильтрации никто не думает
+ Не надо заботиться о создании новой записи
- Все данные не видны в одной карточке

Мы пошли сначала по пути 2, затем (по просьбе пользователей) - по пути 1. Но жизнь показала - что надо было пользователей послать и остановиться на 2-м варианте, т.к. при создании новой компании автоматически "пропадали" клиенты, а запускать каждый раз джоб по созданию записей было непозволительной роскошью. Так было в 3-шке и при переходе на 4-ку мы вернулись ко 2-му варианту

[Eldar9x]

Цитата:

2. Прилепливание таблицы к форме клиентов и связь по Exists Join
- Нет сортировки и фильтрации (для новой таблицы)
+ Не надо заботиться о создании новой записи
+ Все данные видны в одной карточке

правильно ли я себе представляю процеес настройки параметров?
Заходим в компанию 1, заводим клиента, вводим праметры.
Заходим в компанию 2, находим клиента, вводим параметры (возможно другие)

[sukhanchik]

Цитата:

Сообщение от Eldar9x

правильно ли я себе представляю процеес настройки параметров?
Заходим в компанию 1, заводим клиента, вводим праметры.
Заходим в компанию 2, находим клиента, вводим параметры (возможно другие)

Совершенно верно. При этом, если параметр не вводить, то запись создана не будет (БД пухнуть не будет).

[Eldar9x]

Я думаю, сделать примерно так, создать вкладку на клиентах, в ней (по delayed) та самая таблица параметров (которая не в виртуальной), и, не поля, а грид, с полями этой таблицы, потому что, возможно, придется эти параметры вводить в разрезе еще одного поля (например, параметры клиента для поставщика 1 м/б одни, для поставщика 2 - другие). С другой стороны, пользователю придется эти строки параметров создавать...

[sukhanchik]

Я бы так не советовал делать.
1. Это к вопросу о том, что настройки может сделать только разработчик.
2. Вы лишаетесь безумно нужной возможности лукапа, перехода к основной таблице и впадаете в зависимость от одного типа данных. Конечно можно сделать все (см. форму расширенного запроса SysQueryForm), но это не повод ТАК программировать.
3. Вам действительно надо создавать запись.

И потом. На чем Вы экономите? На одной таблице? Посмотрите на Аксапту глазами ее создателей. Создатели решили разделить таблицы клиентов и поставщиков, но сделали мап CustVendTable для размещения (работы с) общей функциональности для клиентов и поставщиков.

Соответственно - Вам что надо сделать:
1. Таблицу для клиентов
2. Таблицу для поставщиков
3. Таблицу для (на этом месте может быть любая Ваша таблица)
.....
И сделать Map аналогичный CustVendTable. Всю общую функциональность повесить на работу с этим мапом

Живите с Аксаптой по ее законам и жизнь покажется проще