gifts2017

WMS на базе 1С:Предприятие 8 - покупка готового решения или самостоятельная разработка?

Опубликовал Сергей Рубанов (rsergio) в раздел Управление - Управление проектом

То что 1С:Предприятие 8 сейчас используется в большинстве компаний в качестве системы управленческого, торгового, финансового и бухгалтерского учета - уже давно не секрет. Но на складах 1С чаще применяется лишь как часть модуля Управление Торговлей и все больше задаются вопросы "А можно ли 1С 8 использовать на складе как полноценную WMS систему?"

Давайте попробуем разобраться и попытаться ответить на два вопроса:
1. Можно ли использовать 1С на складе?
2. Что выбрать - купить готовое решение или самостоятельно разработать собственный продукт?

Введение.

Давайте попробуем разобраться и попытаться ответить на два вопроса:
1. Можно ли использовать 1С на складе?
2. Что выбрать - купить готовое решение или самостоятельно разработать собственный продукт?

Многие задаются вопросом "А если вообще выбор из WMS на базе 1С?"

На текущий момент можно найти следующие коммерческие решения систем управления складом, разработанные на платформе 1С:Предприятие 8:

- 1С:Логистика 3.0 и 4.0

- Penta WMS

- TopLog WMS

- ARENA.WMS

- CargoPrime: WMS

- Кронос: WMS

- Sevco WMS

- Warehouse Management Suite от IT-Scan

- АСТОР:WMS

 Первопроходцем можно считать решение 1С:Логистика, которое является самым массовым продуктом т.к. распространяется коробочное решение через сеть 1С. В версии 3.0 были исправлены многие ошибки предыдущей версии, оптимизированы методы хранения данных и проведена работа по борьбе с блокировками при работе нескольких пользователей одновременно. Но есть ограничения - т.к. продукт коробочный и массовый, то функционал адаптации к конкретному складу не сильно развит, поэтому на многих проектах требуется доработка программного кода. Версия 4.0 уже написана под платформу 8.2 на управляемых формах и содержит больше параметрических настроек.
На основе анализа первых версий этой системы, которые не отличались какой-либо мощной функциональностью, сложилось мнение, что WMS на базе 1С – это только для маленьких складов и небольших фирм. Многие консультанты известных WMS систем составили целый список ограничений, которыми пугают клиентов о проблемах систем на 1С

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

В других же решениях платформа 1С используется лишь как интерфейс, а в качестве хранения и обработки данных используется собственное ядро. Такой подход обусловлен скорее некоторой истории самой компании или имеющихся у них на тот момент решений, чем сложностью реализации нужной специфики на самой платформе.

Выбор 1С в качестве платформы для разработки.

Но данная статья не о выборе того, или другого решения, а о возможности реализации полноценной системы управления складом на платформе 1С.

Почему именно 1С? Все очень просто – эта платформа позволяет достаточно быстро создавать решение, имеет очень богатый функционал «из коробки», узнаваемый и удобный интерфейс, невысокая стоимость самой платформы и сопровождения, наличие большого количества специалистов на рынке труда, которые смогут продолжить развитие системы после увольнения текущих сотрудников.

Так почему 1С заслужила такую плохую «славу» в области решения задач автоматизации склада?

Все дело в том, что стандартный подход, который мы привыкли видеть в типовых конфигурациях «Документ – Движение – Регистр накоплений» не совсем подходит для склада, который работает в режиме реального времени потому что:

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

Многие разработчики коммерческих решений выявили эти проблемы и заменили табличную часть на список простых документов, ссылающихся на «главный», или список регистра сведений с ведущим измерением, которым является исходный документ-шапка. Это позволило распараллелить процесс проведения больших документов, вернее позволить обрабатывать документ построчно разными сотрудниками склада.

Вторым шагом к избавлению «болячек» 1С при реализации сложной системы управления складом является избавление от регистров накоплений в пользу регистров сведений и написания собственного движка выполнения движений.

В итоге получилось то, что платформа 1С превратилась в инструмент манипулирования простыми таблицами, где все действия контролирует разработчик, а не платформа.

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

И эту задачу можно решить совсем простым способом – построить структуру базы данных так, чтобы все расчеты выполнялись в запросах на сервере SQL, а сама платформа занималась лишь выводом результата пользователю.

А т.к. язык запросов в 8 версии платформы повторяет язык SQL, то мы получаем в руки решение, где сама платформа уже не является ограничивающим моментом и теперь все зависит от квалификации системного архитектора и программистов.

В «подарок» мы получаем большое количество механизмом, которые можно использовать в решении – управляемые блокировки, фоновые задачи, работа с почтой и ftp, настройка прав доступа, клиент-серверное решение с возможностью использования кластера серверов, мощный инструмент вывода отчетности, практика работы с торговым оборудованием и т.п. и т.д.

Отсюда хочется сделать вывод и ответить на первый вопрос:
Создание полноценной WMS системы на базе 1С возможно! 

Но "возможно" не означает, что можно сразу же поставить задачу собственному отделу разработки и он в приемлемые сроки выдаст хорошее решение, полностью удовлетворяющие потребности текущего склада.

Теперь перед нами встает другая задача:

  1. Купить готовое решение вместе с услугами по доработке и внедрению
  2. Купить готовое решение, но все работы провести самостоятельно
  3. Разработать собственное решение

Попробуем рассмотреть все варианты.

Покупка готового решения вместе с услугами по внедрению. 

Такой вариант имеет самые низкие риски, но возможно (именно возможно) самую дорогую цену.
Перед выбором поставщика можно детально ознакомиться с решением, посмотреть уже автоматизированные склады, пообщаться с начальниками складов и в итоге купить не "кота в мешке", а все же готовое и рабочее решение.

В случае, если решение окажется не достаточно гибким можно постепенно дорабатывать его с помощью собственного ИТ отдела, что существенно снижает стоимость поддержки, но повышает риск испортить работающую систему неграмотными доработками.

Какие сложности мы можем получить? Может так получиться, что за вполне хорошие деньги наш склад будет работать не самым оптимальным образом и попытка дожать разработчика закончиться или его сопротивлением т.к. бюджет будет уже исчерпан, или дополнительными инвестициями и увеличением сроков внедрения, которые вы не можете контролировать.

Покупка готового решения с самостоятельным внедрением.

Это решение куда бюджетней, хотя может оказаться, что то решение которое вам очень понравилось, попросту отдельно не продается как коробочный продукт.

В целом такой подход можно применить если вы уверены в силах собственных специалистов, не готовы нести затраты на собственную разработку и хотите за минимальные деньги и минимальное время автоматизировать собственный склад, а далее спокойно тиражировать это решение на другие склады.

Разработка собственного решения.

Данный подход можно применить только если:

  1. У вас простые складские процессы и небольшие требования к функционалу.
  2. Или есть планы по коммерческому продвижение полученной разработки.
  3. При этом имеется штат специалистов очень высокого класса, которые не только хорошо знают платформу 1С, но имею большой опыт в оптимизации запросов SQL и также разбираются в предметной области.

На практике есть как положительный опыт, так и отрицательный.
Я был на складах где собственное решение отвечало всем запросам склада, хотя и не являлось каким-то гибким решением.
Также есть и опыт наблюдения, когда в течении 3-х лет решение постоянно модифицировалось, компания несла большие затраты на собственную команду разработчиков, а процессы на складе были далеки от того, что можно было бы получить при внедрении даже самой простой коммерческой WMS на базе 1С.

Но стоит отметить тот факт, что многие решения, приведенные вверху статьи, как раз родились при самостоятельной разработке и доведенные до готового решения вышли на коммерческие рельсы. Только уверены ли вы, что именно вашей команде посчастливиться разработать успешную конфигурацию и отбить деньги, затраченные на ее разработку?

Так как же разработать правильную WMS на 1С?! 

Если вы все-таки решились самостоятельно разработать собственную систему автоматизации склада, то вот несколько советов:

  • Запаситесь терпением - рабочий продукт выйдет не раньше чем через год начала разработки (при соблюдении всех других требований)
  • Не пытайтесь найти логистов, которые поставят задачу программистам - разработчик должен понимать что он автоматизирует, иметь опыт работы на складе и хорошо знать известные WMS, чтобы не изобретать велосипед
  • Отнеситесь очень ответственно к планированию архитектуры решения - от этого зависит "взлетит или не взлетит"
  • Не используйте типовой подход - проведение документа с записью в регистры накопления
  • Используйте управляемые блокировки
  • Перенесите всю логику работы в запросы, код выполняется максимально возможно на сервере и сведите к минимуму обработку данных в циклах.
  • Пользуйтесь фоновыми заданиями, но не пытайтесь решить с помощью их те вопросы, которые не получается решить с первой попытки (типа каждые 5 минут проверять не нужно ли удалить что-нибудь)
  • Пытайтесь вынести все настройки из кода - это впоследствии позволит быстрее проводить модификации, а также позволит рассматривать продукт в качестве коммерческого решения.
  • Не пытайтесь сделать систему гибкой за счет существенного ухудшения быстродействия - планируйте архитектуру с умом, чтобы все возможные внешние настройки не превращались в большое количество запросов к базе данных.
  • Обязательно анализируйте запросы на стороне SQL сервера для поиска ошибок в архитектуре системы на ранних этапах, когда еще можно избежать больших ошибок.
  • Если вы изначально заложились на разработку коммерческой системы, то подход постепенной разработки по мере необходимости той или иной функции тут не подходит - оцените потребности различных складов и заложите их на этапе проектирования системы.
  • Пишите сразу же универсальный движок работы с терминалами сбора данных т.к. впоследствии писать отдельную форму под каждый процесс совсем не практично.

 Вот и все.

