Вариант реализации адресного хранения в УПП 1.3

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

(41) Добрый день,
Никаких прорывных технических фишек на данном проекте, пожалуй, что не было. В ходе внедрения больше делали упор на качестве бизнес-процессов и максимальной эффективности и простоте работы линейных сотрудников.
Из особенностей можно отметить в частности:
1. Основной документ подсистемы «Перемещение товаров по ячейкам» тесно связан с типовыми документами опер. Учета. Реализован ввод на основании типовых документов (об этом написано в статье). При проведении типовых документов движения (ПТиУ, перемещение, требование-накладная, реализация…) реализован контроль остатков не только по типовым регистрам, но и по нашему регистру. Все это гарантировало корректный параллельный учет в двух контурах.
2. При поступлении товаров на адресный склад (ввод документа «Перемещение товаров по ячейкам» на основании типовых документов) документ заполняется автоматически, при этом автоматом подбираются ячейки склада для каждого товара согласно определенного алгоритма – программа сначала пробует расположить товар в ячейке определенной для товара как основная, а если она уже занята, то ищет наиболее близкую к ней свободную ячейку. Это позволяет группировать один и тот же товар из разных партий в определенных областях склада, уменьшает его «фрагментацию» и сокращает передвижение сотрудников по складу.
3. При отборе со склада так же реализованы некоторые алгоритмы подбора: ячейки которые программа автоматически указывает для отбора, определяются по FIFO партий по поступлению на склад или по срокам годности товара если он ведется. При этом также учитывается близость расположения ячеек, для сокращения передвижения по складу.
4. Подсистема заточена под многопользовательскую работу за счет использования оповещений. То есть одни сотрудники (менеджеры) оформляют типовые документы, а другие (кладовщики) документы перемещения по адресному складу. Чтобы упростить их взаимодействие, реализованы оповещения: после оформления типового документа (например, ПТиУ, Заказ на внутреннее потребление и т.д.) фоновое задание генерирует оповещение кладовщику оповещение о том, что необходимо сформировать «Перемещение товаров по ячейкам». Кладовщик, переходит к указанному документу и вводит на основании него свое перемещение. Аналогично в обратной ситуации, товар по заказу собран кладовщиком в зоне отгрузки генерируется оповещение ответственному сотруднику, что можно оформлять отгрузку (РТиУ, Т-Н). Вот такая фишка – не надо никому звонить с этажа на этаж))))
5. На первом складе на котором, осуществлялось внедрение, подстроились под уже имевшееся оборудование. Там был wi-fi сканер штрих-кодов. Соответственно задействовали его. Фактически это происходило так: кладовщик создавал, заполнял документ «Перемещение товаров по ячейкам», распечатывал себе задание с маршрутом (есть такая ПФ у документа), брал в руки сканер и отправлялся в путь))) документ на компьютере оставался открытым… В процессе кладовщик считывал штрих-коды с ячейки и с упаковки товара – тем самым подтверждая что товар из ячейки он забрал.. Программа по считанным штрих кодам определяла строку документа и устанавливала в ней отметку-подтверждение (не редактируется вручную). Так последовательно по всем адресам. Движения по регистру создаются только при установленном признаке подтверждения. Иначе выдается сообщение и движение по строке не выполняется – кладовщик разбирается с проблемой.
Если при считывании штрих-кодов программа не находила строку в документе (пересорт) 1С издавала «тревожный звук»))) чтобы кладовщик мог понять, что что-то пошло не так (компьютер находится вне зоны видимости в этот момент) – вот такая фишка))))
На последующих складах предполагалось уже использовать ТСД…
6. На первом этапе вся ячейки считались безразмерными, т.е. могли вместить любое количество товара, но не допускалось совместное хранение, то есть если ячейка уже занята (пусть даже минимальным количеством товара), то в дальнейшем в ней не удастся разместить товар даже ту же номенклатуру… В последующем насколько мне известно при внедрении на других складах использовались массо-габаритные характеристики и контролировалось возможность размещения конкретных упаковок в конкретные ячейки… но это уже без меня…
7. Еще была заложена возможность генерировать штрих-коды (для ячеек склада и для упаковок товара не имевшего собственный штрих-код). При этом генерация и печать штрих-кодов для упаковок были встроены в процесс приемки товара, чтобы минимизировать задержки на этом этапе.
Это вкратце то, что удалось вспомнить по прошествии лет…
На самом деле от заказчика по результатам ОПЭ поступил целый ряд пожеланий по расширению функционала подсистемы при внедрении на новые склады, но в этом проекте я уже участвовал лишь косвенно…

(44) хорошее расследование ))
Я понимаю, что в интернете никого ни в чем убедить нельзя...
Обработку я действительно скачивал - было любопытно, что интересного есть в текущей реализации...Тем более, что сотрудничество с заказчиком продолжалось и у него были запросы на развитие функционала (в частности требовалось адресный учет материалов в НЗП).
Что касается отзыва и статьи, то в 18 году у нас изменилась схема мотивации согласно которой сотрудникам требовалось не просто участвовать в разрабатывать, но и получать положительные отзывы, делиться опытом с помощью статей и вебинаров (именно с 18 года их стало появляться на сайте достаточно много ))) Поэтому и отзыв и статья были подписаны "с оттяжкой" из моих меркантильных целей...
Ну и напоследок - я при разработке "вдохновлялся" в первую очередь реализацией в типовой ERP/УТ11, как впрочем и автор данной разработки - см. например, обработку "Генерация топологии склада"))) Так, так что очевидно, что схожесть решений обусловлена именно общим предком)))