ТИС 7.7. Хочу посоветоваться Учет работы сборщиков товара!!!
 

ТИС 7.7. Решили анализировать работу сборщиков чеков и оптовых накладных.
Но пока надо только по чекам ККМ. Ессно они Штрих-кодированные. В штрих-код чека входит его номер дата и код магазина (поскольку их 3).
Сборщики имеют бейджики со Штрих-кодами.

Сделал файл логов (номер чека, дата чека, время чека, количество строк в чеке). Это справочник. При пробитии чека в этот справочник добавляется информация. Чеки на возврат ессно пропускаются.

А вот дальше как-то не очень понятно.
Клиент отдает сборщику чек. Затем планирую так:
1. Сборщик ручным комовским сканером сканирует чек
2. Сборщик сканирует свой ШК на бейджике и идет собирать товары для чека.
3. После того как клиент распишется на чеке сборщик еще раз сканирует чек.

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

Что напрягает сразу: все-таки нет четкой уверенности что чеки привяжутся к сборщикам. Мало ли что - перепутал последовательность сканирования, забыл отсканировать свой ШК, второй раз не отсканировал ШК чека. Еще напрягает то, что если за день примерно 300 чеков, то уже за месяц файлики прилично вырастут в объеме и искать там что-то а тем более писать в найденное - скорость будет не ахти.
ПОДСКАЖИТЕ КТО ЧТО ДУМАЕТ НА ЭТУ ТЕМУ!!!

UP Господа!!! Такая возможность попинать, попенять и прочие по....!!! Давайте!!!

"А хорошо бы через пруд построить каменный мост, и чтобы по обоим сторонам моста были бы лавки, а в них сидели купцы и торговали нужными для крестьян товарами".
Цель-то какая всей этой музЫки?

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

Но это так все, поделка на коленке. Постучись лучше к Чучундеру в скайп. Он тебе расскажет как это прально делается, и сколько стоит оборудование.

(3,4) Спасибо. Но у меня есть только ручной сканер - так что буду плавать в этих водах, другой пока не наливают. Цель понятна - учет работы по сборке чеков и позже накладных: кто сколько собрал, сообтветственно - понять сколько надо сборщиков, как каждый из них работает и т.д. Я вот тут подробненько начал все себе расписывать и понял, что файл-то надо использовать для всех один, поскольку потом неизвестно к какому сборщику относится данный чек. [b]Работа с ТСД это супер и Чучундер это супер, но пока я исхожу из того что у меня есть в наличии. ТСД у меня нет.[/b]

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

2(1) Первая и самая серьезная ошибка -
после сборки надо не сканировать чек второй раз, а сканировать сами собранные товары - для контроля того, правильно ли собрано.

7-bma1 Нет у меня штрих-кодирования товаров - поэтому думаю делать как и описал

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

9 - bma1 Спасибо. Но почему не прокатит такой вариант:
Сборщик отсканировал чек, затем себя и пошел чек собирать, сборал, клиент расписался в чеке и сборщик еще раз отсканировал чек. ВОТ И ВСЕ!!! Мне кажется, что все срастется правильно!!!

10-Путевый лист > Сборщику никто не мешает отсканировать чек [b]второй раз[/b] ДО ТОГО КАК он собрал полностью товар по чеку. И твоё времяф окончания сборки получается сущая фикция. Не взлетит

а слабо, чтобы чек закрывал контролер на выдаче товара?
он проверит, что товар собран правильно.
за закрытие неправильно собранного - ломом контролера по башке.
контролер контролирует сборщика

платим за сборку чеко-строк с учетом веса товара

"Правильно ли собрано" надо поручать клиенту: если он согласен - значит правильно. Контролировать - кладовщику - ему за недостачу отвечать.
Вот уже половина "задачи" растворяется в элементарном наведении порядка.
Для "кто сколько собирает" двойного ввода не нужно. Однократного хватит.
Для "за сколько времени и на сколько можно сократить этих дармоедов" придуманная методика никак не поможет: момент второго считывания бэйджика (да и первого то же) целиком и полностью в руках самого "снимающего".

