intermediate draft 4

agreement.cfm

@@ -160,7 +160,13 @@
 </div>
 Соглашение просто объединяет правки строк спецификации в пакет и оформляет их документом (в случае с допником). То есть версии строк существуют не сами по себе, а связаны с конкретным соглашением. Между прочим, это означает, что в рамках одного доп. соглашения мы не можем сделать 2 изменения строки, например 2 разные цены с разных дат - нужно оформлять отдельными допниками.
 Можно назвать нулевое соглашение базовым, а остальные дополнительными. (наверное, можно было бы синтезировать базовое соглашение с NULL номером, но NULL проблематично включить в первичный ключ, а любое специальное значение будет нарушать внешний ключ)
-Есть ли понятие текущего соглашения?
+
+Дата соглашения не имеет никакого отношения к датам актуальности строк (это чисто формальное поле)
+Предполагается, что даты актуальности строк согласованы с номерами версий (можно обнаруживать и репортить ошибки)
+
+Поскольку соглашение не может дважды изменить строку спецификации, можно говорить о версии спецификации в соответствии с соглашением 
+
+Есть ли у нас понятие текущего соглашения?
 Есть ли понятие действующего соглашения, или у нас все действуют, или строки из недействующего соглашения не должны участвовать в цепочке (тогда, видимо, не удастся активировать соглашение задним числом, цепочка может разрушиться)
 Если к соглашению нет измененных строк спецификации, в нем нет большого смысла (но изменения строк надо к чему-то приписывать).
 Надо было начать с моделирования данных в таблицах, до интерфейса?
@@ -197,7 +203,7 @@
 		left outer join svc on (i.svc_id=svc.svc_id) 
 		where s.contract_id=<cfqueryparam cfsqltype="cf_sql_integer" value="#d.contract_id#"/>
 		AND iv.agreement_version=<cfqueryparam cfsqltype="cf_sql_integer" value="#d.agreement_version#"/>
-		order by 1
+		order by i.specification_id
 	</cfquery>
 	
 	<cfoutput>