Скидка с датой.

[slava09]

Может уже обсуждалось...
Есть скидка у которой указан интервал: март 2006 - 5%
Есть скидка у которой интервал не указан - 10%

Логика: в марте 2006 запланировали клиенту отпускать по 5%, все остальное время по 10%.

Но у меня не подставляется скидка в 5%, если я создаю заказ мартовской датой.

В чем причина?

[Dron AKA andy]

Для Аксапты относительно ваших настроек в марте действительны обе скидки, и она предлагает наиболее выгодную для клиента, о чем прямо указано в хелпе. Поиграйтесь с галочкой "Найти далее", а лучше задайте жесткие непересекающиеся интервалы дат.

[slava09]

Quote:

Originally Posted by Dron AKA andy

Для Аксапты относительно ваших настроек в марте действительны обе скидки, и она предлагает наиболее выгодную для клиента

Красиво рассуждаете.
1. Почему должна Акса действовать с позиции выгоды клиента а не предприятия (по вашим словам)?
2. Меняя значения скидки местами происходит тоже самое;

[Dron AKA andy]

Это я не рассуждаю, а пишу о реализации как есть. Номер соответствующей главы из "Управления торговлей и логистикой" не приведу, т.к. не помню.

Quote:

Originally Posted by slava09

Меняя значения скидки местами происходит тоже самое;

Не понял, что и с чем вы меняете. Поиск другой сделки после нахождения первой попавшейся определяется упомянутой галочкой "Найти далее".

[slava09]

Есть скидка у которой указан интервал: март 2006 - 10%
Есть скидка у которой интервал не указан - 5%

Аксапта выбирает всеравно скидку 5%
Вот что я имел ввиду.

[slava09]

Quote:

Originally Posted by Dron AKA andy

Поиск другой сделки после нахождения первой попавшейся определяется упомянутой галочкой "Найти далее".

Это не просто поиск, это суммирование скидок.

[Dron AKA andy]

Quote:

Originally Posted by slava09

Это не просто поиск, это суммирование скидок.

Да, согласен, перепутал с ценовыми соглашениями.

[slava09]

Ну всетаки. Возвращаясь к теме.
По всей видимости Аксапта игнорирует скидку с интервалом, если есть скидка без интервала.
Независимо выгодна ли она клиенту или нет.

Но, если следовать такому логическому рассуждению, что скидка с интервалом должна уточнять условия в определенный интервал времени, то выходит что Аксапта работает не правильно.

А если не следовать, то работает не понятно как Точнее, не так как я ожидал (я только про себя говорю).

[AndyD]

Обратите внимание - класс PriceDisc, метод findDisc()

    while select priceDiscTable
        index [u]PriceDiscIdx[/u]  // equals order by QuantityAmount
        where ...

В индекс PriceDiscIdx входит поле FromDate - дата начала действия скидки. Если не указывать дату в этом поле, то в таблицу запишется значение "01.01.1900". Т.е. при прочих равных условиях будет выбрана первой запись без срока начала действия. Из нее и выберется скидка.

Либо разбивайте бессрочную скидку на две - одна действует до начала (например, 28.02.2005), а другая - после начала (например, 02.03.2006) дополнительной скидки.

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

[Владимир Ю.]

Сталкивался с такой ФИЧЕЙ на проекте. Спасло только создание 3-х строк с конкретными датами действия скидки. В код не лезли по определенным причинам.

[Vadik]

Quote:

Originally Posted by slava09

Но, если следовать такому логическому рассуждению, что скидка с интервалом должна уточнять условия в определенный интервал времени, то выходит что Аксапта работает не правильно

Скидка ищется согласно \Classes\PriceDisc\findDisc

У Вас текущая дата попадает в ДВА интервала - какой из них "правильнее" ? Где в документации можно почитать про принцип "уточнения" одного интервала другим ?

А закладываться на

index PriceDiscIdx  // equals order by QuantityAmount

по-моему как-то нездОрово - ибо, судя по комментариям, какой-либо сортировки по ДАТЕ здесь не планировалось

order by QuantityAmount

тоже imho не помешало бы.. так, на всякий случай

[slava09]

Так согласно findDisc, или согласно того что выгоднее клиенту?
Мне тут сказали, что в документации так и написано.
Конечно, для вас это очевидно, что пустая дата, это "01.01.1900", но для пользователя, это выглядит несколько иначе.
В документации про "принцип уточнения" ничего не сказано, я же сказал - по моему личному мнению.
Не надо меня тыкать носом в документацию.
Кстати, в конечной дате стоит тоже пустое значение, а следовательно "01.01.1900", так что у меня только одна текущая дата получается!

