Доп.Соглашение

[jopagames]

Коллеги, общий привет.

Подскажите, пожалуйста, как лучше прикрутить к системе Доп.Соглашения к Договорам?
Я вот думал-думал, но идей пока никаких. (Точнее есть, но все неудобные)

Имеем.
1. Таблицу договоров (Customer Agreement)
2. К ней добавляем новую сущность - строки (Customer Agreement Lines) в которые вносим услуги (или товары) и печатаем их список с договором.
Предположим, по договору мы обязуемся с ДатыНачала по Дату Окончания оказывать ежедневно клиенту услугу XXX. Наша задача - выставить клиенту правильный счёт за произвольный период.
3. Через неделю вдруг выясняется, что клиент хочет с середины месяца вместо услуги XXX получать YYY и надо составить (и распечатать!!!) ДопСоглашение, меняющее по сути условия основного договора.

И вот через какие сущности это всё увязать - для меня загадка.
Либо ДопСоглашение - это полная, но измененная копия строк оригинального договора, но с другими товарами\датами\ценами.
Мы тогда старый договор вообще не учитываем, а считаем всё по строкам Допника на конкрентую дату (шагаем по периоду с шагом в 1 день и смотрим, активен ли допник)

Либо это отдельная таблица, которая цепляется к строке договора и её "подменяет". Тогда вопрос, как, собственно, это отражается в самом договоре? Как это будет видеть и оформлять менеджер?

Либо стоки договора - это, вообще, некая "книга операций": типа 10 числа добавили товар ХХХ, а 15 числа удалили товар ХХХ, а вместо добавили товар YYY и теперь до конца периода считаем его.
А тогда вопрос: как из этой книги операций выделить отдельный допник для печати? (в строке договора какой-то "Код ДопСоглашения" вводить? А визуально как это будет?)
+тогда ещё нужны чёткие правила некие (а какие?), которые не позволят, например, "перекрывать" в рамках действия договора даты Допников (их может быть несколько в одном договоре)

Словом, кто понял про что я спрашивал - поделитесь идеей, пожалуйста ))

[apanko]

Как фантазия на тему - а не взглянуть ли на Производственные Спецификации и версии, для вдохновения. В спецификациях есть возможность указывать дату начала/окончания действия строки. Также дату можно указывать в версии. Ну и есть логика которая выбирает правильную спецификацию/версию/строки для документа с датой.

[Captain]

Очень давно делали что-то похожее. Договор он оставался единым, а использовали квоты продажи, которые хранились в архиве (стандарт NAV). К ним привязали отдельную нумерацию(номер допника),даты, номенклатуру и + отдельная обработка которая работала по дате и копировала строки из архива в заказ (счет) продажи.

[DAX.Company]

С Навом не работал. Но во всех системах одно и тоже. Я бы делал так. Во-первых, никакой программисткой мешанины. Все должно быть прозрачно для пользователей. Т.е. должна быть возможность легко увидеть/распечатать Текущий договор (обязательства), основной договор, все доп соглашения.
Вводим enum (перечисление): Текущий договор, Основной договор, Доп. соглашение. Все основано на сущности договор (Customer Agreement и Customer Agreement Lines). Сначала пользователь создает Текущий договор (это просто болванка для будущего заполнения). Далее по кнопке нажимает Основной договор. Появляется та же форма с Договорами. Водит шапку/строки. По некоему апруву данные из основного договора заполняются в шапку Текущего договора. В том числе копируются строки. Далее из Текущего договора так же по кнопке можно ввести Доп. соглашения. В доп соглашении надо ввести новые строки, а так же выбрать какие строки удалить из Текущего договора (Основной договор при этом никак не меняется!). Тут не надо заморачиваться с корректировкой строк. Просто удаляем и создаем новые. По апруву удаляем выбранные строки в Текущем договоре и создаем из доп. соглашения новые строки. Доп. соглашений можно создавать много. Ес-но у Основного договора и Доп. соглашений есть ссылка на Текущий договор. В операциях в системе (создание Заказов, выставление счета и прочее) используется только Текущий договор. Так же можно организовать иерархию на форме договоров. Достаточно фильтровать по Типу и Дате договора. Т.е. на форме будет идти Текущий договор, Основной договор, потом все Доп. соглашения. Так же есть такое понятие как Рамочный договор. Его тоже легко вписать в эту концепция.
Сам так не делал. Не судите строго. Чисто мысли как я бы сделал.

