Алексеев А.А.
ИСПОЛЬЗОВАНИЕ API И МИКРОСЕРВИСОВ НА PHP В УЧЕТЕ ТОВАРНЫХ ЗАПАСОВ *
Аннотация:
современные ИТ-системы играют решающую роль в повседневной деятельности производственных компаний, торговых компаний и поставщиков логистических услуг. Системы планирования ресурсов предприятия (ERP), системы управления складами (WMS), системы управления товарами (WWS) и системы управления складами (LVS) незаменимы в средних и крупных компаниях — от управления заказами клиентов до контроля производства и обработки отгрузок. Эти системы чрезвычайно сложны и часто связаны между собой посредством автоматизированных процессов, благодаря чему их часто можно адаптировать к конкретным потребностям компании (кастомизация). Цель данной статьи – провести детальный анализ использования API и микросервисов на PHP в учете товарных запасов, установив их возможности, делая упор на популярных на рынке решениях. В результате были проанализированы существующие API на рынке, были проанализированы их особенности, и роль PHP в построении гибкой системы наследования благодаря открытым библиотекам данных. В то же время требования к компаниям растут в связи с изменением рыночных условий. Международная конкуренция на мировых рынках, экономические колебания и короткие инновационные циклы требуют от компаний высокой адаптивности. ИТ-системы должны поддерживать эту адаптивность и обеспечивать гибкость и масштабируемость в дополнение к основным функциональным требованиям. Такие системы характеризуются высокой гибкостью и масштабируемостью. Их можно легко адаптировать к меняющимся требованиям и расширить за счет включения дополнительных устройств. Отдельные элементы могут быть изменены, заменены или добавлены, если они совместимы с базовыми протоколами связи.
Ключевые слова:
логистические системы, структуры данных, микросервисы, учет товарных запасов, параллельное хранение
DOI 10.24412/2712-8849-2024-170-632-651
УДК 004
Алексеев А.А.
магистрант,
направление: Прикладная информатика
Профиль: Программное обеспечение, Интернет и облачные технологии
ORCID: 0009-0009-4046-2393
Московский финансово-промышленный университет «Синергия»
(г. Кострома, Россия)
ИСПОЛЬЗОВАНИЕ API И МИКРОСЕРВИСОВ
НА PHP В УЧЕТЕ ТОВАРНЫХ ЗАПАСОВ
Аннотация: современные ИТ-системы играют решающую роль в повседневной деятельности производственных компаний, торговых компаний и поставщиков логистических услуг. Системы планирования ресурсов предприятия (ERP), системы управления складами (WMS), системы управления товарами (S) и системы управления складами (LVS) незаменимы в средних и крупных компаниях — от управления заказами клиентов до контроля производства и обработки отгрузок. Эти системы чрезвычайно сложны и часто связаны между собой посредством автоматизированных процессов, благодаря чему их часто можно адаптировать к конкретным потребностям компании (кастомизация). Цель данной статьи – провести детальный анализ использования API и микросервисов на PHP в учете товарных запасов, установив их возможности, делая упор на популярных на рынке решениях. В результате были проанализированы существующие API на рынке, были проанализированы их особенности, и роль PHP в построении гибкой системы наследования благодаря открытым библиотекам данных. В то же время требования к компаниям растут в связи с изменением рыночных условий. Международная конкуренция на мировых рынках, экономические колебания и короткие инновационные циклы требуют от компаний высокой адаптивности. ИТ-системы должны поддерживать эту адаптивность и обеспечивать гибкость и масштабируемость в дополнение к основным функциональным требованиям. Такие системы характеризуются высокой гибкостью и масштабируемостью. Их можно легко адаптировать к меняющимся требованиям и расширить за счет включения дополнительных устройств. Отдельные элементы могут быть изменены, заменены или добавлены, если они совместимы с базовыми протоколами связи.
Ключевые слова: логистические системы, структуры данных, микросервисы, учет товарных запасов, параллельное хранение.
Введение.
Распространенным методом достижения высокой масштабируемости является построение системы из множества простых, недорогих и совместимых модулей, которые можно гибко комбинировать. Каждое из этих подразделений имеет ограниченную функциональность и информацию, но может принимать независимые решения на месте. Желаемое поведение системы создается путем объединения всех модулей. Примерами этого являются мобильные транспортные средства или модульные стационарные системы.
Децентрализованное управление уже зарекомендовало себя при контроле сложных процессов, таких как управление производством и материальными потоками. Исследовательские проекты показали, что децентрализованное управление материальными потоками может быть успешно реализовано без специальных компьютеров. В этой работе исследуется, можно ли распространить эту философию на управление складами и запасами, чтобы обеспечить полностью децентрализованную разработку всей производственной системы. Различные исследовательские группы уже разработали концепции децентрализованных систем управления складами, которые анализируются с точки зрения различных аспектов. В принципе, можно провести различие между децентрализованным хранением и обработкой данных и автоматическим учетом складских движений. Хотя последнее не является обязательной функцией децентрализованных систем управления складом, особых преимуществ можно достичь за счет интеграции таких технологий в децентрализованную WMS [1, c. 180-183].
Децентрализованная система управления складом под названием «WISHIS» была разработана Виландом и др. по поручению Siemens Corporate Technology в рамках проекта Кобургского университета прикладных наук. В этой системе сенсорные узлы, прикрепленные к полкам, взаимодействуют друг с другом через беспроводную сенсорную сеть (WSN) и подключением посредством PHP. Система работает без центральной базы данных, поскольку информация распределена по отдельным вычислительным блокам. Товары на складе оснащены RFID-транспондерами и могут быть идентифицированы бесконтактно. Взаимодействие с системой происходит через мобильные портативные компьютеры с поддержкой RFID, которые можно использовать для записи хранения и извлечения. Однако сами вычислительные подразделения складской инфраструктуры не имеют считывателей RFID и поэтому зависят от правильного учета изменений запасов. Еще одна децентрализованная система управления складом, основанная на беспроводных сенсорных сетях, была разработана Аркадием Широм из Института потоков материалов и логистики Фраунгофера (IML). В этой системе узлы датчиков крепятся к средствам погрузки, например европоддонам. Эти сенсорные узлы хранят состояние единицы хранения (например, хранится, транспортируется) и список предметов на поддоне. Считыватели RFID на транспортных средствах, таких как вилочные погрузчики, и транспондеры RFID на отсеках для хранения позволяют автоматически определять место хранения во время хранения и извлечения вилочными погрузчиками.
Альтернативный метод определения местоположения запоминающих устройств с использованием триангуляции путем оценки уровня сигнала оказался подвержен помехам из-за отражений и затухания сигнала в промышленных условиях. Радиолокация также потребует значительного количества дополнительных опорных узлов в инфраструктуре хранения данных в качестве контрольных точек. Концепция Шира также не требует наличия центральной базы данных. Для поиска конкретного объекта в сенсорную сеть через базовую станцию отправляется запрос, который затем пересылается от одного сенсорного узла к другому посредством многопереходной сети. Соответствующие сенсорные узлы проверяют свой список элементов и возвращают ответ на базовую станцию через многопереходный режим. Следует отметить, что эта концепция в значительной степени адаптирована к конкретным условиям эксплуатации и не обеспечивает достаточной гибкости.
Материалы и методы (Materials and methods).
В работе используется метод наблюдения, для проведения анализа существующих API предложений для рынка, формирующихся за счет использования PHP и открытых библиотек. Метод сравнения был для использования детального выяснения особенностей современных логистических API на PHP, а также классификации их основных функций. В качестве материалов были использованы работы таких авторов, как Лариной Д.О, Мантуловой А.Н, Качковой П.Д и других.
Результаты и обсуждение (Results and discussion).
Структуры данных, такие как описание мест хранения и номера позиций, а также структура телеграмм фиксированы, а количество позиций на единицу хранения ограничено восемью. Вероятно, это связано с ограниченной производительностью используемых сенсорных узлов с 8-битным микроконтроллером. Информация о структуре склада (основные данные склада) продолжает храниться централизованно в программе администрирования, и децентрализованный LVS не осуществляет автоматический поиск свободных мест хранения. Основная задача Smart Shelf — анализ покупательского поведения покупателей в магазине. Он фиксирует, когда товар снимается с полки или кладется обратно. Например, владельцы магазинов могут использовать эти данные, чтобы узнать, сколько времени в среднем покупатели тратят на просмотр товара и с какими другими товарами они его сравнивают. Эту информацию можно использовать для оптимизации ассортимента и расположения товаров. Кроме того, их также можно использовать для контроля запасов на «умных полках» или для определения того, находится ли конкретный товар в назначенном отделении полки. Благодаря технологии распределенных датчиков, которая обычно основана на технологии RFID, Smart Shelf может идентифицировать предметы на полке и определять точное место их хранения.
Для этого каждый предмет, хранящийся на Smart Shelf, должен быть оснащен пассивным RFID-транспондером, и последующей отладкой посредством открытого кода. Полка имеет несколько последовательно соединенных антенн, которые активируются одна за другой. Таким образом, система может определить, в какой зоне антенны находится транспондер, и определить соответствующий отсек на полке. Однако альтернативная техническая концепция использует «магазинную шкуру». Специальный сенсорный коврик на полу полки фиксирует вес находящихся на ней товаров, позволяя фиксировать выемку товаров и приблизительно оценивать количество имеющихся товаров.
Рисунок 1. Модель дистанционного учета запасов предприятия [12].
Если единица хранения физически хранится на каком-либо месте хранения, это изменение должно быть отражено в образе цифрового склада. Это осуществляется посредством складского резервирования и позволяет осуществлять процессы хранения, вывоза и перемещения. Некоторые системы управления складом руководствуются принципом «нет записи без чека», как известно из бухгалтерского учета. Поэтому для проводки складского движения необходимо наличие соответствующего складского или приемочного заказа. Представление места хранения в базе данных зависит от типа склада или складской площади. Например, на полках с фиксированными местами хранения место хранения может быть описано уникальным именем полки, а также информацией о строках и столбцах. На зональном складе или стеллажной системе патерностера необходимо использовать другие подходящие системы. Информация о месте хранения должна позволять сотрудникам и, при необходимости, автоматизированным складам находить товар без сложного поиска [2, c. 286-288].
Описанный выше алгоритм управляется через центральный функционал приложения, когда как работа с базами данных формируется посредством активных запроса, редактируемых после проверки из стека. В этом случае, с помощью стандартных библиотек данных, собирается информация от каждой ячейки, а на каждый транспондер создается отдельный поток. Закрытое обращение позволяет лишь с помощью центрального ключа получить выгрузку, когда как каждый транспондер может быть настроен с помощью отдельной разбалансировки на определенное значение. Например, в ячейке остается меньше товара, чем должно в ней быть, в этом случае программа делает полученные данные открытыми, и передаёт запрос на покупку. Поэтому система управления складом посредством PHP должна обеспечивать высокую доступность данных. Временные сбои могут произойти, если все или часть данных временно недоступны из-за аппаратных ошибок, проблем с программным обеспечением или сбоев связи. Однако данные остаются нетронутыми и могут быть восстановлены из резервных копий. Безвозвратная потеря данных происходит, когда данные уничтожаются из-за дефекта или ошибки программного обеспечения и не могут быть восстановлены из-за отсутствия или устаревших резервных копий. В таком случае восстановление базы данных требует трудоемкой и трудоемкой инвентаризации.
Мастер-данные, по определению Хансена и Неймана, — это «данные, ориентированные на условия, которые используются для идентификации, классификации и характеристики фактов и которые доступны в неизменном виде в течение длительного периода времени». Они часто используются в различных бизнес-процессах в разных отраслях. Центральное администрирование этих наборов данных освобождает отдельные отделы от ответственности за независимое хранение данных и их актуальность. Избегая избыточного хранения данных, управление основными данными упрощает обеспечение согласованности в масштабах всей компании. В области управления складом особенно важны основные данные материалов. Они описывают ассортимент предметов или материалов, используемых в компании. Каждый тип материала идентифицируется уникальным, часто внутренним номером позиции или материала компании. Основные данные материала, относящиеся к LVS, могут включать в себя такую информацию, как размеры, вес, особые требования к хранению (например, для замороженных товаров или опасных товаров), назначенные места хранения, отчетные запасы и т. д. Кроме того, они также могут содержать информацию об отслеживании партий, серийных номерах или сроках годности, чтобы более точно различать отдельные запасы [3, c. 149-154].
Семантическая информация, такая как размер или варианты цвета предметов одежды или диаметры резьбы типов винтов, также может быть отмечена в основных данных материала. Дополнительная информация, такая как поставщики, цены или сроки пополнения запасов, может храниться для других подразделений компании. Логический образ существующих складских или парковочных мест в компании также можно рассматривать как форму основных данных, и ниже они называются основными данными склада. Они включают информацию о различных складских помещениях, типах складских помещений (например, высокие стеллажи, напольные блоки), а также количестве и расположении складских помещений. Дополнительные свойства, такие как максимальные нагрузки, размеры и этикетки для хранения охлажденных, глубоко замороженных или опасных грузов, также могут храниться в основных данных склада. После принятия товара товар может быть переупакован в подходящее погрузочное оборудование с последующей вывозкой. Товары объединяются в единицы хранения (LE) и логически фиксируются в системе. Каждая созданная единица хранения получает этикетку, содержащую как простой текст, так и машиночитаемые идентификационные элементы, такие как штрих-коды. В ходе этого процесса информация может быть получена из основных данных материала, которые содержат, например, инструкции по упаковке или другую информацию для этого шага. В зависимости от конструкции процесса данные заказа также могут быть запрошены, чтобы решить, что делать с доставленными товарами. Таким образом, материалы, которые необходимы немедленно для поставки продукции, могут быть отправлены напрямую, без предварительного хранения. В этом случае мы предполагаем, что созданный LE необходимо сохранить.
Рисунок 2. Циклограмма наследования,
выстроенная через открытые библиотеки PHP [13].
Во-первых, подыскивается подходящее свободное место для хранения, при этом необходимо учитывать особые требования к хранению (например, для охлажденных товаров или опасных грузов) или специально отведенные места для хранения. Эта информация содержится в основных данных материала и необходима для принятия решения о том, подходит ли место склада. Свойства склада (грузоподъемность, размеры и т. д.) из основных данных склада сравниваются с требованиями LE на основе информации о месте хранения выбирается и резервируется одно из доступных мест хранения, чтобы гарантировать, что это место хранения не будет передано кому-либо другому. Для этого требуется доступ на запись к информации о месте хранения [4, c. 141-144].
Затем создается заказ на транспортировку для выполнения складирования. Отдельные этапы процесса перевозки контролируются путем идентификации погрузочной единицы и отсека для хранения. После завершения приемки на склад LE переносится на новое место хранения путем обновления информации о месте хранения. В течение периода хранения условия хранения контролируются: датчики фиксируют условия окружающей среды, такие как температура на складе глубокой заморозки, и обеспечивают соблюдение установленных предельных значений. Условия окружающей среды обычно определяются независимо от хранящихся товаров и не адаптируются динамически к содержимому склада. Кроме того, контролируется количество запасов, при этом покупатель получает уведомление, если отчетный запас падает ниже прописанного количества, что позволяет своевременно разместить повторный заказ. Для этого мониторинга требуется доступ для чтения к данным запасов и основным данным материалов, в которых хранятся отчетные запасы.
Рисунок 3. Алгоритм наследования создаваемых API [11].
Процесс отпуска материала инициируется внешним заказом, например, заказом на отгрузку или заказом на пополнение запасов. Во-первых, необходимый товар должен быть найден на складе, что требует доступа на чтение данных инвентаризации. Если искомый товар имеется на складе несколько раз, выбор осуществляется в соответствии со стратегией работы склада. Помимо правил, связанных с товарами (таких как «первым поступило — первым отправлено» или «первым истек срок годности — первым отправлено»), также могут быть приняты во внимание такие факторы, как транспортные расходы. Выбранный LE зарезервирован, и создается приказ об удалении. После удаления со склада движение запасов фиксируется путем обновления информации о месте хранения. При передаче товара на отгрузку проводится проводка запасов со склада и соответствующие данные запасов удаляются, для этого также можно использовать фреймворк Eventuate Tram Saga. Хранение данных относится к постоянному хранению информации на носителях данных [5, c. 174].
Одной из возможных проблем может стать количество исходных значений, которые будут перегружать код. Однако предложенный алгоритм сбора данных предполагает, что каждая переменная, обозначающая конкретный товар, будет вызываться лишь в случае либо пополнения ячейки, либо уменьшения количества товара в ней. В примерах, рассмотренных выше, контроль осуществлялся благодаря облачному хранению, что снижает затраты на центральный алгоритм.
В системе управления складом могут встречаться разные типы данных, и для каждого из этих типов данных могут использоваться разные концепции хранения данных, будь то централизованные или децентрализованные. В контексте этого текста под хранением данных понимается хранение основного экземпляра набора данных. Важно отметить, что простой копии записи или идентификатора, указывающего на запись (например, в центральной базе данных), недостаточно.
Следует отметить, что, согласно этому определению, наличие активной вычислительной единицы не является обязательным условием локального хранения данных. Данные также могут храниться на пассивных транспондерах RFID или простых носителях данных, таких как дискеты или USB-накопители, при условии, что носитель данных допускает перезапись. Когда дело доходит до децентрализованного хранения данных, необходимо учитывать особенности PHP. Это означает, что согласованность, доступность и устойчивость к разделению не могут быть достигнуты одновременно. В контексте децентрализованного управления складом это означает, что в случае сбоя связи с самоуправляемой складской зоной информация об имеющихся на ней запасах либо перестанет быть доступной, либо вам придется продолжать работу с копиями, которые могут быть неактивны. В таком случае, созданная система воплощает политику разрозненных кусков бизнес функциональности, которые собираются вместе в случае запроса посредством централизованного UI, программы складского управления, реализующей данный принцип [6, c. 24].
Данные внешних заказов (заказы, объявления о доставке и т. д.) возникают вне зоны ответственности системы управления складом и запускают процессы на складе. Данные заказа, такие как позиции заказа или адрес доставки, необходимы для управления этими процессами. Эти данные могут храниться непосредственно на затронутых устройствах хранения. Для входящей поставки (поступления товара) эти данные должны быть доступны по прибытии и предоставлены поставщиком. Но в случае заказов или заказов на отгрузку сначала необходимо идентифицировать затронутые единицы хранения и передать им данные заказа. В этом случае данные о накопителях можно будет использовать для контроля и наблюдения за последующими процессами.
Данные внутренних заказов, такие как заказы на хранение и поиск, заказы на транспортировку и заказы на комплектацию, используются для выполнения внешних заказов или для реализации внутренних складских процессов (например, перемещения в складскую организацию, заказы на пополнение). Заказы на хранение могут быть записаны непосредственно в единицы складирования, чтобы передать транспортному средству назначение транспортировки. С другой стороны, заказ на аутсорсинг сначала должен быть передан в хранимое подразделение. Информацию о месте посадки придется передавать транспортным средствам другим способом. Транспортному средству в любом случае необходимо управлять этой информацией, чтобы знать пункт назначения, поэтому имеет смысл хранить весь заказ на самом транспортном средстве.
Сохранение основных данных материалов, релевантных для склада, на самих товарах дает то преимущество, что информацию о товарах можно считывать даже при отсутствии центрального органа. Если одни и те же материалы доступны несколько раз в разных единицах складирования на складе, соответствующие основные данные материала также должны быть доступны несколько раз в соответствующих единицах складирования, складах или зонах хранения (избыточность). Чтобы избежать несоответствий, следует убедиться, что каждый узел имеет текущую запись основных данных, но только тогда, когда она действительно предназначена для использования. Прежде чем использовать набор основных данных, вы можете проверить, актуален ли он. Однако существует риск несоответствий из-за неправильного многократного создания записей основных данных для одного и того же материала, аналогично центральному хранению данных.
Одним из вариантов автоматического сбора данных являются активные или полуактивные PHP протоколы (метки) UHF в сочетании с одной или несколькими стационарными антеннами. Активные транспондеры характеризуются большой, часто перезаписываемой памятью объемом до нескольких мегабайт и большим диапазоном считывания. Протоколы PHP можно считывать без прямого визуального контакта, что позволяет одновременно обнаруживать несколько транспондеров с помощью одного процесса считывания, известного как массовое обнаружение. Это может сэкономить время, например, при получении товара. Преимущество массового захвата увеличивается с увеличением количества считываемых тегов. Однако из-за высокой стоимости активные транспондеры можно прикрепить лишь к небольшому количеству (обычно высококачественных) изделий. Активные и полуактивные протоколы также могут быть оснащены внешними датчиками, например, датчиками температуры, для регистрации изменения температуры во время транспортировки. Эту информацию можно оценить при обеспечении качества [10, c. 148-164].
Активные протоколы также можно использовать для контроля условий хранения. Если измеренные значения выходят за пределы допустимого диапазона, транспондеры выдают соответствующий сигнал тревоги в среде хранения через подключенные датчики. Эти возможности становятся возможными благодаря собственному источнику питания, либо от батарей, либо от подключения к сети. В полуактивных транспондерах дополнительный источник питания используется только для поддержания энергонезависимой памяти и работы датчиков. Если используется несколько протоколов обнаружения, метки все равно записываются в разных местах. Поэтому желательно синхронизировать зоны хранения и чтения данных считывателей с децентрализованным управлением складом, чтобы материалы и информация были доступны в одном и том же месте.
Другой вариант сбора данных — использование RFID-ворот и пассивных меток. Из-за отсутствия стабильного и достаточно мощного источника питания к пассивным меткам невозможно подключить дополнительные датчики. Радиус действия транспондеров зависит от полосы частот и условий окружающей среды. По сравнению с низкочастотными метками передача данных в PHP протоколах происходит быстрее. Поэтому требуются более мощные антенны, чем в активных системах. Обратите внимание, что низкочастотные транспондеры — единственные транспондеры, которые нельзя использовать в системах массового обнаружения. Когда товары поступают на хранение, они сначала идентифицируются, и соответствующая информация о товарах, такая как тип продукта, размеры и вес, сохраняется в заказе на хранение. Эти заказы на размещение, которые еще не были обработаны, могут быть запрошены сотрудниками через узлы ввода-вывода и отображены на этих устройствах. После выбора заказа его статус меняется с «открыто» на «в работе». Это изменение состояния синхронизируется службой каталогов на всех других узлах ввода-вывода, чтобы предотвратить одновременное редактирование двумя пользователями одного и того же задания [7, c. 18].
Как только сотрудник выбирает заказ на размещение, запрос на размещение отправляется всем активным узлам складской зоны вместе с ранее сохраненной информацией о товаре. Они проверяют, могут ли они принять рассматриваемый товар. Сюда входит проверка наличия достаточного свободного места, утверждение типа продукции для хранения на складе и соблюдение максимальных размеров хранения. Проверка заканчивается отправкой подтверждения или отклонения запрашивающему узлу ввода-вывода на хранение. Если получено подтверждение, на запрашивающий компьютер также отправляется информация о подходящем месте хранения. Узлы, фиксирующие хранилище, не будут принимать дальнейшие запросы в течение ограниченного времени, чтобы избежать возможных конфликтов при резервировании места для хранения. Однако эта остановка запроса будет отменена самое позднее после получения ответа от запрашивающего узла.
Когда отправленные сообщения достигают запрашивающего узла ввода-вывода, он выбирает один из полученных обещаний. Результат выбора отправляется обратно отправителям промисов. Выбранный узел складской зоны затем резервирует соответствующее место хранения для новых запросов на размещение. Затем этот узел отправляет подтверждение резервирования запрашивающему узлу ввода-вывода. Получив это подтверждение, узел ввода-вывода обновляет место хранения в порядке хранения и отображает результат пользователю. Затем товары транспортируются в соответствующее место хранения и хранятся. Приемка на склад завершается подтверждением приемки на узел склада, который обновляет свой инвентарный список хранящимися товарами и отменяет резервирование места хранения.
Для поиска сохраненного продукта пользователь вводит нужные атрибуты продукта на узле ввода-вывода и отправляет их всем узлам, запрошенным из службы каталогов. Узлы ищут товары, соответствующие указанным атрибутам, и отправляют список результатов поиска исходному узлу ввода-вывода. Результаты поиска из различных узлов области хранения объединяются, сортируются и отображаются пользователю. Эта последовательность операций работает аналогично для запасов, при этом поиск ведется не по конкретным атрибутам товара, а по всем товарам, имеющимся на складе. Полученные результаты поиска можно использовать, например, для составления заказов клиентов. Здесь узел ввода-вывода отправляет запрос на удаление товара с искомыми атрибутами во все узлы складской зоны. Они проверяют, возможен ли аутсорсинг в зоне их ответственности, и отправляют соответствующий ответ обратно на узел ввода-вывода. Подобно процессу заказа на размещение, описанному ранее, узлы складской зоны, которые зафиксировали, не будут принимать другие конкурирующие запросы в течение определенного периода времени. Узел ввода-вывода выбирает вариант на основе всех полученных ответов и отправляет результат своего выбора (утверждение или отклонение) обратно в соответствующие узлы области хранения. Когда узел зоны хранения получает одобрение, он резервирует товары для вывоза. Это резервирование отправляется обратно в качестве подтверждения на узел ввода-вывода, который затем обновляет заказ на аутсорсинг, указав конкретные сведения о товарах, подлежащих аутсорсингу, и пункте назначения. Результат этого обновления отображается пользователю на экране [8, c. 251-273].
Принятие исходящего заказа происходит таким же образом, как описано для входящих заказов. Если товар вывезен успешно, сотрудник подтверждает это, отправляя подтверждение вывоза ответственному узлу склада через узел ввода-вывода. Затем он обновляет список инвентаря. Узел ввода-вывода помечает состояние задания разгрузки как завершенное и сообщает об этом обновленном состоянии службе каталогов. Как только сообщение о завершенном задании достигает службы каталогов, она обновляет список заданий на всех остальных узлах ввода-вывода в соответствии со своим собственным списком заданий. Реализация распределенной системы требует больше усилий, чем центральных систем, из-за интенсивного общения между участниками сети. Это особенно актуально для операций запроса, которые отправляются посредством широковещательной рассылки и ответы, на которые необходимо обработать позже. Синхронизация таких данных, как основные данные или данные заказа, увеличивает сложность. Такие помехи, как задержка, дрожание и шум, могут повлиять на сетевую связь и привести к задержкам или отсутствию ответов. Эти сбои могут быть вызваны помехами, коллизиями сообщений и ограниченной полосой пропускания [9, c. 1].
Когда связь происходит по беспроводным сетям, возникают дополнительные ограничения из-за совместного использования среды передачи и возможных внешних помех в том же диапазоне частот. Это приводит к большим колебаниям задержки, пропускной способности и доступности по сравнению с проводной связью. Проблемы связи в настоящее время трудно или невозможно решить. Поэтому важно реализовать надежную модель связи, которая может либо компенсировать, либо, по крайней мере, обнаруживать возникающие ошибки, особенно для процессов, требующих высокой доступности данных, таких как инвентаризация или создание заказов на повторный заказ. Однако следует отметить, что беспроводная связь также может использоваться в различных формах в системах управления центральным складом, например, когда заказы передаются через WLAN на мобильные вычислительные устройства на вилочных погрузчиках или сборщикам заказов.
Заключение.
В этой статье представлено всестороннее исследование децентрализованных систем управления складом, в котором особое внимание уделяется масштабируемым и эффективным стратегиям управления запасами. Изучая дизайн модульных систем и децентрализованные механизмы управления, демонстрируется, как эти подходы повышают гибкость и оперативность в складских операциях. Интеграция таких технологий, как RFID и беспроводные сенсорные сети, наряду с использованием открытых библиотек на базе PHP, обеспечивает динамичную и адаптируемую среду для управления запасами и хранилищем. Исследование подчеркивает потенциал децентрализации процессов обработки данных и принятия решений, которая может революционизировать способ ведения складских операций. Этот сдвиг в сторону децентрализации не только упрощает операции, но и значительно снижает зависимость от центральных хранилищ данных, снижая риски, связанные с потерей данных и системными сбоями. Полученные результаты свидетельствуют о том, что внедрение этих инновационных методов может привести к более эффективным, экономичным и устойчивым методам управления складом, что в конечном итоге будет способствовать оптимизации общего управления цепочкой поставок.
СПИСОК ЛИТЕРАТУРЫ:
Alekseev A.A.
Moscow Financial and Industrial University Synergy
(Kostroma, Russia)
USING PHP APIS AND MICROSERVICES IN INVENTORY ACCOUNTING
Abstract: modern IT systems play a crucial role in the daily activities of manufacturing companies, trading companies and logistics service providers. Enterprise resource planning (ERP) systems, warehouse management systems (WMS), commodity management systems (S) and warehouse management systems (LVS) are indispensable in medium and large companies — from customer order management to production control and shipment processing. These systems are extremely complex and often interconnected through automated processes, so they can often be adapted to the specific needs of the company (customization). The purpose of this article is to conduct a detailed analysis of the use of APIs and microservices in PHP in inventory accounting, establishing their capabilities, focusing on solutions that are popular on the market. As a result, the existing APIs on the market were analyzed, their features were analyzed, and the role of PHP in building a flexible inheritance system thanks to open data libraries. At the same time, demands on companies are increasing due to changing market conditions. International competition in global markets, economic fluctuations and short innovation cycles require companies to be highly adaptable. IT systems must support this adaptability and provide flexibility and scalability in addition to basic functional requirements. Such systems are characterized by high flexibility and scalability. They can be easily adapted to changing requirements and expanded to include additional devices. Individual elements can be changed, replaced or added if they are compatible with the basic communication protocols.
Keywords: logistics systems, data structures, microservices, inventory accounting, parallel storage.
Номер журнала Вестник науки №1 (70) том 3
Ссылка для цитирования:
Алексеев А.А. ИСПОЛЬЗОВАНИЕ API И МИКРОСЕРВИСОВ НА PHP В УЧЕТЕ ТОВАРНЫХ ЗАПАСОВ // Вестник науки №1 (70) том 3. С. 632 - 651. 2024 г. ISSN 2712-8849 // Электронный ресурс: https://www.вестник-науки.рф/article/12517 (дата обращения: 18.05.2024 г.)
Вестник науки СМИ ЭЛ № ФС 77 - 84401 © 2024. 16+