<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
«Запаситесь терпением — рабочий продукт выйдет не раньше чем через год начала разработки»
вот с этим я полностью согласен. вернее сроки могут быть разные, но спешка в данном вопросе без опробирывания процесса программистом невозможна, вернее даже без тестирования на реальном объекте
Позновательно. Хотя мне лично хотелось бы по подробней узнать почему не регистры накопления….
(0)
Многое, из сказанного в публикации, актуально и для других участков «автоматизации управления», а не учета документов.
(2)
Подробно, надеюсь, автор расскажет.
Кратко.
В жизни — накопление на реальных полках, а не на датах в регистрах накопления.
Похоже, что второй путь — это, на самом деле, третий, только со стартовой площадкой. Если предполагаются серьезные доработки, то рано или поздно выяснится, что система состоит из сплошных заплаток, и надо ее переписывать заново.
(2) Регистры накопления сразу порождают проблемы с последовательностью документов, с проведением «задней минутой» и всем сопутствующим букетом.
(4) При серьезных изменениях в системе можно второй путь переквалифицировать в третий, но если изменения косметические (формы, печать документов) и нужно только настроить интеграцию с КИС, загрузить справочники и ввести топологию с алгоритмами размещения, резервирования и пополнения, то все же здесь не так нужны очень сильные программисты. Вполне хватит хорошего программиста + адекватного логиста.
(5) «только настроить интеграцию с КИС» — сильно сказано 😀
(6) Как правило, все разработчики WMS уже имеют готовые модули интеграции с различными КИС, в том числе, конечно, с 1С.
В случае типовой конфигурации все совсем просто, даже специалисты WMS могут это сделать за вас.
Если конфигурация не типовая, или с большим кол-вом доработок, то уже имея готовый модуль нужно его адаптировать к текущей КИС.
Это касается обмена данными.
Нужно еще понимать, что в интеграцию нужно закладывать изменения некоторых процессов в КИС, связанных с тем, что меняется процесс отпуска товара со склада.
(7) У меня все происходило ровно наоборот. Провда, не с серьезной WMS, а с простенькой системой учета на заготовительном складе — особенностью было только объем приходов, до 100 в час на оператора. Пока работали на самописной конфигурации, пользовались самописным же блоком сопряжения, а потом купили другую — тоже на 1С, но без малейшего сопряжения 😮
(7)
«в интеграцию нужно закладывать изменения»(с)
Если говорить об 1С — возможно.
В других случаях, интеграция обеспечивается общей БД с открытым описание схемы базы данных. И ОНО само интегрируется по мере развития системы. Задачи «интеграция» не существует. Равно, как и самостоятельной «WMS», изолированной от всего остального. Ну, возможно, существует для удобства продажи «готовых модулей». 😉
(9) Не понял мысли.
Интеграция может выполняться различными средствами — с помощью обмена файлами, выделенной БД, непосредственная запись/чтение из БД КИС, OLE и т.п.
Разные WMS предлагают разные варианты интеграции — кто-то использует только-ко один какой-то формат, кто-то предлагает несколько форматов, по выбору клиента.
«оно само интегрируется» — как?
Зачастую структура хранения данных в КИС и WMS может сильно различаться, поэтому нужно проводить в соответствие данных из одной системы в другую.
(10)
В идеале, структура хранения данных должна разрабатываться не под отдельные задачи (системы), а под предметную область. Т.е., грубо говоря — создаётся банк данных и уже на данные «навешиваются» задачи. Давным-давно для этого были придуманы СУБД. Не для продвинутой системы ввода/вывода, как это сделано в «1С 8.х», а для интеграции информации. Но, думаю, это другая тема.
А под Вашу статью я поставил «плюс», т.к про 1С говорим в данной теме. Не про «идеал»…
Приводить в теме как императив сугубо частное решение :
отказаться от регистров накопления — на мой взгляд , неверно.
Как некоторый способ , который ,может быть, приведет к успеху , пожалуй.
Как некое универсальное средство — НЕТ.
Судя по-всему, автор наелся борьбой с задним числом и с проведением документов с большой табличной частью , что и привело его к такому паническому выводу.
Можно заметить , что в регистр накопления можно писать не только в режиме замещения , но и добавления . Т.е. не меняя предыдущие движения записывать только изменения табличной части. Тоже не идеал — со своими плюсами и минусами, но такой подход возможен.
Речь не о том , что такой подход намного лучше , а речь о том , что указывать в теме как императив : Откажемся от регистра накопления ! — на мой взгляд , неверно.
(12) Это не сугубо частное решение. Это универсальное перспективное направление. Или, другими словами: регистры накопления, как они реализованы в 1С, — источник гемора с максиматьным дебитом.
(12) Вы плохо прочитали статью или не в теме…
В WMS нет работы задним числом по определению, все остатки должны хранится только на текущее время.
В WMS нельзя работать с большой табличной частью разом т.к. строчки «расхватываются» исполнителями и выполняются постепенно и параллельно.
Ни одна западная WMS, которую я разбирал на косточки, не использует механизмы, похожие на регистр накоплений в 1С.
Поэтому мой совет прозвучал в статье, если считаете по другому — я не спорю, но очень хочется увидеть хорошую и быструю WMS в вашем исполнении на документах и регистрах накопления…
(2), (12) — отказаться от регистров накопления — в данном случае (управление складом) верно потому, что функционал РН резко избыточен. Просто надо понять, что на складе никого не интересует остаток товара в ячейке 11-А-3-15 на момент 01.04.2009 17:32 — важно, какой остаток сейчас. И держаться за механизмы РН только потому, что это кажется теоретически неверным, не следует. В задачах других они на месте, а здесь, увы, просто не нужны.
(15) Я бы так дополнил — знать остаток в ячейке 11-А-3-15 на момент 01.04.2009 17:32 порой бывает нужно, но процент этой необходимости настолько мал, что не стоит периодически рассчитывать остатки в регистре накоплений, тем самым раздувая его и замедляя получения из него информации.
Для цели получения остатка в любой ячейке вполне хватит механизм расчета, где берется текущий остаток в ячейке и отматываются движения по журналу транзакций до нужной даты.
Тем самым мы оставляем возможность для разбора полетов посмотреть остатки на любую дату (возможно более медленным путем), и оставляем в регистре остатков только актуальные данные, что позволяет достаточно быстро получать нужные остатки.
Но это не единственное преимущество.
(16)
Для работы склада это не нужно никогда. Для разбора полетов же интересно знать, в какой момент данные учета перестали соответствовать фактическим данным — но тут никакая учетная система не поможет. Несоответствие данных в двух учетных системах… Это уже вопрос интеграции систем, к каждой из этих подсистем он опять-таки не относится. Здесь более продуктивно замечание (11).
(14) Возможно, не в теме . Сейчас узнаем.
Не увидел никакой проблемы в раздельном вводе в один документ.
Как организовать одновременный ввод разных пользователей в один документ так , чтобы они не мешали друг другу ?
1. Первый пользователь заполняет все необходимые реквизиты документа, которые другим пользователям недоступны для редактирования.
2. Остальные пользователи имеют на форме табличное поле с типом ТаблицаЗначений.
В момент открытия в ТаблицуЗначений выгружаются только те записи из табличной части документа , которые были введены им ранее. Если это первый ввод , то ТаблицаЗначений пуста.
3. Пока конкретный пользователь вводит свои строки в ТаблицуЗначений документ может как угодно меняться. Перед записью документа пользователем происходит считывание объекта («Прочитать()») и только затем событие Записи объекта с удалением из табличной части «старых» строк пользователя и добавлением новых из ТаблицыЗначений.
В чем тут проблема ?
Чем оформление для каждой строки отдельного документа лучше ?
Можно поговорить и эффективном быстром проведении такого документа по регистру накопления (режим только добавления записей в регистр с типом «обороты» или «остатки»).
(18) Пока нет возможности объяснять на пальцах с примерами почему такой подход более оптимален при работе на складе с использованием терминалов сбора данных.
Давайте начнем с конца, с регистра накоплений. Он состоит из двух таблиц — таблицы движений и таблицы остатков. Пользователю доступно управление только таблицой движений, таблица остатков живет своей жизнью, которой управляет платформа. Далее — в таблице остатков актуальные данные записываются с указанием далекой даты, а также каждый месяц рассчитываются остатки за прошлые периоды.
Теперь попробуем понять насколько удобно SQL серверу выбирать данные из такой таблицы, которая содержит как нужные нам данные, так и лишние. Конечно, индексы по периоду рулят, но зачем нам такой механизм, которым не можем управлять и которых хранит избыточные данные?
(19) Как общие и очевидные соображения — принимается.
Как конкретный аргумент при выборе варианта регистра (одного из нескольких) сомнителен.
Разумеется, Вам виднее в Вашей разработке. Но Вы -то делаете общий вывод и приводите его читателям : «Откажемся от РН !».
Никаких обоснований не приводится. Дескать , а чего тут думать ?
Против этого я и возражаю в своем первом посте , если Вы внимательно его читали.
(20) Я написал статью, основываясь на своем опыте детального изучения архитектуры БД таких WMS систем как EXceed 4000, Manhattan ILS и PSIwms. Каждая из них имеет уникальную архитектуру, но во многом они сходятся. Также могу сказать, что все эти базы никак не подходят ни под один уровень нормализации — их таблицы заведомо избыточны данными и сделано это все для одного, быстродействия!
Также у меня есть возможность наблюдать за развитием решения 1С:Логистика и эти ошибки также там проявляются.
Переход на регистры сведений — это не моя выдумка, это тенденция — рассмотрите другие решения и вы поймете, что многие уже так поступают.
Это не научная статья, размещенная в популярном журнале. Это лишь мое мнение, основываясь на опыте работы с WMS (как пользователя, как заказчика, так и разработчика и внедренца) — использовать мои рекомендации или нет решать вам.
Но пока разработчики WMS на 1С закрывают глаза на международную практику разработки таких решений, то мы получаем результат — заказчики до сих пор не верят в возможность установки системы автоматизации на платформе 1С. Приходиться им долго объяснять, возить на склады, показывать статистику и т.п.
Отсюда возникают такие вот вопросы:
Поэтому цель этой статьи — показать, что 1С не является ограничением для построения сложных систем. А как решит тот или иной разработчик — это уже другой вопрос.
Но еще раз предлагаю окунуться в специфику работы на складе и понять, что она никак не пересекается с финансовым/управленческим учетом.
(21) Ок. Как дилетанту в складском учете мне было интересно познакомиться с Вашей статьей.
(22) Спасибо за оценку.
Если будет время, то попробую в следующей статье подробней описать особенность организации учета на складе.
И Вы поймете, что подход работы «от документа» сильно ограничивает и заставляет писать всевозможные обработки, которые как-то пытаются имитировать работу в режиме реального времени.
Например, одно из странных ограничений первых версий 1С:Логистика было в том, что нельзя было размещать принятые паллеты до окончания процесса приемки. Это было связано с тем, что не закрыв один документ и сформировав другой, пользователь на терминале не смог сформировать задачу на перемещения паллеты.
Хоть я может и открываю некоторые «секреты» для конкурентов, но моя позиция сейчас схожа с той, что обозначена в «ДАО Тойота» — развивайте конкурентов и вы поднимите отрасль в целом! (под отраслью я понимаю WMS на базе 1С)
(23) Честно говоря , прочитав , хмыкнул.
Критика конкретного решения в «1с-Логистика» вовсе не означает ущербность самого подхода «от документа». Вообщем , подождем следующую статью с критикой похода «От документа». Кажется , на ИС об этом никто не писал (но могу соврать).
(24) В последней версии 1С:Логистика как-раз во всю используются регистры сведений и управляемые блокировки.
Ребята из Logiton (сейчас Penta и TopLog) уже давно избавились от табличной части (еще в 2007 году, когда в 1С:Логистика версии 2.0 был классический подход и куча ограничений по функционалу).
Поэтому, как минимум типовое решение «документ с табличной частью и движением в регистры накопления» уже многие из разработчиков WMS не применяют.
(25) Интересно узнать , а рассматривалось ли следующее решение :
Отказаться от регистров вовсе при оперативном учете .
И сделать учет на справочниках .
Реквизит в справочнике один : Ссылка на Номенклатуру. Табличных частей — две. Первая для всех движений , Вторая имеет два реквизита Склад и Остаток.
В первую ТабЧасть пишутся движения с указанием документа только в конец (если исправление, то вначале сторно потом само значение). Во вторую таб.часть пишется (исправляется остаток на складе).
Из преимуществ такого подхода
1. невиданное для регистра распараллеливание.
Т.к. элемент справочника обладает объектной сущностью ,то писать можно одновременно в разные элементы справочника.
2. Очень высокая скорость записи (добавление) движений в табличную часть.
Запись в конец табличной части осуществляется многократно быстрее, чем в регистр сведений.
Это , разумеется , экспромт , как и пост о раздельной работе пользователей. И всё-таки ?
(26) Для таблицы остатков есть определенное требование — составной индекс т.к. учет идет в нескольких измерениях (номенклатура, партия, ячейка, паллета).
Этим требованиям удовлетворяют только регистры сведений и накоплений.
Когда 1С сделает возможность создавать составные индексы для справочников и его табличных частей, то можно рассмотреть и этот вариант.
(27) Да , не продумал. А жаль. Проблема с блокировками и тормозами просто исчезает.
(28) Табличная часть справочника — это такая же таблица, просто у нее уже есть предопределенный реквизит «Владелец» ссылающий на номенклатуру, и соответствующий индекс по владельцу.
Создание регистра сведений с измерением «Номенклатура» и индексом повторяет эту конструкцию (я часто вместо табличных частей использую именно регистры сведений т.к с ними удобней работать).
(29) Разумеется . С одним только НО.
Запись в табличную часть элемента справочника блокирует только этот элемент справочника. В остальные пиши — сколько хочешь. Т.е. главное преимущество справочника — распараллеливание операций , невозможное для регистра , записи которого не обладают объектной сущностью.
P.S. Если главная цель распараллеливание , то игра стоит свеч.
Во второй табличной части предусмотреть те же реквизиты , что и в регистре .
И тогда новое движение ищет по своим реквизитам остаток во второй табличной части и исправляет его. Если не находит , то осуществляет новую запись.
Т.е. в принципе такой возможен и мы достигаем превосходного распараллеливания. Ну , а насколько удобен подход в других аспектах — тот еще вопрос.
Не пойму какое распараллеливание при использовании табличной части справочника?
Если посмотреть на таблицы SQL то никаких преимуществ нет.
Если смотреть на модель поведения 1С, то табличные части проигрывают регистрам сведений. Их удобство только в автоматизации подвязки их к справочнику.
При работе с объектом номенклатура мы блокируем этот объект, т.е. если в разных частях склада разные сотрудники отбирают из ячеек один и тот же товар, то они встанут в очередь. При использовании управляемых блокировок для регистров сведений они параллельно запишут информацию в БД.
(31) Вы правы. Ок.
(27) Таким требованиям полностью отвечают «БухгалтерскиеИтоги», где «план счетов» идентичен физической структуре хранилища, а содержимое = субконто.
(33) ИМХО БухИтоги — это самое последнее, на чем можно пытаться строить WMS 🙂
(34) ИМ — это хорошо. ХО — и не собираюсь. А аргументация?
(35) Устал приводить аргументы, если кто хочет писать WMS на бухитогах — готов поучаствовать в тестировании конечного решения.
(24)
«…подождем следующую статью с критикой похода «От документа».(с)
Игорь.
Эта статья уже давно написана, самими определением:
«Все хозяйственные операции, проводимые организацией, должны оформляться оправдательными документами, которые называются первичными. Первичные документы принимаются к учету, …»(с)
Т.е. из этого следует, что «сущность документа», расположенного в БД, является отражением и учетом документов. И такая схема БД ориентирована именно на сбор и учет (хранение) документов. Со всеми вытекающим особенностями: проведение, последовательности по дате расположения документа в БД и т.д.
Но, с точки зрения «бумажной жизни», документ это только удобная форма отражения реальных хоз.операций (ХО). Типа, меньше писать руками. И писать в определенных местах бумажки. Часто с объединением нескольких ХО в одну бумажку.
Но ХО выполняются с реальными объектами жизни и только отражаются в документе. При наличии «автоматизации» совершенно логично в ЭВМ-у заносить факты выполнения ХО, а не факты их отражения документом. А документы только представлять как единое целое в момент получения бумажной копии (если она требуется).
Т.е. в «подходе От документа»: ХО->БумажныйДокумет-ДокументБД-ЗаписиПроХО
А в другом подходе: ХО-ЗаписиХО-БумажныйДокумент.
Исчезает совершенно лишняя «сущность».
Т.е. учитывается и автоматизируется реальна жизнь, а не бумажки.
И в этом смысле, огромным 😉 прорывом в «1С 8.х» является появление «Регистра сведений». В 7.7 это приходилось реализовывать на справочниках.
И для осознания такого «подхода» не требуется быть специалистом в «складском учете». Такой подход реализуется и требуется для любого участка АСУП-а…
Поддерживаю мнение автора. Особенно в части «важно что сейчас», прокрутил в 7.7 ТиС свою простенькую WMS, строил на справочниках и внешних файлах. Работает! При этом работает ВМЕСТЕ с КИС.
Хочу также обратить внимание на такую проблему как интеграция WMS с КИС — вот здесь вот может быть много бяк (имхо). Самый простой пример: рассогласование резервов в КИС и WMS — отклонения при сборке — вопли менеджеров и клиентов. Именно поэтому у себя «WMS» впихнул в ТиС. Отдельная WMS, возможно, имеет смысл для больших «проектов», бешенных темпов отбора и постоянного непрекращающегося товародвижения с высокой плотностью/темпом. В других случаях вполне возможно в «типовые» КИС отдельным «сейчасным» контуром вставить маленькую «WMS».
Немного покопавшись в некоторых вмсах, побродив по выставкам и поговорив с людьми — зачем нам ВМС, которая УПРАВЛЯЕТСЯ ОПЕРАТОРОМ???
(37)
А в другом подходе: ХО-ЗаписиХО-БумажныйДокумент.
Исчезает совершенно лишняя «сущность».
И это правильно
(37) Вначале частность :
Тарабарщина .
Сущность документа, расположенного в БД не является учетом документов.
Правильно так :
Сущность документа , расположенного в БД может являться как отражением «бумажного документа», так и отражением любого другого факта хозяйственной деятельности , влияющего на числовые характеристики ХО. Точка.
Затем главный тезис Владимира :
А в другом подходе: ХО-ЗаписиХО-БумажныйДокумент.
Исчезает совершенно лишняя «сущность».
Действительно , зачем нам эта лишняя сущность — «ДокументБД» ?
«Лишняя сущность» нам нужна для хранения реквизитов (свойств) всех ХО, составляющих документ. Нам нужно хранить НомерДокумента, ДатуДокумента как минимум.
В общем случае, нам нужно хранить в сущности-документе некоторые параметры выходящие за рамки учета БУ, но прямо влияющих на числовые характеристики всех ХО составляющих сущность — документ , например температуру воздуха в момент поступления товара. Обращаю внимание , в данном случае реквизит Документа БД не просто довесок , дополнение к ХО , а важнейшая характеристика всех ХО.
«Узко-конкретный» подход :
Отталкиваясь от частного случая (простейшего складского учета), где удобно рассматривать поступление каждого товара,перечисленного в бумажной накладной , как ХО , а реквизиты бумажного документа как довесок , дополнение — делается «глобальное обобщение» ,т.е. вывод о «лишней сущности» ДокументаБД.
(40)
А в другом подходе: ХО-ЗаписиХО-БумажныйДокумент.
Исчезает совершенно лишняя «сущность».
И содержимое склада моментально окажется на ближайшем рынке. 😎
Ну для своих сотрудников положим еще можно сертифицированную ЭЦП прикрутить. А с поставщикам/покупателями что делать будем? 😐
Остатки на 25.06.2008 17:25:30 нужны и регулярно:
1. Выяснение проблемных ситуаций.
2. Анализ работы (например, когда на каком участке (хранение, комплектация, погрузка и т.п.) пиковая загрузка и какая она.
3. Проведение инвентаризаций без остановки работы.
Другой вопрос, что использование РН — или нет никак с возможностью получения таких остатков не связано. РН — просто штатный механизм для некоторых расчетов. И пользоваться им надо грамотно, а не как в типовых.
А вот как раз для основной операции (отпуск товара) остатки СКЛАДУ вообще не нужны ни на какую дату, НИ ТЕКУЩИЕ. Так как если склад работает в режиме выдачи заказов, то остатки проверяются программой когда менеджер товар выписывает. (Хотя если у менеджера своя база, у кладовщика своя, у бухгалтера своя и остатки у каждого свои — то 😥 ).
А если склад работает в режиме самостоятельного набора товара (как супермаркет), остатки тем более не нужны — т.к. возможность отпуска товара определяется его фактическим наличием. И если на складе по учету 3 т дров, а покупатель набрал 5т, Вы ему что эти 2 т не отпустите что ли?
Про скорость работы. 1С конечно не сильно шустрая, но склад — это не фондовая биржа и реальные процессы на складе (т.е. кару подъехать, снять палету, отвезти на пандус, поставить в машину) по любому требуют на порядок большего количества времени требуемого на проведение этой операции в программе. (если конечно не типовая конфигурация используется 😥 ). «Тормоза из-за программы» (равно как и часто ломающиеся кары, грузовые лифты и т.п.) говорят обычно том, что начальство на пандусе редко появляется и работники предоставлены сами себе.
Регулярно в разных организациях вижу одну и ту же картину. Нужен покупателю товар, который на складе присутствует в 10 вариантах (фасонах, расцветках), причем покупатель готов взять любой фасон. Начальство менеджеру (оператору) что выписывает товар как работать с программой четких команд не выдало. В результате менеджер работает так: ставит все количество на первый вариант, пытается провести накладную 😉 . Программа ему пишет: что мол списываешь 100 единиц, на складе 23 единицы, 77 не хватает 👿 . После этого количество по первому варианту уменьшается до 23, 77 ставится на второй вариант и так далее. А товаров в накладной может быть не один десяток.
аля реклама… вон, ребята из Axelota 90% времени потратили на защиту своего творения, чем на нормальную реализацию конфигурации… используя и без того медленный интерпритатор 1С, они своим кодом сделали его еще медленнее.. чего только стоит их раскраска строк! учитесь нормально кодировать!!!
вообще обсуждать WMS имеет смысл тогда, когда имеешь опыт их использования… вот у меня есть опыт использования Логистики от Axelot … начинается все с того, что берем большой большой напильник и начинаем из танка делать самолет!
Уж простите меня грешного, но многие о проблемах учета на складе знают понаслышке.
Если бы видели работу склада хотя бы 5 т. кв.м. с персоналом в 30 комплектовщиков, которые постоянно что-то собирают, вывозят, все это кто-то контролирует, в это время параллельно товар принимается, пополняется, часть товара отгружается, а система еще загружает и запускает в работу новые заказы,
то не говорили бы о быстродействии WMS так пространственно.
Лично я на складах провел времени почти полгода и видел лица обычных русских мужиков, когда на нажатие кнопки «далее» они не получали ответа от зверской машинки. Одни бесятся, другие сразу идут курить, третьи забивают на работу …
Также интересно наблюдать работу склада, когда на одной западной WMS при запуске заказа в 500 строк весь склад вставал в ступор на 5 минут (если для офиса это еще простительно — люди могут почитать почту, обсудить проблемы с коллегами, то на складе этот простой очень негативен).
(45)
то не говорили бы о быстродействии WMS так пространственно.
Заказы в систему не с Луны падают. Описанная ситуация имеет место, когда начальство на работе не появляется и менеджер, получив заказ, вводит его в компьютер, только когда клиент уже грузиться приехал.
Так для справки: даже на скоропортящийся товар (охлажденка) все крупные торговые сети (АШАН, МЕТРО и т.п) заказы присылают минимум за неделю. Но даже 2 часов вполне достаточно, чтобы все полностью обсчитать и спланировать складскую и транспортную логистику даже на самом тормозном железе (имеется в виду именно «процессорное» время). Я даже представить себе не могу какой-то более-менее распространенный реальный товар, заказы на который надо обсчитывать быстрее.
Вопрос исключительно адмнистративный — чтобы сотрудники делали свою работу (в т.ч. ввод заказов в систему) вовремя а не в последний момент.
(47) А при чем тут время ввода документов в систему?
У склада есть своя нагрузка, скажем 5000 строк отбора в день, из расчета этого подбирается штат в 30 комплектовщиков + 10 контролеров + 3 водителя ричтрака +операторы + грузчики.
Все эти люди приходят с утра на работу, переодеваются, берут в руки терминал (кому он нужен) и идут работать до обеда. Пул задач им уже сформирован вчера, а также появляются новые.
Каждый комплектовщик в минуту отбирает 1-2 товарных позиций. Время ответа терминала на запрос пользователя не должно превышать 1 секунды (такое же требование у PSIwms). Теперь вспомним, что работают 30 комплектовщиков, 10 контролеров и 3 водителя ричтраков — считаем нагрузку в единицу времени.
Еще раз хочу подчеркнуть разницу между офисной системой и складской.
В офисе люди работают и ЗАНОСЯТ данные в систему учета. Если система недоступна, то могут заняться другими обязанностями — обзвонить клиентов, ответить на почту, обсудить с коллегами вопросы, открыть вторую сессию с БД и анализировать нужные данные.
На складе рядовые работники ПОЛУЧАЮТ задания от системы и подтверждают свое выполнение. Т.е. если система тормозит, то в целом весь склад работает не эффективно т.к. заставлять складских в паузах подметать полы не очень эффективно.
Поэтому к WMS предьявляются более строгие требования в плане скорости работы т.к. она УПРАВЛЯЕТ работает склада, а не является базой данной для хранения факта сделанных ХО.
(47)
Все эти люди приходят с утра на работу, переодеваются, берут в руки терминал (кому он нужен) и идут работать до обеда. Пул задач им уже сформирован вчера, а также появляются новые.
Если пул задач сформирован вчера то чего вообще в реальном времени считать то?
Каждый комплектовщик в минуту отбирает 1-2 товарных позиций. Время ответа терминала на запрос пользователя не должно превышать 1 секунды (такое же требование у PSIwms).
1-2 товарных позиции в минуту означает, что на каждую позицию требуется 30-60 секунд. Чего ему терминал ответить в течение секунды отвечать должен? «Заказчик передумал, положь назад откуда взял 😉 » что ли?
Или просто посообщение о том, что, например, такого серийного номера нет в системе и вероятно произошла ошибка при считывании штрих-кода, надо пересканировать? — так какая необходимость это в течение секунды делать? Можно совершенно спокойно получить это подтверждение как минимум до завершения операции со следующим товаром — т.е. в течение тех же 30-60 секунд. А как более нормальное решение — в том случае, если «центральный сервер» перегружен, просто сохранить данные в терминале и передать их когда нагрузка спадет. Ведь эти серийные номера реально понадобятся только когда будут печатать накладную — т.е. когда будет собран весь заказ — а до этого момента уже небось целый час времени есть. Т.е. о чем я с самого начала говорю проблема только одна — начальство работников самих себе предоставило вот они дурью и занимаются.
Теперь вспомним, что работают 30 комплектовщиков, 10 контролеров и 3 водителя ричтраков — считаем нагрузку в единицу времени.
30 комплектовщиков, одна операция в 30-60 секунд — это одна операция в один товар каждые 1-2 секунды. Ну пусть остальные еще столько же — одна операция в один товар каждые 0,5-1 секунды. Такая скорость проведения документов обеспечивается даже типовыми конфигурациями на обычном «офисном» железе.
Вот еще из жизни пример: Склад палеттный 20,000 ячеек, автоматизация логистики выполнена местным франчем следующим образом: взяли типовую торговлю, на каждую ячейку завели по складу 😥
(49)
Поэтому к WMS предьявляются более строгие требования в плане скорости работы т.к. она УПРАВЛЯЕТ работает склада, а не является базой данной для хранения факта сделанных ХО.
Вот с такого подхода бардак на складе и начинается. Типа клиент приехал, кладовщики должны ему все срочно собрать, и если терминал ему вместо 1 сек 3 думал — это все тормозит, 1С надо выкидывать, САП покупать.
А то, что этот заказ клиент неделю назад прислал, и все можно было давно собрать, скомплектовать и документы оформить, но просто в офисе его никто не почесался этот заказ в комп забить — так это же другая система, офисная, ей в реальном времени работать незачем…
(50) Ух… думаю, что нужно писать новую статью т.к. все комментировать нет мочи уже 🙂
Вы понимаете как идет процесс работы человека с ТСД на складе? Какие действия он делает, что считает система и чем она нагружена в процессе работы пользователей?
Без понимания работы людей с терминалом дальнейшие разговоры переходят в теоретические споры о смысле жизни и наличии высшего создателя…
(51) Да при чем тут клиент и его срочный приезд? Это отдельный разговор о планировании ресурсов.
Я же в статье описываю другое — если даже склад закрыт (ночная смена) и работает только на отбор продукции, то типовой подход не может обеспечить хорошее быстродействие для режима работы в реальном времени.
И дело тут не в клиентах, а в пользователях системы, которые могут выполнять операции до 10 в одну секунду по одному и тому же заказу (крупный клиент), и всем им WMS через секунду должна дать ответ что делать дальше.
При этом пользователь не задумывается ЧТО именно делает система, а она подтверждает данные о выполненной операции (отбор), изменяет остатки, движения, вычисляет следующую задучу, резервирует за пользователем, выдает ему на терминал.
Если же система тратит 5 секунд на рассчет, а пользователь 30 секунд на выполнение операции, то можете просчитать процент простоя пользователя в ожидании «а что дальше делать то, а?»
(0) а Ваш продукт что-то оптимизирует?
(53)
Если же система тратит 5 секунд на рассчет, а пользователь 30 секунд на выполнение операции, то можете просчитать процент простоя пользователя в ожидании «а что дальше делать то, а?»
Ну и где здесь простой? Положил коробку, сосканил штрихкод, терминал (пусть даже на нем софт однозадачный/однопоточный стоит — хотя тоже бред полнейший) думает, приступаешь к следующей коробке. Запас времени до следующего скана 30 секунд, и 5 секунд на ответ системы перекрывается с 6кратным запасом.
(53) А как пользователь узнает что ему дальше делать, какую коробку из какой ячейке нужно отобрать?
(54) Не понял вопроса
(56)
А как пользователь узнает что ему дальше делать, какую коробку из какой ячейке нужно отобрать?
В компьютерной игре «Тетрис» можно включить подсказку: показ фигурки, которая будет падать следующей. Реально помогает. И тут то же самое — если комплектовщику не дается никакой сводной разнарядки, то показывать на терминале не только текущее задание, но и как минимум следующее.
(57) В ряде случаев удобно выдавать несколько задач пользователю, они прописываются в его пул задач и выдаются из него. Но это все-равно время работы системы.
В каких-то случаях (например, работа ричтракера на пополнении) очередную задачу следует высчитывать на текущую секунду — пока он выполнял задание поблизости освободилась ячейка отбора и именно ее удобнее всего пополнить, а не ту, что была бы приоритетней минуту назад (в другом конце склада).
Мне кажется, что дискусия переходит в угадайку, а не к обсуждению практических проблем работы WMS на складе.
(41)
Игорь.
1) «Документа БД не просто довесок , дополнение к ХО , а важнейшая характеристика всех ХО. «(с)
Примените свои знания о «дереве» в контексте — «ДокументБД». 😉
Документ не является «характеристикой всех ХО», а в ХО имеется ссылка на характеристику ХО под названием «ОформленоБумажнымДокументом_НомерДата».
2) «»Лишняя сущность» нам нужна для хранения реквизитов (свойств) всех ХО, составляющих документ.»(с)
Совершенно верно. Только зачем эту «сущность» хранить как единое целое в БД и раскладывать (дублировать) на «ПсевдоХО» в, например, регистрах. Только для упрощения взятия этой информации запросами? Но про «запросы» это уже другая тема. Ага?
(42)
Виталий.
1) «И содержимое склада моментально окажется на ближайшем рынке.»(с)
Схема БД никак на это не может повлиять.
2) «А с поставщикам/покупателями что делать будем?»
Работать на уровне «БумажныйДокумент». 😉
(59)
Там не про схему БД речь шла, а про предложение сначала товар отпускать/проводки делать, а только потом документы оформлять.
(60)
Виталий.
Извините, но я — зануда. И люблю ясность… 😉
В сообщении (40) была цитата моего (37) сообщения и согласие с окончательным выводом моего сообщения. И в этих сообщениях нет слов про «сначала товар отпускать…»(с), там исключительно про схему БД в части хранения «суЧности ДокументБД». Не думаю, что Александр («Арчибальд») согласился бы с моей мыслью «товар отпускать» без документов. Не такой он человек… 😉
Думаю, разночтение у нас с Вами получилось.
(62) на, порадуйся:
— Время реакции системы от момента считывания ШК ТСД до ответа на ТСД — не знаю, не мерял, но до трех раз в секунду — проходит…
.
— тоже использовал ТЗ, при этом совершенно пофиг сколько человек работает с 1 документом ибо — в момент выдачи задания на склад минимальной единицей работы становится 1 лист (40 строк), есть заявки и по 20 строк и по 700 строк. Отгрузка — самая разна — от «розничной» до крупнооптовой.
.
Средняя нагрузка в сезон порядка 3000 строк, строка может быть и 2 штучки и 10 коробок+2 блока+3 штуки. На самом деле это низкий показатель, в основном упирается в то, что отгрузка идет самая разнокалиберная — поэтому сборка по бумажным листам, контроль и упаковка по ТСД.
.
у меня «WMS» опирается на складские остатки, зафиксированные в ТиС — потому как для меня совершенно неприемлимо отклонение того что зарезервировал менеджер от факта сборки. И позволить себе учет когда в КИС одни данные, а в WMS — другие — я себе не могу. Пришлось всех построить и застрогать работу в ТиС на ТА. и все пучком.
.
маленький кусочек склада
.
реально на все-провсе, связанное с внедрением, ушло примерно месяц — реального программирования где-то полных 3-5 дней рабочих. Большую часть времени заняло обдумывание и проверка.
.
с ТСД никаких проблем не было и не возникало. работа в 7.7 в терминальном режиме.
.
много по уму не сделано. приходилось выбирать компромиссы между скоростью и качеством, и там где можно обойтись без ТСД — там обходились без ТСД.
.
кучу интересных вещей не сделал…
.
если бы делал сейчас — многое сделал бы по-другому…
Самое из этого интересное — что заблокировать сборку какого-то артикула в случае проблем (для быстрого разбора полетов) — я не могу принципиально…
.
Истина — она где-то рядом.. между (0) и (62)…
ПописАв «wms» на 7.7 — могу ответственно заявить — катит!!! еще как катит! Вплоть до того, что начал задумываться над выпуском отдельной подсистемы «wms» хоть для Бухии, хоть для ТиС, хоть для ПуБ. Все упирается в одно: в аккуратность ведения учета в КИС. если это есть — в принципе, никакие ОТДЕЛЬНЫЕ wms — не нужны в большом количестве случаев… Отдельные wms — они откуда взялись? только от того что wms решает несвойственные для Кис задачи..? если это так — то эти два контура (КиС и WMS) можно (и нужно?) объединять В ПЕРВУЮ ОЧЕРЕДЬ ДЛЯ ВЫСОКОЙ ЭФФЕКТИВНОСТИ (?) — ввиду своей разнородности они не будут мешать друг другу. Работа wms начинается там, где заканчивается (или еще не началась) работа КИС…(?)
Реально чего не хватает на 7.7 — это сервера…
(46)
— это происходит не из-за использования типовых конфигураций. на типовых конфигах МОЖНО СДЕЛАТЬ ОЧЕНЬ МНОГОЕ. Это происходит из-за отсутсвия выстроенного регламента/учета — а на чем он — на типовой или самописке — это совсем другой вариант…
(48) если у вас на 5000 строк задействовано 30 сборщиков+10 контролеров+прочее — то что ни все делают??? у меня конечно попроще все и нагрузка поменьше.. но для нормировочной нагрузки в 3000 строк — у меня штатный состав 16 человек, в число которых входит и штабелерщик и старший смены… Реально работает 12 человек — и вообщем-то — не потеют. но хорошо, если было бы 16.. тогда можно было бы все намного улучшить.. Лично у меня основная проблема «то пусто, то густо» — т.е. самое нужное — это расчет нагрузки, которую может выполнить склад при имеющихся на складе ресурсах. ни в однйо системе ЭТОГО я не видел (может плохо смотрел)…
— покажите мне ХОТЯ БЫ демку, на котрой видно, как ВМС УПРАВЛЯЕТ складом — я буду тогда плакать от щастья…
для NAFA надо памятник поставить за высказывание, отражающее одну из основных проблем:
Ждем ответа автора и раскрытия темы по (52).
.
Мне кажется, что надо разгарничивать те объекты, где основной деятельностью является СКЛАДСКАЯ ДЕЯТЕЛЬНОСТЬ (например склады ОХ, склады ОХ с оказанием услуг по сборке товара) и те объекты, где основной деятельностью является торговля. На самом деле очень многое зависит от темпа и загруженности склада.
(63)
Сергей.
Это у тебя отгрузка.
Да?
А приход — как?
ОТДЕЛЬНОЙ СТРОКОЙ ЗАМЕЧУ: автор RSERGIO до недавного времени являлся одним из лидеров (присутствие в ТОП3 на постоянной основе в течение длительного времени) в прводимом ГУГЛЕ конкурсе, он и сейчас там — чуть пониже упал…
(72) вылазь в скайп!!!
(72) с Приходом — все плохо.. 😉 потому как это был один из беспроблемных участков… но только до той поры, пока не навел порядок более-менее на прочих участках — вот тут Приходы и стали узким местом.. Но ничего сложного — все поянтно как и что делать и никаких сомненйи что будет сделано — нет.. проблема в том, что я оттуда уволился… 😉
Ребята, я честно ничего не понимаю.
Знаю компанию Axelot с момента когда они были еще Аистом.
Отслеживаю их версии — вначале на 7.7, потом 2.0 на 8.0, далее 3.0 на 8.1, немного в курсе планов по 4.0 на 8.2.
При этом WMS они разрабатывают очень давно, вложили в нее много сил, пытались продвигать даже западную систему, но не вышло.
При этом на тендерах они не то что именитым проигрывают, но даже конкурентам из лагеря 1С (которые тоже немало сил вложили).
И ладно бы еще, так успел поработать консультантом, поездить по России по складам «Пятерочки», посмотреть на работу крупных складов на мощных WMS
А тут, оказывается, настоящую WMS можно за два месяца написать на старенькой 7.7 и все счастье …
А я уже 3 года оттачиваю в системе то, что люди за пару месяцев пишут.
Пора на пенсию…
(76) Спакуха! Кто сказал что «настоящую ВМС»? (я читал твое описалово Арены — Злопчинский=я) — впечатляет! достойная ситсема по крайней мере на фоне других. Другой вопрос, что для моих потребностей — она не нужна, как и прочие системы. Вот и все. Ценность имеет то, что работает ЗДЕСЬ И СЕЙЧАС. так что не баись! система у тебя правильная, а у меня — простенькая. Вот если твою систему параметрическими настройками можно свести к требуемому лично мной функционалу… вплоть до внешнего представления экранных форм… 😉 — тут было бы интересно о чем поговорить… У меня тут наклевывается склад новый.. может и обращусь ПРЕДМЕТНО…
.
Спи спокойно.
а тянет моя маленькая wms на гордое звание WMS — ты это лучше наверное представишь по картинкам, которые я выше выложил.. если что — готов на всякие вопросы ответить… 😉 а то вдруг, ты действительно 3 года фигней занимался 😉
(76) А что тут понимать ? Создать продукт для конкретного предприятия , абстрагируясь от многих важнейший деталей — достаточно просто.
Создавая более или менее универсальное решение, разработчик всегда попадает … на три года.
(76) Смотрели продукты Axelot в апреле этого года. Честно — презентация «от девочки» не впечатлила совсем («не то что именитым проигрывают, но даже конкурентам из лагеря 1С » — кажется, причина в этом), поехал к ним в офис — разговаривать с разработчиками, покопаться в коде программном (дали доступ, даже над душой не стояли много).
В итоге нам система не подошла (для нас много допилов пришлось бы делать), но в целом она рабочая. И руководитель проектов у них адекватный
(63) Порадовало!
Сеансы ТСД в терминале — аналогично.
По поводу проблем с ПО самого ТСД — переписал, т.к. генератор форм с которым он шел не удовлетворял своей негибкостью. Сделав же ТСД «полноценным» компьютером (только с маленьким экраном) — каким он по существу и является, появилась возможность встроить его работу в технологию работы склада, а не наоборот технологические складские операции подгонять под уже готовые формы. За одно и вспомнил молодость. А что по времени — так лето было жаркое и дымное…
А поводом отклинуться было то, что возможен и другой взгляд и подход к решению задачи автоматизации склада, нежели изложен автором.
(76) Сергей! Не волнуйтесь. Всякому продукту, а уж тем более ПРАВИЛЬНОМУ есть свое место в этой жизни. Про пенсию — рано.
Все-таки Вы обещали написать еще одну статью, которую с ждем с интересом.
(63) Кстати, поскольку у нас с Вами получился диалог, то хочу поблагодарить Вас за идею, которую Вы представили как «Рабочее место сборщика по ШК»!!!
Оснастив похожее рабочее место сенсорным экраном (как в платежном терминале), подцепив весы (планирую еще и принтер ШК — скоро пришлют) — вынес его на склад в зону комплектации — с ним работают непосредственно товароведы.
Так что обмен идеями безусловно полезен (про яблоки уже писАл)…
Рассмотрите еще решение «БИТ: Складская логистика».
(82) «Продам» Рабочее место расфасовщика большой кучи товаров по заказам/точкам/отгрузкам — для чего может быть применено: есть большая куча товара (например, у меня — 300-500 дисков, каждого наименования от 1 до количестов заказа) — прислал поставщик консолидированную поставку. Есть куча получателей товаров из этой поставки (точки/магазины/заказы на отборсборку/итд — у меня точки торговли дисками, известно требуемое количестов пономенклатурно на каждого получателя), в пришедшей «куче» может быть товар, не входящий ни в один из получателей. Задача — быстро «расфасовать» товар, по условиям расфасовки сформровать перемещения/отгрузки/что-то еще… Условие — товар д.б. штрихкодирован (в принципе поддерживается и отдельная «задача» штрихкодирования пришедшего товара — но это отдельный вопрос).
.
Если кому интересно — могу записать живой ролик и выложить…
(84) Мне интересно. Напиши вообще статью про свое внедрение. Всем интересно будет.
(0) Программа просто хранит информацию или есть какая то функция оптимизации потоков/хранения?
(86) Если программа только хранит информацию, то это учетная система и не может обозначаться как WMS (система управления складом).
(76) Сергей, безусловно Ваша статья (надеюсь, что будет продолжение) интересна как концептульная, каковых появляется все меньше или они «тонут» в очередных ВПФ, и как говориться «зацепило»!
Если немного отвлечься от «специфики» 1С, то видим 2 подхода к проектированию систем/подсистем, а именно:
Подход А – проектирование «сверху-вниз» (сквозное, комплексное) — то что Вы и представили, преимущества которого очевидны (система как единое целое, по крайней мере непротиворечивые бизнес-процессы, единые подходы к интерфейсу, информационному пространству, движкам и т.д ). Но и недостатки – время, цена, высокая квалификация проектировщика (методология) – иначе «не взлетит». Здесь уже неизбежно приходиться сравнивать с аналогами и решать «простой» вопрос, как говорил один из моих учителей – «а где изюм» .
Подход Б – проектирование «снизу-вверх» (мне нравится мем — «лоскутная автоматизация» — поясню ниже). Преимущества также очевидны («здесь и сейчас», цена, требования к исполнителю), но и недостатки на лицо ( «за деревьями не вижу леса», переделывание/доработка уже сделанного, если Заказчик захочет развития («требую продолжения банкета, ибо…») — качество проекта в целом, да и сроки). Сам неоднократно «наступал на эти грабли», да и участники обсуждения говорят об этом (последняя фраза в посте (63)). И дело не в том, что не хватает квалификации (методологии), а в том, что эти недостатки имманентны самому подходу — «за все приходится платить». А кому то действительно – не хватает – за такими просто «выноситься мусор» и проект начинается заново – жизнь – (не так давно так и пришлось поступить в одном проекте- хоть Заказчик и заплатил деньги (приобрел «опыт») – «не взлетело»).
Кажется, что противоречия между этими двумя подходами «принципиальны и неустранимы» — но это МИФ!!!
Поясню кратко, пользуясь терминологией IDEF. Если Вы имеете понимание «идеальной» «TO BE» в замен реальной «AS IS», и корректную ее декомпозицию до какого-то N-го уровня (лучше, как показывает опыт, до N+2), где задача A-N.x.y.z уже четко выделена и понятны ее связи по входу/выходу/управлению/ресурсам со всеми остальными – то возможно начать проектирование ВСЕЙ системы A0 (c которой и начиналась декомпозиция) именно с ЭТОЙ задачи A-N.x.y.z!!!
Именно такой подход мной и был предложен для рассмотрения.
А по-русски это изложил в посте выше, когда сняв ограничение на ПО ТСД (ресурс) появилась возможность изменить концепцию (A0) в сторону ее расширения.
P.S. «Лоскутная автоматизация» — не обидный термин, именно этим мы и занимаемся бОлшую часть своего времени, работая с «1С» — просто за этими красными, желтыми и синими «лоскутами» НУЖНО видеть многоцветное красочное ОДЕЯЛО!!!
Удачи…
(84)Спасибо за предложение!
А то о чем сказал — мышку Клавку не используем — а работаем…
(89) я когда ТСД «отлаживал», ходил по складу целый день — потом постоянно в экран монитора большим пальцем тыкал…
(92) Вы правы в том, что ЕСТЬ системы где «в действительности управляет ОПЕРАТОР или ПРОГРАММИСТ».
Вы можете даже в Интернете найти красивые скриншоты «решений на 1С», где оператору можно 10 разными способами назначить исполнителя для выполнения заказа. В этом плане да — управляет оператор, а все что делает система — ведет адресный УЧЕТ на складе и фиксирует норму выработки (по листку или ТСД — не важно).
НО в нормальных WMS оператор ничего никому не назначает. Его основная задача — печатать сопроводительные документы для отгрузки, ставить печати и держать связь с отделом продаж. Начальник склада сидит у себя и мониторит работы — если что-то пошло не так, то может скорректировать приоритеты в программе или выйти на склад и дать кому-то пендалей.
Все остальное делает именно WMS — она самостоятельно выбирает для каждого сотрудника лучшую задачу на текущий момент времени и склад работает как улий. Есть такая вещь как человеческая лень, так вот на это есть мотивация персонала (премии, пинок начальника склада, увольнение)…
А как же склады, где во всю используются конвееры и автоматизированные стеллажные хранилища? Там WMS тоже ничем не управляет и оператор кнопочками выбирает из какой ячейки автомату взять товар?!
Если вам не нравиться слово «управляет», давайте заменим на «распределяет задания».
Выложил статью, которую два года назад писал в журнал «Логистика и управление» (журнал в 2010 году закрылся)
В ней немного подробней описаны функциональные требования к разным процессам работы склада.
Ссылка на статью:
(93)Сергей, спасибо за ответ!
Для меня бесспорно то, что данное подробное обсуждение привело к СИНЕРГИИ ВСЕХ его участников!
Удачи…
В продолжении разговора статья
— разработка от БИТ
Кортес: адресный склад —
Как вы думаете, из списка WMS на 1с8 предложенных в статье, какие 3 лидера системы можно выделить как — высокая производительность, гибкость/адаптируемость(хотя бы вплане настроек)?
для меня очевидно что в (93) — написано так как мне хочется и так как должно быть. мой мелкий опыт показывает что там, где «управляет» оператор — все время идут затыки и нестыковки…
(91) (A),
Показательно время, которое занимает вычислительный процесс, в результате которого программа выдаст информацию необходимую для принятия решения (например, у меня это операция расчета адресов, которые доступны для размещения/снятия продукции — писал выше).
А если при сканировании ШК просто идентифицируется ТМЦ, то это не показатель.
В системе, которяа позиционируется как универсальная я очень сомневаюсь что что-то «тяжелое» (например план размещения или отбора, пусть даже для 1 паллетоместа) будет рассчитываться в онлайн-режиме именно тогда, когда паллет берут на размещение/отбор. Просто потому, что для универсальной системы это неприемлемо с тоxки зрения возможных тормозов и ожидания на ТСД. Все что можно насчитать заблаговременно считают потихоньку регламентыми заданиями заблаговоременно, без напряга. Это вообще рулит/кузяво на 100% на «линейно-временных» складах (каждая входящая заявка отгружается позже уже существующих), где очередь заданий/заявок обрабатывается по ФИФО. Когда же практически в любой момент план обслуживания заявок меняется на 50% (да и при ФИФО-заблоговоременных просчетах нет-нет да бывает нужно) — заблоговременный план обслуживания — приходится пересчитывать…