Заметил что в последних обновлениях Розницы (начиная с версии 2.3.9) заметно начал тормозить поиск в рмк.
в описании обновлений написано что добавили поиск по штрихкоду.
Суть проблемы в следующем.
Если в РМК по кнопке INS добавлять товар, то быстро в поиск не получится написать несколько цифр артикула. После нажатия на первую цифру, сразу же начинается поиск (скриншот1), подвисание где то на 1 секунду, но когда стоит большая очередь это очень сильно напрягает, можно случайно не тот товар в чек добавить.
и еще, если в чеке изменить количество товара быстро (т.е. если быстро нажать "5, Enter")
открывается окно "поиск номенклатуры по штрихкоду (скриншот2)
вы видимо не понимаете что происходит на кассе когда у вас очередь из 10 человек, которые хотят после работы побыстрее попасть домой. А за кассой стоит тетя которой завтра 50 лет исполнится. Она быстро пытается ввести артикул, но поиск проглатывает одну/две цифры и надо все стереть и ввести заново только медленно. Тот поиск что вы говорите очень не удобный. Хотелось бы подискутировать не с теоретиком а кто работает с магазинами у которых минимум две кассы и в день по 500 чеков
(7)
нет, это не понимаете вы, что в магазине ,где работаю
это словосочетание "мне быстрее,я очень спешу" звучит,
как магическое заклинание
при отсутствии очереди !!!!
почему-то в банке при оплате вы такое не услышите
или на приеме у стоматолога, а ?
А за кассой стоит тетя которой завтра 50 лет исполнится и ?
моя коллега работала в таком супермаркете и открою вам тайну
- им было задание некоторые коды запоминать и да,касса была не одна
и когда ей нужно выйте - ее подменяли
у вас также ?
если вы не пользовались поиском из розницы - простым или расширенным, то вы не поймете,о чем речь
может вы не знаете, что еще есть и быстрые товары ?
(6) поиск есть и расширенный ? это какая комбинация клавиш ?
любой поиск по F11 неудобен. ISN и "стрелка вниз" намного удобнее, так как в одном окне мы можем и по артикулу искать и по наименованию. Бывает ведь что ценник с кодом потерялся, но на колбасе написано название (тут речь не идет о скорости, так как это больше исключение)
(18) использвание мыши не напрягает в работе. Кто-то пользуется мышью, кто-то нет. Главное чтоб было как можно меньше действий. Есть программы в которых вообще ничего не нужно вводить. Окно поиска товара находиться сразу в форме чека. И курсор по умолчанию всегда стоит на поиске. Продавец с консоли вводит код или часть наименования и Enter, потом сразу новый код и Enter. Так работает Тирика, Галион. Там это очень быстро работает.
С артикулами думаю нужно бороться, хотя понимаю что в некоторых товарах от них никуда не деться.
У себя большинство артикулов заменил SKU номерами в 1с с последующим "этикитированием" на весах.
Для пожилых продавцов этот вариант даже более удобен чем артикул в 1с, на весах нажимают 2 кнопки и всё готово, этикетку наклеили товар в зал положили, в будущем на кассе просто отсканировали. С весовым товаром основная схема.
Для не весового товара можно просто сделать печать штрихкода на этих же весах в магазине, без SKU кода.
С овощами и подобными продуктами посложнее, если количество небольшое то можно у кассы иметь листок с штрихкодами.
В пятёрочке при взвешивании на кассе используют что-то типо быстрых товаров в 1с, что как бэ говорит об эффективности метода, учитывая что время обслуживания клиента в X5 анализируют.
Я бы посоветовал использовать быстрые товары и весы с печатью этикеток вместе со SKU.
По тратам от 10 до 30к на весы, в зависимости от возможности выгрузки товаров из 1с в online режиме
Хотелось бы отдельно ответить на комментарии выше.
Господин ХАКЕР, опять ничего не понял. Какое отношение стоматолог, подмена продавца и обслуживании в банке, имеет к скорости ввода информации ? (я это буду повторять несколько раз, чтобы понял)
Ключевой ВОПРОС. Скорость добавления товара в чек замедлилась после обновления на версию 2.3.9. 5 магазинов, 5 серверов, 25 рабочих мест. Базы серверные, на SQL. До обновления конфигурации таких проблем небыло. Далее по списку:
1. Запоминание кодов не ускоряет ввод цифр в РМК.
2. Ваш опыт по автоматизации супермаркетов, тоже не ускоряет ручной ввод данных.
3. Не верно утверждение, что продавец захотел в туалет, а его никто не подменяет, поэтому он переминаясь с ноги на ногу совершает ошибки при добавлении товаров в чек.
4. Пока что во второй раз повторяю, поиск в рознице не удобен тем что во-первых нужно для каждого конкретного поиска нажимать свою комбинацию клавиш. И после ввода подтверждать поиск кнопкой Enter, а потом еще раз Enter чтобы добавить товар в чек.
5. Вы не поняли. Быстрые товары не для всех случаев подходят. Пакеты, кофемашина, яйца и другой товар который всегда есть в наличии и не меняется - ПОДХОДИТ. Для весового печенья, колбасы, конфет и овощей не подходит.
6. Весы с печатью этикеток не подходят для магазина в 60-100 кв.м где 2-3 кассы, но это целесообразно для супермаркета, где вводом кодов SKU, PLU занимается IT-шник, а фасовкой отдельный сотрудник. Уверяю для магазина у дома это нецелесообразно. Опять же если речь идет о весовых конфетах и колбасе. Они не фасуются заранее.
7. Не понял вопрос о экономии на работниках и оборудовании. Совсем не понял. При чем здесь экономия. Очень глупое утверждение.
C комментариями user1137881 тяжело не согласиться, но если речь идет о супермаркете. Здесь же почти весь весовой товар лежим за спиной у продавца. Речь идет о заприлавочной торговле, а не о супермаркете. Весы с печатью этикеток есть, проработала эта схема ровно пару недель, пока я лично занимался кодами PLU, продавцам проще приклеить ценник на котором написан артикул.
Итак если всем все понятно, то еще раз опишу проблематику:
Все проблемы появились совсем недавно, после обновления на Розницу 2.3.9 :
1. При сканировании обычного штрихкода иногда срабатывает появление окна "Поиск номенклатуры по штрихкоду"
2. Если курсор стоит на количестве в чеке, то при быстром нажатии "2, Enter" (любая цифра), выскакивает окно "Поиск номенклатуры по штрихкоду"
3. Товар добавляем через поиск нажатием кнопки INS или "Стрелка вниз", далее с консоли быстро вводим артикул 14375, но в поле поиска оказывается 1375 или 175, потому что сразу после ввода первого символа начинается поиск, система подвисает и далее в поле поиска оказывается 1375 или 175. Потом все стираем и медленно вводим пять цифр. после этого Ctrl+Enter и товар в чеке.
4. По поводу Ctrl+Enter тоже проблема недавно появилась. Если быстро нажать то ничего ен происходит. Надо нажать Ctrl, подождать секунду и только потом не отпуская нажать Enter.
Раньше такого не было. Сервера на процессорах G6400, i3, i5, i7. Памяти везде не менее 16Гб. Везде SSD. Везде одинаково работало быстро, потом после обновления начались одинаковые проблемы. и одинаковые жалобы от персонала.
Значит проблема не в железе, не в людях, не в отсутствии SKU.
Проблема в 1С. И тут хочу процитировать одно нововведение, которое описано в обновлении 2.3.9.37 новое в версии.
цитата:
"Переработан механизм поиска по штрихкоду. При сканировании штрихкода происходит одновременный поиск по всем местонахождениям этого штрихкода в базе".
Товар добавляем через поиск нажатием кнопки INS или "Стрелка вниз", далее с консоли быстро вводим артикул 14375, но в поле поиска оказывается 1375 или 175, потому что сразу после ввода первого символа начинается поиск, система подвисает и далее в поле поиска оказывается 1375 или 175. Потом все стираем и медленно вводим пять цифр. после этого Ctrl+Enter и товар в чеке.
посмотрите видео, которое вам для общего развития оставил
и не говорите глупостей
Здесь же почти весь весовой товар лежим за спиной у продавца.
Речь идет о заприлавочной торговле, а не о супермаркете.
а еще раньше было 500чеков в день :)
очередь из 10 человек
5 серверов, 25 рабочих мест -- это у всех так ?
т.е вместо решения проблем управления в магазине вы валите все на 1с
даже не так. на ХАКЕРа , который ну ничего не понял :)
и на несчастную клавишу Insert - которая не справляется с вашими желаниями
Не верно утверждение, что продавец захотел в туалет, а его никто не подменяет, поэтому он переминаясь с ноги на ногу совершает ошибки при добавлении товаров в чек.
я даже не утверждал
и не намекал о туалете :)
речь вообще-то может быть и о обеденном перерыве - ее подменили те ,
которые ранее или позже будут обедать
Переработан механизм поиска по штрихкоду. При сканировании штрихкода происходит одновременный поиск по всем местонахождениям этого штрихкода в базе
При сканировании штрихкода вы не используете Insert
например: создание карты по шаблону или запись номера телефона в чек продажи) отображается окно выбора действия. Разработана форма "Анализ штрихкодов", в которой осуществляется заполнение шаблонов штрихкодов, проверяется пересечение диапазонов шаблонов штрихкодов, проверяется соответствие найденного объекта шаблону штрихкода, происходит поиск дублей штрихкодов.
вы не знали, что 1с не только обновляется, но и добавляет проблем :) ?
XAKEP снова ничего не понял.
Объясняю.
Момент первый. По видео. Я посмотрел видео, вы уволены ! С такой скоростью обслуживания вы можете претендовать на наш удаленный магазин в деревне Путрушка в 150 км от города.
Момент второй. Магазинов за неделю меньше не стало. И серверов тоже меньше не стало. И я начал подходить к самой сути ваших умозаключений. У вас видимо всегда 1С тормозит и медленная работа у вас в норме. Поэтому вы не понимаете сути проблемы.
Вы не поняли, при чем тут сканирование сканером и INS ?
Объясняю.
При сканировании существующего в базе штрихкода выскакивает может появиться рандомно окно "поиск номенклатуры по штрихкоду".
Ну что тут не понятного ?
Третий момент. В третий раз объясняю, что поиск по F11 будь то любая другая комбинация клавиш НЕУДОБНА.
п.3.1. Там так же работает все медленно !!!
Четвертый момент. надеюсь эту формулу вы хоть поймете. 5 магазинов, в каждом по четыре продавца и оператор. Всего 25 сотрудников, которые на протяжении многих лет работали и скорость работы 1С всех устраивала. После обновления на 2.3.9 массово начали жаловаться на то что скорость добавления товаров в документы 1С стала медленнее.
- да операторы тоже жалуются на медленный поиск. Да, это новые вводные.
В продуктовых магазинах нельзя делить количество чеков на время. Потому что днем покупателей мало, основной поток людей идет вечером с 20 до 22 часов.
Рекомендую зайти в любой супермаркет днем и вечером, часов в 9. И Все поймете.
Про поиск я спросил, потому что, вы очень уверенно продвигаете его использование, поэтому я подумал, что может там есть что-то чего я не знаю. При этом каждый раз я писал что любой поиск который скрыт по F11, очень неудобен.
И на видео видно что это долго и неудобно.
(26) Пояснение к видео.
1. Вначале ввожу код 14261, но в поиск попадает 1261. Потом стираем и вводим медленно 14261
2. курсор стоит на количестве. быстро нажимаем 3, Enter. Появляется окно "Поиск номенклатуры по штрихкоду". Закрываем, и делаем все медленно 3, Enter.
или тетя 50лет не знает, где найти нужную комбинацию ?
а когда происходит сложная оплата - карточка и наличные
у ваших продавцов нет жалоб, что это медленно :)
ведь на этом участке тете все равно очередь, патамучта ошибка стоит ей ее же денег.
я понял! надо два монитора на кассу поставить, что ж вы раньше то не сказали.
только после F11, F4, Ctr+8 надо еще два раза вокруг себя повернуться, подпрыгнуть, присесть, плюнуть чрез плечо и прочитать заклинание. 1С совсем не причем.
(26) Вот так выглядит очередь. командир взвода дает 10 минут на покупки 30 подчиненным.
Теперь ВАМ понятно, что нет времени жевать сопли с вашим расширенным поиском ?
если я установлю последнюю версию розницы и торможения не будет
начнете изучать теорию ?
вместо методом "тыка" или "по старинке" работать ?
фотку выложили , преувеличили число
о весовом товаре, как будто не услышали
т.е. у вас при наборе заклинаний не нужно ?
или стыдно признаться, что в моем случае ошибок нет
ваше пояснение к видео.
1. Вначале ввожу код 14261, но в поиск попадает 1261. Потом стираем и вводим медленно 14261 2. курсор стоит на количестве. быстро нажимаем 3, Enter. Появляется окно "Поиск номенклатуры по штрихкоду". Закрываем, и делаем все медленно 3, Enter.
__________ну просто фантастика :) да ?
___________
вместо
F11
F4
Ctr+8
нужный артикул
и без ошибок.
( у вас при вашей методике ищет во всех местах базы )
при том, что вам нужен артикул (!) - дошло наконец ?
(32) еще раз объяснить что 5 баз на 5 серверах с одинаковыми симптомами после добавления разработчиками нового механизма поиска ? вы весь свой опыт в комментариях изложили ? Или будут еще бесполезные советы ?
Подскажите контакты, нам как раз вангующего по наколкам специалиста и не хватало все это время.
(33) Этому товарищу объяснять бесполезно. К сожалению 1С забила на производительность болт, с переходом с Розницы 2.2 на 2.3 упала производительность РМК, причем вполне заметно. При каждом обновлении начинаешь ждать прямо с утра звонков с жалобами, сначала из магазинов, а потом уже и от самих заказчиков. Какого-либо разумного варианта решения проблемы, кроме доработки 1С, я не вижу.
В вашем случае, скорее всего, есть смысл написать свой поиск, причем сделав его прямо на форме, чтобы лишний раз не нажимать кнопки.
Ну или продумать альтернативные пути поиска товаров. Например, делали так в одном магазине, для весового товара печатали отдельный лист со ШК с весом в 1кг. А РМК доработали так, что при получении позиции со сканера с весом ровно 1кг оно открывало отдельное окно для ввода веса с фокусом на поле ввода.
Хотя я бы все таки рассмотрел вариант с весами с печатью этикеток. Очень хороший опыт есть у пивняков, там вообще основной ассортимент, кроме пива, весовой. Товар заводится в весы и назначается на быстрые клавиши, также печатается своя вкладка на клавиши с указанием наименований. Потом продавец просто кладет товар на весы и нажимает кнопку. Вполне удобно и эффективно. Ну и все, что можно расфасовать - нужно расфасовать. Поднимите статистику, посмотрите какой вес обычно берут покупатели и нафасуйте вариантов.С печеньем, конфетами и всем, что долго хранится - очень хороший вариант.
с переходом с Розницы 2.2 на 2.3 упала производительность РМК
у вас лично ?
а потом окажется, что у вас дубли или полнотекстовый поиск
производительность это относительное понятие
но вот системные требования совсем другой вопрос
посмотрите, какая минимальная платформа нужна под последнюю розницу
с вытекающими отсюда последствиями .
вот вы сообщали о
__________________________________________________________
Хотя я бы все таки рассмотрел вариант с весами с печатью этикеток.
___________________________________________________________
но, у автора вопроса "не супермаркет" и накладно с его точки зрения
так что виновата 1с
и этот ХАКЕР , как вы думаете
-------- Этому товарищу объяснять бесполезно.......
так помогите вы найти решение проблемы :)
мой совет использовать стандартный поиск и расширенный - не подходит
(41) Языком трепать - не мешки ворочать. А производительность хорошо видна, когда ставишь рядом два одинаковых POS, с одинаковой базой и на одном обновляешь ее до 2.3. А потом думаешь, что сказать заказчику. Предложение купить новое железо не прокатывает.
потому что, кроме написания кода и обслуживания 1с
нужно знать, что такое база данных и последствия запросов типа " а мне так удобней "
я уже не говорю о плохой организации управления и учета в самой компании
во первых, грамотнее тестить на клиенте.
во-вторых, надо в базу добавить: 10000 накладных и столько же установок цен, 3000 отчетов о розничных продажах, 300000 чеков. чтоб документы были заполнены номенклатурой, а так же приходные и расходные кассовые ордера. и т.д.
протестить это дело на пеньке а не xeon.
вот оно че :)
только дело еще вот в чем
10000 накладных и столько же установок цен, 3000 отчетов о розничных продажах, 300000 чеков
пусть даже и по миллиону .
расширенный поиск ищет в конкретно указанном столбце :
артикул, часть артикула,часть штрих-кода . при этом сервер смотрит,
к чему клиент часто обращается и какие
столбцы индексируются ,
соответственно, если вы ищете не по одному столбцу,
а по 10 при наличии от 100 000 строк - вы его загружаете "по полной"
в чем проблема на месте проверить
F11+F4+Ctrl+8 для полного артикула
или F11+F4+Ctrl+4 для части артикула
и узнать - причина в железе или в методике работы :)
Обновил 10 касс до 2.3.9.42.
Одна из них на ФФД 1.2 и плюсом на ней селерончик простенький, но SSD.
Так вот жалоба с него есть от продавцов на ввод цифр в РМК: жует, пропускает при быстром наборе.
Но не в поиске, а при вводе цены - бьют некоторые товары "Товар на сумму", сделанный быстрыми товарами на пробел на клаве, и РМК при нулевой цене выдает окошко для ввода цены, вот тут тупня. Т.е. как бы проблема не в поиске, а на этапе ввода с клавы.
Остальные пока не жаловались, но там компы пошустрее.
после обновления на 2.3.9.42 и у меня появилась проблема с торможением поиска в 1с, причем только пока что на 1 кассе из 6, платформа 8.3.18.1520, тонкий клиент, серверная, postgresql 12.6-6.1С. в скриншоте поиск слова молоко
Оказалось для решения проблемы выделения введенных символов и их последующего затирания надо в свойстве поля "Обновление текста редактирования" указать "Не использовать")