сеть магазинов, терминальный сервер, чеки печатаются на локальных ФП
есть система накопительных дисконтов, 5-7-9-10-15%
всё самописное 7.7
проблема:
товар крупный, штучный, дорогой, но вот эти 7-9 % скидки...
продавцы жалуются на то, что попадаются суммы в чеках с копейками, долго рассчитываться с покупателем, неудобно, а округлять на ходу - некрасиво, бывает что покупатель проверяет чек, скажут ему с вас 295, а он посмотрит - 294.75, и бывают такие, кто ещё и шум поднимают...
казалось бы, чего проще:
но не тут-то было!
ФП печатает чек построчно. И ему плевать что там у тебя в итоге, он считает каждую напечатанную строку, а потом сам подбивает и сумму и скидку...
фактически ему передаётся только сумма, налоговая ставка, процент скидки, название товара и ещё парочка не относящихся к делу параметров.
а считает он сам, и ничего он округлять не собирается.
т.е. чтобы получить нужный результат, нужно выдавать ему строки чека, заранее обработанные под конечный результат...
выдавать ему разные скидки под каждую отдельную строку - неправильно изначально, так как скидка указывается в чеке, т.е. покупатель опять же увидит, что в этой строке у него 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% - легко догадаться...
посоветуйте что-нибудь, ато даже как-то стыдно пасовать, замучаюсь объяснять почему не сделал такую "простейшую вещь"
есть система накопительных дисконтов, 5-7-9-10-15%
всё самописное 7.7
проблема:
товар крупный, штучный, дорогой, но вот эти 7-9 % скидки...
продавцы жалуются на то, что попадаются суммы в чеках с копейками, долго рассчитываться с покупателем, неудобно, а округлять на ходу - некрасиво, бывает что покупатель проверяет чек, скажут ему с вас 295, а он посмотрит - 294.75, и бывают такие, кто ещё и шум поднимают...
казалось бы, чего проще:
Код:
СуммаСНДС = ОКР(СуммаСНДС);
СуммаСкидки = ОКР(СуммаСкидки);но не тут-то было!
ФП печатает чек построчно. И ему плевать что там у тебя в итоге, он считает каждую напечатанную строку, а потом сам подбивает и сумму и скидку...
фактически ему передаётся только сумма, налоговая ставка, процент скидки, название товара и ещё парочка не относящихся к делу параметров.
а считает он сам, и ничего он округлять не собирается.
т.е. чтобы получить нужный результат, нужно выдавать ему строки чека, заранее обработанные под конечный результат...
выдавать ему разные скидки под каждую отдельную строку - неправильно изначально, так как скидка указывается в чеке, т.е. покупатель опять же увидит, что в этой строке у него 7%, а в этой, например, 6.87% - ну чтобы получить итого целое число - и опять же странные ситуации...
НО, у ФП есть ещё функция скидки не по процентам, а по сумме, при этом надо явно указать эту сумму.
вроде бы неплохой вариант, покупатель увидит что у него покупка на 455, скидка 32 итого к оплате 423. сразу сходу посчитать 7% там или 6.87% или 7.12% - нереально, а на глаз - примерно правильно.
теперь нужно построчно рассчитать округлённую суммовую скидку, таким образом, чтобы в ИТОГО всё сходилось...
я пошёл в лоб, рассмотрев 2 стандарных варианта - округлять в большую или меньшую стороны, но при первых же попытках получить работающий чек, нарвался на неожиданны результаты:
для примера возьму небольшие числа и "круглую" скидку 10%, считать удобно и наглядно:
4 товара, сумма 100 скидка 10%
Код:
1. товар1 сумма 26 виртуальная скидка 2,6
2. товар2 сумма 38 виртуальная скидка 3,8
3. товар3 сумма 17 виртуальная скидка 1,7
4. товар4 сумма 19 виртуальная скидка 1,9должны получить к оплате 90, скидка 10
округляем скидку в меньшую сторону:
Код:
1. товар1 сумма 26 скидка 2 к оплате 24
2. товар2 сумма 38 скидка 3 к оплате 35
3. товар3 сумма 17 скидка 1 к оплате 16
4. товар4 сумма 19 скидка 1 к оплате 18ИТОГО получаем к оплате 93 скидка 7, негусто... 10% даже не пахнет...
округляем в большую сторону:
Код:
1. товар1 сумма 26 скидка 3 к оплате 23
2. товар2 сумма 38 скидка 4 к оплате 34
3. товар3 сумма 17 скидка 2 к оплате 15
4. товар4 сумма 19 скидка 2 к оплате 17ИТОГО к оплате 89 скидка 11
для товаров ценой 23 33 21 23 получаем:
в большую сторону - к оплате 87 скидка 13
в меньшую сторону - к оплате 91 скидка 9
и, заметьте, такой разброс на "круглой" скидке
что происходит на 7% и 9% - легко догадаться...
посоветуйте что-нибудь, ато даже как-то стыдно пасовать, замучаюсь объяснять почему не сделал такую "простейшую вещь"