Понятие "необходимо и достаточно" : Кассовые программы

Если в разряд необходимого внести наличие определенных параметрических настроек ( а их число на мой взгляд конечно) плюс открытая платформа для плагинов на события - этого будет достаточно для решения любых процессов розничного магазина в сегменте, который выделял для рассмотрения выше.

Подход Ашана, да и любой другой крупной сети говорит о том, что надо работать с поставщиком. Для мелкого собственника эта работа не отменяется. Хотя это и не вопрос кассы.

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

Потому что кроме вопросов удобства кассиров, есть еще и вопросы безопасности. Чем больше у кассира свободы выбора - чем больше поле для различного рода махинаций и ухищрений.
Один пример я приводила выше - возможность продать другой товар, по меньшей стоимости другу, брату, свату.
Второй - реальный из жизни. Практически на любом кассовом ПО есть возможность отмены продажи последней позиции чека. Закрытие данной возможности для кассиров, сократило недостачу в одном отдельно взятом магазине в 3 раза. Теперь убрать последнюю позицию можно только в присутствии менеджера магазина.

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

Всё-таки, хочу вернуться к теме.
Мы обсуждаем что нужно для организации работы в небольшом магазине (произвольного формата), или идеологию КПМ?

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

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

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

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

По поводу отмены продажи последней позиции чека....
Это уже частность частности.
А именно - я говорю про автоматизацию магазина не зависимо от того, можно к ПК подключать кассу или нет.... Это условие не НЕОБХОДИМОЕ.
ВО вторых даже если говорить про кассу, то это скорее всего в вашем примере это фискальные регистраторы. Вторая частность.
А третья частность в том, чтобы каждую введенную позицию тут же печатать на ленту фискальника.
Вот двигаясь по этой цепочке - я соглашусь что этот запрет был актуален.
НО ! Мы ведь не частные случаи разбираем.

Если говорить про софт - то он должен уметь предлагать Заказчику иметь максимум вариантов. А не отдельные частные решения, как единственно верные. Это собственно уже не софт, а одна из комбинаций его настройки.
Я не отрицаю, что кому-то полезно делать запреты, но это не НЕОБХОДИМО. И смешно в магазине из 3 человек говорить про запрет с вызовом старшего кассира - согласитесь.... Какой там старший кассир ?
Какой там запрет отмены последней позиции ?
И самое смешное - что мы бы при своем подходе автоматизации в своей программе наверно запрет не поставили бы, а недостачи бы уменьшились также :)
Мы просто по-другому бы организовали бизнес-процесс, при котором кассиры бы уже не хотели вот так запросто делать отмены....
Совсем недавно одного из кассиров очень быстро так поймал представитель хозяина, нас в милиции попросили объяснить принцип работы нашего механизма, этого описания было достаточно для доказательства вины. Т.е. проводя параллель к Вашему примеру кассир сделал отмену (она была не запрещена) и тут же попался.... Буквально в течение часа.

Все что касается распределенных систем.
Магазин, особенно маленький с постоянным инет-каналом....наталкивает на мысль а действительно ли мы о маленьком магазине говорим ? Хотя такой вариант в нашем регионе ужее имеет место и достаточно давно.
Лично я считаю, что автоматизация кассы должна работать независимо - есть канал связи или нет: т.е. уметь работать и так и так.
Вопросы безопасности в таких магазинах в плане требования к ним в маленьком коллективе намного ниже, чем Вы пытаетесь их передо мной поставить. Речь идет о небольших коллективах.
Чрезмерное увлечение безопасностью вредно для их здоровья :)
На самом деле в этом сегементе такие вопросы опять становятся несколько надуманными. Т.е. софт должен уметь позволять два варианта работы и автономный и в связке.
А самое главное, в случае полной автономии как правило продавцам дают некую свободу действий. И общаясь с одной западной компанией, я им обяснял в чем беда их распределенных систем и какие на самом деле задачи надо в этом случае перед собой ставить и способы их решения.
Т.е. отрицать эту возможность, как необходимую для автономных магазинов не стоит. Более того у нас есть решение по стыковке в таком ключе с такими продуктами как Dynamics Nav. И вот тут (в таких магазинах) кассовые системы со своим SQL сервером порой раз при интеграции выглядят комично. Когда посмотришь как там люди работают в итоге - не знаешь: смеяться надо или плакать....