volk13 - Вот я на эту тему тоже думаю.
Helen 1986 - Еще бы контролера, который будет проверять контролера и т.д.
VZ - насчет сократить мне кадется задача не стоит. Сборщики как ни странно сами хотят этого контроля. [b]Сканировать мне кажется все-таки надо в том порядке что я написал -чек в начале-сборщик-чек в конце. [/b]

(15) Еще бы контролера, который будет проверять контролера и т.д.

нафег? схема с одним контролером ваще то типична на 99.9999999% для большинства выдач товара

11-volk13 Да когда сборщик пошел собирать товар - сканера у него нет же. Сканер прикручен к окну выдачи. Если только вообще сразу два раза, но вот тут можно и отловить время при анализе. Типа начал сборку в 10:00, закончил в 10:01 - невозможно это. За халтуру будут бить по голове.
12-Helen 1986 Хочет всего этого еще и начальник склада. Вот собсвенно он в какой-то степени и выступает контролером.
[b]Вопрос делать или не делать не стоит. Вопрос как это более-менее красиво и надежно сделать технически[/b]

Интересно, что дешевле - платить контролеру ЗП или штрихкодирование товаров внедрить...

(18) дешевле - ввести штрих-кодирование и держать контролера

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

Контролировать надо факт а не бумажку. Тем более сборка сборке рознь. Одно дело принести на выдачу какой-нибудь чайник, а другое дело прикатить двудверный холодильник...

19-Helen 1986 Мне важно знать, какой чек собирал какой сборщик. Поскольку полная информация о чеке хранится в архиве чеков - то всегда можно разобраться и с пересортом и по голове настучать - если понятно, кто чек собирал и как это было по времени!!!

Вопрос такой: кроме как замечания Волка о том, что можно отсканировать чек два раза подряд при начале его сборки - есть какие-нибудь видимые глазу подводные и надводные камни такой методики???

Жду пинков и умных советов от Чучундера!!!

Прежде чем делать проект, надо разделить участников на 3 части: активисты, пофигисты и саботеры.
Активисты являются заказчиками и на них можно повестить дополнительные функции. В данном контексте, это отчет с автообновлением о задержки выдачи или автоматическое формирование задач/извещений по e-mail. К примеру, в твоем случае это может быть завсклад или РОП.
Пофигисты - основная масса работников. В кождом из них следует подозревать саботера.
На действия саботеров надо ориентироваться при разработке методов защиты, в первую очередь за счет активистов. Их надо идентифицировать - это прежде всего люди, за которыми устанавливается жесткий контроль или навешиваются дополнительные обязанности. Затем определить, как они могут проект похоронить. И только после этого делать железобетонную защиты.
Одно дело, если кладовщики сами хотят отслеживать свое время, другое - если это хочет директор а кладовщики будут саботировать.

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

24-Lexusss Вот насчет отправки сообщений по е-мейл в каки-то случаях завскладу или управляющему магазином - это интересная мысль. Надо подумать
25 - bma1 Насчет этой самой липучки - ШК менеджера на чек наклеить - мысль тоже интересная. Но не разбирать же потом эти складские корешки чеков за месяц. То есть сканировать-то все равно придется по-любому. И конец сборки тоже фиксировать сканером надо!!!

25-bma1 > Пересорт должны контролировать клиент и кладовщик. У них интересы разные, и если придут к согласию - значит, сборка достоверна.
И нефиг.

2(26) Я лет десять назад подобное писал для швейников. Там не чек а "личный листок", на который наклеивались ш-коды отшитых пакетов-операций. Лист начинался с личного штрих-кода швеи и оканчивался штрихкодом "END". И мастер в конце смены минут за десять сканировал сменную выработку своей бригады (человек 40-50). Листки хранились по три года (и нормально после этого читались, даже слегка потертые, штрих-коды печатали обычным оффисным лазерником). Система примерно такая-же как ты описал. Работает до сих пор...