С уважением, Рубанов Сергей, руководитель разработки системы управления складом ARENA.WMS

 

 

 

См. также

Подписаться Добавить вознаграждение

Комментарии

1. roman romanov (rsu555) 13.11.10 23:03
"Запаситесь терпением - рабочий продукт выйдет не раньше чем через год начала разработки"

вот с этим я полностью согласен. вернее сроки могут быть разные, но спешка в данном вопросе без опробирывания процесса программистом невозможна, вернее даже без тестирования на реальном объекте
2. script Мальчинко (script) 14.11.10 01:24
Позновательно. Хотя мне лично хотелось бы по подробней узнать почему не регистры накопления....
3. Владимир (hogik) 14.11.10 02:02
(0)
Многое, из сказанного в публикации, актуально и для других участков "автоматизации управления", а не учета документов.
(2)
Подробно, надеюсь, автор расскажет.
Кратко.
В жизни - накопление на реальных полках, а не на датах в регистрах накопления.
4. Александр Рытов (Арчибальд) 14.11.10 11:57
Похоже, что второй путь - это, на самом деле, третий, только со стартовой площадкой. Если предполагаются серьезные доработки, то рано или поздно выяснится, что система состоит из сплошных заплаток, и надо ее переписывать заново.
(2) Регистры накопления сразу порождают проблемы с последовательностью документов, с проведением "задней минутой" и всем сопутствующим букетом.
5. Сергей Рубанов (rsergio) 14.11.10 12:23
(4) При серьезных изменениях в системе можно второй путь переквалифицировать в третий, но если изменения косметические (формы, печать документов) и нужно только настроить интеграцию с КИС, загрузить справочники и ввести топологию с алгоритмами размещения, резервирования и пополнения, то все же здесь не так нужны очень сильные программисты. Вполне хватит хорошего программиста + адекватного логиста.
6. Александр Рытов (Арчибальд) 14.11.10 12:33
(5) "только настроить интеграцию с КИС" - сильно сказано :D
7. Сергей Рубанов (rsergio) 14.11.10 12:37
(6) Как правило, все разработчики WMS уже имеют готовые модули интеграции с различными КИС, в том числе, конечно, с 1С.
В случае типовой конфигурации все совсем просто, даже специалисты WMS могут это сделать за вас.
Если конфигурация не типовая, или с большим кол-вом доработок, то уже имея готовый модуль нужно его адаптировать к текущей КИС.
Это касается обмена данными.
Нужно еще понимать, что в интеграцию нужно закладывать изменения некоторых процессов в КИС, связанных с тем, что меняется процесс отпуска товара со склада.
8. Александр Рытов (Арчибальд) 14.11.10 12:48
(7) У меня все происходило ровно наоборот. Провда, не с серьезной WMS, а с простенькой системой учета на заготовительном складе - особенностью было только объем приходов, до 100 в час на оператора. Пока работали на самописной конфигурации, пользовались самописным же блоком сопряжения, а потом купили другую - тоже на 1С, но без малейшего сопряжения :o
9. Владимир (hogik) 14.11.10 15:07
(7)
"в интеграцию нужно закладывать изменения"(с)
Если говорить об 1С - возможно.
В других случаях, интеграция обеспечивается общей БД с открытым описание схемы базы данных. И ОНО само интегрируется по мере развития системы. Задачи "интеграция" не существует. Равно, как и самостоятельной "WMS", изолированной от всего остального. Ну, возможно, существует для удобства продажи "готовых модулей". ;-)
10. Сергей Рубанов (rsergio) 14.11.10 15:12
(9) Не понял мысли.
Интеграция может выполняться различными средствами - с помощью обмена файлами, выделенной БД, непосредственная запись/чтение из БД КИС, OLE и т.п.

Разные WMS предлагают разные варианты интеграции - кто-то использует только-ко один какой-то формат, кто-то предлагает несколько форматов, по выбору клиента.

"оно само интегрируется" - как?
Зачастую структура хранения данных в КИС и WMS может сильно различаться, поэтому нужно проводить в соответствие данных из одной системы в другую.
11. Владимир (hogik) 14.11.10 15:29
(10)
В идеале, структура хранения данных должна разрабатываться не под отдельные задачи (системы), а под предметную область. Т.е., грубо говоря - создаётся банк данных и уже на данные "навешиваются" задачи. Давным-давно для этого были придуманы СУБД. Не для продвинутой системы ввода/вывода, как это сделано в "1С 8.х", а для интеграции информации. Но, думаю, это другая тема.
А под Вашу статью я поставил "плюс", т.к про 1С говорим в данной теме. Не про "идеал"...
12. Игорь Исхаков (Ish_2) 15.11.10 09:51
Приводить в теме как императив сугубо частное решение :
отказаться от регистров накопления - на мой взгляд , неверно.
Как некоторый способ , который ,может быть, приведет к успеху , пожалуй.
Как некое универсальное средство - НЕТ.
Судя по-всему, автор наелся борьбой с задним числом и с проведением документов с большой табличной частью , что и привело его к такому паническому выводу.
Можно заметить , что в регистр накопления можно писать не только в режиме замещения , но и добавления . Т.е. не меняя предыдущие движения записывать только изменения табличной части. Тоже не идеал - со своими плюсами и минусами, но такой подход возможен.
Речь не о том , что такой подход намного лучше , а речь о том , что указывать в теме как императив : Откажемся от регистра накопления ! - на мой взгляд , неверно.

13. Александр Рытов (Арчибальд) 15.11.10 10:03
(12) Это не сугубо частное решение. Это универсальное перспективное направление. Или, другими словами: регистры накопления, как они реализованы в 1С, - источник гемора с максиматьным дебитом.
14. Сергей Рубанов (rsergio) 15.11.10 10:25
(12) Вы плохо прочитали статью или не в теме...
В WMS нет работы задним числом по определению, все остатки должны хранится только на текущее время.
В WMS нельзя работать с большой табличной частью разом т.к. строчки "расхватываются" исполнителями и выполняются постепенно и параллельно.
Ни одна западная WMS, которую я разбирал на косточки, не использует механизмы, похожие на регистр накоплений в 1С.

Поэтому мой совет прозвучал в статье, если считаете по другому - я не спорю, но очень хочется увидеть хорошую и быструю WMS в вашем исполнении на документах и регистрах накопления...
CheBurator; hogik; +2 Ответить 2
15. Борис Скворцов (gaglo) 15.11.10 10:31
(2), (12) - отказаться от регистров накопления - в данном случае (управление складом) верно потому, что функционал РН резко избыточен. Просто надо понять, что на складе никого не интересует остаток товара в ячейке 11-А-3-15 на момент 01.04.2009 17:32 - важно, какой остаток сейчас. И держаться за механизмы РН только потому, что это кажется теоретически неверным, не следует. В задачах других они на месте, а здесь, увы, просто не нужны.
16. Сергей Рубанов (rsergio) 15.11.10 10:36
(15) Я бы так дополнил - знать остаток в ячейке 11-А-3-15 на момент 01.04.2009 17:32 порой бывает нужно, но процент этой необходимости настолько мал, что не стоит периодически рассчитывать остатки в регистре накоплений, тем самым раздувая его и замедляя получения из него информации.
Для цели получения остатка в любой ячейке вполне хватит механизм расчета, где берется текущий остаток в ячейке и отматываются движения по журналу транзакций до нужной даты.
Тем самым мы оставляем возможность для разбора полетов посмотреть остатки на любую дату (возможно более медленным путем), и оставляем в регистре остатков только актуальные данные, что позволяет достаточно быстро получать нужные остатки.
Но это не единственное преимущество.
17. Александр Рытов (Арчибальд) 15.11.10 11:00
(16)
знать остаток в ячейке 11-А-3-15 на момент 01.04.2009 17:32 порой бывает нужно
Для работы склада это не нужно никогда. Для разбора полетов же интересно знать, в какой момент данные учета перестали соответствовать фактическим данным - но тут никакая учетная система не поможет. Несоответствие данных в двух учетных системах... Это уже вопрос интеграции систем, к каждой из этих подсистем он опять-таки не относится. Здесь более продуктивно замечание (11).
18. Игорь Исхаков (Ish_2) 15.11.10 12:05
(14) Возможно, не в теме . Сейчас узнаем.
Не увидел никакой проблемы в раздельном вводе в один документ.
Как организовать одновременный ввод разных пользователей в один документ так , чтобы они не мешали друг другу ?
1. Первый пользователь заполняет все необходимые реквизиты документа, которые другим пользователям недоступны для редактирования.
2. Остальные пользователи имеют на форме табличное поле с типом ТаблицаЗначений.
В момент открытия в ТаблицуЗначений выгружаются только те записи из табличной части документа , которые были введены им ранее. Если это первый ввод , то ТаблицаЗначений пуста.
3. Пока конкретный пользователь вводит свои строки в ТаблицуЗначений документ может как угодно меняться. Перед записью документа пользователем происходит считывание объекта ("Прочитать()") и только затем событие Записи объекта с удалением из табличной части "старых" строк пользователя и добавлением новых из ТаблицыЗначений.

В чем тут проблема ?
Чем оформление для каждой строки отдельного документа лучше ?
Можно поговорить и эффективном быстром проведении такого документа по регистру накопления (режим только добавления записей в регистр с типом "обороты" или "остатки").
19. Сергей Рубанов (rsergio) 15.11.10 12:13
(18) Пока нет возможности объяснять на пальцах с примерами почему такой подход более оптимален при работе на складе с использованием терминалов сбора данных.

