| Регистрация Правила Главная форума Поиск |
| 0
- 04.01.2021 - 20:22
|
Продолжение бложика про складские дела, WMS и мысли о великом (ну то есть обо мне)... зачем это все: Зачем? Ну как обычно: потешить ЧСВ, потрепаться да и просто так... Может кому и полезно будет (хотя это вряд ли, но тогда буду музейным мамонтенком) Предыдущие ветки здесь: 0.5офф * (6): I'll be back или Cкромность украшает когда нет других достоинств... 0.5офф*5: I'll be back или Cкромность украшает когда нет других достоинств... 0.5офф*4: I'll be back или Cкромность украшает когда нет других достоинств... 0.5офф*3: Терминатор-жопик I'll be back Cкромность украшает когда нет других достоинств... 0.5офф*2: Терминатор-жопик I'll be back Cкромность украшает когда нет других достоинств... ..а самую первую ветку админы покоцали, типа устаревшая была...     | | |
| 81
- 02.03.2021 - 00:21
| ..нужную зону. тут система думает/считает что выдать сборщику в пул заданий, общее количество и заказов и задний может быть достаочно большое, разная приоритетность направленйи доставки, клиентов, приоритетов самих заказов, датавремяотгрузки итд, порядка 11 критериев приоритетности/сортировки.. Система подумала малость и выдала сборщику на ТСД пул заданий | | |
| 82
- 02.03.2021 - 00:21
|  | | |
| 83
- 02.03.2021 - 00:25
|
количесво одноврпеменно собираемых заказов - настраиваемое. в табличке - по каждому заказу - количество заданий и примерный объем по заказу (в текущей зоне сборки). Внизу таблички - более крупными буквами расшифровка если посмотреть надо | | |
| 84
- 02.03.2021 - 00:27
| Здесь сборщик просто проваливается в саму сборку - система поведет его по маршруту сборки. Или может отказаться от выданного системой отбора - система тогда "сбросить" все задания назад в "спецконтейнер" заданий. Любой другой сборщик при заходе на эту зону получит их в отбор... | | |
| 85
- 02.03.2021 - 00:28
| Выдача в отбор на сборщика поддерживает приоритетную выдачу заданий назначенных конкретно на этого сборщика. То есть задания на сборку могут быть как общие, так и персонализированные. в Первую очередь на сборщика выдаются персонализированные задания, а потом уже общие. | | |
| 86
- 05.03.2021 - 00:43
|
Доделал на ТСД основную часть процесса отбора (сборка из ячеек). С экрана, который приведен выше, сборщик попадает на (знакомый вам уже) экран сборки товара. .  | | |
| 87
- 05.03.2021 - 00:51
| Экрнаы и на приемке, и на инвентаризации, и на размещении товара и на отборе товара - очень похожие. Потому что по сути - все операции внешне однотипные. Любая операция на складе - это всегда по сути "перемещение". из "места-источника" в "место-получатель" определенного количеств атовара. Поэтому и экраны все идентичные почти. Определить место-источник, определить количество товара, определить место-получатель, определить количество товара. В некоторых процессах "источник" и "получатель" могут быть неявно обозначены - например на сборке товара источник- ячейка, получатель - конкретный сборщик, после помещения собранного в зону контроля/упаковки/отгрузки - источник = сборщик, получатель - ячейка контроля/упаковки/отгрузки. В простых вариантах автоматизации сборщик-получатель и сборщик-источник после окончания операции могут "исчезать", т.е по складской операции товар из ячейки "01-001" в ячейку "отгрузка" минуя транзитную ячейку "сборщик". Но сам сборщик тем не менее фигурирует как конкретный исполнитель складской операции. В более развитых вариантах автоматизации (где не упрощают процессы) товар путешествует по более замысловатым маршрутам типа "из ячейки 01-001" в буферную ячейку "Буф1", из "Буф1" другой исполнитель тащить в "Буф2" в другую зону, а там третий исполнитель еще куда-нибудь дальше передает... У меня на проекте передаточные буфера не используются для упрощеняи процесса и по масштабам склада и процессам товародвижения надобнсоти в них на данный момент нет | | |
| 88
- 05.03.2021 - 00:57
| Но есть такие "упрощения "по пожеланию заказчика (для ускорения сборки) что хз как вывернуться. Например, не регистрировать укладку мелкого товара в конкретные коробки, но при этом иметь в итоге перечень сколько коробок получилось... такая штука ввиду разнородности и нехватки ресурса на складе. потому как опустили процесс перепаковки собранной мелкоштучки из некскольких коробок в одну на этапе сборки/упаковки. и Получается товар из ячейки ушел, в отгрузку пришел уже в виде грузовых мест, но что в каком грузовом месте лежит (как это правильно надо делать) - хз... Придется при маркировке обезличенных грузовых мест номерными этикетками такие обезличенные грузовые места ПРИНИМАТЬ в заказ на отгрузку. И до момент аотгрузки в зоне контроля/упаковки висит по заказу вест товарный ассортимент и висят также на балансе склада/заказа конкретные номерные места. опыт мне подсказывает что в итоге все равно придут к нормальному процессу упаковки. потом. в итоге. но это уже будет отдельная песня. пока так. | | |
| 89
- 05.03.2021 - 11:41
|
Копипаст с ИС . На одном из самых первых семинаров 1С (кажется, в 94-95 годах) нам продемонстрировали программульку по управлению небольшим магазинчиком в Голландии. Я тогда был удивлен бедностью интерфейса (что упоминалось в обсуждаемой статье!). Мы уже тогда щеголяли выпадающими меню и расцвечивали их во все цвета VGA)) А в той программе меню, как в школьном Бейсике "нажмите 1, если...." и т.п. Задал разработчикам вопрос - "Что за позор??" И получил очень внятный и четко аргументированный ответ. Кратко, звучало так: 1. Россия очень избалована (на тот момент!) уровнем образования своего населения. В 90-е за кассами возникающих тогда супермаркетов сидели кассиры с ВЫСШИМ образованием и это не удивляло никого. В Голландии, по словам разработчиков, такая фигня не прокатит. Там за кассу надо посадить убогую дурочку, закончившую школу для умственно ненапряженных деток, чьи родители вовсю пользовались легалайзом. И платить этой девочке надо совсем немного. Поэтому интерфейс и прочие "раскрашки" не должны отвлекать низкооплачиваемого сотрудника от исполнения пяти, доступных ему, несложных действия. В окошечке программы надо вводить циферки от одной до пяти, если цифра стала шестеркой - зови Босса! Мы же до сих пор пишем программы для гениев, выросших в самой читающей стране. А страна давно не читает и гениев не воспроизводит. поэтому тратим на производствах кучу времени при обучении пользовательского персонала, дотягивая его почти до уровня разработчика. Это долго, дорого и несуразно. В конкурентном мире на такую фигню программисту просто не дадут ни времени, ни денег. В экономике труд художников не оплачивается - для этого есть другие сферы. 2. Отсутствие выбора из справочников. Это никак не недостаток. Единственный способ работы с большими данными - это применение кодификаторов. Что такое выбор из справочника? Это умение читать, как минимум. Далее, после прочтения надо проанализировать несколько похожих строк, понять чем они отличаются и сделать осознанный выбор. Выбор - это принятие решения! И тут мы снова возвращаемся к качеству персонала! У нас даже кладовщики "выбирают из справочников"! Мы никак не дорастем до понятия артикулы, кодификаторы и прочие полезные штучки, которые СССР юзал вовсю! В каждой отрасли были кодификаторы, каждая гайка имела цифровое представление. Зато теперь разаработчики усиленно учат компьютеры - читать, предлагая пользователям работать с "рулонами и простынями" выпадающих текстов, где мелкими буковками без всякой системы хранится "жизнеописание" какой-нить оболочки для колбасы или куска пластмассы. Для примера предлагаю вспомнить - как выбирается запчасть для ремонта автомобиля (все проходили). Хвала судьбе, спрос на иномарки принудил нашу страну начать пользовать ВИН код. С него и начинается выбор. вводишь несколько цифровых значений и получаешь ОДНОЗНАЧНЫЙ результат выбора! А из справочников 1С выбирается как? "Загогулина для седан-баклажан снизу под левым передним крылом". Так в справочниках и предлагается в очень многих случаях. И это, что - преимущество? Я бы так не сказал... Отсутствие иерархии в отчетах и т.д. Как уже упоминалось, в SAPe (я даже не знаю - что это такое!) есть центральное ядро. Вот там с учетом ЗАРАНЕЕ заданной кодификации можно организовать ЛЮБУЮ иерархию в любом разрезе и раскладе. Речь идет лишь об изначально правильной организации кодификаторов. То, что вы не видите иерархию - это не означает, что ее нет или невозможно построить в нужный момент. Можно взять любые цифры и просто выстроить иерархию по десяткам сотням и тысячам. Это может сделать школьник средних классов. А вот пользователю на конкретном месте совершенно необязательно (в большинстве случаев вообще нежелательно или запрещено!) иметь лишний объем информации, позволяющей анализировать финансовую деятельность предприятия. Конкуренты и промышленные шпионы не дремлют! Пользователь исполняет четко заданный и заранее ограниченный перечень функционала в пределах своей ответственности. Пять полей ввода, десять возможных вариантов цифр. Вышел за границы выбора - звони боссу! Любая автоматизация производственной или финансовой сферы всего лишь отражает сложившиеся там практики делового оборота. Если наши программы так хороши, то они должны отражать соответствующее состояние организации всех процессов в производстве и финансах. Так ведь? Теперь сами себе на этот вопрос ответьте) Если мы такие умные, то почему у нас все так.... загадочно? Чтобы однозначно идентифицировать меня в США надо ввести пару цифровых кодов (код в системе соцстраха) и код водительских прав или код в системе занятости. У нас надо принести непременную копию паспорта, встать в фас и профиль, дать две фотографии 3х4 и правильно громко произнести девичью фамилию своей матери. Зато программа, в которой это все описано, имеет обалденный интерфейс и очень красивые справочники)) . https://forum.infostart.ru/forum15/t...message2607664 | | |
| 90
- 09.03.2021 - 23:33
| работаю над проектом. Нервно, конечно. Но идет, по основным ключевым моментам норм. За прошедешее время доделывал процесс "отбор" (много тестил, когда логистика на складе кривая, процессы упрощены - появляется много интерактивности со стороны исполнителя/сотрудника с ТСД - а это сразу добавляет геморроя), паралельно с доделками для разминки мозгов/разгона с утра - кучу попутной нужной мелочевки. | | |
| 91
- 09.03.2021 - 23:40
|
Из ключевых моментов еще не сделано (срок уже поджимают) - (делать ПЕРВЫМ) планирование отбора, делать для начала в простейшем режиме ручного управления, ибо опыт подсказывает что если запилить как представляется мне правильным - клиент не справится, так что стартанем с ручного планирования, а для этого и отслеживания текущей ситуации на складе - сделан АРМ, в котором все заказы по приоритетам... отсюда и будем планировать сборку... - подпитку, это вообще непонятно, пока придется сделать тоже в упрощенном варианте как клиент описывал; сами блоки расчета подпитки кусками уже есть в других процессах, но это пока самый мутный процесс. - свободное перемещение, здесь сделать надо только набор товара из ячеек, свободная раскладка уже есть - просто после свободного набора товара сформировать правильно набор параметров и подсунуть в процесс "свободное размещение"; - доточить "хвосты" по ранее сделанным процессам. . как-то вот так.. . конечно, велосипед страшный что капец, все это уже есть в нормальных WMS, страшножабовостьбюджетность клиентов кто хочет "автоматизацию склада" - убивает напрочь. Но, по крайней мере, если осилю то что должен сделать - по многим параметрам возможности лучше чем в типовых 8-ых конфах по "адресному хранению" | | |
| 92
- 09.03.2021 - 23:55
|
заключительный этап отбора - сборщик по зоне насобирал кучу всего (одновременно несколько заказов в разную "тару", под каждый заказ - своя "тара"), после выполнения всех заданий на отбор система направляет сборщика на маркировку (или сборщик в процессе отбора говорит сам системе типа "хватит"), и предлагает выбрать заказ для печати маркировочных этикеток - запрос количества этикеток - печать-обклейка - и так поочередно для всех заказов. | | |
| 93
- 09.03.2021 - 23:58
| После печати маркировки система направляет сборщика на получение очередной порции заданий или предлагает определиться с теми заданиями, которые еще не были выполнены по текущему пулу заказов. Сборщик может или продолжить выполнение заданий-отборов или сказать (после маркировки) типа "не, все.. больше не хочу" ;-) - невыполненные задания упадут в "контейнер заданий" и будут выданы очередному сборщику... | | |
| 94
- 10.03.2021 - 00:03
|
Сложность всех этих процессов заключается в том, что ничто нигде не должно упасть/сломаться, а потенциальных мест таких - вагон... И если при обычной десктопной работе типовых конфиг ну не провелся документ (транзакция, что-то не заполнено как надо итд) - поправил, повторил, то здесь - такое не получится.. сборщик в принципе не может ничего поправить... что он на экране ТСД поправит? а с учетом того, что, например, на сборщика выдан пул заданий, например 50 заданий (подойти к ячейке и взять и так 50 заданий) и на 6-ом задании что-то сломалось - все задания повиснут в неадекватном состоянии, и чтобы вернуть систему к "адекватности" - надо как говоритьяс "шурупить" что и как в системе взаимосвязано и работает и почему. . Именно поэтому настоящие промышленные ВМС - дорогие. И именно поэтому во многих фирмах никто внутрь настроек не лезет, ибо это д.б. соответствующая квалификация СКЛАДСКОГО ЛОГИСТА/ТЕХНОЛОГА, причем еще завязанная на конкретный инструмент-ВМС. . как-то вот так... | | |
| 95
- 10.03.2021 - 12:23
|
— Петрович, ты не знаешь, куда у нас со склада шесть коробок энергетика пропало? — Не знаю! — Может, их сперли, пока ты спал? — Это исключено! Я уже две недели вообще не сплю!.. | | |
| 96
- 11.03.2021 - 05:24
| Уф.. вроде добил на ТСД процесс "ОТБОР". непросто, непросто все... | | |
| 97
- 11.03.2021 - 05:36
| Что делать с перфекционизмом - прям не знаю.. давлю-давлю гадину, а она все лезет и лезет.. | | |
| 98
- 15.03.2021 - 20:12
|
Пока застрял на расчетах, просто тупняк. надо делать планирование отбора - там вариантов 10, тупняк - пготому что это опять велосипеды... . но пока сделал загрузку данных из КИС в WMS/ перебрал несколько вариантов для человеческой работы с XML. Все что надо - последовательный разбор XML. В итоге хотел остановится на ВК от romix'f OpenXML - сделано для девелоперов типа меня ;-) - понравилось, но потыкал малость - есть два (найденных) существенных ограничений OpenXML: 1. Не понимает комментарии в XML - а это сильная бяка, потому что я обычно в выгрузку пихаю в комментарии описания форматов/пояснения (до xsd не дорос, да и излишество это на небольших проектах имхо) 2. при сбое при разборе файла и прекращении кода выполнения - файл остается занятым и надо проворачивать доп.телодвижения. что очень некузяво. | | |
| 99
- 15.03.2021 - 20:25
|
В итоге по подсказке глубоких профессионалов в 77 - остановился на использовании XMLite из состава 1С++, благо 1Сpp и Formex - дефакто штатный функционал. . В итоге содержательный код получился достаточно компактный, универсальный для загрузки "глобальных" справочников, таких как Бренды, УчетныеСкладскиеГруппы, Номенклатура, Контрагенты, Направления - частности при загрузке справочников реализуются просто вставкой функции частной обработки для конкретного справочника. . Почти половину содержательного кода заняла обработка загрузки единиц для номенклатуры - сложная схема синхронизации, в которой участвует ОКЕИ, Кф единицы, Штрихкод, признаки "базовая" и "Основная", в т.ч. признаки в базе WMS типа "единица выверена". . В т.ч. различаются заданные в файле обмена пустые значения атрибутов (типа Объем="0") и отсутствие атрибутов как таковых. . Поддерживается загрузка иерархии групп справочника если она выгружена на стороне КИС. | | |
| 100
- 15.03.2021 - 20:30
| Обмен должен работать быстро, т.к. часть данных придется грузить в транзакции, а длинные транзакции в WMS - это страшная бяка, поэтому были предприняты меры для отсечения необходимости записи данных, если пришедшие данные в файле обмена не приводят к изменениям данных в базе. Код можно было бы существенно упростить, но это привело бы к необходимости записывать в базу КАЖДЫЙ загружаемый объект 9и новый и существующий), а это страшная бяка, т.к. Объект.Записать() жрет 99% времени. В итоге увеличениее кода загрузки, но при этом увеличение существенное скорости загрузки. если первоначальная загрузка данных может идти несколько минут (суммарно порядка 30 тыс. объектов если грузить начистовую), то повторная загрузка - всего 10 сек - при этом обрабатываются те же самые 30 тыс, суммарно это в районе 6МБ иксемеля исходного. | | |
| 101
- 15.03.2021 - 20:54
| И да, ССД - это сила! | | |
| 102
- 15.03.2021 - 21:30
| ССД у меня стоит как системный диск и обычно ничего более я там не держу. Здесь же, при постоянном тестировании и многократных загрузках хочется чтобы прогон данных не занимал много времени, поэтому m,fpe временно перекидываю на ССД. | | |
| 103
- 15.03.2021 - 21:49
|
(HDD7200) . Вот, например, неоптимизированная загрузка данных .  общее время исполнения = 15мин, самый большой файлик ~2700 объектов, 635Кб = 107 сек . Вот то же самое - оптимизированная загрузка (крайний вариант, когда все пришедшие в обмене данные не требуют записи/перезаписи в базе: . https://content.screencast.com/users..._Recording.png общее время исполнения = 12 секунд, самый большой файлик ~2700 объектов, 635Кб = 1 сек | | |
| 104
- 15.03.2021 - 21:53
| Конечно, правильнее было бы оптимизироваться на стороне выгрузки, чтобы в файл обмена попадало минимум данных, только то что изменилось. Но к данным на стороне выгрузки не всегда есть доступ, да и программисты на стороне выгрузки в разных фирмах разные. Здесь выгрузку тоже писал я и сделана она по минимуму - просто выгружается перечень заданных объектов и все... а на вход выгрузки сейчас подается просто, без анализа изменения (надо выгружать/не надо выгружать) объектов. | | |
| 105
- 16.03.2021 - 09:16
| Цитата:
Я вот тоже сейчас на распутье, выбираю инструмент для чтения входящих XML. Что посоветуешь, взять XMLlite? Он точно не зависит от компонентов ОС и способен БЫСТРО прочитать многомегабайтные XML-файлы? А для выгрузки в XML что посоветуешь? Я вот смотрю в строну curl.exe (у меня на нем очень успешно построен обмен с ЕГАИС) или Djelf-овский curl1c.dll | | |
| 106
- 16.03.2021 - 11:41
| 106-victuan > ответил развернуто в личку | | |
| 107
- 16.03.2021 - 11:43
|
главное: "Он точно не зависит от компонентов ОС и способен БЫСТРО прочитать многомегабайтные XML-файлы?" - при обработке скорость работы будет определяться количеством операций записи, а не собственно самим чтением данных. | | |
| 108
- 18.03.2021 - 07:26
|
УФ! Делаю процесс "планирование отбора". Долго стартовал, не укладывались некоторые концепции друг к другу. Когда уложились - дело пошло гораздо веселее... Вариативность очень большая, кодом чистым делать это как типа Если Фамилия="Иванов"... . поэтому на основные расчетные процессы приходится писать небольшие "метаконструкторы", где уже на пользовтаельском уровне орписывать всозможные вариативности. А по коду получается гораздо проще и стройнее - главное корректно данные, обработанные текущим шагом - передавать на вход следующего шага расчета. а последовательность шагов определяется настройками... и даже в таком случае тоже не шибко просто, но и не сказал бы что сильно и сложно. основное - куча таблиц, из перемножеений, сложений, вычитаний, отборов одних таблиц из других итд. И тут главное чтобы все измененяи на самом нижнем уровне частных расчетов корректно передавались по "иерархии" наверх. Костяк накидал, работает хорошо. много времени (ну как много - часов 7) ушло на костяк, в котором обвеска протоклирования процесса расчета, ибо объемных данных нет чтобы полноценные тесты гонять, это только по живому можно, на частных тестах и то уже тупить начинаешь почему так а не иначе считает - в протокол если писать - то все сразу лучше - это шибко поможет на запуске в случае проблем. и особенно в слуае недопониманий типа - прибегает "главны" по складу - ааа прога невпраильно считает - надо брать из вот той ячейки. а дает из другой. ответ простой РАЗ ДАЕТ ИЗ ДРУГОЙ _ ЗНАЧИТ ТАК И НАДО. потому как начинаешь разбираться - ошибки конечно бывают, но чаще всего комп "считает" лучше.. и оказывается что или сборщик не имеет доступа к ячейкам определенным (так было ОГОВОРЕНО!) или начсклада заблокировал ячейки исходя из каких-то своих побуждений или еще что-то подобное. Как-то вот так примерно... | | |
| 109
- 21.03.2021 - 23:09
| Сделал просто офигенную подсистемку планирования отборов (расчет сборки товаров из ячеек под заказы в соответствии с очередностью/приоритетностью заказов). Позволяет реализовать нужные в рамках проекта стратегии сборки разных складских групп товаров находящихся в разных зонах. разработка шла практически через "тестирование", с паралельным написание мтрассировки расчета в протокол, ибо понять почему посчитала так или не посчитала тсяк как представлялось - малореально даже на куцых тестировочных данных, а с трасировкой расчета впротокол - ну просто наикузявейше получилось... даже лучше чем в настоящих больших системах ;-) | | |
| 110
- 21.03.2021 - 23:38
|
Попутно всяких плюшек/фишек в основные объекты конфигурации (типа временного отключения правил итд итп). попутно еще и ошибку одну отловил грубую. именно простой осмотр протокола-трассировки сразу показал что что-то не то... Потому что тестировать вариативные системы ну капец как тяжело, сильно зависит от состава входных данных (разнородности ситуаций) и понять считает как ожидается или неправильно - это практически пошагово с помощью трассировки разбирать расчет... тяжело... Но вроде все заборол, завтреца осталось написать два частных алгоритма этапа сборки, один простой (взять товар из той ячейки, где количество товара в точности соответствует потребному количеству в заказ), и второй посложнее (набирать количество товара в заказ из тех ячеек где количество отбираемого товара забирается из ячейки полностью). Это всего 2 правила из 5, причем 3 правила из этих 5 - работают и в прямом и в обратном направлении. Плюс каждое правило сборки пытается учесть историю предыдущих шагов сборки для уменьшения "пробега" сборщика - т.е. минимизировать количесвто посещаемых сборщиком ячеек). . Например сборка мелкоштучного товара состоит из кучи этапов (важна последовательность их выполнения. каждое следующий этап выполняется если на предыдущем этапе осталось нераспределенное количество), например: 1. берем товар из резервных ячеек если _все полное_количество_заказа_ можно взять из одной ячейки (быстрота и оставляем в рабочих ячейках для прочих мелких заказов) 2. (п.1 не удалось), набираем из резервных ячеек количествами кратными упаковкам 3. (п.2 остался остаток для сборки), набираем из резервных ячеек количествами некратными упаковкам (поддерживаем порядок в резервных ячейках чтобы там не болтались распакованные коробки) если таковые количества есть в резервных ячейках (два варианта, от мелких некратных количеств к бОльшим и наоборот, при этом сначала приоритет имеют ячейки из п.2) 4. (п3 остался остаток), набираем из рабочих ячеек поштучно (два варианта, от Больших количеств к меньшим (скорость сборки) и наоборот (максимальное освобождение ячеек) 5. (п.4 остался остаток) - снова набираем из резервных ячеек, но уже поштучно (два варианта от больших количеств к меньшим и наоборот), при этом приоритет ячеек, которые уже задействованы в п.2 и п.3 . такой вариант сборки товара - реализуется без программирования посредством комбинации правил и их последовательности. . в вышеприведенном примере упомянуты не все возможные правила, есть и другие, например сборку по зоне делать только в том случае если все можно набрать в заказ из этой зоны, например: в заказ = 100, в рабочих ячейках = 80, в резервных - 300. если сделать два правила - 1.поштучный набор в из рабочих ячеек и 2. потом что не хватило - из резервных - это не всегда будет хорошо получаться. В одном случае все можно набрать из рабочих, а в другом - получится часть из рабочих, часть из резервных - тогда уже проще сразу все взять из резервных. поэтому правила описываем примерно так 1. взять поштучно из рабочих ячеек если в рабочих ячейках достаточно товара на все количество 2. взять из резервного хранения (вариантов реализации несколько, в зависимости как настроим) | | |
| 111
- 24.03.2021 - 00:06
| уф.. переделал кодирование системы правил на более понятное, мнемоническое.... а то сам без справочника что к чему начинал путаться. Ну и код удалось сократить раза в три по обработке правил... | | |
| 112
- 24.03.2021 - 00:11
|
Самое интересное - что набор ячеек для расчета/планирования отбора - один, а набор ячеек, по которому выполняется отбор спланированного - немного другой. . например, планирование отбора насчитывается по разным правилам для зоны резервного хранения и зоны активного хранения (рабочих ячеек). Обычно сборка по этим зонам также выполняется раздельно и заказ(ы) консолидируются уже в зоне контроля/упаковки/отгрузки. Но у меня, например, зона резервного хранения (на полу и на верхней полке стеллажей) мелкоштучки находится собственно там же где рабочие ячейки мелкоштучки - и собирать заказ из рабочих ячеек и из резервных по отдельности - некузяво будет. Вот и получается что отбор планируется по отдельности для двух зон, а зонйо отбора является другая, третья зона, объединяющая в себе две по которым считалось планирование. | | |
| 113
- 24.03.2021 - 00:13
|
При тестировании подсистемы стратегий/правил получилось что в шибко тяжелых/развесистых случаях планирование сборки одного товара может проходить до 8 этапов... Каждый этап и параметры планирования для этапа - в подсистеме правил описываются отдельно...
Отредактировано Чучундер; 24.03.2021 в 00:14. Причина: Поправил ширшее | | |
| 114
- 24.03.2021 - 00:16
| Сейчас думаю на д стратегией расчета подпитки, пока что мутновато получается, надо сильнее думать, сделать надо к концу-началу недели. Обработка на ТСД - практически клон уже существующих (с мелкими вариациями тот же отбор), а вот насчитать задания - надо подумать... | | |
| 115
- 30.03.2021 - 21:47
| Подпитку на NCl начал делать, программно на ТСД должно получиться. а вот с расчетом... пока непонятно. | | |
| 116
- 31.03.2021 - 01:22
|
Подпитка на ТСД не сильно отличается от "Отбора" | | |
| 117
- 31.03.2021 - 01:25
| проблемы есть, все упирается в адекватность исходных данных по ВГХ номенклатуры. если этого не будет вменяемого - все не сильно хорошо. ибо все действия на ТСД заточены на минимум жмаканий/тыканий в ТСL персоналом. и все отклонения от штатного ожидаемого поведения обрабатываются по минимуму, что будет доставлять проблем если таких отклонений будет много. | | |
| 118
- 31.03.2021 - 01:27
|
Если порядка нет. Ресурса нет. исходных данных нет. БЕРИТЕ БУМАГУ И РАБОТАТЙЕ ПО БУМАГЕ. мне вот лично идеологию работы по бумаге на ТСД переность просто тупо лень. делал уже несколько раз, хочется сделать что-то более "продвинутое"... посмотрим что получится. . но это все адские "велосипеды". | | |
| 119
- 31.03.2021 - 01:28
| вот интересно - у Клеверенса - есть сборка в несколько заказов одновременно? (сомневаюсь) Есть подпитка из резервных ячеек в рабочие? или как там сделано - мне не приходилось с Клеверенсом работать... | | |
| 120
- 31.03.2021 - 04:45
| 120-Чучундер >Так может стоить изучить чужой опыт, взять из него продуктивно все полезное, перед тем (вместо того) как браться за свой "адский велосипед"? ;) | |
Интернет-форум Краснодарского края и Краснодара |
