diff --git a/agreement.cfm b/agreement.cfm
index aac3ae6..8ce9ec8 100644
--- a/agreement.cfm
+++ b/agreement.cfm
@@ -159,7 +159,7 @@
 	</div>		
 </div>
 Соглашение просто объединяет правки строк спецификации в пакет и оформляет их документом (в случае с допником). То есть версии строк существуют не сами по себе, а связаны с конкретным соглашением. Между прочим, это означает, что в рамках одного доп. соглашения мы не можем сделать 2 изменения строки, например 2 разные цены с разных дат - нужно оформлять отдельными допниками.
-Можно назвать нулевое соглашение базовым, а остальные дополнительными. (наверное, можно было бы синтезировать базовое соглашение с NULL номером)
+Можно назвать нулевое соглашение базовым, а остальные дополнительными. (наверное, можно было бы синтезировать базовое соглашение с NULL номером, но NULL проблематично включить в первичный ключ, а любое специальное значение будет нарушать внешний ключ)
 Есть ли понятие текущего соглашения?
 Есть ли понятие действующего соглашения, или у нас все действуют, или строки из недействующего соглашения не должны участвовать в цепочке (тогда, видимо, не удастся активировать соглашение задним числом, цепочка может разрушиться)
 Если к соглашению нет измененных строк спецификации, в нем нет большого смысла (но изменения строк надо к чему-то приписывать).
@@ -172,8 +172,8 @@
 <cfif d.agreement_version GE 0>
 	<cfquery name="qItem" datasource="#request.DS#">
 		select 
-		 i.specification_item_uid
-		 i.agreement_version /*лучше читается, когда все берется из резалтсета*/
+		 iv.specification_item_uid
+		,iv.agreement_version /*лучше читается, когда все одинаково берется из резалтсета*/
 		,i.svc_id	
 		,svc.svc	
 		,svc.code	
diff --git a/abstract_service_del.cfm b/agreement_del.cfm
similarity index 58%
rename from abstract_service_del.cfm
rename to agreement_del.cfm
index d5299cc..c3e45aa 100644
--- a/abstract_service_del.cfm
+++ b/agreement_del.cfm
@@ -4,35 +4,36 @@
 	<cfimport prefix="layout" taglib="layout"/>
 </cfsilent><m:silent silent="No">
 
-<m:prepare_detail entity="abstract_service" pageInfoOut="pageInfo"/>
-<cfparam name="abstract_service_id" type="integer"/>
+<m:prepare_detail entity="agreement" pageInfoOut="pageInfo"/>
+<cfparam name="agreement_id" type="integer"/>
 
 <d:del
 	entity="#pageInfo.entity#" 
-	confirmMessage="Удалить абстрактную услугу?"
-	denyMessage="Удаление данной абстрактной услуги невозможно (есть конкретные услуги)."
+	confirmMessage="Удалить соглашение?"
+	denyMessage="Удаление данного соглашения невозможно (есть версии строк спецификации)."
 	accessObj="#pageInfo.entity#"
 	status="status"
 	output="markup">
 	
-	<d:dependency entity="service" title="Конкретные услуги">
-		<d:dependency_field key>s.service_id</d:dependency_field>
+	<d:dependency entity="specification_item_version" title="Версии строк спецификации">
+		<d:dependency_field key>siv.specification_item_uid</d:dependency_field>
+		<d:dependency_field key>siv.agreement_version</d:dependency_field>
 		<d:dependency_field title="Характеристика">m.modifier</d:dependency_field>
 		<d:dependency_from> 
-			service s
+			specification_item_version siv
 			left outer join modifier m on (s.modifier_id=m.modifier_id)
 		</d:dependency_from>
-		<d:dependency_condition cfsqltype="cf_sql_integer" value='#abstract_service_id#'>s.abstract_service_id</d:dependency_condition>
+		<d:dependency_condition cfsqltype="cf_sql_integer" value='#agreement_id#'>s.agreement_id</d:dependency_condition>
 		<d:dependency_order_by>2 desc</d:dependency_order_by>
 	</d:dependency>
 	
-	<d:del_condition field="abstract_service_id" value="#abstract_service_id#" cfsqltype="cf_sql_integer"/>	
+	<d:del_condition field="agreement_id" value="#agreement_id#" cfsqltype="cf_sql_integer"/>	
 </d:del>
 
 <m:dispatch_detail
 	usePRG="Yes" 	
 	pageInfo=#pageInfo#	
-	id="#abstract_service_id#"
+	id="#agreement_id#"
 	status=#status#
 	trackOut="tr"
 	idAttributesOut="id"
@@ -40,9 +41,9 @@
 
 <!--- decoration --->
 <cfquery name="qDecoration" datasource="#request.DS#">
-	select a.code, a.abstract_service
-	FROM abstract_service a
-	where a.abstract_service_id=<cfqueryparam cfsqltype="cf_sql_integer" value="#abstract_service_id#" null=#!isValid("integer", abstract_service_id)#/>
+	select a.code, a.agreement
+	FROM agreement a
+	where a.agreement_id=<cfqueryparam cfsqltype="cf_sql_integer" value="#agreement_id#" null=#!isValid("integer", agreement_id)#/>
 </cfquery>
 
 
@@ -53,9 +54,9 @@
 	<layout:attribute name="title">
 		<cfoutput>
 			Удаление абстрактной услуги (номенклатурной позиции, строки каталога услуг)
-			#qDecoration.abstract_service# 
-			<cfif abstract_service_id GT 0>
-				[#abstract_service_id#] 
+			#qDecoration.agreement# 
+			<cfif agreement_id GT 0>
+				[#agreement_id#] 
 			</cfif>
 		</cfoutput>
 	</layout:attribute>
diff --git a/contract.cfm b/contract.cfm
index a11866e..6d279f5 100644
--- a/contract.cfm
+++ b/contract.cfm
@@ -216,6 +216,7 @@
 				<button type="button" class="maincontrol" onclick="document.location.href='#addUrl#'">
 					<a href="#addUrl#">Создать</a>
 				</button>
+				Создание базового соглашения надо автоматизировать, но пока вручную.
 			</cfoutput>
 		</cfif>		
 			
@@ -245,7 +246,7 @@
 				</tr>
 			</cfoutput>
 		</table>
-		любопытное последствие использования составного ключа: отпадает желание делать для сущности самостоятельный реестр (может быть, только если есть явная сущность-владелец, как договор для соглашения)
+		любопытное последствие использования составного ключа: отпадает желание делать для сущности самостоятельный реестр (может быть, только если есть явная сущность-владелец, как договор для соглашения). Это аналогично отразится на структуре ReST API URL, если вдруг
 	</cfif> 
 	
 <layout:page section="extension" closeForm="Yes"/>	<!--- *** правильно так? --->