Dimitry SibiryakovНе имеет.


А почему не имеет?

Сам case работает:

KreatorXXISashaua,

Полный запрос нужен. Я, например, вижу, что запрос по неким таблицам, а кейс по локальной переменной. Странновато.

Много где применяется подход "цена по первой колонке, по второй колонке" и т.п.
В прайсе предварительно заданы допустим 3-5 колонок с различными ценами,
у клиента имеется право использовать цены из конкретной колонки.
Вот в параметре номер колонки и задается.

Гаджимурадов Рустамfraks> Много где применяется подход
fraks> Вот в параметре номер колонки и задается.

Василий, ви таки правы, но чтобы так задавался способ
округления, думаю, не слышали даже ашкенази Майами.


Я таки не Василий :)

С округлениями еще больше заморочек.
Возможно человек делает несколько вариантов под хотелки разных контрагентов :)

Dimitry SibiryakovГаджимурадов Рустамобработанное значение может понадобиться опять же на сервере.

Вот где оно понадобится - там и нужно принимать решение об его обработки или необработке.


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

Гаджимурадов Рустамfraks> Я таки не Василий :)

Ой, Владимир, извини, на автомате спутал с коллегой из соседней темы. :)

> Возможно человек делает несколько вариантов под хотелки разных контрагентов :)

Ну, закладывать каждую хотелку каждого контрагента
в CASE на сервере - граблепроктостоматология, ИМХО.


Закапывать это в код на клиенте - ничем не лучше.
Такова селяви.
Бизнес озвучит хотелки и настоит на их выполнении.
И хорошо если бизнес эти хотелки в состоянии нормально озвучить :)

Гаджимурадов РустамSashaua> Но вылазят хвосты когда цену необходимо пересчитать
Sashaua> с одной валюты в другую например PRICE =15 текущий
Sashaua> курс = 26.31 = 394.65 продажники хотять чтобы это было 395.

Продажники люди неглупые. Пару десятков таких преобразований из
одной валюты в другую (и даже между 2 валютами) - и глядишь цена
вырастет заметно. Округлять "вниз" они не предлагают, есессно.


А откуда возьмутся эти десятки преобразований??
Входная цена.
От нее наценка до уровня соответствующей колонки прайса.
Округление на эту цену.
Всё.

Округлять вниз смысла никакого нет.

WildSeryПоэтому это не в код (на сервере, на клиенте) закладывают, а в реквизит цены "настройки округления", например.

А что, реквизиты как-то сами, без какого-либо кода к цене научились применяться?

WildSeryfraksА что, реквизиты как-то сами, без какого-либо кода к цене научились применяться?Освежу твою память, раз через один пост уже забыл, о чём говорил в предыдущем.
Речь шла о "закладывать каждую хотелку каждого контрагента ... плохо на сервере, и на клиенте тоже плохо".

Так и куда ее закладывать в итоге?

WildSeryfraksА что, реквизиты как-то сами, без какого-либо кода к цене научились применяться?Освежу твою память, раз через один пост уже забыл, о чём говорил в предыдущем.
Речь шла о "закладывать каждую хотелку каждого контрагента ... плохо на сервере, и на клиенте тоже плохо".

Очередной клиент из 10 тысяч захотел свою хотелку.
Добавляем ее в код под именем "хотелка №10".
У клиентов, хотелки которых совпадают, пишем что цена формируется как "хотелка №10".
В свойствах контрагента прописываем номер его хотелки.

Реализацию хотелок, по возможности, сводим в одно место.
Например в SP или общий запрос который тянет цены с сервера.

Что не так в этой системе?

Гаджимурадов Рустамfraks> Добавляем ее в код под именем "хотелка №10".
> У клиентов, хотелки которых совпадают, пишем что

А конкретнее (как реализовано) ?


А чего у меня спрашиваете? Это впросы к ТС.

Про вариативность хотелок.
Например, формат экспорта данных для некоего ЭДО.
Отправляем клиентам документы в электронном виде, печатная форма в виде PDF - клиент может у себя распечатать ровно то что получит с товаром, когда он придет.
Те из клиентов которые каким-то образом автоматизировали учет и загрузку данных о приходах - берут их в электронном виде.
Некоторые уникумы хотят секса и запрашивают бухгалтерские печатные формы в Excel что бы потом из них выковыривать данные, а те люди которые четко понимают чего им нужно - формулируют свои хотелки более конкретно, но их не так много.
В итоге, идя навстречу ВСЕМ клиентам, у меня в программе реализовано всего 4 варианта специализированного экспорта в DBF и один неспециализированный. И вот эти 4+1 варианта хотелок закрывают все пожелания тычяч клиентов.

У ТС масштаб хотелок и вариантов реализации мне представляется примерно таким же, поэтому не вижу больших проблем.