select coalesce(max(agreement_version)+1,0) as next_version from agreement where contract_id= pageInfo=#pageInfo# id="" queryString="contract_id=#d.contract_id#&agreement_version=#d.agreement_version#" status=#pageInfo.status# trackOut="tr" idAttributesOut="id" /> select a.login as creator, a.shortname as creator_shortname, m.login as updater, m.shortname as updater_shortname from agreement e left outer join usr a on (e.creator_id=a.usr_id) left outer join usr m on (e.updater_id=m.usr_id) where e.contract_id= AND e.agreement_version= select d.contract_id, d.contract, d.dt_contract, c.contragent_id, c.contragent from contract d left outer join contragent c on (d.contragent_id=c.contragent_id) where d.contract_id= Соглашение #d.agreement# [#d.agreement_version#]

#status.errorMessage#

Договор

#qContract.contract# #dateFormat(qContract.dt_contract,'DD.MM.YYYY')# а как у нас поведет себя трек для составных ключей?

Номер версии

#d.agreement_version# (некорректно, в одном месте версией называется номер, а в другом сущность, и это отразилось в именовании таблиц и полей)

Соглашение (номер для печати)

Дата соглашения

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

Действует

checked/> если соглашение действует, это означает ровно то, что его правки учитываются при формировании спецификации на любую дату

Описание

Создано

#dateFormat(d.dt_created,'DD.MM.YYYY')# #timeFormat(d.dt_created,'HH:MM')# #qDecoration.creator# (#qDecoration.creator_shortname#) Изменено #dateFormat(d.dt_updated,'DD.MM.YYYY')# #timeFormat(d.dt_updated,'HH:MM')# #qDecoration.updater# (#qDecoration.updater_shortname#)

Соглашение просто объединяет правки строк спецификации в пакет и оформляет их документом (в случае с допником). То есть версии строк существуют не сами по себе, а связаны с конкретным соглашением. Между прочим, это означает, что в рамках одного доп. соглашения мы не можем сделать 2 изменения строки, например 2 разные цены с разных дат - нужно оформлять отдельными допниками. Можно назвать нулевое соглашение базовым, а остальные дополнительными. (наверное, можно было бы синтезировать базовое соглашение с NULL номером, но NULL проблематично включить в первичный ключ, а любое специальное значение будет нарушать внешний ключ) Есть ли понятие текущего соглашения? Есть ли понятие действующего соглашения, или у нас все действуют, или строки из недействующего соглашения не должны участвовать в цепочке (тогда, видимо, не удастся активировать соглашение задним числом, цепочка может разрушиться) Если к соглашению нет измененных строк спецификации, в нем нет большого смысла (но изменения строк надо к чему-то приписывать). Надо было начать с моделирования данных в таблицах, до интерфейса? select iv.specification_item_uid ,iv.agreement_version /*лучше читается, когда все одинаково берется из резалтсета*/ ,i.svc_id ,svc.svc ,svc.code ,iv.specification_item_version /*it is printable name not number*/ ,iv.quantity ,iv.price ,iv.dt_from ,iv.dt_to ,i.specification_id ,s.specification ,s.contract_id ,d.contract ,d.dt_contract ,d.contragent_id ,k.contragent from specification_item_version iv join specification_item i on (iv.specification_item_uid=i.specification_item_uid) join specification s on (i.specification_id=s.specification_id) join contract d on (s.contract_id=d.contract_id) join contragent k on (d.contragent_id=k.contragent_id) left outer join svc on (i.svc_id=svc.svc_id) where s.contract_id= AND iv.agreement_version= order by 1

Строки спецификаций (#qItem.recordCount#)

	Стабильный ключ строки	Услуга	Код услуги	Имя для печати	Дата с	Дата по	Кол-во	Цена	Спецификация	Договор	Контрагент
"edit""view">	#specification_item_uid#	#svc#	#code#	#specification_item_version#	#dateFormat(dt_from,'DD.MM.YYYY')#	#dateFormat(dt_to,'DD.MM.YYYY')#	#quantity#	#price#	#specification#	#contract# #dateFormat(dt_contract,'DD.MM.YYYY')#	#contragent#