AXForum  
Вернуться   AXForum > Microsoft Dynamics NAV > NAV: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 12.09.2017, 21:36   #1  
jopagames is offline
jopagames
Участник
 
45 / 24 (1) +++
Регистрация: 22.11.2011
Доп.Соглашение
Коллеги, общий привет.

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

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

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

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

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

Словом, кто понял про что я спрашивал - поделитесь идеей, пожалуйста ))
Старый 13.09.2017, 08:35   #2  
apanko is offline
apanko
MCTS
MCBMSS
Лучший по профессии 2009
 
1,164 / 139 (7) +++++
Регистрация: 24.02.2005
Как фантазия на тему - а не взглянуть ли на Производственные Спецификации и версии, для вдохновения. В спецификациях есть возможность указывать дату начала/окончания действия строки. Также дату можно указывать в версии. Ну и есть логика которая выбирает правильную спецификацию/версию/строки для документа с датой.
Старый 13.09.2017, 09:23   #3  
Captain is offline
Captain
Участник
Лучший по профессии 2017
 
300 / 81 (3) ++++
Регистрация: 28.02.2003
Очень давно делали что-то похожее. Договор он оставался единым, а использовали квоты продажи, которые хранились в архиве (стандарт NAV). К ним привязали отдельную нумерацию(номер допника),даты, номенклатуру и + отдельная обработка которая работала по дате и копировала строки из архива в заказ (счет) продажи.
__________________
---------------------------------------------------------------------------------------------
"Собрать стадо из баранов легко, трудно собрать стадо из кошек" Профессор Сергей Капица
Старый 13.09.2017, 09:54   #4  
DAX.Company is offline
DAX.Company
Участник
 
296 / 97 (4) ++++
Регистрация: 24.11.2016
С Навом не работал. Но во всех системах одно и тоже. Я бы делал так. Во-первых, никакой программисткой мешанины. Все должно быть прозрачно для пользователей. Т.е. должна быть возможность легко увидеть/распечатать Текущий договор (обязательства), основной договор, все доп соглашения.
Вводим enum (перечисление): Текущий договор, Основной договор, Доп. соглашение. Все основано на сущности договор (Customer Agreement и Customer Agreement Lines). Сначала пользователь создает Текущий договор (это просто болванка для будущего заполнения). Далее по кнопке нажимает Основной договор. Появляется та же форма с Договорами. Водит шапку/строки. По некоему апруву данные из основного договора заполняются в шапку Текущего договора. В том числе копируются строки. Далее из Текущего договора так же по кнопке можно ввести Доп. соглашения. В доп соглашении надо ввести новые строки, а так же выбрать какие строки удалить из Текущего договора (Основной договор при этом никак не меняется!). Тут не надо заморачиваться с корректировкой строк. Просто удаляем и создаем новые. По апруву удаляем выбранные строки в Текущем договоре и создаем из доп. соглашения новые строки. Доп. соглашений можно создавать много. Ес-но у Основного договора и Доп. соглашений есть ссылка на Текущий договор. В операциях в системе (создание Заказов, выставление счета и прочее) используется только Текущий договор. Так же можно организовать иерархию на форме договоров. Достаточно фильтровать по Типу и Дате договора. Т.е. на форме будет идти Текущий договор, Основной договор, потом все Доп. соглашения. Так же есть такое понятие как Рамочный договор. Его тоже легко вписать в эту концепция.
Сам так не делал. Не судите строго. Чисто мысли как я бы сделал.
Старый 13.09.2017, 10:05   #5  
DA_NEAL is offline
DA_NEAL
Участник
Аватар для DA_NEAL
Лучший по профессии 2017
Лучший по профессии 2009
 
788 / 54 (3) ++++
Регистрация: 05.08.2002
Адрес: Королев
Без серьезных доработок системы красивое и функциональное решение не сделать. Твой вопрос в том как выкрутится на стандарте или какую архитектуру данных использовать для реализации задачи?
__________________
Want to believe...
Старый 13.09.2017, 10:09   #6  
DAX.Company is offline
DAX.Company
Участник
 