[DA_NEAL]

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

[DAX.Company]

То что я описал не требует серьезных доработок. Часов 10-15.

[Sancho]

допник часто изменяет ключевые параметры договора, следовательно - это НОВАЯ ВЕРСИЯ договора.
старый блокируем, новый создаем.
повсеместная практика.

[Captain]

Цитата:

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

допник часто изменяет ключевые параметры договора, следовательно - это НОВАЯ ВЕРСИЯ договора.
старый блокируем, новый создаем.
повсеместная практика.

Не очень красиво собирать данные по одному договору с версиями по 17 таблице)). А если версии 100 - в фильтр не влезет))

[DAX.Company]

Цитата:

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

допник часто изменяет ключевые параметры договора, следовательно - это НОВАЯ ВЕРСИЯ договора.
старый блокируем, новый создаем.
повсеместная практика.

Вы не правы. Допники составляются на этапы. Они только корректируют/уточняют основной договор. Но НЕ ОТМЕНЯЮТ его!!! Это не новая версия договора!

[Sancho]

Цитата:

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

Не очень красиво собирать данные по одному договору с версиями по 17 таблице)). А если версии 100 - в фильтр не влезет))

а нумерация на кой?
ДОГ_000123
ДОГ_000123_1
ДОГ_000123_2
ДОГ_000123_3
...
и фильтр
ДОГ_000123*

[Sancho]

Цитата:

Сообщение от DAX.Company

Вы не правы. Допники составляются на этапы. Они только корректируют/уточняют основной договор. Но НЕ ОТМЕНЯЮТ его!!! Это не новая версия договора!

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

[DAX.Company]

Цитата:

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

просто часть документов идут по исходнику, часть по допнику (счета и оплаты)

Счета как правило выставляют бухгалтера или помощники менеджеров. Им будет крайне сложно понять откуда брать текущие условия.

[DA_NEAL]

Могу описать более общий случай из практики по договорам биллинга.
1. С клиентом заключен общий договор в рамках которого проводятся взаиморасчеты (который и отображается в операция с контрагентом)
2. В договор по мере работы с клиентом добавляются приложения (доп. соглашения), У каждого своя дата начала действия и окончания. Может быть одно приложение, а может быть сколько угодно.
4. Клиент может попросить выставлять счета в целом по договору, по группе приложений, отдельно по приложениям.
5. В приложении описывается первоначальный пакет услуг (детализация) которая в дальнейшем может меняться без переподписывания договора, приложения (письмо клиента, личный кабинет, запрос на изменение услуг и т.д.)
6. Каждая услуга в приложении к договору может иметь свой период действия,стоимость, период действия скидки или спец предложения и т.д. Услуги так же могут добавляться.
7. Изменение пакета услуг, приостановка действия, активация спец. предложений и периодов действия скидок реализуются отдельным документом.

Итого: у Договора в общем случае нет постоянных финансовых параметров, все они являются функцией от времени.

[Captain]

Цитата:

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

а нумерация на кой?
ДОГ_000123
ДОГ_000123_1
ДОГ_000123_2
ДОГ_000123_3
...
и фильтр
ДОГ_000123*

Зацепил Sancho))
А номенклатуру по договору или версиям где хранить? Тем более версия вроде высокая 2017) Что думаешь? Пилить и пилить...?

[DAX.Company]

Цитата:

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

Итого: у Договора в общем случае нет постоянных финансовых параметров, все они являются функцией от времени.