Давайте начнем с конца, с регистра накоплений. Он состоит из двух таблиц - таблицы движений и таблицы остатков. Пользователю доступно управление только таблицой движений, таблица остатков живет своей жизнью, которой управляет платформа. Далее - в таблице остатков актуальные данные записываются с указанием далекой даты, а также каждый месяц рассчитываются остатки за прошлые периоды.
Теперь попробуем понять насколько удобно SQL серверу выбирать данные из такой таблицы, которая содержит как нужные нам данные, так и лишние. Конечно, индексы по периоду рулят, но зачем нам такой механизм, которым не можем управлять и которых хранит избыточные данные?
20. Игорь Исхаков (Ish_2) 15.11.10 12:23
(19) Как общие и очевидные соображения - принимается.
Как конкретный аргумент при выборе варианта регистра (одного из нескольких) сомнителен.
Разумеется, Вам виднее в Вашей разработке. Но Вы -то делаете общий вывод и приводите его читателям : "Откажемся от РН !".
Никаких обоснований не приводится. Дескать , а чего тут думать ?
Против этого я и возражаю в своем первом посте , если Вы внимательно его читали.
21. Сергей Рубанов (rsergio) 15.11.10 12:33
(20) Я написал статью, основываясь на своем опыте детального изучения архитектуры БД таких WMS систем как EXceed 4000, Manhattan ILS и PSIwms. Каждая из них имеет уникальную архитектуру, но во многом они сходятся. Также могу сказать, что все эти базы никак не подходят ни под один уровень нормализации - их таблицы заведомо избыточны данными и сделано это все для одного, быстродействия!
Также у меня есть возможность наблюдать за развитием решения 1С:Логистика и эти ошибки также там проявляются.
Переход на регистры сведений - это не моя выдумка, это тенденция - рассмотрите другие решения и вы поймете, что многие уже так поступают.

Это не научная статья, размещенная в популярном журнале. Это лишь мое мнение, основываясь на опыте работы с WMS (как пользователя, как заказчика, так и разработчика и внедренца) - использовать мои рекомендации или нет решать вам.
Но пока разработчики WMS на 1С закрывают глаза на международную практику разработки таких решений, то мы получаем результат - заказчики до сих пор не верят в возможность установки системы автоматизации на платформе 1С. Приходиться им долго объяснять, возить на склады, показывать статистику и т.п.

Отсюда возникают такие вот вопросы:
http://logist.ru/forum/YaBB.cgi?board=it;num=1289141503

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

Но еще раз предлагаю окунуться в специфику работы на складе и понять, что она никак не пересекается с финансовым/управленческим учетом.
odin777; CheBurator; +2 Ответить 3
22. Игорь Исхаков (Ish_2) 15.11.10 12:36
(21) Ок. Как дилетанту в складском учете мне было интересно познакомиться с Вашей статьей.
23. Сергей Рубанов (rsergio) 15.11.10 12:44
(22) Спасибо за оценку.
Если будет время, то попробую в следующей статье подробней описать особенность организации учета на складе.
И Вы поймете, что подход работы "от документа" сильно ограничивает и заставляет писать всевозможные обработки, которые как-то пытаются имитировать работу в режиме реального времени.

Например, одно из странных ограничений первых версий 1С:Логистика было в том, что нельзя было размещать принятые паллеты до окончания процесса приемки. Это было связано с тем, что не закрыв один документ и сформировав другой, пользователь на терминале не смог сформировать задачу на перемещения паллеты.

Хоть я может и открываю некоторые "секреты" для конкурентов, но моя позиция сейчас схожа с той, что обозначена в "ДАО Тойота" - развивайте конкурентов и вы поднимите отрасль в целом! (под отраслью я понимаю WMS на базе 1С)
24. Игорь Исхаков (Ish_2) 15.11.10 12:50
(23) Честно говоря , прочитав , хмыкнул.
Критика конкретного решения в "1с-Логистика" вовсе не означает ущербность самого подхода "от документа". Вообщем , подождем следующую статью с критикой похода "От документа". Кажется , на ИС об этом никто не писал (но могу соврать).
25. Сергей Рубанов (rsergio) 15.11.10 12:56
(24) В последней версии 1С:Логистика как-раз во всю используются регистры сведений и управляемые блокировки.

Ребята из Logiton (сейчас Penta и TopLog) уже давно избавились от табличной части (еще в 2007 году, когда в 1С:Логистика версии 2.0 был классический подход и куча ограничений по функционалу).

Поэтому, как минимум типовое решение "документ с табличной частью и движением в регистры накопления" уже многие из разработчиков WMS не применяют.
26. Игорь Исхаков (Ish_2) 15.11.10 13:54
(25) Интересно узнать , а рассматривалось ли следующее решение :
Отказаться от регистров вовсе при оперативном учете .
И сделать учет на справочниках .
Реквизит в справочнике один : Ссылка на Номенклатуру. Табличных частей - две. Первая для всех движений , Вторая имеет два реквизита Склад и Остаток.
В первую ТабЧасть пишутся движения с указанием документа только в конец (если исправление, то вначале сторно потом само значение). Во вторую таб.часть пишется (исправляется остаток на складе).

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

Это , разумеется , экспромт , как и пост о раздельной работе пользователей. И всё-таки ?
27. Сергей Рубанов (rsergio) 15.11.10 13:59
(26) Для таблицы остатков есть определенное требование - составной индекс т.к. учет идет в нескольких измерениях (номенклатура, партия, ячейка, паллета).
Этим требованиям удовлетворяют только регистры сведений и накоплений.

Когда 1С сделает возможность создавать составные индексы для справочников и его табличных частей, то можно рассмотреть и этот вариант.
28. Игорь Исхаков (Ish_2) 15.11.10 14:05
(27) Да , не продумал. А жаль. Проблема с блокировками и тормозами просто исчезает.
29. Сергей Рубанов (rsergio) 15.11.10 14:17
(28) Табличная часть справочника - это такая же таблица, просто у нее уже есть предопределенный реквизит "Владелец" ссылающий на номенклатуру, и соответствующий индекс по владельцу.

Создание регистра сведений с измерением "Номенклатура" и индексом повторяет эту конструкцию (я часто вместо табличных частей использую именно регистры сведений т.к с ними удобней работать).
30. Игорь Исхаков (Ish_2) 15.11.10 14:26
(29) Разумеется . С одним только НО.
Запись в табличную часть элемента справочника блокирует только этот элемент справочника. В остальные пиши - сколько хочешь. Т.е. главное преимущество справочника - распараллеливание операций , невозможное для регистра , записи которого не обладают объектной сущностью.

P.S. Если главная цель распараллеливание , то игра стоит свеч.
Во второй табличной части предусмотреть те же реквизиты , что и в регистре .
И тогда новое движение ищет по своим реквизитам остаток во второй табличной части и исправляет его. Если не находит , то осуществляет новую запись.
Т.е. в принципе такой возможен и мы достигаем превосходного распараллеливания. Ну , а насколько удобен подход в других аспектах - тот еще вопрос.
31. Сергей Рубанов (rsergio) 15.11.10 14:30
Не пойму какое распараллеливание при использовании табличной части справочника?
Если посмотреть на таблицы SQL то никаких преимуществ нет.

Если смотреть на модель поведения 1С, то табличные части проигрывают регистрам сведений. Их удобство только в автоматизации подвязки их к справочнику.

