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 номером) Есть ли понятие текущего соглашения? Есть ли понятие действующего соглашения, или у нас все действуют, или строки из недействующего соглашения не должны участвовать в цепочке (тогда, видимо, не удастся активировать соглашение задним числом, цепочка может разрушиться) Если к соглашению нет измененных строк спецификации, в нем нет большого смысла (но изменения строк надо к чему-то приписывать). Надо было начать с моделирования данных в таблицах, до интерфейса? #agreement_item_uid# #svc# #code# #item_version_count# --->