А это изюм, но он не продается... : Супермаг Плюс (Супермаг 2000)

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

Ну если бутик блатной то... я бы сделал так...
1. При входе выдаем покупателю магнитную карту\или карту с ШК...
2. Продавец\Цы при просьбе покупателя пикают его карту затем товар который продают... и колво, естественно с помощью ТСД... моно даже в виндовом RDP... так наверное проще будет...ну или поставить по компу продавцам...
3. Покупатель подходит к кассе пикает\катает карту весь товар который он собрал появляется на кассе... продавец видит общий вес и на всякий проверяет общим весом на кассе...

да и карту если на много купил можно подарить как дисконтную с почестями...

По сути, Олег прав. Очень подходит для таких бутиков (был я в них) "убийца очередей" на ТСД. Все равно подход индивидуальный - продавец-кассир ходит с покупателем и собирает набор. Взял с витрины, отсканировал ШК, которым отмаркирован данный тип конфет . Если необходимо взвешивать (т.е. товар весовой), придется взвешивать и вводить количество.

Ивиняюсь, сразу не смогу поучавствовать в этой теме.
В общем, даю полный расклад на то, что сейчас у нас есть в бутиках:

Кассы: Стандартные кассы на LexPOS, УКМ42.5, мониторы TVS
Персонал бутика: 2 продавца и администратор.

Товар: Имеется группа товара - конфеты ручной работы.
Каждая конфета обладает своим артикулом и ШК в базе, но маркировке товар не поддается, т.к. мелкий. Количество отдельных позиций - около 110. Товар не весовой, а штучный.
Конфеты не имеют какой-либо определенной логической группировки и могут быть сгруппированы разве что только по ценам:
10р., 20р., 25р., 30р., 50р., 60р.

Продажа товара:
В момент продажи покупатель выбирает понравившуюся упаковку, куда требуется сложить все эти конфеты и с помощью продавца производит набор конфет в коробку. При этом часто бывает так, что конфеты в процессе сбора заменяются на другие, содаются разные варианты и т.п.

У нас в бутиках имеется книжка, в которой есть описание каждой конфеты и ее артикул и ШК. Но считывать из этой книжки очень не удобно, т.к. в сезон очереди в бутике просто громадные, покупателей много и необходимо крайне быстро всех обслужить. Да и просто человеческий фактор тут громадный. Постоянно происходили ошибки или намерянные считывания позиции схожей по цене, но другой по артикулу (типа, чтобы быстрее посчитать). Например: не по 10 штук 10-ти видов конфет за 20р., а 100 штук 1-го вида за те же 20р.

Как решался вопрос раньше:
Раньше продавцы просто собирали набор, считали цену на калькуляторе и проводиле по кассе авансовым платежем (в Супермаге заведена специальная позиция - "Авансоывй платеж" стоимостью 1 р.). Т.е. выбирали позицию Авансовый платеж и вводили коичество равное сумме. При этом, какие позиции содержались в наборе определить просто не возможно.

Как реализовано на данный момент:
Единственный вариант, который я сомг найти - это объединение конфет по ценовым категориям. После этого я создал еще несколько позиций на подобие "Авансового платежа", но с другой ценой:
Конфета 10р.
Конфета 20р.
Конфета 30р. и т.д.
Все эти ценовые категории я вынес на кнопки клавиатуры. Проводить покупку стало намного удобнее и быстрее.

По сути дела это тот же самый "Авансовый платеж", но уже не в одну кучу, а хоть как-то поддающийся обработке. В конце месяца, например, можно определить сколько было продано конфет той или иной ценовой категории.

Но в итоге мы все равно не видим каких конфет и сколько было продано.
Возникает постоянный пересорт - где созданные авансовые позиции уходят в минус, а реальный позиции конфет остаются в излишках.
Я предлагал в компании проводить еженедельные промежуточные инвентаризации только по группе "Конфеты ручной работы" и потом содавать приходные и расходные накладные, тем самым компенсирую пересорт, но идею не поддержали из-за лишних затрат времени на инвентаризацию. Вот теперь думаю, как можно еще решить эту проблему.

Мысли:
Варианты с ценниками и ТСД конечно хороши, но они очень сильно тормозят работу. А в пиковые дни сезона (Например, НГ) в бутике твориться черт знает что! Там по сути дела получается настоящая биржа - стоит только показать какой-то товар, как сразу на него налетают несколько покупателей. =))))))
Вариант дисплея с точскрином мне кажется наиболее оптимальным. Но как бы не произошло той же проблемы что и с папочкой с ШК.... Да и софт скорее всего придется полностью поменять. УКМ такое не поддержит.

Ты не упомянул одного из главных вопросов. Откуда набираются конфеты? Как я понял, набирает все равно продавец? Почему не пикать коробку, откуда берется товар? Или с ценника на лотке? Понятное дело, что забрасывать товар в толпу еще быстрее будет, но учет-то нужен...

все не успеваю протестить вариант, который родился по мере прочтения ветки:
- сканируем ценник того, что закинули в коробку
- сканируем специальный ШК, в который зашито некоторое количество и суффиксом символ операции "количество".

цель: исключить беготню до кассы, где надо ввести количество товара, закинутого в коробку.
"+" чек можно набирать весьма шустро
"-" если монитор от прилавка не видно (видно плохо) - попрут ошибки

УКМ2 - не поддержит. УКМ4, в варианте Lillo - должен. Ну или альтернативные варианты, типа атолловских (в РМК 2 года назад (если не три) ввели представление дерева товаров в виде тачскриновской сетки)

Сильно не заморачивайтесь, переведите этот штучгый товар в весовой, и продовайте как вес, укладывая его в отдельную упаковку и кодируя на весах

Кроме фразы "сильно не заморачивайтесь" толком ничего не понял. Обозначить конфету, как килограмм, например? :) Не совсем понятно, какой выигрыш в скорости это даст, за счет чего?