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

18.03.14

Учетные задачи - Оптовая торговля

То что 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

 

 

 

WMS

См. также

SALE! 20%

Автоматический заказ поставщику в 1С: загрузка прайсов и анализ цен поставщиков для УТ 10.3, УТ 11, КА2, УНФ, УПП, ERP, Розница 2

Бюджетирование и планирование Оптовая торговля Розничная торговля Логистика, склад и ТМЦ Анализ продаж Платформа 1С v7.7 Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Розница 2 1С:Управление производственным предприятием 1С:Управление нашей фирмой 1.6 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

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

28500 22800 руб.

21.04.2017    90208    105    39    

191

ЕГАИС++. Опт, производство, импорт

Оптовая торговля Розничная торговля Обмен с ГосИС Платформа 1С v8.3 1С:Управление торговлей 10 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Рестораны, кафе и фаст-фуд Россия Бухгалтерский учет Управленческий учет Акцизы Платные (руб)

Полнофункциональное расширение (ранее известное как Модуль 1С-ЕГАИС) для взаимодействия типовых конфигураций 1С и ЕГАИС, предоставляющее максимум возможностей по работе с УТМ. Получение и отправка ТТН, отправка акта о постановке на баланс и акта о списании. Получение остатков. Загрузка и сопоставление номенклатуры и контрагентов. Оправка в ЕГАИС отчетов о производстве и импорте.

8970 руб.

15.12.2015    165995    677    362    

386

SALE! 10%

Загрузка номенклатуры из Excel в УТ11, КА 2, ERP 2, Розница 2. Дополнительные реквизиты и сведения, характеристики, картинки, цены, остатки

Загрузка и выгрузка в Excel Розничная торговля Логистика, склад и ТМЦ Ценообразование, анализ цен Прайсы Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Розница 2 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Управленческий учет Платные (руб)

Загрузка из файлов xls, xlsx, ods, csv, mxl в УТ11, КА 2, ERP 2, Розница 2. Задействованы все возможности конфигурации - заполнение реквизитов номенклатуры, дополнительных реквизитов и сведений, характеристики, доп.реквизиты и сведения характеристик. Дополнительные обработки для расширения возможностей.

10560 9504 руб.

29.10.2014    210239    621    524    

439

Модуль "Ответственное хранение" или фулфилмент (FBS / FBO) для 1С:УТ 11.5, КА 2.5, ERP 2.5

Логистика, склад и ТМЦ Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Оптовая торговля, дистрибуция, логистика Управленческий учет Платные (руб)

Модуль "Ответственное хранение" для 1С (УТ 11.5, КА 2.5, ERP 2.5) позволяет организовать учет ответственного хранения товаров с весовыми характеристиками, в том числе со сроком годности и личным кабинетом Поклажедателя. Модуль реализован в виде расширения конфигурации, устанавливается в режиме 1С:Предприятие 8 за 5 минут по инструкции, что позволяет оставить конфигурацию 1С на стандартной поддержке и продолжать получать стандартные обновления от фирмы "1С".

60000 руб.

09.06.2020    34351    27    57    

54

Обмен с системой ЦРПТ (Универсальная конфигурация ХамелеонЦРПТ + маркировка табака, обуви, одежды, лекарств, фото, молока, духов(парфюма), питьевой воды, велосипедов и шин)

Оптовая торговля Розничная торговля Обмен с ГосИС Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Россия Бухгалтерский учет Управленческий учет Платные (руб)

Данная публикация создана для помощи разработчикам, интеграторам и другим заинтересованным лицам по настройке системы маркировки обуви, одежды, лекарств, табака, фото, молока, духов(парфюма), питьевой воды, велосипедов и шин. Смело задавайте нам вопросы по работе с ЦРПТ, GS1, ЭДО, Национальным каталогом, мы накопили достаточно большую базу знаний по данным темам и готовы ответить на все Ваши вопросы.

104000 руб.

18.03.2019    110346    34    114    

178

Загрузка номенклатуры c картинками (несколько потоков одновременно) и сопутствующими данными в базу и любые документы из yml, xls, xlsx, xlsm, ods, ots, csv для УТ 10.3, УТ 11 (все), БП 3, КА 2, ERP 2, УНФ 1.6/3.0, Розница 2