296 / 97 (4) ++++
Регистрация: 24.11.2016
То что я описал не требует серьезных доработок. Часов 10-15.
Старый 13.09.2017, 10:19   #7  
Sancho is offline
Sancho
Administrator
Аватар для Sancho
Лучший по профессии 2017
Лучший по профессии 2009
 
1,294 / 221 (10) ++++++
Регистрация: 11.01.2006
допник часто изменяет ключевые параметры договора, следовательно - это НОВАЯ ВЕРСИЯ договора.
старый блокируем, новый создаем.
повсеместная практика.
Старый 13.09.2017, 10:25   #8  
Captain is offline
Captain
Участник
Лучший по профессии 2017
 
300 / 81 (3) ++++
Регистрация: 28.02.2003
Цитата:
Сообщение от Sancho Посмотреть сообщение
допник часто изменяет ключевые параметры договора, следовательно - это НОВАЯ ВЕРСИЯ договора.
старый блокируем, новый создаем.
повсеместная практика.
Не очень красиво собирать данные по одному договору с версиями по 17 таблице)). А если версии 100 - в фильтр не влезет))
__________________
---------------------------------------------------------------------------------------------
"Собрать стадо из баранов легко, трудно собрать стадо из кошек" Профессор Сергей Капица
Старый 13.09.2017, 11:33   #9  
DAX.Company is offline
DAX.Company
Участник
 
296 / 97 (4) ++++
Регистрация: 24.11.2016
Цитата:
Сообщение от Sancho Посмотреть сообщение
допник часто изменяет ключевые параметры договора, следовательно - это НОВАЯ ВЕРСИЯ договора.
старый блокируем, новый создаем.
повсеместная практика.
Вы не правы. Допники составляются на этапы. Они только корректируют/уточняют основной договор. Но НЕ ОТМЕНЯЮТ его!!! Это не новая версия договора!
Старый 13.09.2017, 12:58   #10  
Sancho is offline
Sancho
Administrator
Аватар для Sancho
Лучший по профессии 2017
Лучший по профессии 2009
 
1,294 / 221 (10) ++++++
Регистрация: 11.01.2006
Цитата:
Сообщение от Captain Посмотреть сообщение
Не очень красиво собирать данные по одному договору с версиями по 17 таблице)). А если версии 100 - в фильтр не влезет))
а нумерация на кой?
ДОГ_000123
ДОГ_000123_1
ДОГ_000123_2
ДОГ_000123_3
...
и фильтр
ДОГ_000123*
Старый 13.09.2017, 13:00   #11  
Sancho is offline
Sancho
Administrator
Аватар для Sancho
Лучший по профессии 2017
Лучший по профессии 2009
 
1,294 / 221 (10) ++++++
Регистрация: 11.01.2006
Цитата:
Сообщение от DAX.Company Посмотреть сообщение
Вы не правы. Допники составляются на этапы. Они только корректируют/уточняют основной договор. Но НЕ ОТМЕНЯЮТ его!!! Это не новая версия договора!
может и не прав. случаи бывают разные.
но можно и не блокировать исходный договор.
просто часть документов идут по исходнику, часть по допнику (счета и оплаты)
Старый 13.09.2017, 13:04   #12  
DAX.Company is offline
DAX.Company
Участник
 
296 / 97 (4) ++++
Регистрация: 24.11.2016
Цитата:
Сообщение от Sancho Посмотреть сообщение
просто часть документов идут по исходнику, часть по допнику (счета и оплаты)
Счета как правило выставляют бухгалтера или помощники менеджеров. Им будет крайне сложно понять откуда брать текущие условия.
Старый 13.09.2017, 13:56   #13  
DA_NEAL is offline
DA_NEAL
Участник
Аватар для DA_NEAL
Лучший по профессии 2017
Лучший по профессии 2009
 
788 / 54 (3) ++++
Регистрация: 05.08.2002
Адрес: Королев
Могу описать более общий случай из практики по договорам биллинга.
1. С клиентом заключен общий договор в рамках которого проводятся взаиморасчеты (который и отображается в операция с контрагентом)
2. В договор по мере работы с клиентом добавляются приложения (доп. соглашения), У каждого своя дата начала действия и окончания. Может быть одно приложение, а может быть сколько угодно.
4. Клиент может попросить выставлять счета в целом по договору, по группе приложений, отдельно по приложениям.
5. В приложении описывается первоначальный пакет услуг (детализация) которая в дальнейшем может меняться без переподписывания договора, приложения (письмо клиента, личный кабинет, запрос на изменение услуг и т.д.)
6. Каждая услуга в приложении к договору может иметь свой период действия,стоимость, период действия скидки или спец предложения и т.д. Услуги так же могут добавляться.
7. Изменение пакета услуг, приостановка действия, активация спец. предложений и периодов действия скидок реализуются отдельным документом.

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