только VZ нормально рассуждает, Lexuss как всегда фигню городит, а bumu1 ваще кудато в пампасы понесло

пересорт и учет должны вести заинтересованные лица
пересорт - контролирует КЛИЕНТ
кладовщик контролирует пересорт с другой стороны (при выдаче дорогого товара вместо дешевого ответственность несет кладовщик)

кладовщик контролирует попутно и время (автоматически)

Всем - Предлагаю дискуссию временно прекратить. Если конечно есть ну очень конкретные идеи - буду рад. [b]Сделать мне это дело по плану надо к концу этой длинной недели!!![/b]Обязательно отпишусь во всех подробностях. Большое всем спасибо. Вы меня натолкнули на несколько идей. Вроде должно все взлететь!!!

2(29) нет тама кладовщиков. есть сборщик что ходит по складу и собирает отгруз, и ему договориться с клиентом ничто не мешает, тем более проверки на фактический отгруз, из-за отсутствия ш-кодов на товарах, никак не проверяется. а потом по чекам определить кто вместо чайника отгрузил трехметровую плазму не получится никак.

Не вижу смысла в справочнике (файле?) логов. Общий реквизит "ДокументШК" для отгрузочной накладной, кассового чека и т.п. Плюс документ "Сборка" с реквизитами "ВремяНачала","ДокументШК" и "Сборщик".

1. Первый клик по документу. Ищется накладная и ее "Сборка", проверяется на отгрузку (проведенная "Сборка") и на набор (непроведенная "Сборка").
2. Проведенная "Сборка"- пошел [filolog]нах[/filolog]. Непроведенная- проводим. Нет "Сборки"- создаем.
3. Клик по бейджику- и в последний непроведенный док "Сборка" вписан реквизит "Сборщик".

Работы на пару часов (если с перерывами на чай- 3 часа).

Меня в этой истории напрягает "Сборщики как ни странно сами хотят этого контроля". Вместе с начальником склада.
Что, "сны Веры Павловны" ожили? Ну-ну...

Зомби - очень любопытные мысли. Спасибо. Думаю

Зомби - так не пойдет. Это розничные покупателм - люди. Покупатель забрал чек и потом еще ходит по магазину (такое очень часто бывает). Ну и еще разные варианты могут быть - в результате хронология получения товара по чекам не совпадает с хронологией их пробития и все это не работает. Чек №10 идет самым первым непроведенным с точки зрения его сборки, но реально выдается чек под номером 15. [b]Что касается накладной то у меня давно реализован некий журнал сборки-достави, но это пока малость не по теме[/b]

А я бы непосредственно в документ (Чек, Расх.накладная) добавил бы пару реквизитов (Сборщик, Время начала/конца сборки, Статус обработки). Последовательность действий:
1) Первое сканирование ШК на чеке или бланке накладной - следует запрос ШК сборщика (если статус документа позволяет), после чего в документе прописывается сборщик, время начала сборки и статус "в сборке".
2) Второе сканирование ШК на документе - фиксируется время окончания сборки и статус "закрыто".

(36) mr Gilmor. Золотые слова. Парктически также я и делаю, хотя в чек ничего ен пишу. Чеки в конце дня удаляются же. Пишу в лог

36) mr Gilmor - Добавлял я в чек сборщика - ну вот что-то мне не понравилось чеки перезаписывать

37-Путевый лист >Так ты же говорил, что у тебя чеки не удаляются, а в архив чеков уходят. Как архив-то организован? Мы когда-то делали так - чеки после закрытия касс.смены распроводились, устанавливался флаг "архив" и перебрасывались на дату типа "десять лет назад". Тогда и все параметры сборки можно было в чеках-же и хранить.

39-mr Gilmor Архив чеков - это внешний файлик, который записывается ТЗ с информацией по всем чекам за день. И так каждый день. Потом я уже этим архивом пользуюсь для анализа работы продавцов-консультантов например. Разницы между справочником логов и реквизитами документа я особо и не вижу