@Tomosh

сеть магазинов, терминальный сервер, чеки печатаются на локальных ФП

есть система накопительных дисконтов, 5-7-9-10-15%

всё самописное 7.7

проблема:
товар крупный, штучный, дорогой, но вот эти 7-9 % скидки...
продавцы жалуются на то, что попадаются суммы в чеках с копейками, долго рассчитываться с покупателем, неудобно, а округлять на ходу - некрасиво, бывает что покупатель проверяет чек, скажут ему с вас 295, а он посмотрит - 294.75, и бывают такие, кто ещё и шум поднимают...

казалось бы, чего проще:

Код ( (Unknown Language)):
СуммаСНДС = ОКР(СуммаСНДС);
СуммаСкидки = ОКР(СуммаСкидки);
но не тут-то было!

ФП печатает чек построчно. И ему плевать что там у тебя в итоге, он считает каждую напечатанную строку, а потом сам подбивает и сумму и скидку...
фактически ему передаётся только сумма, налоговая ставка, процент скидки, название товара и ещё парочка не относящихся к делу параметров.
а считает он сам, и ничего он округлять не собирается.

т.е. чтобы получить нужный результат, нужно выдавать ему строки чека, заранее обработанные под конечный результат...
выдавать ему разные скидки под каждую отдельную строку - неправильно изначально, так как скидка указывается в чеке, т.е. покупатель опять же увидит, что в этой строке у него 7%, а в этой, например, 6.87% - ну чтобы получить итого целое число - и опять же странные ситуации...

НО, у ФП есть ещё функция скидки не по процентам, а по сумме, при этом надо явно указать эту сумму.
вроде бы неплохой вариант, покупатель увидит что у него покупка на 455, скидка 32 итого к оплате 423. сразу сходу посчитать 7% там или 6.87% или 7.12% - нереально, а на глаз - примерно правильно.

теперь нужно построчно рассчитать округлённую суммовую скидку, таким образом, чтобы в ИТОГО всё сходилось...

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

для примера возьму небольшие числа и "круглую" скидку 10%, считать удобно и наглядно:

4 товара, сумма 100 скидка 10%


должны получить к оплате 90, скидка 10

округляем скидку в меньшую сторону:

ИТОГО получаем к оплате 93 скидка 7, негусто... 10% даже не пахнет...

округляем в большую сторону:

ИТОГО к оплате 89 скидка 11

для товаров ценой 23 33 21 23 получаем:

в большую сторону - к оплате 87 скидка 13
в меньшую сторону - к оплате 91 скидка 9

и, заметьте, такой разброс на "круглой" скидке

что происходит на 7% и 9% - легко догадаться...

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

0

@Дийнеки

Советую:
Я предполагаю
- Вы россиянин (в РБ нет копеек).
- на разные товары могут быть разные % скидок. Даже если сейчас этого нет, то потом может быть.
- но пока скидка на одного покупателя едина и на все товары.


Мучатся с округлением - дело бесполезное, тебя всегда будут тыкать носом в разные ситуации.
Я бы категорично видел только один выход: печатать товары с ценами без скидок. А в конце строку с фиктивным товаром
"Общая скидка". И на ней вычисленную сумму со знаком минус.

0

@Tomosh

на самом деле, достаточно развитая система скидок уже присутствует, скидки есть и на покупателя(накопительная персонифицированная дисконтка), и на товары, и особые условия, навроде: купите то и то, получите вон то на 50% дешевле, и автоматическое увеличение процента дисконта на период акций/праздников, и система референций "приведи друга" с зачётом бонусов на карточку референта, и отдельная большая скидка на день рождения клиента раз в году...
если несколько скидок накладываются, специальная обработка всегда выбирает наибольшую действующую



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

0