При работе с объектом номенклатура мы блокируем этот объект, т.е. если в разных частях склада разные сотрудники отбирают из ячеек один и тот же товар, то они встанут в очередь. При использовании управляемых блокировок для регистров сведений они параллельно запишут информацию в БД.
32. Игорь Исхаков (Ish_2) 15.11.10 14:57
33. Александр Рытов (Арчибальд) 15.11.10 15:30
(27) Таким требованиям полностью отвечают "БухгалтерскиеИтоги", где "план счетов" идентичен физической структуре хранилища, а содержимое = субконто.
34. Сергей Рубанов (rsergio) 15.11.10 15:31
(33) ИМХО БухИтоги - это самое последнее, на чем можно пытаться строить WMS :)
35. Александр Рытов (Арчибальд) 15.11.10 15:50
(34) ИМ - это хорошо. ХО - и не собираюсь. А аргументация?
36. Сергей Рубанов (rsergio) 15.11.10 15:54
(35) Устал приводить аргументы, если кто хочет писать WMS на бухитогах - готов поучаствовать в тестировании конечного решения.
37. Владимир (hogik) 15.11.10 20:32
(24)
"...подождем следующую статью с критикой похода "От документа".(с)
Игорь.
Эта статья уже давно написана, самими определением:
"Все хозяйственные операции, проводимые организацией, должны оформляться оправдательными документами, которые называются первичными. Первичные документы принимаются к учету, ..."(с)
Т.е. из этого следует, что "сущность документа", расположенного в БД, является отражением и учетом документов. И такая схема БД ориентирована именно на сбор и учет (хранение) документов. Со всеми вытекающим особенностями: проведение, последовательности по дате расположения документа в БД и т.д.
Но, с точки зрения "бумажной жизни", документ это только удобная форма отражения реальных хоз.операций (ХО). Типа, меньше писать руками. И писать в определенных местах бумажки. Часто с объединением нескольких ХО в одну бумажку.
Но ХО выполняются с реальными объектами жизни и только отражаются в документе. При наличии "автоматизации" совершенно логично в ЭВМ-у заносить факты выполнения ХО, а не факты их отражения документом. А документы только представлять как единое целое в момент получения бумажной копии (если она требуется).
Т.е. в "подходе От документа": ХО->БумажныйДокумет-ДокументБД-ЗаписиПроХО
А в другом подходе: ХО-ЗаписиХО-БумажныйДокумент.
Исчезает совершенно лишняя "сущность".
Т.е. учитывается и автоматизируется реальна жизнь, а не бумажки.
И в этом смысле, огромным ;-) прорывом в "1С 8.х" является появление "Регистра сведений". В 7.7 это приходилось реализовывать на справочниках.
И для осознания такого "подхода" не требуется быть специалистом в "складском учете". Такой подход реализуется и требуется для любого участка АСУП-а...
kiruha; CheBurator; Арчибальд; rsergio; +4 Ответить 3
38. Eugeneer (Eugeneer) 15.11.10 20:36
Хорошая статья. Спасибо автору.
39. Сергей (Che) Коцюра (CheBurator) 16.11.10 01:11
Поддерживаю мнение автора. Особенно в части "важно что сейчас", прокрутил в 7.7 ТиС свою простенькую WMS, строил на справочниках и внешних файлах. Работает! При этом работает ВМЕСТЕ с КИС.
Хочу также обратить внимание на такую проблему как интеграция WMS с КИС - вот здесь вот может быть много бяк (имхо). Самый простой пример: рассогласование резервов в КИС и WMS - отклонения при сборке - вопли менеджеров и клиентов. Именно поэтому у себя "WMS" впихнул в ТиС. Отдельная WMS, возможно, имеет смысл для больших "проектов", бешенных темпов отбора и постоянного непрекращающегося товародвижения с высокой плотностью/темпом. В других случаях вполне возможно в "типовые" КИС отдельным "сейчасным" контуром вставить маленькую "WMS".
Немного покопавшись в некоторых вмсах, побродив по выставкам и поговорив с людьми - зачем нам ВМС, которая УПРАВЛЯЕТСЯ ОПЕРАТОРОМ???
40. Александр Рытов (Арчибальд) 16.11.10 08:43
(37)
Т.е. в "подходе От документа": ХО->БумажныйДокумет-ДокументБД-ЗаписиПроХО
А в другом подходе: ХО-ЗаписиХО-БумажныйДокумент.
Исчезает совершенно лишняя "сущность".
И это правильно
41. Игорь Исхаков (Ish_2) 16.11.10 10:16
(37) Вначале частность :
что "сущность документа", расположенного в БД, является отражением и учетом документов. "
Тарабарщина .
Сущность документа, расположенного в БД не является учетом документов.
Правильно так :
Сущность документа , расположенного в БД может являться как отражением "бумажного документа", так и отражением любого другого факта хозяйственной деятельности , влияющего на числовые характеристики ХО. Точка.

Затем главный тезис Владимира :
Т.е. в "подходе От документа": ХО->БумажныйДокумет-ДокументБД-ЗаписиПроХО
А в другом подходе: ХО-ЗаписиХО-БумажныйДокумент.
Исчезает совершенно лишняя "сущность".


Действительно , зачем нам эта лишняя сущность - "ДокументБД" ?
"Лишняя сущность" нам нужна для хранения реквизитов (свойств) всех ХО, составляющих документ. Нам нужно хранить НомерДокумента, ДатуДокумента как минимум.
В общем случае, нам нужно хранить в сущности-документе некоторые параметры выходящие за рамки учета БУ, но прямо влияющих на числовые характеристики всех ХО составляющих сущность - документ , например температуру воздуха в момент поступления товара. Обращаю внимание , в данном случае реквизит Документа БД не просто довесок , дополнение к ХО , а важнейшая характеристика всех ХО.

"Узко-конкретный" подход :
Отталкиваясь от частного случая (простейшего складского учета), где удобно рассматривать поступление каждого товара,перечисленного в бумажной накладной , как ХО , а реквизиты бумажного документа как довесок , дополнение - делается "глобальное обобщение" ,т.е. вывод о "лишней сущности" ДокументаБД.
42. Виталий (nafa) 16.11.10 10:49
(40)

А в другом подходе: ХО-ЗаписиХО-БумажныйДокумент.
Исчезает совершенно лишняя "сущность".

И содержимое склада моментально окажется на ближайшем рынке. 8-)
Ну для своих сотрудников положим еще можно сертифицированную ЭЦП прикрутить. А с поставщикам/покупателями что делать будем? :|

Остатки на 25.06.2008 17:25:30 нужны и регулярно:
1. Выяснение проблемных ситуаций.
2. Анализ работы (например, когда на каком участке (хранение, комплектация, погрузка и т.п.) пиковая загрузка и какая она.
3. Проведение инвентаризаций без остановки работы.
Другой вопрос, что использование РН - или нет никак с возможностью получения таких остатков не связано. РН - просто штатный механизм для некоторых расчетов. И пользоваться им надо грамотно, а не как в типовых.

А вот как раз для основной операции (отпуск товара) остатки СКЛАДУ вообще не нужны ни на какую дату, НИ ТЕКУЩИЕ. Так как если склад работает в режиме выдачи заказов, то остатки проверяются программой когда менеджер товар выписывает. (Хотя если у менеджера своя база, у кладовщика своя, у бухгалтера своя и остатки у каждого свои - то :cry: ).
А если склад работает в режиме самостоятельного набора товара (как супермаркет), остатки тем более не нужны - т.к. возможность отпуска товара определяется его фактическим наличием. И если на складе по учету 3 т дров, а покупатель набрал 5т, Вы ему что эти 2 т не отпустите что ли?

Про скорость работы. 1С конечно не сильно шустрая, но склад - это не фондовая биржа и реальные процессы на складе (т.е. кару подъехать, снять палету, отвезти на пандус, поставить в машину) по любому требуют на порядок большего количества времени требуемого на проведение этой операции в программе. (если конечно не типовая конфигурация используется :cry: ). "Тормоза из-за программы" (равно как и часто ломающиеся кары, грузовые лифты и т.п.) говорят обычно том, что начальство на пандусе редко появляется и работники предоставлены сами себе.
Регулярно в разных организациях вижу одну и ту же картину. Нужен покупателю товар, который на складе присутствует в 10 вариантах (фасонах, расцветках), причем покупатель готов взять любой фасон. Начальство менеджеру (оператору) что выписывает товар как работать с программой четких команд не выдало. В результате менеджер работает так: ставит все количество на первый вариант, пытается провести накладную ;) . Программа ему пишет: что мол списываешь 100 единиц, на складе 23 единицы, 77 не хватает :evil: . После этого количество по первому варианту уменьшается до 23, 77 ставится на второй вариант и так далее. А товаров в накладной может быть не один десяток.
CheBurator; +1 Ответить 1
43. Ярослав Радкевич (WKBAPKA) 16.11.10 10:50
аля реклама... вон, ребята из Axelota 90% времени потратили на защиту своего творения, чем на нормальную реализацию конфигурации... используя и без того медленный интерпритатор 1С, они своим кодом сделали его еще медленнее.. чего только стоит их раскраска строк! учитесь нормально кодировать!!!
44. Ярослав Радкевич (WKBAPKA) 16.11.10 10:56
вообще обсуждать WMS имеет смысл тогда, когда имеешь опыт их использования... вот у меня есть опыт использования Логистики от Axelot ... начинается все с того, что берем большой большой напильник и начинаем из танка делать самолет!
45. Сергей Рубанов (rsergio) 16.11.10 11:10
Уж простите меня грешного, но многие о проблемах учета на складе знают понаслышке.

Если бы видели работу склада хотя бы 5 т. кв.м. с персоналом в 30 комплектовщиков, которые постоянно что-то собирают, вывозят, все это кто-то контролирует, в это время параллельно товар принимается, пополняется, часть товара отгружается, а система еще загружает и запускает в работу новые заказы,
то не говорили бы о быстродействии WMS так пространственно.

Лично я на складах провел времени почти полгода и видел лица обычных русских мужиков, когда на нажатие кнопки "далее" они не получали ответа от зверской машинки. Одни бесятся, другие сразу идут курить, третьи забивают на работу ...
Также интересно наблюдать работу склада, когда на одной западной WMS при запуске заказа в 500 строк весь склад вставал в ступор на 5 минут (если для офиса это еще простительно - люди могут почитать почту, обсудить проблемы с коллегами, то на складе этот простой очень негативен).
Nexux; CheBurator; +2 Ответить 1
46. Андрей Д. (detec) 16.11.10 11:26
Регулярно в разных организациях вижу одну и ту же картину. Нужен покупателю товар, который на складе присутствует в 10 вариантах (фасонах, расцветках), причем покупатель готов взять любой фасон. Начальство менеджеру (оператору) что выписывает товар как работать с программой четких команд не выдало. В результате менеджер работает так: ставит все количество на первый вариант, пытается провести накладную . Программа ему пишет: что мол списываешь 100 единиц, на складе 23 единицы, 77 не хватает . После этого количество по первому варианту уменьшается до 23, 77 ставится на второй вариант и так далее.


Это происходит из-за использования типовых конфигураций. У нас самописка, и менеджеры прямо при вводе резервируют товар. А не при проведении.
47. Виталий (nafa) 16.11.10 12:15
(45)
Если бы видели работу склада хотя бы 5 т. кв.м. с персоналом в 30 комплектовщиков, которые постоянно что-то собирают, вывозят, все это кто-то контролирует, в это время параллельно товар принимается, пополняется, часть товара отгружается, а система еще загружает и запускает в работу новые заказы,
то не говорили бы о быстродействии WMS так пространственно.

