Похожие объекты с разными данными

Question

Я оцениваю использование CRM 2011 для замены одного из наших существующих LOB-приложений и у меня есть вопрос, касающийся пользовательских сущностей.

У нас есть несколько сущностей, которые совместно используют некоторую базовую информацию, но для каждой сущности требуются разныесвязанные объекты в зависимости от его «типа».Также правила проверки будут меняться в зависимости от типа.В довершение всего каждый клиент может поддерживать различные подмножества типа.

Например,

Сотрудник

• Тип сотрудника: полный рабочий день, неполный рабочий день,Контракт
• Имя, адрес, дата найма и т. Д.

Различные типы сотрудников в зависимости от выбранного типа.

Полная занятость:

• Зарплата
• Пособие (связанные лица)
• Пенсия (связанные лица)

Неполный рабочий день:

• Почасовая ставка
• Количество часов в неделю

Договор:

• Почасовая ставка
• Начало контракта
• КонтрактКонец
• Информация о контракте (связанные лица)
• Отправленные табели (связанные лица)

Вопросы:

1. Как это моделироватьтакие вещи в динамике 2011?Есть ли поддержка какой-либо формы наследования?
2. В настоящее время я думаю о том, чтобы процесс автоматически создавал связанные сущности в зависимости от «Типа сотрудника» при первом создании Сотрудника.Есть ли лучший способ реализовать это?
3. Как реализовать проверку для этого сценария?

Answer 1

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

К сожалению, нет никакого наследования форм (например, создание главной формы, которая распространяется на ее потомков).И вы также не можете копировать формы.

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

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

Ситуация, в которой вы находитесьописание очень выполнимо в CRM 2011, форма не самая элегантная, но с остальными довольно легко разобраться.

Answer 2

Я бы предложил пару вещей, чтобы сохранить это "аккуратным".

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

new_all_dateofhire
new_all_name
new_ft_salary
new_pt_hourlyrate

Во-вторых, я бы создал главную вкладку с общей информацией о сотрудниках и дополнительную вкладку для каждого типа сотрудников и использовал бы подсетки для отображения пользовательских отношений. Создайте JavaScript OnLoad для отображения / скрытия только правильной дополнительной вкладки (или отсутствия вкладки для новой записи).

На общей вкладке есть раскрывающийся селектор для «Типа сотрудника». Используйте код OnChange для принудительного сохранения / обновления формы при изменении типа сотрудника. С соответствующим плагином вы сможете очистить отношения.

Answer 3

Как отметил Коул, учитывая ваши требования, вы вносите ненужную сложность, разбивая поля на отдельные объекты.Вам лучше отслеживать все эти поля в одном объекте и различать их по списку «Тип сотрудника» (выпадающий список).Затем вы можете динамически отображать / скрывать соответствующие поля в форме с помощью JavaScript, основываясь на выбранном типе сотрудника, а также настраивая соответствующие поля по мере необходимости.

Answer 4

Лучший способ сделать это не через наследование, поскольку это приведет к денормализации данных.На мой взгляд, лучшим вариантом будет просто иметь список выбора / набор параметров, который указывает тип сотрудника.Затем есть дополнительные поля для поддержки каждого типа.Если это сотрудник на полную ставку, то поля для сотрудника на неполной ставке, скорее всего, будут нулевыми, но это не имеет значения, поскольку при любой выполняемой вами интеграции проверяется установленный параметр, чтобы увидеть, где следует ожидать поиск данных.

я видел только типы «наследования»:

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