[AndyD]

2 vadik

Quote:

А закладываться на PriceDiscIdx по-моему как-то нездОрово - ибо, судя по комментариям, какой-либо сортировки по ДАТЕ здесь не планировалось

Это к чему?
Добавление order by QuantityAmount принципиально ситуацию не изменит (это поле и так входит в индекс).

[Vadik]

Quote:

Originally Posted by slava09

или согласно того что выгоднее клиенту? Мне тут сказали, что в документации так и написано

Мне о такой трогательной заботе о клиентах неизвестно. Может быть, имелся в виду способ расчета скидки при наличии скидки по строке и многострочной (Расчеты с клиентами \ Параметры \ Цены \ Скидка) ?

Quote:

Не надо меня тыкать носом в документацию.

Извините, больше не буду. Это же шутка была

Quote:

Кстати, в конечной дате стоит тоже пустое значение, а следовательно "01.01.1900", так что у меня только одна текущая дата получается!

Если Вы имеет в виду то, что "сегодня" не должно попадать в период "с 1900.01.01 по 1900.01.01", попадает-попадает, и не только при поиске скидок. Довольно удобно, на мой взгляд

[Vadik]

Quote:

Originally Posted by AndyD

2 vadik
Добавление order by QuantityAmount принципиально ситуацию не изменит (это поле и так входит в индекс).

ситуация изменится, если
- какая-нибудь неугомонная личность отключит индексные хинты на уровне конфигурации
- она же закомментирует index hint или укажет в нем другой индекс
- она же изменит индекс, поменяв поля местами

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

а ORDER BY - он и в африке ORDER BY

[Dron AKA andy]

Quote:

Originally Posted by slava09

Так согласно findDisc, или согласно того что выгоднее клиенту?
Мне тут сказали, что в документации так и написано.

Написал же выше, что перепутал с ценовыми соглашениями, где как раз ищется минимальное по величине значение цены (т.е. выгодное клиенту) при прочих равных.
А механизм поиска по дате работает одинаково что для цен, что для скидок.

[slava09]

Quote:

Originally Posted by Vadik

Извините, больше не буду. Это же шутка была

Вы тоже меня звиняйте. Настроение никудышное совсем. Сорвался.

Насчет заботы о клиентах, это слова товарища Dron AKA andy. Он имел ввиду цены.

По поводу интервалов: конечно можно представить самый простой случай когда текущая дата попадает в несколько интервалов заданных в прайсах (даже без пустых дат). И можно сказать, что Аксапта не имеет никакого предпочтения в их выборе.
Согласен, что ситуация когда нужно разбивать на несколько интервалов, чтобы добиться желаемого эффекта вполне нормальна, но достаточно хлопотна.

[AndyD]

2 vadik

Во-первых, против лома нет приема.

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

ORDER BY itemCode, accountCode, QuantityAmount, FromDate

В-третьих. Если есть желание и возможность изменять чтобы-то ни было - это ваше право. Но какое это имеет отношение к работе стандартного приложения? Или вы не согласны, что стандартная Axapta выбирает скидки именно так?

2 slava09

Quote:

Конечно, для вас это очевидно, что пустая дата, это "01.01.1900", но для пользователя, это выглядит несколько иначе.

Извините, но Axapta'у не я писал. И что должно быть очевидно для пользователей - не мне решать. Я лишь описал почему так происходит. И не понимаю в чем провинился перед вами

[Vadik]

Quote:

Originally Posted by AndyD

Во-первых, против лома нет приема

Факт

Quote:

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

ORDER BY itemCode, accountCode, QuantityAmount, FromDate

Все верно. Маленькое уточнение - сортировки по QuantityAmount достаточно, потому что все остальные поля уже "зажаты" в WHERE

P.S. А вообще - наличие скидок на несколько пересекающихся периодов при включенном "найти далее" (а поле по умолчанию включается при ручном вводе) позволяет обеспечить клиентам хорошую "халяву"

Причем сугубо штатными средствами

[AndyD]

Вдогонку.

index idx и index hint idx - это разные вещи и первое не отключишь конфигурационной утилитой.

Quote:

Все верно. Маленькое уточнение - сортировки по QuantityAmount достаточно, потому что все остальные поля уже "зажаты" в WHERE

Точно! Стормозил

PS Точнее запутался А FromDate?