intermediate draft 3

This commit is contained in:
msyu 2025-06-06 18:11:05 +03:00
parent 535ac713c6
commit c1e32d840b
3 changed files with 22 additions and 20 deletions

View File

@ -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

View File

@ -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>

View File

@ -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"/> <!--- *** правильно так? --->