Загрузка и выгрузка в Excel Логистика, склад и ТМЦ Ценообразование, анализ цен Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 Платные (руб)

Эволюция не стоит на месте - новая удобная версия функциональной обработки для Вашего бизнеса! Что же Вы получаете? Удобный и интуитивно понятный интерфейс с 3-мя этапами работы. 2 режима - автоматический и ручной. Чтение XLSX, XLSM, CSV, XML/YML форматов без офиса, на любом сервере! Визуальное связывание колонок файла и реквизитов простым перетаскиванием колонок. Создание или обновление номенклатуры с иерархией, характеристик, доп. реквизитов, упаковок, загрузка практически неограниченного количества картинок на одну номенклатуру (с возможностью загрузки в несколько потоков одновременно), с хранением в томах или в базе. Загрузка номенклатуры поставщиков или поиск по их данным номенклатуры. Загрузка доп. реквизитов в характеристики. Загрузка штрихкодов с генерацией новых. Создание элементов справочников и ПВХ "на лету" для выбранных реквизитов. (Обновление от 11.12.2023, версия 9.5 - 9.9)

13200 руб.

20.11.2015    150756    365    375    

501

AS WMS: автоматизация склада с адресным хранением с помощью ТСД

Логистика, склад и ТМЦ Платформа 1С v8.3 Россия Платные (руб)

Подсистема управления складом AS WMS для конфигураций на платформе 1С 8. AS WMS – готовое решение для эффективного управления адресным складом. Внедрение системы AS WMS способствует быстрому отбору товара, ускорению инвентаризации, снижению зависимости от персонала, исключению пересорта. AS WMS встраивается в любую конфигурацию на платформе 1С 8 и работает как единая система без обменов. В учетной системе нет необходимости менять процессы под AS WMS (например, вводить ордерную схему), AS WMS использует стандартные документы по товародвижению вашей учетной системы.

40000 руб.

26.07.2023    3238    13    0    

8
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
98. ArchyX 19.01.11 11:12 Сейчас в теме
Как вы думаете, из списка WMS на 1с8 предложенных в статье, какие 3 лидера системы можно выделить как - высокая производительность, гибкость/адаптируемость(хотя бы вплане настроек)?
100. axxell 1054 01.04.14 09:14 Сейчас в теме
Очень интересная статья, как раз сейчас работаю над проектом автоматизации склада.
Видел последние версии решений от Axelot и 1С:Бит. Как думаете, почему разработчики отказались от подхода к хранению остатков в регистре сведений и перешли к использованию для этой цели регистра накоплений?
Видели ли Вы эти решения в работе и как они себя ведут на быстрооборачиваемых складах?
Планируете ли Вы в будущих версиях своей системы перейти к регистрам накопления или будете использовать регистры сведений?
104. AlexandrIII 17.04.14 11:10 Сейчас в теме
(100) axxell, А где Вы увидели что они отказались от РС для хранения остатков ? В 3-ей версии у Акселота никаких архитектурных изменений нет. 4-ка это абсолютно другой продукт, который архитектурно отличается и вроде бы как у них разное позиционирование. В целом у Акселота довольно таки грамотное решение и зная любовь Пиголкина С. и Шорина Д. ко всяким оптимизациям, думаю что они делали достаточное кол-во моделирования больших объемов данных. ИМХО.
Aleskey_K; baracuda; +2 Ответить
101. rsergio 80 01.04.14 10:12 Сейчас в теме
axxell, думаю, что регистры накопления используются из-за их простоты (нет необходимости создавать свой движок) и из-за необходимости получить "1С:Совместимо".

Детально разбирал версии 3.0 и 4.0 от Axelot. У меня сложилось свое мнение, которое видимо отличается от мнения разработчиков.
Мы переходить на регистры накопления не планируем, по крайней мере в текущей их реализации.
102. axxell 1054 11.04.14 14:30 Сейчас в теме
103. CheBurator 3119 11.04.14 23:01 Сейчас в теме
перчитал все еще раз с большим интересом...
105. rsergio 80 17.04.14 16:30 Сейчас в теме
AlexandrIII, если бы внимательно изучите запросы (вернее пакеты запросов) в 4 версии, а также посмотрите количество этих запросов на резервирование одной строчки товаров или поиска ячейки для размещения, то по поводу оптимизации можно будет подискутировать. Ну и в 4 версии остатки хранятся в регистрах накоплений (именно в нескольких регистрах, но меньше чем в 3-ей версии).
106. AlexandrIII 18.04.14 08:45 Сейчас в теме
(105) ну наверно не стоит судить по размерам и кол-ву запросов, все таки нужно смотреть на качество их реализации. Ведь порой маленький запрос в 1С может превратиться в такую простыню на скуле, что мама не горюй. Я лишь сказал в прошлом посте о том что 4-ка кардинально отличается(архитектурно) от 3-ки и если люди(разработчики) пошли таким путем, наверно они делали это учитывая недостатки предыдущей версии ? Ну по крайней мере мне очень хочется в это верить )))
107. rsergio 80 18.04.14 09:28 Сейчас в теме
(106) AlexandrIII, в том то и дело, что не только большое количество запросов, но и сами запросы иногда вызывают непонимание. Например, при поиске ячейки размещения формируется пакет из 14 подзапросов, где только первые 4 запроса находят массив доступных ячеек по конкретному алгоритму, потом считываются положения всех контейнеров во всех подходящих ячейках, потом считываются все остатки по всем товарам из контейнеров из предыдущего шага, потом определяются подходящие контейнеры, находится вместимость товара в них, и только в самом последнем запросе получается список контейнеров, которые подходят для размещения и влезает не менее одной упаковки. И это только обработка одной строчки алгоритма под один товар.
Тоже самое при резервировании товара под отбор - в пакете из 8 подзапросов считываются все доступные ячейки в указанных зонах алгоритма, потом абсолютно все доступные контейнера в этих ячейках, и только под конец считываются остатки товаров с учетом ограничения по списку контейнеров и нашего товара.
И таким моментов много - начиная от сложных запросов, и заканчивая спорными архитектурными решениями.
Но версия еще молодая, думаю что со временем все оптимизируют.
108. CheBurator 3119 19.04.14 02:41 Сейчас в теме
Любое универсальное решение хуже специализированного. Может ли универсальное решение "настройками" сведено до уровн я"необходимого специализированного "решения? м.б. да. Но ксолько при этом "мусора" будет все равно тащиться и выполняться непроизводительных действий...? все мутно и непонятно
109. CheBurator 3119 19.04.14 02:42 Сейчас в теме
Пишите еще, только помедленнее, я конспектирую ;-)
110. rsergio 80 19.04.14 06:49 Сейчас в теме
CheBurator, рано или поздно на любом складе нужно менять процессы или для оптимизации, или в связи с изменением внешних факторов - бизнеса компании, появление новых товарных групп и т.п. И специализированное решение уже не может поддержать все изменения, когда универсально быстро адаптируется под новые требования.
Например, сейчас есть клиент, который на своем региональном складе решил внедрить нашу WMS т.к. та система, что стоит на центральном складе не справляется по производительности и главное не поддерживает множество процессов, которые клиент хотел бы запустить. Попытки дописать требуемый функционал на старой системе в итоге привели к необходимости сменить систему т.к. после каждой такой доработки возникало множество ошибок в других местах ("тут лечим, там колечим").
Но если свой штат специалистов готов поддерживать систему быстро и качественно, то согласен, что специализированная система всегда будет более быстрой т.к. содержит прямой код без необходимости поддерживать универсальные механизмы.
111. пользователь 19.12.14 18:22
Сообщение было скрыто модератором.
...
112. ctpayc 19.12.14 18:47 Сейчас в теме
Почитал статью, ничего так, но и Америку не открыли. А вот сходу в статье написать, что 2 основных конкурирующих продукта имеют недостатки - не ново совсем. Но с комментариями совсем плохо. Надо же, Акселот обвиняют в использовании регистров накопления, что это ошибочное решение, при этом в свои плюсы ставят использование регистров сведений... Даже представить себе такого не мог.

