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

[slava09]

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

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

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

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

[Dron AKA andy]

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

[slava09]

Цитата:

Сообщение от Dron AKA andy

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

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

[Dron AKA andy]

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

Цитата:

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

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

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

[slava09]

Цитата:

Сообщение от Dron AKA andy

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

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

[Dron AKA andy]

Цитата:

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

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

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

[slava09]

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

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

[slava09]

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

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

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

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

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

[Vadik]

Цитата:

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

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

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

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

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

index PriceDiscIdx  // equals order by QuantityAmount

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

order by QuantityAmount

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

[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) дополнительной скидки.

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

[slava09]

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

[Vadik]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

[slava09]

Цитата:

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

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

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

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

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

[Dron AKA andy]

Цитата:

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

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

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

[AndyD]

2 vadik

Цитата:

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

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

[Vadik]

Цитата:

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

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

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

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

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

[AndyD]

2 vadik

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

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

ORDER BY itemCode, accountCode, QuantityAmount, FromDate

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

2 slava09

Цитата:

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

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

[Vadik]

Цитата:

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

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

Факт

Цитата:

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

ORDER BY itemCode, accountCode, QuantityAmount, FromDate

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

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

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

[slava09]

Цитата:

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

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

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

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

Я же никого не виню. Просто у меня мозги были выкручены именно в таком направлении логики