Про код я понял что штрих-код.... Я наверно невнятно выразился, но вы затронули один любопытный вопрос...наверно для другой темы.
А суть его в том, что код товара - это цифоровое определение товара.
Штрих-код - это разновидность такого определения.
Не иметь оцифрованного товара в рознице - это одна крайность и думаю Вам она понятна.
Делать кодировку только штрих-кодом - это другая крайность. В которую не следует упираться и не следует считать ее НЕОБХОДИМОЙ, она всего лишь ДОСТАТОЧНАЯ.
Существуют комбинированные варианты оцифровки товара.
Например, отдельные вещи лучше цифровать этикет-пистолетом.
КОроче, есть еще варианты....

уточню: я не говорил про постоянный канал; и не говорил про работу on-line.
в приведенном мной примере, речь шла о действительно маленьких алкогольных (преимущественно) точках площадью в районе 50 квадратов. 2-3 сотрудника.

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

некоторые из этих магазинов работали вообще по gprs.

под какой-то другой операционкой можно было бы обойтись и вовсе без роутера (опускаем пока вопросы безопасности при "выпускании" кассы в интернет).

справочники закрыты. аннуляция чека (и последней позиции) закрыта. функция "количество" закрыта.
у кассиров только продажа. у администратора дополнительно возвраты, X- и Z-отчет.

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

такой вот вариант достаточности для маленького магазина.

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

Поэтому давайте исходить из "сухих" аргументов. не будем друг другу приводить примеры и контрпримеры: они обязательно найдутся.

Теперь про запреты. Они необязательны !!!! Вот это самое важное.
Софт должен позволять ставить запреты, но не должен диктовать ставить их обязательно. Можно подчеркнуть только необходимость наличия такого механизма в решении.

Это действительно всего лишь вариант, чатсный случай, как квадрат частный случай прямоугльника.
Для расчета площади квадрата достаточно значть длину одной стороны, для прямоугльника это не так.

Мы стараемся рассмотреть наиболее общий случай.
Сколько приходило клиентов желающих давать возможность на месте продавцам управлять ценами. Как можно хозяину -заказчику говорить на это нет ?
Зачем удаленно управлять обновлением справочника, когда достаточно всего лишь обеспечить обновление из файла обмена, а уж средство доставки у кого как - у кого через средства связи, а у кого просто флешкой.
Говорить о том, что магазин не должен уметь принимать напрямую товар, продавать его с колес, потому что в офисе это еще не прошло централизованного учета - категорично это утверждать тоже нельзя.
Схема должна уметь и так и так....

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

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

Мне кажется, мы плавно заехали в тупик.

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

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

Естественным образом, человек хочет экономить на всем, но все же хочет иметь более-менее современный учет.

Любые запреты теряют смысл.
За свои деньги человек готов прийти пораньше или задержаться (или выкроить время между покупателями), чтобы обработать документооборот.
Вопросы доверия кассира, который никого не пускает на кассу делать что-то еще, тоже снимаются.
Проблемы квалификации часто меняющихся кассиров, аналогично, отпадают...

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

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

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

Вот с этого места вы отклонились в своей логической цепочке на мой взгляд.
1 Момент: Вы допускаете текущее деление функций на фронтовые и бэковые, к которому Вы привыкли единственно правильным.
На самом деле это не так. Функции при переходе на рабочее место в магазине также претерпевают изменения и становятся несколько другими. И наконец, я пока не увидел необходимости пихать сюда задачи офисные в том виде, как они решаются там...
2.Все вариации по сути вариации вполне конечного числа параметрических настроек + могут быть отраслевые плагины. Они по своей сути равносильны перечню подключаемого железа. Его тоже много всяких вариаций, однако это не отрицает возможность его подключения в одном и том же программном обеспечении.

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

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

P.S. А запреты и контроли и все равно ни при чем. Этот спор бесконечен, потому что равнозначен по числу плюсов и минусов и этот баланс может быть нарушен только конкретикой определенного магазина.

Но в общем и целом пора начинать новую тему как я понял :)