Последний раз редактировалось DA_NEAL; 13.09.2017 в 14:01.
Старый 13.09.2017, 14:02   #14  
Captain is offline
Captain
Участник
Лучший по профессии 2017
 
300 / 81 (3) ++++
Регистрация: 28.02.2003
Цитата:
Сообщение от Sancho Посмотреть сообщение
а нумерация на кой?
ДОГ_000123
ДОГ_000123_1
ДОГ_000123_2
ДОГ_000123_3
...
и фильтр
ДОГ_000123*
Зацепил Sancho))
А номенклатуру по договору или версиям где хранить? Тем более версия вроде высокая 2017) Что думаешь? Пилить и пилить...?
__________________
---------------------------------------------------------------------------------------------
"Собрать стадо из баранов легко, трудно собрать стадо из кошек" Профессор Сергей Капица
Старый 13.09.2017, 14:04   #15  
DAX.Company is offline
DAX.Company
Участник
 
296 / 97 (4) ++++
Регистрация: 24.11.2016
Цитата:
Сообщение от DA_NEAL Посмотреть сообщение
Итого: у Договора в общем случае нет постоянных финансовых параметров, все они являются функцией от времени.
Да. То что вы описали это классика Договорных отношений. Так везде. Во всех сферах. Иного просто не бывает. Так как за этим всем стоят юридические законы.
Старый 13.09.2017, 14:09   #16  
DAX.Company is offline
DAX.Company
Участник
 
296 / 97 (4) ++++
Регистрация: 24.11.2016
Да, кстати. Еще и Приложения бывают. Их может быть несколько к Основному договору. А Доп. соглашения идти к Приложениям. Т.е. по сути в счете будет оплата согласно "Договору XXX, Приложению YYY, Доп.соглашению ZZZ"
Старый 13.09.2017, 21:48   #17  
Sancho is offline
Sancho
Administrator
Аватар для Sancho
Лучший по профессии 2017
Лучший по профессии 2009
 
1,294 / 221 (10) ++++++
Регистрация: 11.01.2006
Цитата:
Сообщение от Captain Посмотреть сообщение
Зацепил Sancho))
А номенклатуру по договору или версиям где хранить? Тем более версия вроде высокая 2017) Что думаешь? Пилить и пилить...?
кхм... договор это как бы российская специфика (обратите внимание на номер таблицы).
во всем иностранном мире согласовывают не договор, а именно спецификацию, и для этого в Наве есть, кхм, blanked order.
Старый 13.09.2017, 22:16   #18  
DAX.Company is offline
DAX.Company
Участник
 
296 / 97 (4) ++++
Регистрация: 24.11.2016
Цитата:
Сообщение от Sancho Посмотреть сообщение
кхм... договор это как бы российская специфика (обратите внимание на номер таблицы).
во всем иностранном мире согласовывают не договор, а именно спецификацию, и для этого в Наве есть, кхм, blanked order.
Хм. Немного не в курсе. На западе нет договоров? Как они меняют "спецификации" по ходe исполнения?
Старый 14.09.2017, 00:34   #19  
jopagames is offline
jopagames
Участник
 
45 / 24 (1) +++
Регистрация: 22.11.2011
Коллеги, спасибо всем огромное!
Это тот редкий (я бы даже сказал уникальный случай), когда я согласен со всеми. И мне все идеи нравятся. Вот просто любую из них можно брать и допиливать до удобоваримости.

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

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

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

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

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

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

Последний раз редактировалось jopagames; 14.09.2017 в 01:11.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Клиент Соглашение rem2 NAV: Функционал 8 16.09.2008 12:37
импортирование доп. форм tofsla NAV: Программирование 2 11.06.2004 11:14
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 18:06.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.