Есть различные условия формирования цены.

Речь о скидках при продаже одному покупателю
1. Назначаем строку, на которую назначаем скидку в %.
Пример. Назначаем 10 сироку, 15%
Т.е. если покупатель купил 10 товаров, то на 10 строке будет скидка 15%
2. Назначаем кол-во в строке,на которую назначаем скидку в %. - это просто.
3. Сумма предыдущих N строк> S скидка F
Пример.
5 строк, сумма 500 руб, сикда 8%
Покупатель купил в сумме на 5 стсроках больше 500р, скидка на эти 5 строк, 8%.

Ясно, рассчитать это элементарно.
А вот как хранить?
Просто в ini файле, в xml, хотелось бы в табличке...

Может кто сталкивался с таким...
И что еще не нравится, ясно что каждую продажу, придется пробегать по всем условиям.
(по времени не страшно - коду много)))
А таких условий может быть много.

Аспид
А вот как хранить?

Хранить что? Факт, что предоставлена скидка? Тогда, в той же записи, что "документ-продажа" добавить колонки "процент скидки" и "сумма скидки". Так не получится? Или, хранить что то ещё?

При такой навороченной логике я бы каждую скидку сделал тупо отдельным объектом. А в базе бы держал таблицу с идентификаторами объектов. Плюс граф начисления скидок, который задаёт очередность и ветвления при применении объектов. По-жизни такой граф чаще всего вырождается в дерево скидок. Либо лес скидок, зависимый от условий реализации.
Документ последовательно по дереву скармливается объектам. А в сам документ записывается идентификатор объекта-скидки, а так же объекты и место его применения. Лучше, если запись идёт в отдельные таблицы, которые будут иметь ссылки на строки, группы строк и/или заголовок документа.

Соответственно, 1 - группа строк, на которые применяется скидка по бизнес-логике объекта. Плюс место применения - 10-я строка.
2 - объект применения и место применения совпадают со строкой, где сработала количественная скидка.
3 - объект применения и место применения совпадают с группой из 5-и строк, где набралась условная сумма.

Можно не хранить объект и место применения, конечно, - тупо %-ик подставил и нормально. Но потом обычно начинают спрашивать отчёты: "а как применялась такая-то скидка"? "А за год покажите"?

Вот когда начнут спрашивать, как оно применялось, и как повлияло на рентабельность отдельных товаров/групп, тогда придётся делать свёртку структуры начисленных скидок до той аналитики, которую попросили показать. Часто оказывается, что скидка отнесена на конкретную строку, а потерю рентабельности необходимо раскидать на всю группу объектов применения. Вот тогда избыточность структуры начинает оправдываться.

pasha_usue
Спасибо за мысль. Хоть что то отличное, от тупого скармливания дока всем условиям, после любого изменения...
Надо осмыслить.

Может какие то альтернативы?...

Однозначно не стоит хранить логику в БД - всякие "формулы", свой "птичий язык" или тот же фоксовый код.
Справочник "скидок" и ссылка на него из документов применявших ту или иную скидку - это другое дело. Но не сама логика.

А что, порядок внесения товаров в чек влияет на скидку? По-моему это ущербная логика. Ну хорошо, я куплю 9 разных упаковок жевательной резинки, а на 10 позицию попрошу какой мега-крутой телевизор за 5к зелени
Скидка должна быть простой и не позволяющей её "трактовать" так или иначе, как порой у нас с законами происходит...