Заказы в систему не с Луны падают. Описанная ситуация имеет место, когда начальство на работе не появляется и менеджер, получив заказ, вводит его в компьютер, только когда клиент уже грузиться приехал.
Так для справки: даже на скоропортящийся товар (охлажденка) все крупные торговые сети (АШАН, МЕТРО и т.п) заказы присылают минимум за неделю. Но даже 2 часов вполне достаточно, чтобы все полностью обсчитать и спланировать складскую и транспортную логистику даже на самом тормозном железе (имеется в виду именно "процессорное" время). Я даже представить себе не могу какой-то более-менее распространенный реальный товар, заказы на который надо обсчитывать быстрее.
Вопрос исключительно адмнистративный - чтобы сотрудники делали свою работу (в т.ч. ввод заказов в систему) вовремя а не в последний момент.
48. Сергей Рубанов (rsergio) 16.11.10 12:22
(47) А при чем тут время ввода документов в систему?
У склада есть своя нагрузка, скажем 5000 строк отбора в день, из расчета этого подбирается штат в 30 комплектовщиков + 10 контролеров + 3 водителя ричтрака +операторы + грузчики.

Все эти люди приходят с утра на работу, переодеваются, берут в руки терминал (кому он нужен) и идут работать до обеда. Пул задач им уже сформирован вчера, а также появляются новые.
Каждый комплектовщик в минуту отбирает 1-2 товарных позиций. Время ответа терминала на запрос пользователя не должно превышать 1 секунды (такое же требование у PSIwms). Теперь вспомним, что работают 30 комплектовщиков, 10 контролеров и 3 водителя ричтраков - считаем нагрузку в единицу времени.
49. Сергей Рубанов (rsergio) 16.11.10 12:34
Еще раз хочу подчеркнуть разницу между офисной системой и складской.

В офисе люди работают и ЗАНОСЯТ данные в систему учета. Если система недоступна, то могут заняться другими обязанностями - обзвонить клиентов, ответить на почту, обсудить с коллегами вопросы, открыть вторую сессию с БД и анализировать нужные данные.

На складе рядовые работники ПОЛУЧАЮТ задания от системы и подтверждают свое выполнение. Т.е. если система тормозит, то в целом весь склад работает не эффективно т.к. заставлять складских в паузах подметать полы не очень эффективно.

Поэтому к WMS предьявляются более строгие требования в плане скорости работы т.к. она УПРАВЛЯЕТ работает склада, а не является базой данной для хранения факта сделанных ХО.
CheBurator; +1 Ответить 2
50. Виталий (nafa) 16.11.10 13:13
(47)

Все эти люди приходят с утра на работу, переодеваются, берут в руки терминал (кому он нужен) и идут работать до обеда. Пул задач им уже сформирован вчера, а также появляются новые.

Если пул задач сформирован вчера то чего вообще в реальном времени считать то?


Каждый комплектовщик в минуту отбирает 1-2 товарных позиций. Время ответа терминала на запрос пользователя не должно превышать 1 секунды (такое же требование у PSIwms).

1-2 товарных позиции в минуту означает, что на каждую позицию требуется 30-60 секунд. Чего ему терминал ответить в течение секунды отвечать должен? "Заказчик передумал, положь назад откуда взял ;) " что ли?
Или просто посообщение о том, что, например, такого серийного номера нет в системе и вероятно произошла ошибка при считывании штрих-кода, надо пересканировать? - так какая необходимость это в течение секунды делать? Можно совершенно спокойно получить это подтверждение как минимум до завершения операции со следующим товаром - т.е. в течение тех же 30-60 секунд. А как более нормальное решение - в том случае, если "центральный сервер" перегружен, просто сохранить данные в терминале и передать их когда нагрузка спадет. Ведь эти серийные номера реально понадобятся только когда будут печатать накладную - т.е. когда будет собран весь заказ - а до этого момента уже небось целый час времени есть. Т.е. о чем я с самого начала говорю проблема только одна - начальство работников самих себе предоставило вот они дурью и занимаются.


Теперь вспомним, что работают 30 комплектовщиков, 10 контролеров и 3 водителя ричтраков - считаем нагрузку в единицу времени.


30 комплектовщиков, одна операция в 30-60 секунд - это одна операция в один товар каждые 1-2 секунды. Ну пусть остальные еще столько же - одна операция в один товар каждые 0,5-1 секунды. Такая скорость проведения документов обеспечивается даже типовыми конфигурациями на обычном "офисном" железе.

Вот еще из жизни пример: Склад палеттный 20,000 ячеек, автоматизация логистики выполнена местным франчем следующим образом: взяли типовую торговлю, на каждую ячейку завели по складу :cry:
51. Виталий (nafa) 16.11.10 14:03
(49)

Поэтому к WMS предьявляются более строгие требования в плане скорости работы т.к. она УПРАВЛЯЕТ работает склада, а не является базой данной для хранения факта сделанных ХО.

Вот с такого подхода бардак на складе и начинается. Типа клиент приехал, кладовщики должны ему все срочно собрать, и если терминал ему вместо 1 сек 3 думал - это все тормозит, 1С надо выкидывать, САП покупать.
А то, что этот заказ клиент неделю назад прислал, и все можно было давно собрать, скомплектовать и документы оформить, но просто в офисе его никто не почесался этот заказ в комп забить - так это же другая система, офисная, ей в реальном времени работать незачем...
pisarevEV; Aleskey_K; Nexux; +3 Ответить 1
52. Сергей Рубанов (rsergio) 16.11.10 14:08
(50) Ух... думаю, что нужно писать новую статью т.к. все комментировать нет мочи уже :)

Вы понимаете как идет процесс работы человека с ТСД на складе? Какие действия он делает, что считает система и чем она нагружена в процессе работы пользователей?

Без понимания работы людей с терминалом дальнейшие разговоры переходят в теоретические споры о смысле жизни и наличии высшего создателя...
53. Сергей Рубанов (rsergio) 16.11.10 14:13
(51) Да при чем тут клиент и его срочный приезд? Это отдельный разговор о планировании ресурсов.

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

И дело тут не в клиентах, а в пользователях системы, которые могут выполнять операции до 10 в одну секунду по одному и тому же заказу (крупный клиент), и всем им WMS через секунду должна дать ответ что делать дальше.

При этом пользователь не задумывается ЧТО именно делает система, а она подтверждает данные о выполненной операции (отбор), изменяет остатки, движения, вычисляет следующую задучу, резервирует за пользователем, выдает ему на терминал.

Если же система тратит 5 секунд на рассчет, а пользователь 30 секунд на выполнение операции, то можете просчитать процент простоя пользователя в ожидании "а что дальше делать то, а?"
54. huse 16.11.10 14:17
(0) а Ваш продукт что-то оптимизирует?
55. Виталий (nafa) 16.11.10 14:43
(53)

Если же система тратит 5 секунд на рассчет, а пользователь 30 секунд на выполнение операции, то можете просчитать процент простоя пользователя в ожидании "а что дальше делать то, а?"

Ну и где здесь простой? Положил коробку, сосканил штрихкод, терминал (пусть даже на нем софт однозадачный/однопоточный стоит - хотя тоже бред полнейший) думает, приступаешь к следующей коробке. Запас времени до следующего скана 30 секунд, и 5 секунд на ответ системы перекрывается с 6кратным запасом.
56. Сергей Рубанов (rsergio) 16.11.10 14:46
(53) А как пользователь узнает что ему дальше делать, какую коробку из какой ячейке нужно отобрать?

(54) Не понял вопроса
57. Виталий (nafa) 16.11.10 15:38
(56)

А как пользователь узнает что ему дальше делать, какую коробку из какой ячейке нужно отобрать?

В компьютерной игре "Тетрис" можно включить подсказку: показ фигурки, которая будет падать следующей. Реально помогает. И тут то же самое - если комплектовщику не дается никакой сводной разнарядки, то показывать на терминале не только текущее задание, но и как минимум следующее.
58. Сергей Рубанов (rsergio) 16.11.10 15:45
(57) В ряде случаев удобно выдавать несколько задач пользователю, они прописываются в его пул задач и выдаются из него. Но это все-равно время работы системы.

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

Мне кажется, что дискусия переходит в угадайку, а не к обсуждению практических проблем работы WMS на складе.
59. Владимир (hogik) 16.11.10 20:51
(41)
Игорь.
1) "Документа БД не просто довесок , дополнение к ХО , а важнейшая характеристика всех ХО. "(с)
Примените свои знания о "дереве" в контексте - "ДокументБД". ;-)
Документ не является "характеристикой всех ХО", а в ХО имеется ссылка на характеристику ХО под названием "ОформленоБумажнымДокументом_НомерДата".
2) ""Лишняя сущность" нам нужна для хранения реквизитов (свойств) всех ХО, составляющих документ."(с)
Совершенно верно. Только зачем эту "сущность" хранить как единое целое в БД и раскладывать (дублировать) на "ПсевдоХО" в, например, регистрах. Только для упрощения взятия этой информации запросами? Но про "запросы" это уже другая тема. Ага?
(42)
Виталий.
1) "И содержимое склада моментально окажется на ближайшем рынке."(с)
Схема БД никак на это не может повлиять.
2) "А с поставщикам/покупателями что делать будем?"
Работать на уровне "БумажныйДокумент". ;-)
60. Виталий (nafa) 16.11.10 21:55
(59)
Схема БД никак на это не может повлиять.