Да. То что вы описали это классика Договорных отношений. Так везде. Во всех сферах. Иного просто не бывает. Так как за этим всем стоят юридические законы.

[DAX.Company]

Да, кстати. Еще и Приложения бывают. Их может быть несколько к Основному договору. А Доп. соглашения идти к Приложениям. Т.е. по сути в счете будет оплата согласно "Договору XXX, Приложению YYY, Доп.соглашению ZZZ"

[Sancho]

Цитата:

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

Зацепил Sancho))
А номенклатуру по договору или версиям где хранить? Тем более версия вроде высокая 2017) Что думаешь? Пилить и пилить...?

кхм... договор это как бы российская специфика (обратите внимание на номер таблицы).
во всем иностранном мире согласовывают не договор, а именно спецификацию, и для этого в Наве есть, кхм, blanked order.

[DAX.Company]

Цитата:

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

кхм... договор это как бы российская специфика (обратите внимание на номер таблицы).
во всем иностранном мире согласовывают не договор, а именно спецификацию, и для этого в Наве есть, кхм, blanked order.

Хм. Немного не в курсе. На западе нет договоров? Как они меняют "спецификации" по ходe исполнения?

[jopagames]

Коллеги, спасибо всем огромное!
Это тот редкий (я бы даже сказал уникальный случай), когда я согласен со всеми. И мне все идеи нравятся. Вот просто любую из них можно брать и допиливать до удобоваримости.

от Apanko - "период жизни строк" в договоре. У нас сейчас так именно и реализовано, но там всё пока упирается в юзабилити. Менеджер крыжит строки уже подписанного основного договора(меняет в нём дату окончания строки и добавляет новую) и потом оригинальную версию никак не распечатать. В спецификации менеджер-то заранее знает, когда ставить эту самую дату окончания строки, а в договоре - нет. Решение поменять услугу в середине месяца клиенту приходит внезапно

от Sancho идея - нет никаких "допников" - есть новый основной договор. Тоже в эту сторону можно двигать. Правда в договоре при печати 65536 страниц (и неизменны предмет договора, обязанности сторон, реквизиты и проч), а допник пока умещается на детской ладошке: "строку с услугой XXX на такой-то период следует читать как YYY". Но простота реализации подкупает. Sancta Simplicitas! Добавить только в шапке, что этот договор отменяет предыдущий и полностью заново распечатать. Пущай вчитывается.

от DAX вообще супер-идея - текущий договор, заполняющийся от основного+допника. Жаль только, что он лишь "вспомогательный" и на его основе можно только правильно считать сумму за период. А в бухгалтерии никакого такого бумажного + подписанного клиентом документа, нет.
(у нас бухгалтер сидит в 1С, а менеджер в NAV и друг друга они не встречали)
Бухгалтер менеджеру: - А вы по какому именно документу считали? Как мне общую сумму проверить?
Менеджер бухгалтеру: - А это нам программа считает по некоему промежуточному "текущему договору", которого у вас в бумажках нет.
Но в целом и в эту сторону решения проблемы тоже можно думать: как обойти подобные дурацкие вопросы административно.
(закрепить, к примеру, в учётной политике фирмы "кто же именно ошибается на копейку при извлечении НДС из суммы: Nav или 1C?")

от DA_NEAL предложение тоже понравилось: всё финансовое вынести в приложение как функцию. Для биллинга, думаю, самое то. А у нас, понимаешь, сумма (+сумма прописью) прописана прямо посреди текста основного договора, да ещё и НДС из неё извлечён в тексте
Но, разумеется, можно юристу сделать новую рыбу договора предложить - тоже тема. Типа, мы цены за наши услуги в договор не вписываем сразу - стесняемся. А сколько это стоит - пусть это лучше будет сюрприз для клиента в конце месяца Да здравствует биллинг!

Словом, друзья, мне всё понравилось. Чесслово!
Спасибо ещё раз всем откликнувшимся.

ЗЫ: Донесу весь зоопарк идей до клиента - пусть сам выбирает.