Упрямые DataSource не дают построить прайс-лист

[dech]

qbrCena1TransDate.value(queryRange(dateNull(), SOPCenaDoc.TransDate));

qbrCena2TransDate.value(queryRange(SOPCenaTable.TransDate + 1, dateNull()));
qbrCena2TransDate.value(queryRange(dateNull(), SOPCenaDoc.TransDate));

[Яга1]

1)qbrCena2TransDate.value(queryRange(dateNull(), SOPCenaDoc.TransDate)) вообще убивает предыдущее условие, остается только ((TransDate<={ts '2017-01-27 00:00:00.000'})), а надо AND


2)qbrCena2TransDate.value(queryRange(SOPCenaTable.TransDate + 1, dateNull()));
в запросе превращается в ((TransDate>={ts '1900-01-02 00:00:00.000'}))

[dech]

Цитата:

Сообщение от Яга1

1)qbrCena2TransDate.value(queryRange(dateNull(), SOPCenaDoc.TransDate)) вообще убивает предыдущее условие, остается только ((TransDate<={ts '2017-01-27 00:00:00.000'})), а надо AND


2)qbrCena2TransDate.value(queryRange(SOPCenaTable.TransDate + 1, dateNull()));
в запросе превращается в ((TransDate>={ts '1900-01-02 00:00:00.000'}))

Надо просто новый QueryBuildRange добавить

qbrCena2TransDate.value('(SOPCenaTable.TransDate < SOPCenaTableView.TransDate)')
qbrCenaTableTransDate = qbds.addRange(fieldNum(SOPCenaTableView, TransDate));
qbrCenaTableTransDate.value(queryRange(datenull(), _DATE));

где qbds - ваш датасорс SOPCenaTableView

[Яга1]

Тогда условия связались по OR:
(((SOPCenaTable.TransDate < SOPCenaTableView.TransDate)) OR (TransDate<={ts '2016-09-01 00:00:00.000'}))

[AlGol]

Цитата:

решили хранить не прейкурант полностью, а таблицу, что цена на такой-то ItemId меняется с такой-то даты на такую-то (иногда на 0).

Может проще будет доработать таблицу с ценами до полноценной реализации модели ValidFrom-ValidTo?
Добавить поле даты окончания срока действия цены ValidTo, заполнять его по умолчанию максимальной датой, а при создании строки с последующей датой заполнять его соответстующим значением окончания срока действия.

Тогда запросы по актуальным ценам упростятся до
[дата цены]>=ValidFrom AND [дата цены] <= ValidTo.

[KiselevSA]

Цитата:

Сообщение от AlGol

Может проще будет доработать таблицу с ценами до полноценной реализации модели ValidFrom-ValidTo?
.

C ценами нельзя использовать такую модель, т.к. полноценная реализация запрещает иметь пересекающиеся диапазоны. В реально жизни очень часто встречаются маркетинговые акции, действующие короткий срок и с ценами ниже обычной. После окончания маркетинговой акции опять создавать нормальные цены? В свою бытность, помню, даже мутили специальную модификацию, которая выполняла последовательное создание ценового соглашения, если в журнале цен у записи была указана дата окончания действия: закрыть предыдущую датой начала и создать копию с датой начала равной дате окончания + 1.

[dn]

Цитата:

Сообщение от KiselevSA

C ценами нельзя использовать такую модель, т.к. полноценная реализация запрещает иметь пересекающиеся диапазоны. В реально жизни очень часто встречаются маркетинговые акции, действующие короткий срок и с ценами ниже обычной. После окончания маркетинговой акции опять создавать нормальные цены?

Это решается. У нас, например, сделан отдельный тип ЖКС Акция. При его разноске дополнительно действующая цена закрывается за день до начала акции + создается копия этой цены с датой начала на день позже даты окончания акции.

[AlGol]

Цитата:

Сообщение от KiselevSA

очень часто встречаются маркетинговые акции, действующие короткий срок и с ценами ниже обычной. После окончания маркетинговой акции опять создавать нормальные цены?
В свою бытность, помню, даже мутили специальную модификацию, которая выполняла последовательное создание ценового соглашения, если в журнале цен у записи была указана дата окончания действия: закрыть предыдущую датой начала и создать копию с датой начала равной дате окончания + 1.

Да, подобные алгоритмы и подразумевают нормальную непротиворечивую реализацию модели ValidFrom-ValidTo (или Date Effective Framework как это названо в AX2012).

И создавать нормальную цену на последующий период, по идее, нужно не при прекращении действия краткосрочного ценового соглашения, а в тот момент когда становится известным срок окончания акции. Как правило, это бывает уже в начале действия акции.

[Яга1]

Цитата:

Сообщение от AlGol

Может проще будет доработать таблицу с ценами до полноценной реализации модели ValidFrom-ValidTo?
Добавить поле даты окончания срока действия цены ValidTo, заполнять его по умолчанию максимальной датой, а при создании строки с последующей датой заполнять его соответстующим значением окончания срока действия.

Тогда запросы по актуальным ценам упростятся до
[дата цены]>=ValidFrom AND [дата цены] <= ValidTo.

А также нужно возвращать в ValidTо максимальную дату, если новая строка цен удалилась
И не максимальную, а какую-то там еще, если удалилась не последняя строка
И при изменении ValidFrom, если в результате строка перескакивает через несколько строк назад, тоже исправить ValidTo.
Мы уже делали так. Впечатление, что ПРОЩЕ все-таки qbrCena2TransDate.value('((SOPCenaTable.TransDate<SOPCenaTableView.TransDate) && (SOPCenaTableView.TransDate<='+date2StrXpp(_DATE)+'))'); как предложил Wamr
Наглядно и точно нет ошибок при пересчете ValidTo

[Владимир Максимов]

Цитата:

Сообщение от Яга1

Впечатление, что ПРОЩЕ все-таки

Есть два связанных между собой процесса

1. Запись и модификация данных
2. Выборка данных для анализа

Проблема в том, что структура данных, оптимальная для первого процесса, будет не оптимальная для второго. Ну, и наоборот. Просто "целевая аудитория" у этих процессов разная. Выборка - для человека, а хранение - для "железа"

Вы выбрали структуру данных, оптимальную для первого процесса (запись и модификация данных). Но, как Вы видите в данной теме, эта структура создает проблемы при выборке и анализе данных.

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

И тут вопрос в том, что для Вас важнее? Что чаще придется делать? Ведь, в конце концов, написать код триггерров на insert/update/delete придется только один раз. Пусть даже он будет достаточно сложным. А вот выборки цен Вы будете делать еще много раз и по разным поводам. И каждый раз Вы будете мучительно долго вспоминать, как же это все "упихать" в один запрос, причем в синтаксисе Axapta.