Там не про схему БД речь шла, а про предложение сначала товар отпускать/проводки делать, а только потом документы оформлять.
61. Владимир (hogik) 16.11.10 23:09
(60)
Виталий.
Извините, но я - зануда. И люблю ясность... ;-)
В сообщении (40) была цитата моего (37) сообщения и согласие с окончательным выводом моего сообщения. И в этих сообщениях нет слов про "сначала товар отпускать..."(с), там исключительно про схему БД в части хранения "суЧности ДокументБД". Не думаю, что Александр ("Арчибальд") согласился бы с моей мыслью "товар отпускать" без документов. Не такой он человек... ;-)
Думаю, разночтение у нас с Вами получилось.
CheBurator; Арчибальд; +2 Ответить
62. Serg Serg (sgsoft) 16.11.10 23:43
Автор обстоятельно изложил свой подход к заявленной теме. Однозначно спасибо!
Поскольку автор в своем посте (50) сказал о теоретиках, приведу для начала свою позицию, чтобы был понятен изначальный посыл.

В этом году был сделан следующий проект для родной торговой фирмы:
20.10.10 была введена в опытную, а 01.11.10 – в промышленную разработанная СОБСТВЕННЫМИ силами ПОДСИСТЕМА контроля отгрузки к уже давно работающей ТиС 7.7. Работают в ON-LINE 2 или 3 (можно больше, но пока хватает) ТСД (терминала сбора данных - для тех, кто не в теме) со считывателями штрих-кода(ШК) – по ним и работаем.
Время реакции системы от момента считывания ШК ТСД до ответа на ТСД - 1 сек.
Приведу реальные показатели (пришлось посчитать) за день: в несезон – 265 заказов (2558 строк), в сезон – 477 заказов (6937 строк).
Разработка начата в июне с.г. , в июле еще доработал концепцию подсистемы (по результатам теста ПО, прилагаемого к ТСД – в результате пришлось написать свое СОБСТВЕННОЕ - и это развязало руки). Это все с нуля, считая выбор оборудования, закупку, доставку, монтаж и настройку WiFi, разработку ПО для 1С и ТСД, тестирование связи 1С и ТСД – т.е. за 4 МЕСЯЦА – вдвоем со своим починенным программистом 0,5 года опыта с 1С после института.
Причем изначально планировалось, что функционал будет наращиваться, это и инвентаризация, внутрискладские перемещения, приемка товара и – далее куда угодно.
Поскольку данный проект успешно и устойчиво работает и параметры сравнимы с приведенными автором – можно подискутировать.

