Мы работаем с Банками Сообщества, чтобы осуществить адаптацию Клиента и создание Счета кредитной карты.
Наш общий процесс: клиент посещает сайт, выбирает продукт, вводит информацию о приложении, подписывает соглашения в электронном виде, а затем отправляет заказ.
Мы хотим связать продукты с соглашениями по конкретным ролям. То есть Основные подписывает условия кредитной карты и личную гарантию; в то время как сотрудник только подписывает Условия использования кредитной карты.
Другими словами, на основе выбранного Продукта мы хотим создать соответствующее соглашение (я) для электронной подписи.
Мы сделали все возможное, чтобы тщательно изучить существующие модели. Мы видим, как продукты связаны с пунктами соглашения, но не уверены, что это правильный способ удовлетворить наши требования.
Несколько вопросов:
- Ниже мы предлагаем сущность ProductAgreement. Мы интегрируем это в обработку заказа. Любые мысли, вопросы или существующие способы решения этой проблемы очень ценятся.
productId (pk) -Продукт, к которому относится данное соглашение
AgreementTypeEnumId (pk) - тип соглашения, которое будет сгенерировано
partyRoleType (pk) - роль партии, для которой должно быть создано это соглашение
orderStatusId - Статус ордера, по которому должно быть создано это соглашение, и требуется перед продолжением
serviceRegisterId - Служба для вызова для генерации соглашения
templateLocation - расположение ресурса шаблона, который будет использоваться службой для создания текста соглашения.
Следует ли использовать объект Соглашения для хранения шаблонов соглашений или использовать его только для хранения экземпляров Соглашений?
Есть ли рекомендации по хранению электронных подписей? Наш план состоит в том, чтобы создать уникальное соглашение для каждой Стороны и использовать переход статуса и дату соглашения для отслеживания исполнения подписи.
Альтернативными идеями являются создание рабочих заданий или пунктов соглашения.