chore(release): 0.2.0 #71
@@ -7,7 +7,9 @@
|
||||
|
||||
### Requirement: Realized income analytics is account-scoped and period-bound
|
||||
|
||||
Система MUST предоставлять аутентифицированному User аналитику фактически полученного дохода только для одного открытого поддерживаемого Brokerage Account, доступного через текущий T-Bank connection User. Применённый период MUST задаваться включительными календарными датами `from` и `to` в Europe/Moscow, MUST NOT начинаться после своего окончания, MUST NOT содержать будущую дату. Система MUST NOT ограничивать максимальную длительность периода. При отсутствии применённого периода система MUST использовать интервал от первого дня текущего месяца до сегодняшнего дня включительно.
|
||||
Система MUST предоставлять аутентифицированному User аналитику фактически полученного дохода выбранного открытого поддерживаемого Brokerage Account либо существующего режима «Все счета» (`all`) из счетов, доступных через текущий T-Bank connection User. В режиме `all` система MUST проверять доступ каждого входящего счёта и подтверждать полноту каждого исходного периода по всем входящим счетам; отсутствующий вклад счёта MUST NOT заменяться нулём. Применённый период MUST задаваться включительными календарными датами `from` и `to` в Europe/Moscow, MUST NOT начинаться после своего окончания, MUST NOT содержать будущую дату. Система MUST NOT ограничивать максимальную длительность периода. При отсутствии применённого периода система MUST использовать интервал от первого дня текущего месяца до сегодняшнего дня включительно.
|
||||
|
||||
Чтение MUST использовать сохранённые операции текущего подключения и локальное подтверждение доступа без синхронного запроса T-Bank. Ответ MUST иметь envelope `{ data, meta }` по `tbank-data-sync`. Полнота MUST определяться для выбранного периода и каждого необходимого периода сравнения отдельно. Запрос MUST приоритетно загружать их пропуски до фоновой догрузки остальной истории; известные правила календарных дат MUST сохраняться.
|
||||
|
||||
#### Scenario: Аналитика за период по умолчанию
|
||||
|
||||
@@ -29,6 +31,14 @@
|
||||
- **WHEN** User запрашивает аналитику Brokerage Account, который не является открытым поддерживаемым счётом, доступным через его текущий T-Bank connection
|
||||
- **THEN** система возвращает существующий ответ о недоступности счёта и не раскрывает его доход или операции
|
||||
|
||||
#### Scenario: Общий доход требует полноты всех счетов
|
||||
- **WHEN** User запрашивает режим `all` и выбранный период одного доступного счёта ещё не загружен полностью
|
||||
- **THEN** система не возвращает окончательные общие суммы, сохраняет раздельное состояние покрытия счетов и запрашивает недостающую разрешённую историю
|
||||
|
||||
#### Scenario: Открыт ещё не загруженный период
|
||||
- **WHEN** запрошенный допустимый период ещё не имеет сохранённых операций или подтверждённого полного пустого покрытия
|
||||
- **THEN** система отвечает `200` со статусом первичной загрузки или частичного покрытия, запрашивает нужные интервалы и не выдаёт нулевой окончательный доход
|
||||
|
||||
### Requirement: Realized income uses exact executed coupon and dividend payments
|
||||
|
||||
Система MUST рассчитывать фактически полученный доход только по исполненным Ledger Entries с точным upstream-типом coupon или dividend. Для каждой исходной валюты система MUST отдельно возвращать общий итог, купонный subtotal и дивидендный subtotal как точные суммы исходных broker-reported payments. Знак каждой выплаты MUST сохраняться, поэтому отрицательная корректировка MUST уменьшать соответствующий итог и оставаться доступной в составе результата. Dividend transfer, погашение principal, offer, trade, transfer, fee, tax, overnight income, иной тип операции, нереализованный результат и изменение рыночной цены MUST NOT входить в фактически полученный доход. Система MUST NOT выполнять валютную конвертацию или формировать общий итог по разным валютам.
|
||||
@@ -155,11 +165,11 @@ MUST NOT заменять успешно отображённый Portfolio ил
|
||||
|
||||
### Requirement: Income payments remain traceable to exact Ledger Entries
|
||||
|
||||
В разделе «Выплаты» страница MUST показывать единый список карточек точных исполненных Ledger Entries применённого периода в исходном серверном порядке entries. Каждая выплата MUST иметь собственную сразу видимую карточку с описанием, датой исполнения, доступной identity Instrument и signed Money в исходной валюте. Купоны и дивиденды MUST использовать то же представление выплаты, что и на экранах журнала, прогноза и графиков инструментов, при этом карточка MUST обозначать эту сумму именно как фактически исполненную, а не прогнозную. Страница MUST NOT добавлять внешние группировочные карточки или заголовки по Instrument либо валюте, subtotals инструмента или количество выплат инструмента. Список MUST сохранять отрицательные корректировки и повторяющиеся operation IDs как отдельные записи и MUST NOT включать записи вне аналитического итога. Backend MUST обеспечивать согласованность entries, instrumentKey, валюты и receipt count при формировании ответа из одного набора записей. Frontend SHALL доверять типизированному contract без второго runtime consistency validator и MUST NOT пересчитывать денежные итоги.
|
||||
В разделе «Выплаты» страница MUST показывать единый список карточек точных исполненных Ledger Entries применённого периода в исходном серверном порядке entries. Каждая выплата MUST иметь собственную сразу видимую карточку с описанием, датой исполнения, доступной identity Instrument и signed Money в исходной валюте. Купоны и дивиденды MUST использовать то же представление выплаты, что и на экранах журнала, прогноза и графиков инструментов, при этом карточка MUST обозначать эту сумму именно как фактически исполненную, а не прогнозную. В режиме одного Brokerage Account страница MUST NOT добавлять внешние группировочные карточки или заголовки по Instrument либо валюте, subtotals инструмента или количество выплат инструмента. В режиме «Все счета» записи раздела «Выплаты» MUST группироваться по тем же правилам ключа, состава, порядка и итога, что и записи журнала по Requirements «All-accounts ledger groups same-day entries of one instrument», «All-accounts ledger group shows each entry and an exact total» и «All-accounts ledger grouping preserves order and limits» capability `brokerage-account-ledger`. Каждая запись при этом MUST оставаться отдельной сразу видимой карточкой внутри группы, а итог группы MUST NOT показываться, пока полнота периода не подтверждена; заголовки валютных групп и receipt count MUST NOT добавляться. Список MUST сохранять отрицательные корректировки и повторяющиеся operation IDs как отдельные записи и MUST NOT включать записи вне аналитического итога. Backend MUST обеспечивать согласованность entries, instrumentKey, валюты и receipt count при формировании ответа из одного набора записей. Frontend SHALL доверять типизированному contract без второго runtime consistency validator и MUST NOT пересчитывать аналитические денежные итоги. Единственное исключение — итог визуальной группы режима «Все счета»: это точная сумма показанных записей группы по каждой валюте, и он MUST NOT подменять аналитические итоги.
|
||||
|
||||
#### Scenario: Каждая выплата показана отдельной карточкой
|
||||
|
||||
- **WHEN** выбранный период содержит несколько включённых Ledger Entries одного или разных Instrument
|
||||
- **WHEN** в режиме одного Brokerage Account выбранный период содержит несколько включённых Ledger Entries одного или разных Instrument
|
||||
- **THEN** раздел «Выплаты» сразу показывает отдельную карточку каждой записи в исходном порядке без внешних группировочных блоков, раскрытия, итогов инструмента и receipt count на UI
|
||||
|
||||
#### Scenario: Список воспроизводит точный состав дохода
|
||||
@@ -174,9 +184,14 @@ MUST NOT заменять успешно отображённый Portfolio ил
|
||||
|
||||
#### Scenario: Валюта видна в сумме каждой выплаты
|
||||
|
||||
- **WHEN** подходящие выплаты одного Instrument представлены в нескольких исходных валютах
|
||||
- **WHEN** подходящие в режиме одного Brokerage Account выплаты одного Instrument представлены в нескольких исходных валютах
|
||||
- **THEN** каждая карточка показывает свою Money с исходной валютой, без отдельного заголовка валютной группы или объединённого мультивалютного итога
|
||||
|
||||
#### Scenario: Выплаты одной бумаги на двух счетах в режиме «Все счета»
|
||||
|
||||
- **WHEN** в режиме «Все счета» за один день получены купон по облигации на брокерском счёте +200 RUB и купон по той же облигации на ИИС +100 RUB
|
||||
- **THEN** раздел «Выплаты» показывает их одной группой с итогом +300 RUB, внутри которой видны отдельные карточки каждого счёта, а аналитические итоги страницы не меняются
|
||||
|
||||
### Requirement: Analytics summary remains readable per currency
|
||||
|
||||
Страница MUST обозначать фактический результат как «Получено купонами и дивидендами» и для каждой исходной валюты показывать total, coupon subtotal и dividend subtotal выбранного периода. Она MUST объяснять, что tax operations не включены, не называя фактический результат gross, net, суммой до налогов, суммой после налогов или налоговым расчётом. Значения MUST оставаться доступными как читаемый текст, не только как графика, цвет или положение. Страница MUST NOT показывать блок «Динамика», его график, переключатель валюты графика или текстовый список временных buckets независимо от длительности выбранного периода. Страница MUST NOT показывать блоки «Предыдущий период» и «Годом ранее» или сообщения о недоступности сравнений.
|
||||
|
||||
@@ -7,16 +7,30 @@
|
||||
## Requirements
|
||||
|
||||
### Requirement: User can retrieve an account ledger
|
||||
Система MUST предоставлять аутентифицированный журнал только для чтения одного Brokerage Account, принадлежащего текущему User. Журнал MUST содержать только исполненные операции T-Bank и при отсутствии периода по умолчанию охватывать интервал от начала текущего календарного года до момента запроса.
|
||||
Система MUST предоставлять аутентифицированный журнал только для чтения выбранного Brokerage Account либо существующего режима «Все счета» (`all`) в границах текущего User и его T-Bank connection. В режиме `all` доступ MUST проверяться для каждого входящего счёта, операции MUST сохранять принадлежность исходному счёту, а полнота периода MUST учитывать покрытие каждого входящего счёта. Журнал MUST содержать только исполненные операции T-Bank и при отсутствии периода по умолчанию охватывать интервал от начала текущего календарного года в UTC до момента запроса.
|
||||
|
||||
Система MUST читать сохранённые операции и локальное подтверждение доступа текущего подключения без синхронного обращения к T-Bank, включая запрос списка счетов. Ответ MUST содержать envelope `{ data, meta }` по `tbank-data-sync`, отражающий полноту запрошенного периода независимо от текущей страницы. Отсутствующие данные MUST возвращаться с `data: null` и состоянием загрузки, а частично сохранённый период MUST обозначаться как `partial`. Только подтверждённо полный пустой период MUST обозначать отсутствие операций.
|
||||
|
||||
#### Scenario: Получение журнала с периодом по умолчанию
|
||||
- **WHEN** аутентифицированный User запрашивает журнал принадлежащего ему Brokerage Account без периода
|
||||
- **THEN** система возвращает его исполненные операции от начала текущего календарного года до момента запроса
|
||||
- **THEN** система возвращает сохранённые исполненные операции в `data` и полноту периода в `meta` за период от начала текущего календарного года в UTC до момента запроса, запрашивая отсутствующие интервалы в фоне
|
||||
|
||||
#### Scenario: Отклонение недоступного счёта
|
||||
- **WHEN** аутентифицированный User запрашивает журнал счёта, который не является открытым поддерживаемым счётом, доступным через его T-Bank connection
|
||||
- **WHEN** аутентифицированный User запрашивает журнал счёта, для которого локальные данные текущего подключения подтверждают отсутствие доступа либо неподдерживаемое или закрытое состояние
|
||||
- **THEN** система возвращает существующий ответ о недоступности счёта и не раскрывает операции
|
||||
|
||||
#### Scenario: Общий журнал сохраняет принадлежность записей
|
||||
- **WHEN** аутентифицированный User запрашивает журнал в режиме `all`
|
||||
- **THEN** система возвращает исполненные операции доступных ему счетов, и каждая запись указывает свой исходный счёт
|
||||
|
||||
#### Scenario: Общий журнал содержит неполный счёт
|
||||
- **WHEN** User запрашивает режим `all` и у одного из разрешённых счетов есть незагруженный интервал периода
|
||||
- **THEN** система возвращает только разрешённые сохранённые записи с принадлежностью счёту и обозначает общий период неполным, не подменяя отсутствующий вклад пустым счётом
|
||||
|
||||
#### Scenario: Пустая загруженная часть не доказывает отсутствие операций
|
||||
- **WHEN** в сохранённой части периода нет записей, но покрытие периода не завершено
|
||||
- **THEN** ответ обозначает неполноту и запрошенную загрузку, а интерфейс не сообщает, что операций за период нет
|
||||
|
||||
### Requirement: User can browse a filtered ledger
|
||||
Система MUST позволять User ограничивать журнал включительным периодом дат и любым подмножеством категорий trade, income, tax, fee, transfer, other. Система MUST разбивать упорядоченный результат на страницы с непрозрачным cursor и возвращать признак доступности следующей страницы.
|
||||
|
||||
@@ -50,9 +64,10 @@
|
||||
### Requirement: Account overview includes recent ledger events
|
||||
|
||||
Обзор счёта MUST показывать пять последних исполненных записей журнала этого
|
||||
счёта и действие перехода к его полному журналу. Каждая запись MUST иметь ту же
|
||||
счёта, а в режиме «Все счета» — пять последних записей всех входящих счетов, и действие перехода к его полному журналу. Каждая запись MUST иметь ту же
|
||||
визуальную идентичность инструмента и семантику денежного движения, что и запись
|
||||
полного журнала. Неуспешный или пустой запрос MUST оставаться локальным состоянием
|
||||
полного журнала; в группе режима «Все счета» визуальная идентичность, дата и тип
|
||||
показываются в заголовке группы. Неуспешный или пустой запрос MUST оставаться локальным состоянием
|
||||
блока и MUST NOT заменять успешно отображённый Portfolio. При временном сбое
|
||||
обновления блок MUST сохранять доступные записи без технического предупреждения
|
||||
или ручного повтора. При отсутствии результата он SHALL показывать первичное
|
||||
@@ -73,7 +88,7 @@
|
||||
|
||||
### Requirement: Full ledger presents compact rows
|
||||
|
||||
Страница полного журнала MUST показывать для каждой записи дату, тип операции, инструмент и денежное изменение в исходной валюте в компактной структурированной строке. При доступной presentation metadata инструмента строка MUST показывать его визуальную идентичность; при её отсутствии MUST использовать понятный текстовый fallback. Для купонных и дивидендных операций на странице полного журнала и в личной истории инструмента MUST использоваться то же представление выплаты, что в доходе, прогнозе и графиках инструментов, с обозначением исполненного движения. Для каждой записи денежное изменение в исходной валюте MUST сопровождаться подписью конкретного типа события и знаком: для купонной операции — «Купон», для дивидендной — «Дивиденд», для остальных записей — подпись их категории («Сделка», «Налог», «Комиссия», «Перевод», «Прочее»). Строка MUST NOT повторять подпись типа события во вторичной метадате записи. Знак «+» / «−» и семантический цвет MUST оставаться носителями направления и MUST NOT заменяться только текстом. Страница MUST обозначать записи без движения денег нейтрально и MUST NOT показывать цену или количество.
|
||||
Страница полного журнала MUST показывать для каждой записи дату, тип операции, инструмент и денежное изменение в исходной валюте в компактной структурированной строке. При доступной presentation metadata инструмента строка MUST показывать его визуальную идентичность; при её отсутствии MUST использовать понятный текстовый fallback. Для купонных и дивидендных операций на странице полного журнала и в личной истории инструмента MUST использоваться то же представление выплаты, что в доходе, прогнозе и графиках инструментов, с обозначением исполненного движения. Для каждой записи денежное изменение в исходной валюте MUST сопровождаться подписью конкретного типа события и знаком: для купонной операции — «Купон», для дивидендной — «Дивиденд», для остальных записей — подпись их категории («Сделка», «Налог», «Комиссия», «Перевод», «Прочее»). Строка MUST NOT повторять подпись типа события во вторичной метадате записи. Знак «+» / «−» и семантический цвет MUST оставаться носителями направления и MUST NOT заменяться только текстом. Страница MUST обозначать записи без движения денег нейтрально и MUST NOT показывать цену или количество. В группе режима «Все счета» дата, тип операции, инструмент и его визуальная идентичность MUST показываться один раз в заголовке группы, а строка каждой записи группы MUST показывать её счёт и денежное изменение с подписью типа и знаком.
|
||||
|
||||
#### Scenario: Отображение записи только с инструментом
|
||||
|
||||
@@ -110,6 +125,11 @@
|
||||
- **WHEN** полный журнал отображает запись без доступной presentation metadata инструмента
|
||||
- **THEN** строка показывает понятный текстовый fallback без подмены или сокрытия доступных данных инструмента
|
||||
|
||||
#### Scenario: Запись внутри группы режима «Все счета»
|
||||
|
||||
- **WHEN** полный журнал в режиме «Все счета» показывает запись в составе группы
|
||||
- **THEN** её дата, тип и инструмент читаются из заголовка группы, а строка записи показывает счёт и денежное изменение со знаком и подписью типа
|
||||
|
||||
### Requirement: Кэш страниц журнала ограничивает локальные ресурсы
|
||||
Система SHALL кэшировать не более 100 недавно использованных страниц Account Ledger в каждом backend process не более чем на 30 секунд. Cache key MUST включать User, Brokerage Account, нормализованные период и categories, opaque cursor и limit; порядок или дублирование categories MUST NOT создавать отдельную cache identity, а отсутствующий конец периода MUST использовать текущий 30-секундный bucket. Просроченная страница MUST NOT возвращаться, а при переполнении cache MUST удалять наименее недавно использованную страницу.
|
||||
|
||||
@@ -177,3 +197,76 @@
|
||||
#### Scenario: Следующая страница ещё не получена
|
||||
- **WHEN** пользователь перешёл к следующей странице, но её загрузка временно не удалась
|
||||
- **THEN** область новой страницы показывает ожидание или нейтральную недоступность, не выдаёт прежние записи за новую страницу и восстанавливает чтение автоматически
|
||||
|
||||
### Requirement: All-accounts ledger groups same-day entries of one instrument
|
||||
В режиме «Все счета» полный журнал и последние записи обзора MUST объединять в визуальную группу две и более показанных записи с одинаковыми днём (как на экране), identity Instrument и точным upstream-типом операции, даже если они на одном счёте. Записи без Instrument или без пары MUST показываться как раньше. В режиме одного Brokerage Account группировка MUST NOT применяться.
|
||||
|
||||
#### Scenario: Купоны одной облигации на двух счетах
|
||||
- **WHEN** в режиме «Все счета» журнал показывает за один день купон по облигации на брокерском счёте +200 RUB и купон по той же облигации на ИИС +100 RUB
|
||||
- **THEN** они показаны одной группой с облигацией, типом «Купон» и итогом +300 RUB, а под заголовком видны строки «брокерский счёт +200 RUB» и «ИИС +100 RUB»
|
||||
|
||||
#### Scenario: Две операции одного типа на одном счёте
|
||||
- **WHEN** в режиме «Все счета» журнал показывает за один день две покупки одной бумаги на одном счёте
|
||||
- **THEN** они показаны одной группой, где каждая покупка остаётся отдельной строкой со своим денежным изменением
|
||||
|
||||
#### Scenario: Разные типы по одной бумаге не объединяются
|
||||
- **WHEN** в режиме «Все счета» за один день по одной облигации есть купон и налог с этого купона
|
||||
- **THEN** купоны и налоги показаны раздельно, и ни одна группа не содержит записи разных типов
|
||||
|
||||
#### Scenario: Покупка и продажа не объединяются
|
||||
- **WHEN** в режиме «Все счета» за один день показаны покупка и продажа одной бумаги
|
||||
- **THEN** они не входят в одну группу
|
||||
|
||||
#### Scenario: Разные дни не объединяются
|
||||
- **WHEN** в режиме «Все счета» купоны по одной облигации на двух счетах датированы на экране разными днями
|
||||
- **THEN** они показаны отдельными записями без группы
|
||||
|
||||
#### Scenario: Запись без Instrument
|
||||
- **WHEN** в режиме «Все счета» за один день показаны две записи одного типа без identity Instrument
|
||||
- **THEN** они показаны отдельными записями так же, как без группировки
|
||||
|
||||
#### Scenario: Режим одного счёта не меняется
|
||||
- **WHEN** User открывает журнал или обзор одного Brokerage Account, где есть два купона по одной облигации за один день
|
||||
- **THEN** записи показаны отдельными строками без группы, как до изменения
|
||||
|
||||
### Requirement: All-accounts ledger group shows each entry and an exact total
|
||||
Заголовок группы журнала MUST показывать дату, Instrument с визуальной идентичностью, подпись типа операции, как в строке журнала, и итог. Под ним MUST всегда быть видна, без раскрытия, отдельная строка каждой записи со счётом и денежным изменением. Итог SHALL быть точной суммой со знаком по каждой исходной валюте без конвертации и округления. Итог MUST NOT показываться, если у записи группы нет денежного изменения (включая нулевое) или полнота периода не подтверждена.
|
||||
|
||||
#### Scenario: Итог по нескольким валютам
|
||||
- **WHEN** группа содержит записи с денежными изменениями в RUB и в USD
|
||||
- **THEN** заголовок показывает отдельный точный итог в RUB и отдельный в USD, без конвертации
|
||||
|
||||
#### Scenario: Итог со знаком
|
||||
- **WHEN** группа содержит поступление +150.10 RUB и отрицательную корректировку −50.05 RUB
|
||||
- **THEN** итог группы равен +100.05 RUB, а обе записи видны отдельными строками со своими знаками
|
||||
|
||||
#### Scenario: Нулевой итог
|
||||
- **WHEN** группа содержит +150.10 RUB и −150.10 RUB
|
||||
- **THEN** заголовок показывает итог 0 RUB без знака направления, а обе записи видны со своими знаками
|
||||
|
||||
#### Scenario: Группа с записью без денежного изменения
|
||||
- **WHEN** у одной из записей группы нет денежного изменения
|
||||
- **THEN** заголовок группы не показывает итог, а записи остаются видны отдельными строками
|
||||
|
||||
#### Scenario: Запись с нулевой суммой скрывает итог
|
||||
- **WHEN** группа содержит запись +100 RUB и запись с денежным изменением 0 RUB
|
||||
- **THEN** заголовок группы не показывает итог, а запись с нулём обозначена как запись без движения денег
|
||||
|
||||
#### Scenario: Итог скрыт при неполном периоде
|
||||
- **WHEN** журнал в режиме «Все счета» показывает группу, а период обозначен как `partial`
|
||||
- **THEN** заголовок группы не показывает итог, а записи группы остаются видны со своими суммами
|
||||
|
||||
### Requirement: All-accounts ledger grouping preserves order and limits
|
||||
Группа журнала MUST занимать позицию своей первой записи в серверном порядке; записи внутри группы и остальные строки MUST сохранять относительный серверный порядок. Группировка MUST NOT менять состав, фильтрацию, пагинацию или лимит обзора, который считается по записям. Группа собирается только из показанных записей; это осознанное исключение: её итог относится только к ним и не сопровождается пометкой о неполноте.
|
||||
|
||||
#### Scenario: Позиция группы в списке
|
||||
- **WHEN** серверный порядок записей A, B, C, где A и C образуют группу, а B не входит ни в одну группу
|
||||
- **THEN** список показывает группу (A, C) на месте A, затем B
|
||||
|
||||
#### Scenario: Группа на границе страницы
|
||||
- **WHEN** записи одной группы попадают на текущую и на ещё не показанную страницу журнала при подтверждённой полноте периода
|
||||
- **THEN** группа на текущей странице содержит только её показанные записи, итог равен их сумме, и заголовок не содержит пометки о неполноте
|
||||
|
||||
#### Scenario: Группировка в последних записях обзора
|
||||
- **WHEN** в режиме «Все счета» среди пяти последних записей есть две записи с одинаковым ключом
|
||||
- **THEN** блок обзора показывает те же пять записей, что и без группировки, две из них одной группой
|
||||
|
||||
@@ -87,8 +87,9 @@ Instrument в Future Cash Event MUST иметь тот же доменный с
|
||||
|
||||
Страница Brokerage Account MUST предоставлять действие перехода на отдельную
|
||||
страницу «Будущие события». Эта страница MUST показывать все полученные события
|
||||
компактным списком без фильтров, пагинации и суммарного итога, с датой, типом,
|
||||
инструментом и прогнозной суммой в исходной валюте, если она известна. Страница
|
||||
компактным списком без фильтров, пагинации и суммарного итога списка, с датой, типом,
|
||||
инструментом и прогнозной суммой в исходной валюте, если она известна. Прогнозный итог
|
||||
визуальной группы режима «Все счета» не является суммарным итогом списка. Страница
|
||||
MUST объяснять, что прогноз основан на позиции счёта, указан до налогов и может
|
||||
быть неполным из-за доступности данных источника. Это предметное ограничение
|
||||
прогноза MUST NOT превращаться в отчёт о технической синхронизации.
|
||||
@@ -192,3 +193,56 @@ continue to use the existing URL-backed period behavior.
|
||||
a range whose `from` date is after its `to` date
|
||||
- **THEN** the page applies the default seven-calendar-date range
|
||||
- **AND** invalid `from` and `to` parameters are removed from the URL
|
||||
|
||||
### Requirement: All-accounts upcoming events group same-day events of one instrument
|
||||
В режиме «Все счета» страница «Будущие события» и ближайшие события обзора MUST объединять в визуальную группу два и более показанных Future Cash Event с одинаковыми датой и видом даты (как на экране), identity Instrument и типом события, даже если они на одном счёте. События без Instrument или без пары MUST показываться как раньше. В режиме одного Brokerage Account группировка MUST NOT применяться.
|
||||
|
||||
#### Scenario: Прогноз купонов одной облигации на двух счетах
|
||||
- **WHEN** в режиме «Все счета» на одну дату ожидается купон по облигации на брокерском счёте 200 RUB и купон по той же облигации на ИИС 100 RUB
|
||||
- **THEN** они показаны одной группой с облигацией, типом «Купон» и прогнозным итогом 300 RUB, а под заголовком видны строки «брокерский счёт 200 RUB» и «ИИС 100 RUB»
|
||||
|
||||
#### Scenario: Разные типы или даты не объединяются
|
||||
- **WHEN** в режиме «Все счета» по одной облигации ожидаются купон и погашение на одну дату либо купоны на разные даты
|
||||
- **THEN** ни одна группа не содержит события разных типов или разных дат
|
||||
|
||||
#### Scenario: Событие без Instrument
|
||||
- **WHEN** в режиме «Все счета» на одну дату показаны два события одного типа без identity Instrument
|
||||
- **THEN** они показаны отдельными строками без группы
|
||||
|
||||
#### Scenario: Режим одного счёта не меняется
|
||||
- **WHEN** User открывает «Будущие события» одного Brokerage Account
|
||||
- **THEN** события показаны отдельными строками без группы, как до изменения
|
||||
|
||||
### Requirement: All-accounts upcoming event group shows each event and a forecast total
|
||||
Заголовок группы событий MUST показывать дату (для дивиденда — как дату реестра, если она такая), Instrument, тип и прогнозный итог. Под ним MUST всегда быть видна, без раскрытия, отдельная строка каждого события со счётом и прогнозной суммой (или пометкой о неизвестной сумме). Итог SHALL быть точной суммой со знаком по каждой валюте без конвертации и округления. Итог MUST NOT показываться, если у события группы нет суммы или полнота прогноза не подтверждена.
|
||||
|
||||
#### Scenario: Событие с неизвестной суммой в группе
|
||||
- **WHEN** в режиме «Все счета» группа содержит дивиденд на одном счёте с известной суммой и дивиденд по той же бумаге на ту же дату на другом счёте без суммы
|
||||
- **THEN** заголовок группы не показывает итог, а строка второго счёта обозначает сумму как неизвестную
|
||||
|
||||
#### Scenario: Оферта без сумм
|
||||
- **WHEN** в режиме «Все счета» на одну дату ожидается оферта по одной облигации на двух счетах
|
||||
- **THEN** они показаны одной группой без итога, и каждая строка показывает свой счёт
|
||||
|
||||
#### Scenario: Прогнозный итог по нескольким валютам
|
||||
- **WHEN** группа содержит дивиденд 10 USD на одном счёте и дивиденд 200 RUB по той же бумаге на ту же дату на другом счёте
|
||||
- **THEN** заголовок показывает отдельные прогнозные итоги 10 USD и 200 RUB без конвертации
|
||||
|
||||
#### Scenario: Прогнозный итог скрыт при неполном прогнозе
|
||||
- **WHEN** в режиме «Все счета» прогноз обозначен неполным, и на странице есть группа событий с известными суммами
|
||||
- **THEN** заголовок группы не показывает итог, а строки событий остаются видны со своими суммами
|
||||
|
||||
#### Scenario: Группа дивидендов по дате реестра
|
||||
- **WHEN** группа содержит дивиденды, датированные датой реестра
|
||||
- **THEN** заголовок обозначает дату как дату реестра
|
||||
|
||||
### Requirement: All-accounts upcoming event grouping preserves order and limits
|
||||
Группа событий MUST занимать позицию своего первого события в порядке ответа; события внутри группы и остальные строки MUST сохранять относительный порядок ответа. Группировка MUST NOT менять состав, окно, порядок по дате или лимит обзора, который считается по событиям; группы собираются только из показанных событий.
|
||||
|
||||
#### Scenario: Группировка в ближайших событиях обзора
|
||||
- **WHEN** в режиме «Все счета» среди пяти ближайших событий есть два события с одинаковым ключом
|
||||
- **THEN** блок обзора показывает те же пять событий, что и без группировки, два из них одной группой
|
||||
|
||||
#### Scenario: Позиция группы событий
|
||||
- **WHEN** порядок ответа содержит события A, B, C, где A и C образуют группу, а B не входит ни в одну группу
|
||||
- **THEN** список показывает группу (A, C) на месте A, затем B
|
||||
|
||||
Reference in New Issue
Block a user