1. Автор в посте по приведенной им ссылке (21) утверждает, цитата - «Создание своей некоммерческой WMS на 1С – это утопия. По своему опыту могу сказать, что первый более-менее рабочий прототип выйдет только через год разработки. При условии…» - конец цитаты. Пришлось показать, что утверждение автора – МИФ!
2. В своей постановке вопроса автор исходит из посылки, что фирма для СКЛАДА, а не склад для ФИРМЫ. Это возможно, когда складская логистика является не ВСПОМОГАТЕЛЬНЫМ, а СТЕРЖНЕВЫМ бизнес-процессом, , т.е. тем БП, в котором собственно создается ПРИБЫЛЬ фирмы. Для оптовой торговли и производства – это НЕ так. Поэтому, WMS или ее части, закрывающие самые болезненные проблемы склада, а точнее ФИРМЫ и склада как подразделения, правильно делать как подсистему к уже имеющейся КИС (1С) , а не наоборот. В этом согласен с (39).
3. При реализации своей подсистемы на 7-ке в сеансе работы ТСД использовал Таблицу значений, но оговорюсь, что ТСД работает с 1 документом, если же надо режим «1 документ – много ТСД», то для 7–ки Справочник, для 8-ки, подумав соглашусь с автором, - независимый непериодический регистр сведений. Это к (14).
4. В (40) nafa изложил абсолютно верную, но крамольно звучащую мысль- цитата- «… для основной операции (отпуск товара) остатки СКЛАДУ вообще не нужны ни на какую дату, НИ ТЕКУЩИЕ» - конец цитаты. Поясню на примере – если товар не тот или лишний по количеству в Заказе – на ТСД в ON-LINE`е приходит сообщение (1 сек) – ЛИШНИЙ-УБЕРИ, а если не полностью отгружен, то или добери сколько, откуда и чего недостает, или закрой отгрузку принудительно – документально зафиксирован недогруз (то ли пересорт –и нет физически на складе, то ли уже украли до нас – не суть), который в дальнейшем (на следующий день, если отгрузка ночью, или в понедельник – если выходные) анализируется менеджерами - со всеми вытекающими… ну и так далее по учетной политике. Отсюда проведение расходного документа, двигающего регистры накопления (остатки, взаиморасчеты, партии и т.д.) развязано по времени с ФИЗИЧЕСОЙ отгрузкой товара как такового. Поскольку в данной постановке – Физическая отгрузка товара – та же хоз.операция – и она также отражается собственным учетным документом с несколько другими артибутами (мягко скажем!!! – иначе зачем городить WMS).
5. На собственном опыте могу подтвердить утверждение автора, что скорость собственно считывания ШК и реакция системы – 1секунда – ВАЖНЕЙШИЕ и приемлимые показатели с точки зрения складского рабочего, его психологического комфорта. По этому поводу пришлось специально потрудиться.
6. По поводу (23). С интересом ожидаю точку зрения автора по особенностям организации учета, поскольку видна степень погружения в проблему.
63. Сергей (Che) Коцюра (CheBurator) 17.11.10 00:26
(62) на, порадуйся: - Время реакции системы от момента считывания ШК ТСД до ответа на ТСД - не знаю, не мерял, но до трех раз в секунду - проходит...
.
При реализации своей подсистемы на 7-ке в сеансе работы ТСД использовал Таблицу значений, но оговорюсь, что ТСД работает с 1 документом, если же надо режим «1 документ – много ТСД», то для 7–ки Справочник

- тоже использовал ТЗ, при этом совершенно пофиг сколько человек работает с 1 документом ибо - в момент выдачи задания на склад минимальной единицей работы становится 1 лист (40 строк), есть заявки и по 20 строк и по 700 строк. Отгрузка - самая разна - от "розничной" до крупнооптовой.
.
Средняя нагрузка в сезон порядка 3000 строк, строка может быть и 2 штучки и 10 коробок+2 блока+3 штуки. На самом деле это низкий показатель, в основном упирается в то, что отгрузка идет самая разнокалиберная - поэтому сборка по бумажным листам, контроль и упаковка по ТСД.
.
у меня "WMS" опирается на складские остатки, зафиксированные в ТиС - потому как для меня совершенно неприемлимо отклонение того что зарезервировал менеджер от факта сборки. И позволить себе учет когда в КИС одни данные, а в WMS - другие - я себе не могу. Пришлось всех построить и застрогать работу в ТиС на ТА. и все пучком.
.
маленький кусочек склада
.
реально на все-провсе, связанное с внедрением, ушло примерно месяц - реального программирования где-то полных 3-5 дней рабочих. Большую часть времени заняло обдумывание и проверка.
.
с ТСД никаких проблем не было и не возникало. работа в 7.7 в терминальном режиме.
.
много по уму не сделано. приходилось выбирать компромиссы между скоростью и качеством, и там где можно обойтись без ТСД - там обходились без ТСД.
.
кучу интересных вещей не сделал...
.
если бы делал сейчас - многое сделал бы по-другому...
64. Сергей (Che) Коцюра (CheBurator) 17.11.10 00:30
Самое из этого интересное - что заблокировать сборку какого-то артикула в случае проблем (для быстрого разбора полетов) - я не могу принципиально...
.
65. Сергей (Che) Коцюра (CheBurator) 17.11.10 00:32
Истина - она где-то рядом.. между (0) и (62)...
66. Сергей (Che) Коцюра (CheBurator) 17.11.10 00:40
ПописАв "wms" на 7.7 - могу ответственно заявить - катит!!! еще как катит! Вплоть до того, что начал задумываться над выпуском отдельной подсистемы "wms" хоть для Бухии, хоть для ТиС, хоть для ПуБ. Все упирается в одно: в аккуратность ведения учета в КИС. если это есть - в принципе, никакие ОТДЕЛЬНЫЕ wms - не нужны в большом количестве случаев... Отдельные wms - они откуда взялись? только от того что wms решает несвойственные для Кис задачи..? если это так - то эти два контура (КиС и WMS) можно (и нужно?) объединять В ПЕРВУЮ ОЧЕРЕДЬ ДЛЯ ВЫСОКОЙ ЭФФЕКТИВНОСТИ (?) - ввиду своей разнородности они не будут мешать друг другу. Работа wms начинается там, где заканчивается (или еще не началась) работа КИС...(?)
Реально чего не хватает на 7.7 - это сервера...
67. Сергей (Che) Коцюра (CheBurator) 17.11.10 00:47
(46)
Это происходит из-за использования типовых конфигураций. У нас самописка, и менеджеры прямо при вводе резервируют товар. А не при проведении.

- это происходит не из-за использования типовых конфигураций. на типовых конфигах МОЖНО СДЕЛАТЬ ОЧЕНЬ МНОГОЕ. Это происходит из-за отсутсвия выстроенного регламента/учета - а на чем он - на типовой или самописке - это совсем другой вариант...
68. Сергей (Che) Коцюра (CheBurator) 17.11.10 00:52
(48) если у вас на 5000 строк задействовано 30 сборщиков+10 контролеров+прочее - то что ни все делают??? у меня конечно попроще все и нагрузка поменьше.. но для нормировочной нагрузки в 3000 строк - у меня штатный состав 16 человек, в число которых входит и штабелерщик и старший смены... Реально работает 12 человек - и вообщем-то - не потеют. но хорошо, если было бы 16.. тогда можно было бы все намного улучшить.. Лично у меня основная проблема "то пусто, то густо" - т.е. самое нужное - это расчет нагрузки, которую может выполнить склад при имеющихся на складе ресурсах. ни в однйо системе ЭТОГО я не видел (может плохо смотрел)...
69. Сергей (Che) Коцюра (CheBurator) 17.11.10 00:54
Поэтому к WMS предьявляются более строгие требования в плане скорости работы т.к. она УПРАВЛЯЕТ работает склада,

- покажите мне ХОТЯ БЫ демку, на котрой видно, как ВМС УПРАВЛЯЕТ складом - я буду тогда плакать от щастья...
70. Сергей (Che) Коцюра (CheBurator) 17.11.10 00:55
для NAFA надо памятник поставить за высказывание, отражающее одну из основных проблем:
Т.е. о чем я с самого начала говорю проблема только одна - начальство работников самих себе предоставило вот они дурью и занимаются.
71. Сергей (Che) Коцюра (CheBurator) 17.11.10 01:01
Ждем ответа автора и раскрытия темы по (52).
.
Мне кажется, что надо разгарничивать те объекты, где основной деятельностью является СКЛАДСКАЯ ДЕЯТЕЛЬНОСТЬ (например склады ОХ, склады ОХ с оказанием услуг по сборке товара) и те объекты, где основной деятельностью является торговля. На самом деле очень многое зависит от темпа и загруженности склада.
72. Владимир (hogik) 17.11.10 01:04
(63)
Сергей.
Это у тебя отгрузка.
Да?
А приход - как?
73. Сергей (Che) Коцюра (CheBurator) 17.11.10 01:05
ОТДЕЛЬНОЙ СТРОКОЙ ЗАМЕЧУ: автор RSERGIO до недавного времени являлся одним из лидеров (присутствие в ТОП3 на постоянной основе в течение длительного времени) в прводимом ГУГЛЕ конкурсе, он и сейчас там - чуть пониже упал...
http://ai-contest.com/rankings.php
74. Сергей (Che) Коцюра (CheBurator) 17.11.10 01:12
75. Сергей (Che) Коцюра (CheBurator) 17.11.10 01:16
(72) с Приходом - все плохо.. ;-) потому как это был один из беспроблемных участков... но только до той поры, пока не навел порядок более-менее на прочих участках - вот тут Приходы и стали узким местом.. Но ничего сложного - все поянтно как и что делать и никаких сомненйи что будет сделано - нет.. проблема в том, что я оттуда уволился... ;-)
76. Сергей Рубанов (rsergio) 17.11.10 01:39
Ребята, я честно ничего не понимаю.

Знаю компанию Axelot с момента когда они были еще Аистом.
Отслеживаю их версии - вначале на 7.7, потом 2.0 на 8.0, далее 3.0 на 8.1, немного в курсе планов по 4.0 на 8.2.

При этом WMS они разрабатывают очень давно, вложили в нее много сил, пытались продвигать даже западную систему, но не вышло.

При этом на тендерах они не то что именитым проигрывают, но даже конкурентам из лагеря 1С (которые тоже немало сил вложили).

И ладно бы еще, так успел поработать консультантом, поездить по России по складам "Пятерочки", посмотреть на работу крупных складов на мощных WMS

А тут, оказывается, настоящую WMS можно за два месяца написать на старенькой 7.7 и все счастье ...
А я уже 3 года оттачиваю в системе то, что люди за пару месяцев пишут.

Пора на пенсию...
77. Сергей (Che) Коцюра (CheBurator) 17.11.10 03:52
(76) Спакуха! Кто сказал что "настоящую ВМС"? (я читал твое описалово Арены - Злопчинский=я) - впечатляет! достойная ситсема по крайней мере на фоне других. Другой вопрос, что для моих потребностей - она не нужна, как и прочие системы. Вот и все. Ценность имеет то, что работает ЗДЕСЬ И СЕЙЧАС. так что не баись! система у тебя правильная, а у меня - простенькая. Вот если твою систему параметрическими настройками можно свести к требуемому лично мной функционалу... вплоть до внешнего представления экранных форм... ;-) - тут было бы интересно о чем поговорить... У меня тут наклевывается склад новый.. может и обращусь ПРЕДМЕТНО...
.
Спи спокойно.
78. Сергей (Che) Коцюра (CheBurator) 17.11.10 03:55
а тянет моя маленькая wms на гордое звание WMS - ты это лучше наверное представишь по картинкам, которые я выше выложил.. если что - готов на всякие вопросы ответить... ;-) а то вдруг, ты действительно 3 года фигней занимался ;-)
79. Игорь Исхаков (Ish_2) 17.11.10 06:49
(76) А что тут понимать ? Создать продукт для конкретного предприятия , абстрагируясь от многих важнейший деталей - достаточно просто.
Создавая более или менее универсальное решение, разработчик всегда попадает ... на три года.
80. Роман Осадченко (cleaner_it) 17.11.10 07:00
(76) Смотрели продукты Axelot в апреле этого года. Честно - презентация "от девочки" не впечатлила совсем ("не то что именитым проигрывают, но даже конкурентам из лагеря 1С " - кажется, причина в этом), поехал к ним в офис - разговаривать с разработчиками, покопаться в коде программном (дали доступ, даже над душой не стояли много).

В итоге нам система не подошла (для нас много допилов пришлось бы делать), но в целом она рабочая. И руководитель проектов у них адекватный
81. Serg Serg (sgsoft) 17.11.10 12:23
(63) Порадовало!
Сеансы ТСД в терминале - аналогично.
По поводу проблем с ПО самого ТСД - переписал, т.к. генератор форм с которым он шел не удовлетворял своей негибкостью. Сделав же ТСД "полноценным" компьютером (только с маленьким экраном) - каким он по существу и является, появилась возможность встроить его работу в технологию работы склада, а не наоборот технологические складские операции подгонять под уже готовые формы. За одно и вспомнил молодость. А что по времени - так лето было жаркое и дымное...

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

(76) Сергей! Не волнуйтесь. Всякому продукту, а уж тем более ПРАВИЛЬНОМУ есть свое место в этой жизни. Про пенсию - рано.
Все-таки Вы обещали написать еще одну статью, которую с ждем с интересом.
82. Serg Serg (sgsoft) 17.11.10 12:42
(63) Кстати, поскольку у нас с Вами получился диалог, то хочу поблагодарить Вас за идею, которую Вы представили как "Рабочее место сборщика по ШК"!!!
Оснастив похожее рабочее место сенсорным экраном (как в платежном терминале), подцепив весы (планирую еще и принтер ШК - скоро пришлют) - вынес его на склад в зону комплектации - с ним работают непосредственно товароведы.
Так что обмен идеями безусловно полезен (про яблоки уже писАл)...
83. Алексей Кабанов (btr) 17.11.10 16:27
Рассмотрите еще решение "БИТ: Складская логистика".
84. Сергей (Che) Коцюра (CheBurator) 18.11.10 01:38
(82) "Продам" Рабочее место расфасовщика большой кучи товаров по заказам/точкам/отгрузкам - для чего может быть применено: есть большая куча товара (например, у меня - 300-500 дисков, каждого наименования от 1 до количестов заказа) - прислал поставщик консолидированную поставку. Есть куча получателей товаров из этой поставки (точки/магазины/заказы на отборсборку/итд - у меня точки торговли дисками, известно требуемое количестов пономенклатурно на каждого получателя), в пришедшей "куче" может быть товар, не входящий ни в один из получателей. Задача - быстро "расфасовать" товар, по условиям расфасовки сформровать перемещения/отгрузки/что-то еще... Условие - товар д.б. штрихкодирован (в принципе поддерживается и отдельная "задача" штрихкодирования пришедшего товара - но это отдельный вопрос).
.
Если кому интересно - могу записать живой ролик и выложить...
sipoju; gaglo; +2 Ответить 2
85. Доржи Цыденов (support) 18.11.10 07:53
(84) Мне интересно. Напиши вообще статью про свое внедрение. Всем интересно будет.
86. huse 18.11.10 12:10
(0) Программа просто хранит информацию или есть какая то функция оптимизации потоков/хранения?
87. Сергей Рубанов (rsergio) 18.11.10 12:38
(86) Если программа только хранит информацию, то это учетная система и не может обозначаться как WMS (система управления складом).
88. Serg Serg (sgsoft) 18.11.10 12:41
(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С» - просто за этими красными, желтыми и синими «лоскутами» НУЖНО видеть многоцветное красочное ОДЕЯЛО!!!

Удачи…
vakham; detec; support; +3 Ответить
89. Serg Serg (sgsoft) 18.11.10 16:52
(84)Спасибо за предложение!
А то о чем сказал - мышку Клавку не используем - а работаем...
90. Сергей (Che) Коцюра (CheBurator) 18.11.10 17:13
(89) я когда ТСД "отлаживал", ходил по складу целый день - потом постоянно в экран монитора большим пальцем тыкал...
91. (A) 18.11.10 17:37
Доброго всем времени суток, коллеги!
Во-первых, спасибо автору статьи за полезную информацию и желание поделиться опытом. Выскажу собственные соображения по теме, как фрагмент общей картины автоматизации отрасли :)

Около года назад закончил собственный проект по автоматизации адресного склада на родном производственном предприятии. Проект развивался постепенно, изначально задача конкретно не ставилась, т.к. никто не представлял что же на самом деле нужно,
и как-то незаметно перерос в систему, которую можно назвать WMS. Проект реализован на 1Сv77 в рамках самописной КИС.

Параметры склада - 1300 адресных ячеек в гравитационных паллетных стеллажах с каналами различной глубины.
Номенклатурных позиций на сегодня - 540 .
Одновременно работающих пользователей в КИС - около 50.
Складской персонал, работающий с ТСД - 1 кладовщик по приемке продукции с производства,
2 кладовщика по отгрузке,
4 водителя складской техники,
2 звена комплектовщиков по 4 человека (одновременно могут работать как оба звена так и одно).
ТСД работают в терминале.

Что касается автоматизации самого складского процесса, то реализованы:
приемка продукции на склад;
отгрузка на филиалы и клиентов;
комплектация паллет;
инвентаризация;
внутрискладские перемещения,
и другие функции не столь критичные к производительности.
Есть маршрутизация передвижений техники с учетом топологии склада и особенностей самой техники.

Проект реализовывался около года, восновном силами одного программиста.

Теперь по основной теме дискуссии:
как выше написал, реализовано на 1СV77. С использованием регистров и механизма проведения документов.
Без управляемых блокировок.

Конечно же больным местом является производительность системы. Операция расчета адресов доступных для размещения/снятия продукции
занимает около 10 секунд. При этом учитывается резерв по параллельным заданиям. При этом работает логика выбора адресов - есть "свои" адреса и
"чужие". И здесь полностью согласен с автором статьи, что такое время ожидания критично при работе на складе. Для примера, зачастую 2 водителя отвозят паллету и закрывают задание на ТСД быстрее, чем кладовщик успевает выдать новое задание :) Но тем не менее система работает, и это факт.

Сейчас думаю как решать проблему с производительностью.

ВЫВОД: задача вполне реализуема даже штатными средствами и своими силами, и в некоторых случаях вполне имеет право на жизнь.

С интересом прочитал сообщения CheBurator и sgsoft, которые тоже делали проекты WMS на 7ке, все-таки нетрадиционная для 1С задача :)
Не понял что вы имели в виду под временем реакции с момента считывания ШК ТСД в 1 секунду?
Показательно время, которое занимает вычислительный процесс, в результате которого программа выдаст информацию необходимую для принятия решения (например, у меня это операция расчета адресов, которые доступны для размещения/снятия продукции - писал выше).
А если при сканировании ШК просто идентифицируется ТМЦ, то это не показатель.
92. Serg Serg (sgsoft) 20.11.10 13:42
Эпиграф:

«Специалист подобен флюсу: полнота его одностороння» - Козьма Прутков.
«Не люди для СИСТЕМЫ, а система для ЛЮДЕЙ!» - автор не известен.


Хотел о другом - опять «зацепило» - и начну с «принципов». Поскольку автор (0) обходит вниманием в обсуждении некоторые вопросы, поэтому немного «заострю» их. Автор (0) бездоказательно постулирует следующие СОФИЗМЫ:

1) (49) Цит – «WMS…УПРАВЛЯЕТ работой склада…». И туда же – (87) Цит-« Если система только хранит информацию, то это учетная система и не может обозначаться как WMS (система управления складом)»

Разберемся:

Если следовать логики автора, то системы EAM, MES, CRM, SCM, WMS - УПРАВЛЯЮТ соответственно основными фондами / цехом / взаимоотношениями с клиентами / цепочками поставок / складом, ну а ERP, MRP - эти просто ПЛАНИРУЮТ! Где ЧЕЛОВЕКи как ОБЪЕКТы управления и куда ОНи исчезли из КОНТУРА управления?

(Если посмотреть перевод Яндекса слова «MANAGEMENT», то по логике автора перевод словосочетания «management of news» - будет «УПРАВЛЕНИЕ новостями», а никак не «манипуляция новостями». Есть кстати симпатичное, но помеченное как устаревшее значение 4).

Читаем полезные статьи Википедии («Теория управления», «Системы управления», «Системы менеджмента» – (и по ссылкам)- познавательно), ну и статью оттуда же «WMS», где ясным по белому кроме БД, ШК, ТСД, серверов, радиоканалов и т.п., в разделе «Принцип работы WMS» написано : «Таким образом, система контролирует все действия работника и позволяет практически полностью исключить возможность ошибочного размещения груза или неправильного комплектования заказа».

Еще остался вопрос – «что такое WMS» и ЧТО она делает?

Если руководитель примет на ВЕРУ и внедрит систему, которая УПРАВЛЯЕТ, то с неизбежностью (!!!) через некоторое время обнаружит, что в действительности управляет ОПЕРАТОР или ПРОГРАММИСТ (через настройки) или другую сторону – устойчивую схему «склад-забор-базар». ЭТО К БАБКЕ НЕ ХОДИ – поскольку это две стороны ЭНТРОПИИ СИСТЕМЫ, на уменьшение которой собственно и направляется УПРАВЛЕНИЕ!!!! Об этом говорили в обсуждении, извините без ссылок.


2) (21) Цит – «Но еще раз предлагаю окунуться в специфику работы склада и понять, что она никак не пересекается с финансовым/управленческим учетом».

Разберемся:

Тут уж вообще перепрыгнули через (или поднырнули под) К.Маркса и его классическую формулу товарооборота «Т-Д-Т» (товар – деньги - товар)!!!
(В свое время, когда получал образование по спец-ти «АСУ» - учили. Сейчас наверно модно – «ДАО Тойота» - об этом ниже).

Основные функции (да собственно это и есть предназначение СКЛАДА) можно свести к «простой» формуле товарооборота (почти по Марксу) : «Принять – Хранить - Отпустить» - так что тут с чем «никак не пересекается»???

Ну а со «спецификой складов» - помню программы еще на FoxBase…

3) Не поленился, зашел к своему директору – у него хорошая подборка литературы по управлению в частности – взял книгу, которую когда-то прочитал, «Практика ДАО Toyota» от авторов бестселлера «ДАО Toyota» - читаем 11 глава, 4 абзац, стр. 309 (стилистику попытаюсь сохранить):

«…Если вы – менеджер, главное в том, что вы думаете о природе человека на самом деле и что значат ваши люди для вас. … Так же, как и во всех других аспектах дао Toyota, все начинается с вашего образа мышления ». – кон. цит.


Ну а теперь, чтобы не было грустно, приведу вчерашний рассказ старшего смены склада (СтС).

Приехал да-а-авнишний клиент (К) (не был с лета) симпатичный, колоритный армянин, знающих всех и вся на фирме и как обычно подогнал машину под загрузку и пошел оформлять заказ в торг.отдел (другое здание, но пандус склада виден из окна). Видит, товар вывезли под загрузку, идет к СтС, который проверяет отгрузку (через ТСД), подходит и протягивает авторучку(чтобы в накладной отметить что отпущено/нет). Происходит следующий диалог (лично хорошо знаю К, поэтому представил без труда):

СтС: - Зачем? Не нужно – видишь у меня на ТСД «по-нулям» (т.е. все точно как в заказе).

К недоумевает, СтС вкратце на пальцах объясняет (как сам понимает) K как все работает.

К: - Это я пока шел, тут это (показывает руками на небо и два здания) туда-сюда, туда-сюда. А-а-а ШАЙТАН!!!

А мы тут – ВМС - не wms – WMS!!!
CheBurator; support; +2 Ответить 1
93. Сергей Рубанов (rsergio) 20.11.10 19:17
(92) Вы правы в том, что ЕСТЬ системы где "в действительности управляет ОПЕРАТОР или ПРОГРАММИСТ".

Вы можете даже в Интернете найти красивые скриншоты "решений на 1С", где оператору можно 10 разными способами назначить исполнителя для выполнения заказа. В этом плане да - управляет оператор, а все что делает система - ведет адресный УЧЕТ на складе и фиксирует норму выработки (по листку или ТСД - не важно).

НО в нормальных WMS оператор ничего никому не назначает. Его основная задача - печатать сопроводительные документы для отгрузки, ставить печати и держать связь с отделом продаж. Начальник склада сидит у себя и мониторит работы - если что-то пошло не так, то может скорректировать приоритеты в программе или выйти на склад и дать кому-то пендалей.
Все остальное делает именно WMS - она самостоятельно выбирает для каждого сотрудника лучшую задачу на текущий момент времени и склад работает как улий. Есть такая вещь как человеческая лень, так вот на это есть мотивация персонала (премии, пинок начальника склада, увольнение)...

А как же склады, где во всю используются конвееры и автоматизированные стеллажные хранилища? Там WMS тоже ничем не управляет и оператор кнопочками выбирает из какой ячейки автомату взять товар?!

Если вам не нравиться слово "управляет", давайте заменим на "распределяет задания".
CheBurator; +1 Ответить 2
94. Сергей Рубанов (rsergio) 21.11.10 02:08
Выложил статью, которую два года назад писал в журнал "Логистика и управление" (журнал в 2010 году закрылся)

В ней немного подробней описаны функциональные требования к разным процессам работы склада.

Ссылка на статью: Не экономте на настройках WMS
95. Serg Serg (sgsoft) 22.11.10 11:19
(93)Сергей, спасибо за ответ!

Для меня бесспорно то, что данное подробное обсуждение привело к СИНЕРГИИ ВСЕХ его участников!
Удачи...
96. Сергей Рубанов (rsergio) 09.12.10 18:44
97. angeliccare (angeliccare) 22.12.10 18:52
98. Archy (ArchyX) 19.01.11 11:12
Как вы думаете, из списка WMS на 1с8 предложенных в статье, какие 3 лидера системы можно выделить как - высокая производительность, гибкость/адаптируемость(хотя бы вплане настроек)?
99. Сергей (Che) Коцюра (CheBurator) 19.01.11 13:28
для меня очевидно что в (93) - написано так как мне хочется и так как должно быть. мой мелкий опыт показывает что там, где "управляет" оператор - все время идут затыки и нестыковки...
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа