Comments 57
Будьте осторожны — штрих-код code 128 крайне ненадежный и очень размерный.
Для контроля правильности считывания code 128 простой CRC не достаточно.
П.С. Из личного опыта.
Для контроля правильности считывания code 128 простой CRC не достаточно.
П.С. Из личного опыта.
Более того, CRC для порядковых номеров будет откровенно неудачным решением, ведь это получается очень короткая последовательность байт, где старшие 2-3 байта нулевые или такие же, как у прошлого идентификатора. Какой-нибудь простой Fletcher-16 вообще может начать давать коллизии на ровном месте. Тут надо не лениться использовать хеш-функцию, при чем лучше даже от строкового представления.
Murmur2 на 64 бита (std::hash)…
вообще, у объектов в системе есть свой внутренний идентификатор. (в БЭСТе — 11-значный числовой ID, в 1с — 9-символьный IDDOC/ID в 7.7 или почти стандартный UID в 8.*, в Навижене тоже есть, навскидку не помню название). ИД вполне нормально ложится на штрихкод. видел и сделанные на основе EAN'а, и делал на code39 — более 10 лет проработало без всяких проблем, без всяких хэшей.
В QR те же до 30% избыточной информации закладывают
Как то слабо после прошлых частей. Где накал страстей, где экшен?))
Блин, какой ты тупой, а? – улыбнулся Стас
Слишком одннобразно. Всё "положительные" герои считают обвинения в тупизне чем-то весёлым. Не "сказал с издёвкой", не "закричал", а именно "улыбнулся". Ещё и похвалу за это регулярно получают, а это, конечно, полностью оторвано от жизни.
Видимо у всех положительных героев было крайне агрессивное детство. Сочувствую, конечно, но скучновато.
Какой бред. Придумали отдельную бумажку, почему то перенесли все проблемы использования оригинальной формы на эту бумажку и потом героически их решали. Какие такие дублирующиеся строки, если это не официальная форма? Какие такие версии если это отдельная и не официальная бумажка? Зачем их сравнивать?
Сравнивать их, что бы понять — нужно ли разобрать заказ (200 позиций) и собрать ещё раз, по новой бумажке (количество-то могло измениться, а насколько — не ясно!). Если количество изменилось — то нужно. В идеале нужно знать, какие позиции поменяли количество, тогда можно весь заказ не пересобирать, а только перепроверить изменения.
Сравнить две цифры в их новой бумажке они не в состоянии?
Если они сами делают эту форму, то могут и показать изменённые позиции.
Если у них это постоянный кейс со сменой количества, то проблема на уровне склада не решается.
Каким образом сравнение двух цифр поможет? Вы учитывайте, что позиций 200. И как минимум 50 из них поменялось. В состоянии ли они сравнить 50 строк с одной стороны и 100 с другой (потому что из одной стало две или больше)? Да, разумеется в состоянии. Просто это долго, а вся остальная работа будет стоять. Вот герои рассказа и придумывали, как упростить процесс.
Если они сами делают эту форму, то могут и показать изменённые позиции
Могут. Там началось с того, что форма типизированная и менять нельзя. Т.е. нельзя показать (только на экране). А потом у них мысль ушла в сторону штрихкода и они забыли обдумать вариант с печатью изменений прямо в документе. Лично я бы тоже не штрихкодом решал, это скорее костыль, чем решение, но сама их логика в целом понятна.
а какое, в общем, дело кладовщику до «партий списания», если он один хрен в данном случае работает «по количеству»? ему нужна одна сводная накладная. придумывать тоже ничего не надо — в нормальных учетных системах это давно сделано.
Никакого. Ему принесли, он собрал. А потом принесли ещё раз, сказали, новая версия. Ему дела никакого, но собрано должно быть по новой версии.
а никакой «новой версии» с точки зрения кладовшика не существует. раньше «деталей X» было 20 в трех строках, сейчас их 20 в 20 строках. Но их осталось 20. Если же он ведет учет деталей по партиям, по серийным номерам и т.п.- то ему надо не «версионировать», а разбирать собраный заказ, и собирать заново «с нуля». ну и по-хорошему, оплачивать «первичную сборку, разукомплектацию заказа, размещение по местам хранения» кладовщику должна бухгалтерия.
Но их осталось 20
Вы уверены? Откуда? А кладовщик был не уверен, с этим вопросом и пришел — изменилось количество или нет. Ему сказали — нет, количество не изменилось. Это же написано в рассказе, почему бы вам просто не перечитать?
У них есть какая-то версия. Она распечатана на бумаге.
Потом её меняют, возможно не один раз, и печатают снова. От чего изменения считать и показывать?
Потом её меняют, возможно не один раз, и печатают снова. От чего изменения считать и показывать?
Между прошлой бумагой и текущей.
а какая бумага «прошлая»? ту, которую напечатали самой первой, и успешно потеряли? вторая, по которой собирал кладовщик-комплектовшик? третья, которую зажевал принтер? четвертая, которую решили сразу же исправить потому, что в ней отображалась некорректная цена списания, возникшая из-за того, что девочка Маша перепутала при оприходовании количество и цену? пятая, которую использовали в туалете из-за того, что в диспенсеры не поклали полотенец, руки вытирали туалетной бумагой, ну а для других целей использовали накладные?
а какая бумага «прошлая»?
вторая, по которой собирал кладовщик-комплектовшик
Вероятно именно её он и принес. Какую конкретно бумагу принес кладовщик, в рассказе не сказано, но вероятно ту, по которой сам собирал. Откуда у него использованная для туалета, к чему вообще такие предположения?
ну а как «герои» знали, с какой бумагой нужно сравнивать «крайнюю» («новую бумажку», в которой «мы немного поменяли» — и, возможно, не последний раз) версию?
И то, что он принес какую-то бумагу, по которой собирал — совсем не значит, что она вообще адекватна электронному документу (это уже чисто из практики — вороватый кладовщик давал «бумажные» задания на сборку, вообще не зарегистрированные в системе.)
И то, что он принес какую-то бумагу, по которой собирал — совсем не значит, что она вообще адекватна электронному документу (это уже чисто из практики — вороватый кладовщик давал «бумажные» задания на сборку, вообще не зарегистрированные в системе.)
Там проблема несколько в другом. У нас в CRM есть WorkOrder с множеством Segments/PartInvoice. Каждый из Segment/PartInvoice включает список необходимых Parts для выполнения работы. Т.е. первое — дупликаты Parts возможны между Segments. Вторая проблема в том что некоторые Parts могут продаваться по разной цене (warranty vs sell), поэтому в PartInvoice они идут отдельными записями (снова дупликаты). Дальше лажа может быть ещё веселее, типа Segment выполняется несколько дней и цена на Part изменилась (снова новая запись), либо когда делают Transfer между складами (тут может быть как разница в налогообложении [разные LocationTax] так и разница цены между складами [акция]).
Документ который отправляется заказчику и в Кредитное Агенство содержит разбиение по Segment и по позициям\ценам. Кладовщику эта информация не нужна, но судя по всему, кладовщика из истории заставляют работать именно с таким документом. То что предлагают сделать в истории — сводную форму специально для кладовщика, которую будут по ИД мапить с формой для бухгалтера.
Документ который отправляется заказчику и в Кредитное Агенство содержит разбиение по Segment и по позициям\ценам. Кладовщику эта информация не нужна, но судя по всему, кладовщика из истории заставляют работать именно с таким документом. То что предлагают сделать в истории — сводную форму специально для кладовщика, которую будут по ИД мапить с формой для бухгалтера.
То что предлагают сделать в истории — сводную форму специально для кладовщика, которую будут по ИД мапить с формой для бухгалтера.
Отличное решение — рабочая инструкция/форма для конкретного исполнителя.
В принципе этот вопрос решен на 80 строке 165-строчного текста:
— Может, нам унифицировать бумажки? – вдруг сказал Стас. – Ну, для внутреннего пользования.
остальные метания — частный случай решения задачи.
Code128 – там даже буквы писать можно, и они кодируются, и раскодируются, и читаются любым сканером современным.
Наивный чукотский юноша не пробовал работать с этим Code128 вживую.
Вообще, ребята, конечно, фееричные.
про то, что у каждого объекта в системе существует свой идентификатор — они не слышали.
о версионировании — не слышали.
о сводных документах — не слышали.
о видах складского учета — не слышали.
вроде на 1994 год не похожет (они уже про планшеты знают, про ТСД). Просто осьминоги, чтоль?
про то, что у каждого объекта в системе существует свой идентификатор — они не слышали.
о версионировании — не слышали.
о сводных документах — не слышали.
о видах складского учета — не слышали.
вроде на 1994 год не похожет (они уже про планшеты знают, про ТСД). Просто осьминоги, чтоль?
Зачем контрольную сумму (или хэш) хранить именно в штрихкоде? В штрихкоде можно хранить номер записи таблицы (идентификатор), а уже в самой таблице и версию документа, и хэш и кучу всего другого.
видимо, они хотят идентифицировать не только документ, но и версию документа, которую распечатали на бумаге. В ШК вполне можно запихать номер версии, только это особого смысла в моих реалиях не имело (документ-номер страницы-дата-время-пользователь печатались в нижнем колонтитуле документов).
Они это обсуждали, решили, что не подходит.
Так обсуждали штрихкод, привязанный к документу, а не к какой-то специальной таблице с дополнительными данными. Я к тому, зачем в учётной системе нужен штрихкод, хранящий все данные непосредственно в себе? В магазинах да — это актуально, чтобы каждые весы не писали данные в базу. Но в учётной системе мы всё равно работаем с БД, изменяя документ. И при проверке нужно будет прочитать из БД данные документа. Так зачем использовать штрихкод как хранилище информации вместо того, чтобы хранить в нём только идентификатор хранилища информации?
А презерватив и Das Experiment это типа спиноффы?
У автора сейчас идёт ~2 рассказа. + пара отдельных, не входящих ни в какой цикл рассказов(хотя, думаю, связанных с каким-то из рассказов, но лишь в рамках вселенной рассказа. К примеру, про то, «как программист уходит на пенсию» — похоже, будущее Сергея из текущего рассказа)
В обоих рассказах гг — Сергей, но отличаются детали.
В обоих рассказах гг — Сергей, но отличаются детали.
Краткий пересказ рассказов, по тому, как я всё помню.
В одном рассказе этот Сергей директор по качеству(и ИТшник, конечно), всех посылает во все щели, орёт, ругается матом, дерзит, имеет связи с Светланой Юрьевной(или как там директора зовут) и обычно разоблачает разные дебильные вещи\ситуации, вроде расчётов выгоды ВСЕХ предложений, систем мотиваций и прочее-прочее. Этакий злобный, сквернословящий, но в то же время понимающий всё супер-герой. Связь между главами есть, но каждая глава — это как отдельный целостный рассказ. В каждом рассказе приключается какая-то беда и Сергей всем раскрывает глаза, что сделали не так и почему. Почти в каждой такой главе есть своеобразный посыл, мораль.
Во втором рассказе Сергей(собственно мы сейчас находимся под очередной частью этого рассказа) — просто ИТшник, который погряз в рутине, дебилизме системы. Ему ставят идиотские задачи, и он, посредством ворчания и капания на мозги своему руководителю, пытался решать эти проблемы. Пытался убедить людей в том, что они что-то делают неправильно. Его непосредственный руководитель — молодая и неопытная девушка, с которой он регулярно спорил. У этого Сергея есть семья в виде девушки, которая его подпиливает из-за того, что «амбиций» и «понимания» у гг море, а на зарплате это не отображается. Но, в один из дней произошел атас — директор своим руководителям сказал, что у них на складе образуется дыра. Бумаги не сходятся с тем, что на самом деле на складе. В бумагах всё хорошо, а на складе на самом деле меньше всего — обворовывают, вроде. И этот директор поручил своим руководителям разобраться. Но проблема не нова и с ней боролись уже 2 других руководителей пару лет назад и на этот раз дали другому руководителю, не помню кому. Затем от своего руководителя Сергей узнал про это, про то, что это важный проект. И, путём размышлений и болтаний со Стасом(его напарник) он пришел к выводу, что решением этой проблемы должны заниматься инженеры, а не менеджеры. И, в очередной раз поругавшись с своей руководительницей, во время чего наш гг в очередной раз задел эту барышню, отчего та пригрозила, что в этот раз он точно будет разбираться с директором по поводу всех этих срачей. И, собственно, после чего его пригласили на аудиенцию с директором компании, в ходе беседы с которым Сергей высказал свою идею — «это проект для инженера, а не менеджера» и, когда директор согласился, Сергей сам от себя не ожидая вызвался делать этот проект по устранению утечек со склада.
Собственно, после этого дела его назначили эдаким серым кардиналом этого проекта, поскольку обижать директора под надзором которого этот проект уже в бумагах не захотели.
Собственно, теперь наш гг решает эту проблему со складом. Один или два шага уже было предпринято, теперь назревает третий.
Не знаю, зачем я всё это расписал, но может кому станет понятнее.
Во втором рассказе Сергей(собственно мы сейчас находимся под очередной частью этого рассказа) — просто ИТшник, который погряз в рутине, дебилизме системы. Ему ставят идиотские задачи, и он, посредством ворчания и капания на мозги своему руководителю, пытался решать эти проблемы. Пытался убедить людей в том, что они что-то делают неправильно. Его непосредственный руководитель — молодая и неопытная девушка, с которой он регулярно спорил. У этого Сергея есть семья в виде девушки, которая его подпиливает из-за того, что «амбиций» и «понимания» у гг море, а на зарплате это не отображается. Но, в один из дней произошел атас — директор своим руководителям сказал, что у них на складе образуется дыра. Бумаги не сходятся с тем, что на самом деле на складе. В бумагах всё хорошо, а на складе на самом деле меньше всего — обворовывают, вроде. И этот директор поручил своим руководителям разобраться. Но проблема не нова и с ней боролись уже 2 других руководителей пару лет назад и на этот раз дали другому руководителю, не помню кому. Затем от своего руководителя Сергей узнал про это, про то, что это важный проект. И, путём размышлений и болтаний со Стасом(его напарник) он пришел к выводу, что решением этой проблемы должны заниматься инженеры, а не менеджеры. И, в очередной раз поругавшись с своей руководительницей, во время чего наш гг в очередной раз задел эту барышню, отчего та пригрозила, что в этот раз он точно будет разбираться с директором по поводу всех этих срачей. И, собственно, после чего его пригласили на аудиенцию с директором компании, в ходе беседы с которым Сергей высказал свою идею — «это проект для инженера, а не менеджера» и, когда директор согласился, Сергей сам от себя не ожидая вызвался делать этот проект по устранению утечек со склада.
Собственно, после этого дела его назначили эдаким серым кардиналом этого проекта, поскольку обижать директора под надзором которого этот проект уже в бумагах не захотели.
Собственно, теперь наш гг решает эту проблему со складом. Один или два шага уже было предпринято, теперь назревает третий.
Не знаю, зачем я всё это расписал, но может кому станет понятнее.
А у меня просьба. Под заголовком где-нить в начале текста указывайте, что это глава такая-то. А то не понятно, то-ли новая глава, то-ли рассказик…
— Ну да… — задумчиво сказал Стас. //Стас
— Какие еще варианты есть? //Сергей
— Может, нам унифицировать бумажки? – вдруг сказал Стас. – Ну, для внутреннего пользования. //Стас
— В смысле? Как? Разве можно заменить типовую форму, принятую в каком-нибудь законе? //???
— Нет, ты не понял. Смотри сам. Вот у него сейчас какая накладная была? – спросил Сергей. //Сергей
Вот тут нестыковка, по-моему. Про замену формы в законе кто спросил? И кто ему ответил?
Всем спасибо за комментарии про code128, версионирование и т.д.
Есть просьба из двух пунктов:
1. не ассоциируйте происходящее в книге с ее автором, т.е. со мной;
2. не думайте, что я считаю, будто герои всегда правы, и все делают правильно.
Они вполне могут ошибаться. Это ж не сказка, в которой все идет, как по маслу.
Есть просьба из двух пунктов:
1. не ассоциируйте происходящее в книге с ее автором, т.е. со мной;
2. не думайте, что я считаю, будто герои всегда правы, и все делают правильно.
Они вполне могут ошибаться. Это ж не сказка, в которой все идет, как по маслу.
От дырки в заборе перешли к приделыванию костылей к костылям. Надеюсь дальше автор объяснит зачем так резко повернул сюжет.
— Во-первых, дорого. – начал Стас. – Сам посуди. Обычный ТСД, с маленьким экранчиком – не годится, хотя он и не дорогой.
— Почему не годится?
— Ну ты попробуй сам с таким экранчиком пособирать две сотни позиций.
На экран выводится номер места и кол-во сколько брать. Чего там на экранчике не уместится? Да и большой экран — совершенно не проблема. Мы ещё в начале двухтысячных коннектили сканер штрихкодов к КПК с PocketPC. Самое сложное было — изобрести крепление на предплечье :-)
нет у них адресного хранения. не доросли ишшо… осьминоги жеж.
Ну что за дичь? В очередной раз одни, непонятно откуда взявшиеся костыли решаются другими, еще более дикими костылями. Вся проблема в том, что если взять любой профессиональный софт, то там всё это уже давно вылечено и оптимизировано. Так что получается, что герои постоянно работают с какими-то самодельными решениями и поэтому им приходится изобретать велосипеды на костыльной тяге.
Это не дичь, это преломленные пониманием воспоминания автора о трудовых буднях…
К сожалению, должен отметить, что эти воспоминания зачастую являются реальными у нас в компаниях и на производстве.
Увы, не все работают в «самых современных» компаниях, где все в облаке, все дорабатывают мгновенно и все умеют или имеют финансовую возможность дорабатывать решения вендоров, внедрение которых в голом виде зачастую требует более существенных переделок бизнес-процессов, чем внедрение костыля.
Увы, не все работают в «самых современных» компаниях, где все в облаке, все дорабатывают мгновенно и все умеют или имеют финансовую возможность дорабатывать решения вендоров, внедрение которых в голом виде зачастую требует более существенных переделок бизнес-процессов, чем внедрение костыля.
А что, троллейбус-буханку никто так и не запостит??? Может я не уловил суть проблемы, но решение мне видится как забивать болт в рельсу хрустальным сервизом… Почему весь этот гемор нельзя ещё на этапе изменения в базе и перед распечаткой сверять и давать только разницу на распечатку — 2 строки: что забрать и что добавить.
А что за книга в 7 главе о системном мышлении?
Ну тут по хорошему надо совсем не штрихкод вводить. Надо осознать, что внутри склада происходит гораздо больше действий, чем отображено в модели склада используемой в бухгалтерии. И складу нужна собственная система автоматизации основанная на модели отражающей реальные движения внутри склада. И складскому работнику нужны его собственные документы, просто эти документы можно автоматически генерировать на основании входящих бухгалтерских документов. И так же автоматически генерировать бухгалтерские документы на основании внутрискладских. Ну а мелкое исправление в бухгалтерском документе вполне может быть основанием для большого количества внутрискладских движений — и эти движения должны быть отражены в внутрискладских документах (да, потому что люди будут работать и эта работа будет оплачена). И по факту склад может быть перегружен из-за постоянных пересортировок, а для внешнего наблюдателя — склад работает очень медленно, но причина в документах не видна.
Конкретная реализация внутрискладских документов уже может быть выражена в виде листа действий грузчика.
Взять лоток типа 123, пройти в 3 проход до 8 стеллажа и с 4 полки взять 3 единицы товара ХХХ (фото одной единицы), после этого пройти до 12 стеллажа и с 4 полки взять 1 единицу товара УУУ (фото), лоток вынести к окну выдачи 5.
Взять грузовую тележку инв. номер 12345 с места хранения АБВ, пройти до… и т.д.
Или у грузчика могут быть очки дополненной реальности с камерой.Тогда он может получать указания динамически — куда идти, что брать, сколько единиц. Это не требует большого разрешения и качественной графики — одна-две текстовых строки на 20-30 символов, возможно голосовой ассистент-навигатор.
Ну и если денег много, склад огромный, номенклатура гигантская, движение по складу бешеное — смотри склад Амазона ;)
Конкретная реализация внутрискладских документов уже может быть выражена в виде листа действий грузчика.
Взять лоток типа 123, пройти в 3 проход до 8 стеллажа и с 4 полки взять 3 единицы товара ХХХ (фото одной единицы), после этого пройти до 12 стеллажа и с 4 полки взять 1 единицу товара УУУ (фото), лоток вынести к окну выдачи 5.
Взять грузовую тележку инв. номер 12345 с места хранения АБВ, пройти до… и т.д.
Или у грузчика могут быть очки дополненной реальности с камерой.Тогда он может получать указания динамически — куда идти, что брать, сколько единиц. Это не требует большого разрешения и качественной графики — одна-две текстовых строки на 20-30 символов, возможно голосовой ассистент-навигатор.
Ну и если денег много, склад огромный, номенклатура гигантская, движение по складу бешеное — смотри склад Амазона ;)
для этого («лист действий грузчика») нужна уже адресная система хранения, к которой (даже без полноценной WMS) готовы (в первую очередь организационно и интеллектуально) далеко не все. а полноценная WMS и сама денег стоит, и оборудования требует (которое стоит денег), и на этапе внедрения бывает всякое (включая саботаж)
могут быть очки дополненной реальности с камерой— в реальности все попроще — голосовой модуль. В России вторым востребованным языком для голосового модуля является узбекский. (кстати, поговаривают, что русские грузчики работу под «голосовым управлением» не выдерживают, увольняются массово...)
Адресная система хранения добавляет дополнительные требования к сотрудникам и их контролю. Особенно на этапе внедрения…
Если я правильно понял посыл, может быть вариант, тоже не дорогой — с подсветкой нужных полок/элементов диодной лентой/лампочкой/этикеткой.
очки дополненной реальности с камерой.
— в реальности все попроще — голосовой модуль.
Если я правильно понял посыл, может быть вариант, тоже не дорогой — с подсветкой нужных полок/элементов диодной лентой/лампочкой/этикеткой.
Да, поэтому на одном известном мне крупном (более 25 тыс. кв.м, 10 тыс. SKU) складе для узбеков — голосовой ввод, а для неузбеков — обычная работа с ТСД.
Sign up to leave a comment.
Волшебный штрихкод