Давайте вспомним историю... Идея использовать регистры сведений вместо регистров накопления в WMS для хранения остатков и реализовать собственный движок формирования актуального остатка принадлежит Акселот. Именно в третьей версии нашего продукта был впервые применен этот подход, автором идеи является Станислав Пиголкин. Подхватив эту идею (а иногда просто украв основу из 1C-Логистика: Управление складом 3) "на коленке" начали создаваться десятки других WMS решений. Именно Акселот, потратил множество времени на то, чтобы доказать состоятельность этой идеи. Именно Акселот поломал множество копий в битвах, на различных форумах, объясняя, что так можно разрабатывать под 1С. Потому выдавать эту мысль как собственную не состоятельно, хотя бы потому, что зародилась она и реализовывалась еще в те времена, когда была платформа 8.0. Решение 1С-Логистика: Управление складом 3, уже более 8 лет существует на рынке. Выдавать чужую идею, за свое конкурентное преимущество - все так делают, но при этом говорить, что оно является конкурентным преимуществом по сравнению с автором идеи - это плагиат в квадрате.

Теперь же на рынке существует решение WMS 4 (1C: WMS. Логистика. Управление складом 4), говорят что там вернулись к регистрам накопления? Правда ли это? - Да. Значит ли это что, Акселот отказался от своих изначальных идей, и понял их ошибочность? - Нет, мы все также уверены что решение на регистрах сведений очень удачное. Значит ли что Акселот ошибся в новом решении? - Нет. Мы, просто, не стоим на месте, мы находим и тестируем новые решения и идеи. Мы не являемся заложниками одного суждения, и создание WMS 4 это подтверждает. Имея в своем активе очень удачное решение (1C-Логистика: Управление складом 3), мы смогли позволить себе провести большую работу, с поэтапными циклами нагрузочных тестирований и найти новое техническое решение на базе возможностей платформы 1С.

Использование регистров накопления в нашем случае не привело к снижению производительности, правда ради это пришлось использовать 2 регистра для хранения остатков с 2 измерениями в каждом, пришлось склеить измерения в ключи аналитики, это несколько усложнило схему работы, но это позволило сохранить производительность. При этом мы получили, все бонусы, которые несет в себе платформа при работе с регистрами накопления - например splitter. А также избавиться от проблем регистра сведений - как один из примеров - при установке привилегированного режима можно напрямую поправить остаток, и следов такого действия практически нельзя будет найти, да, если усложнять проведение можно и их решить, что было нами сделано в 1С-Логистика: Управление складом 3. Но почему же не поискать новое техническое решение? То, что мы нашли одно хорошее решение, вовсе не значит, что надо останавливаться и дожимать из него все соки, пока получается. Нет, это значит, что надо работать дальше, решать новые технические задачи, представлять на рынке новые идеи и решения - именно это выделяет компанию Акселот среди прочих разработчиков.

Но в общем-то выше описаны не основные проблемы регистра сведений, основная проблема тоже связана с производительностью. Дело в том, что для обновления остатка в регистре сведений, запись необходимо обновить. Платформа 1С обновление записи делает 2 командами - delete + insert. Даже если забыть, что это 2 действия, надо вспомнить об индексах. Команды delete и insert всегда вызывают перестроение индексов, в итоге постоянно фрагментированы, любое наше действие вызывает попадание во фрагмент, а операция дефрагментации индекса очень трудозатратна, и ведет к снижению производительности сервера в целом на время дефрагментации, для складов 24/7 это очень критично, остальные ждут дефрагментации до выходных, в итоге мы постоянно работаем с фрагментами индекса. Вторая проблема это то, что операция delete вызывает эскалацию блокировки до страницы, что также ведет к снижению производительности, кроме того может приводить к неявным деадлокам. В отличие от регистра сведений, обновление итоговой таблицы в регистре накопления идет командой update, с изменением ресурсов, которые не проиндексированы, и это не приводит к постоянному изменению индексов. Правда вы над этим не задумывались, когда писали о том что регистры сведений однозначно быстрее? Нет, это не так - технические проблемы есть в любой схеме, главное учиться их решать, что успешно делает Акселот разрабатывая новые решения. Взять чужую идею просто, а вот по настоящему осознать ее - это совсем другая задача.

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

