spec/etc/spec.txt

2025-06-14 11:02:46
Центральный селект
select * from specification_item_version siv
join specification_item si on (siv.specification_item_uid=si.specification_item_uid)
join specification s on (si.specification_id=s.specification_id)
join agreement a on (s.contract_id=a.contract_id AND siv.agreement_version=a.agreement_version)
Теперь дифференциальный вариант. Для каждого варианта строки можно найти предыдущий (если он есть) и с ним сравнивать.
Нужно ли добавить типы экземпляров инсталл и пейг? С пейгом чтобы получить дифф, нужно количество - иначе мы можем дифф только на цену. Если мы хотим брать во внимание дату НОУ, то без количества разницу в стоимости мы не получим.
Как вообще учитывать дату в диффе? Или никак, просто передавать.

16:12 12.06.2025
Предлагается использовать конечную дату только для завершения действия всей строки спеки. Тогда ее просто убрать из версии? Некорректно, она же возникает в какой-то версии.
Если захочется делать одним соглашением 2 изменения строки, можно соглашению сделать суррогатный ключ, а номер соглашения для версии строки убрать из первичного ключа
2025-06-10
Отчет-дифф
Сделать автосоздание нового соглашения (например, если самое новое не действует - аттачить изменения к нему, если действует - создать новое не действующее)
Сделать прозрачно-версионное редактирование спецификации
Форма-отчет версии спецификации доделать

2025-06-02
можно отметить, что тут смешаны версионность допника и темпоральность строки
Можно сделать таблицу, собирающую версии строк, чтобы не искать каждый раз (а может, нам не нужен снапшот на произвольную дату? или версию допника - вот, я уже запутался)
в сервисе нет единиц измерения у меня
31.05.2025
Спецификация относится к договору. В принципе, в договоре может быть несколько спецификаций, но поддерживать это не кажется безусловно нужным. Каждая новая действующая версия спецификации относится к доп соглашению (возможно для договора ввести нулевой допник). Возможно, для редактирования захочется ввести редакторскую версионность, эту мы не рассматриваем.

Для обсуждения версионности важно, что мы имеем дело с услугами, которые длятся (в отличие от них, для продажи товаров, видимо, имеет смысл только тривиальная редакторская версионность, не имеющая отношения к учету). 
Спецификация состоит из номенклатурных позиций с ценой, количеством, датой начала и окончания действия, уникальным ключом строки. Ключ строки может соотноситься 1 к 1 с объектом биллинга для индивидуальных объектов (облачный пул) или 1 ко многим для счетных объектов (ip адрес). Включение разнородных объектов, отличающихся модификаторами (соответственно, кодами) или значениями параметров, не поддерживается. 
Версионность спецификации поддерживает: добавление, удаление, изменение строки (почти тоже самое, что услуги) . При добавлении или удалении услуги обязательный атрибут - дата начала или завершения оказания услуги (обе даты имеют смысл "включительно": первый и последний день оказания услуги). Дата начала/завершения может быть какой угодно (хоть через 5 лет, мы не реализуем проверок), но с одним ограничением: даты в цепочке версий строки должны быть последовательными (монотонными), дата завершения не меньше даты начала, дата начала следующей версии не меньше даты завершения предыдущей версии.  

Добавленная услуга получает уникальный ключ строки. Ключ удаленной услуги (строки) дискардится. Видимо, есть разные похожие сценарии: удалить услугу (вместе со строкой) с некоторой даты, обнулить количество с некоторой даты, завершить обслуживание с некоторой даты. Разница будет видна, когда дойдем до модификации. 

Разница между строкой и инстансом услуги, возможно, нуждается в пояснении. Когда мы редактируем строку, мы подразумеваем, что за ней могут стоять индивидуальные инстансы. Например, при расширении вычислительного пула мы говорим про конкретный пул (в том числе имеющий уникальный идентификатор) , а не просто докидываем куда-то гигабайт или рублей. В случае со счетными объектами обычно подразумевается, что при увеличении количества объекты добавляются к множеству, при уменьшении - убираются из него (строго говоря, это не так - увеличение просто значит, что добавили больше, чем убрали, причем поменяться могли все элементы). Счетные объекты (те же стойки) обычно имеют индивидуальность: у каждого стойко-места свой номер, но это обычно отражается не в спецификации, а в ТУ (возможно, это связано с тем, что индивидуальность элемента не влияет на взаиморасчеты, только количество). Может быть, это не важно. 

При изменении строки не может меняться номенклатура. Может меняться количество, параметры (компоненты) композитной услуги, цена (или частные цены компонентов). Чтобы не путаться: дата начала/окончания меняться не может, это не обычный прикладной атрибут, а "драйвер" версионности. Иначе говоря, при изменении строки меняются только числовые значения (можно, наверно, менять примечания и пользовательские названия – они на учет не влияют)
Модификация строки нетривиальна по сравнению с созданием и удалением. Когда мы меняем строку, мы создаем новую версию, завершая действие прежней версии некоторым числом и создавая новую версию (непременно) более поздним числом (чаще всего следующим днем, пропуск мы, скорее всего, не захотим поддерживать: это может несколько усложнить формирование счетов... но паузу можно оформить периодом с нулевым количеством). 
Таким образом, спецификация содержит версии строк, которые на любую дату составляют актуальную картину, причем на любую дату актуально не более одной версии каждой строки. За расчетный период могут быть актуальными несколько вариантов строки, логических препятствий для этого нет (может быть, этого придется избегать, чтобы исключить противоречия при формировании счетов). Строки не удаляются, а закрываются некоторой датой. 

Редактирование (включая возможность двигать даты начала/окончания) в некоторый момент замораживается, и строку нельзя уже поменять задним числом (условия уточнить). Может быть, необходим будет механизм компенсирующих проводок для корректировки задним числом. 

Таким образом, мы семантически объединяем даты начала/окончания оказания услуги и даты актуальности версий строк (чтобы не усложнять, и они кажутся очень близкими по смыслу). 
Возобновления оказания услуги, наверное, предусматривать не надо: достаточно создать новую строку спецификации с теми же реквизитами и новым уникальным ключом строки - тогда можно рассчитывать на непрерывность цепочек версий (это ограничение  выглядит успокаивающим, но непонятно, так ли оно полезно или необходимо). ВременнАя монотонность цепочек версий, напротив, кажется совершенно обязательной. 
Номера версий строк монотонны (реализация может позволить наличие пропусков – оно логически ничему не противоречит)

Теперь что такое версия спецификации и откуда берется номер версии спецификации. Предлагается считать версией спецификации снапшот версий строк, последовательность таких снапшотов соответствует истории спецификации.  
Каждая версия спецификации вносит изменения: строка добавилась, строка удалилась, строка изменилась. Строки, которые не менялись, просто остаются в кумулятивном представлении, и отсутствуют в дифференциальном представлении. Измененная строка в кумулятивном представлении выглядит как «стало вот так с такой даты», а в дифференциальном «изменилось на столько с такой даты».
Если нам нужно 2 раза поменять некоторую строку (скажем, с 15 и 20 числа месяца) – нам придется выпустить 2 версии спецификации: формат не предусматривает замножение строк. Вероятно, 2 версии спецификации, в свою очередь, потребуют 2 дополнительных соглашений (кажется, в структуре доп соглашения, даже если предусмотрено несколько спецификаций, то это не версии одной спецификации). Впрочем, не припомню практической необходимости в таких  изысках.

Может быть, тут не хватает вопросов, на которые должна отвечать модель, но мне она пока кажется информационно полной и не сильно противоречивой.