spПока не пойму как реализовать это в структурном виде.Пока почитайте вот это , может помочь.

Сахават Юсифов может подойдет Да запихивать нестандартные услоовия в логовор - я проблем особых не вижу, если они совсем неефоромализованные.
Всеравно все сведется у доп текстовому описанию (составленному из EAV или человеком).

Задача имеет какой-то адекватный смысл, если нестандартный договор компануется из стандартных элементов.
Например: есть кредит ипотека вторичка, аннуитетные платежи, для любых физлиц, справка свободная форма, валюта РУБ, 20%
есть другой продукт: кредит ипотека первичка, аннуитетные платежи, для физлиц по зарплатной схеме, справка 2НДФЛ, валюта USD, 17%

хочется: кредит ипотека первичка, аннуитетные платежи, для любых физлиц, справка свободная форма, валюта РУБ, 18%

если хочется: первичка, но первые полгода платить только проценты, без маратория на досрочные погашения, с правом продажи квартиры до окончаниия кредита, но погашением кредита в момент продажи.
то, боюсь, такое только текстом....

Сахават Юсифовсоздается объект с первичного шаблона потом удаляются одни свойства и добавляются другие
я так думаюОткрывается текстовый файл, в нем пишется нестандартные условия и отправляются на согласование.
Ничем особо не будет отличаться.

EAV подойдет для конструктора, для неизвестных элементов - всеравно только текст.

Сахават Юсифова расчеты всякие после согласования???На основании чего расчеты вобще могут быть сделаны, если это не стандартные условия?
Человек будет морщить ум и расчитывать.
Была бы формула - были бы стандартные условия.

Предлагаю разделить задачу на две, вторую свести к первой.
spВ принципе я понимаю, что "нестандартные условия" это формализованные условия не вошедшие в типовой договорЭто когда набираем условия из конструктора и составляем типовой договор.

Здесь вспоминаем про задачу "Изменения в блюдах" - это почти одно и то же.
Есть аналогичные задачи - "Сборка компьютера на заказ". Конфигурацию определяет клиент.

Делать можно на основе структур типа EAV.
Что быдл бы удобно - определить в структуре "просто договора" обязательные поля, которые должны быть как-то заполнены. Просто чтобы их не забывали заполнять.

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

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

spЕстественно, что различные доп условия влияют на % и сумму договора - часть это расчет, а часть формирование % либо по стандартным условиям либо волюнтаристским :)Это отдельная задача, не зависящая от хранения условий.

Petro123Напр. оценить платежеспособность клиента при ипотеке по нестандартным условиям?Для этого в банках есть отдел Риски.
Они и принимают это решения.

финансовый риск-менеджмент , и в гугле .

Petro123Bely,
значит у нас были небольшие банки, где всё это делалось на сриптовых ЯП.Дело не в крупности и прочем.
Формулы должен придумывать - специалист по Рискам. Учился он на это, не учился, смотрит он в учебник, придумывает из головы - это его проблема.
Программировать формулы - должен програмист.
Очень редко, когда это может сделать один и тот же человек.

Просто надо разделять бизнес функцию и техническую часть.

Обсуждать в каких случаях какие процентные ставки применять - не буду:
1) Не компетентен в этом вопросе
2) Не интересно

Обсуждать как програмировать формулы - вот это я могу :)

Здесь вариантов масса (и скрипты и плагины).
Но эта задача отдельная от хранения.

Petro123странно. С каких пор бизнес-логика (БЛ) стала вне СУБД (1С исключим).
если в БД надо только хранить, то БЛОБ подойдёт.Я имел ввиду другое.
Задачу автора можно разбить на две:

1) Как хранить не типовые условия
2) Как вести подсчеты по условиям договора (типовым и не типовым)

Если рассматривать задачу (2) отдельно от (1) - то для нее всеравно как хранить.
Можно через EAV, можно в более хитрых структурах с иерархической вложенностью, можно в отдельных полях в плоской таблице, в нескольких таблицах...
Просто подсистема должна уметь с этим справляться.

Серьезные ограничения для подсистемы (2) я вижу только если, действительно, хранить все в LOB

в остальных случаях сложность системы правил для расчетов будет соизмерима для разных вариантов. (моя оценка)