PS. Очень не хотелось тут что-либо писать, но меня очень просили. Я не люблю бессмысленные форумные битвы, моим любимым занятием является создание лучшей WMS системы, в конкуренты которой я предпочитаю ставить не коллег по цеху 1С или прочих разработчиков российских WMS, а мировых лидеров WMS - Manhattan, Solvo, Exceed, LVS и пр. Что и вам советую, только это позволит создать действительно хорошее решение.
JohnConnor; vi.rus; abasovit; +3 Ответить
113. rsergio 80 19.12.14 19:18 Сейчас в теме
ctpayc, вы хоть текст выше читали? В материале не разбираются конкретные системы, не отслеживается история применения тех или иных приемов, идет лишь анализ в целом проблематики построения высокоэффективных систем класса WMS на базе платформы 1С.

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

КлючАналитикиУчетаНоменклатуры - новая сущность, которая будет размножаться вместе со справочником Номенклатуры, умножаясь на количество статусов для каждого товара, а также количество партий. Поиск по нескольким реквизитам в самом справочнике невозможен из-за ограничения платформы 1С. Для обхода этого ограничения был добавлен регистр сведений АналитикаУчетаНоменклатуры с реквизитами Номенклатура, Статус, Партия и ресурсом в виде ссылки на справочник. Использование регистра сведений позволит выполнять поиск сразу по нескольким значениям, но опять же имеем в нем то же количество строк, что и в справочнике.

Требуется проверка производительности выполнения запросов, где в качестве условия при получение данных из регистра ОстаткиТоваров указывается вхождения ключа аналитики в список элементов ключей, полученных из регистра АналитикаУчетаНоменклатуры. Дело в том, что основным ключом (primary key) таблицы справочника является длинный код, который создается уникальным на каждый элемент справочника. Когда мы пытаемся установить отбор по списку элементов с одной номенклатурой, но разными статусами или партиями, то для одного и того же товара будут существовать несколько элементов справочника, а значит они могут обладать разными основными ключами (IDRRef), т.е. нужные записи могут находится в разных частях таблицы т.к. таблицы упорядочены по этому ключу. Это как минимум приведет к чтению большого количества страниц таблицы и увеличение операций ввода/вывода, как максимум к невозможности использовать индекс для поиска элементов и использование перебора всей таблицы (Table scan или Index Scan). Если бы в таблице остатков напрямую находились реквизиты Номенклатура, Статус и Партия, то записи остатков одного товара всегда бы находились рядом т.к. основной ключ Номенклатуры (первого измерения в регистре остатков) был бы для всех строк неизменным.

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

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

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

Это касается не только хранения остатков, но и других алгоритмов. Например, в запросе планирования отбора используется пакет запросов из 14 подзапросов, каждый из которых может состоять из соединения нескольких таблиц и результат которого сохраняется во временной таблице.

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

И так далее, вопросов очень много к архитектуре решения...
Но это статья совсем не об этом!
Aleskey_K; CheBurator; +2 Ответить
114. CheBurator 3119 22.12.14 00:34 Сейчас в теме
Ух!
Все это хорошо что вы тут понаписали ;-)
Предлагаю обозначить что автоматизация разных складов требует разной шибкости систем
И если склад логистического оператора какогонибудь или склад обслуживающий свой холдинг требуют для автоматизации универсальных настраиваемых систем, то автоматизация склада какойлибо оптовой компании - например моей - такая универсальность и гибкость это хорошо но может быть запросто излишне
Гораздо более интересный вопрос выбор и оценка адекватности самого решения на основе которого будем автоматизировать склад и оценка команды внедренцев
Также впрочем и оценка команды со стороны заказчика
116. CheBurator 3119 08.06.16 23:44 Сейчас в теме
Всё перечитал ещё раз с удовольствием
Оставьте свое сообщение