Автоматическая отгрузка по заказу клиента
УТ 11.5. Ордерный склад
Интернет магазин оптовой торговли. Ежедневно получаем сотни заказов от клиентов. 90% товаров привозится под заказ. Реализации клиентов могут содержать в себе несколько десятков заказов.
Пожалуйста, помогите разобраться с проблемой
1) После того, как товар поступил на склад, по заказам клиентов надо вручную сделать действие "Отгрузить".
Неужели никак нельзя автоматизировать данное действие? Чтобы после того, как товар стад доступен он сразу же перешел в отгрузку?
2) У нас каждая минута на счету. А на создание расходных ордеров может уйти 2-3 часа (!!!). То есть в среднем у 1С на создание 1го ордера уходит 7 сек, а иногда и больше. А нам надо оперативно собрать товар по 500 клиентам. В чём может быть проблема столь долгого процесса? (проблем с железом не имеем)
Интернет магазин оптовой торговли. Ежедневно получаем сотни заказов от клиентов. 90% товаров привозится под заказ. Реализации клиентов могут содержать в себе несколько десятков заказов.
Пожалуйста, помогите разобраться с проблемой
1) После того, как товар поступил на склад, по заказам клиентов надо вручную сделать действие "Отгрузить".
Неужели никак нельзя автоматизировать данное действие? Чтобы после того, как товар стад доступен он сразу же перешел в отгрузку?
2) У нас каждая минута на счету. А на создание расходных ордеров может уйти 2-3 часа (!!!). То есть в среднем у 1С на создание 1го ордера уходит 7 сек, а иногда и больше. А нам надо оперативно собрать товар по 500 клиентам. В чём может быть проблема столь долгого процесса? (проблем с железом не имеем)
По теме из базы знаний
- Отменённые отгрузки по заказам клиентов, заказам на перемещение. УТ 11
- "БИП: Бизнес-Процессы". Пример настройки сценария "Обработка интернет-заказа клиента"
- Рабочее место доставки с дополнительными полями и фильтрами: Организация, состояние заказа клиента, партнер, только заказы клиентов – УТ 11, КА 2, ЕРП 2
- Перенос резервов по заказам клиентов 1С:УПП -> ERP 2.5.7
- Отгрузка заказа клиента в 1 клик для УТ 11.5, КА 2.5, ERP 2.5
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Можно автоматизировать, но тут нужен программист и грамотный алгоритм. Во-первых, надо поймать момент "товар доступен". Во-вторых, проверка свободных остатков и все такое что еще надо проверить при отгрузке. И всякие блокировки, алгоритм делает отгрузку, манагер делает отгрузку, сделали отгрузку, потом распровели поступление, потому что там ошиблась Маша и вот это вот все. И надо будет писать какие-то сообщения куда-то в случае проблем, причем чтобы их адресаты увидели достаточно онлайн, а не через неделю. Не такая простая задача это все вместе
(1)
мне так сдается, для УТ11 7 секунд это считай быстрее скорости света. Программа эта оооочень нетороплива. Кто понял жизнь, тот не спешит
надо вручную сделать действие "Отгрузить"
Можно автоматизировать, но тут нужен программист и грамотный алгоритм. Во-первых, надо поймать момент "товар доступен". Во-вторых, проверка свободных остатков и все такое что еще надо проверить при отгрузке. И всякие блокировки, алгоритм делает отгрузку, манагер делает отгрузку, сделали отгрузку, потом распровели поступление, потому что там ошиблась Маша и вот это вот все. И надо будет писать какие-то сообщения куда-то в случае проблем, причем чтобы их адресаты увидели достаточно онлайн, а не через неделю. Не такая простая задача это все вместе
(1)
То есть в среднем у 1С на создание 1го ордера уходит 7 сек, а иногда и больше
мне так сдается, для УТ11 7 секунд это считай быстрее скорости света. Программа эта оооочень нетороплива. Кто понял жизнь, тот не спешит
(2) штатный кодер все прописал, и оно работает. Но работает охренеть как долго, имеется ввиду процедура создания расходных ордеров.
А ребята на складе не могут приступить к сборке груза пока все ордера не будут готовы. Час-два после приемки груза просто сидят и ждут пока появятся расходники.
Я просто до последнего надеялся, что это мы со своей стороны может написали чего лишнего, и наверное есть все таки какой-то типовой метод, который выполняет это дело быстрее.
Просто в голове не укладывается, как и почему это все не предусмотрено, и самое главное почему так медленно...
А ребята на складе не могут приступить к сборке груза пока все ордера не будут готовы. Час-два после приемки груза просто сидят и ждут пока появятся расходники.
Я просто до последнего надеялся, что это мы со своей стороны может написали чего лишнего, и наверное есть все таки какой-то типовой метод, который выполняет это дело быстрее.
Просто в голове не укладывается, как и почему это все не предусмотрено, и самое главное почему так медленно...
(11) ну например чтобы склад успел все собрать. Если в 500 доках есть товар А и товар Б, можно подойти к полке и взять сразу 500 товаров А, а можно 500 раз сходить к полке, где он лежит, и взять по одной штуке. И есть вероятность, что второй путь не будет оптимальным.
Впрочем, настоящие программеры 1с такими мелочами не заморачиваются, это проблема склада ))))
Впрочем, настоящие программеры 1с такими мелочами не заморачиваются, это проблема склада ))))
(14) принцип такой, что у каждого клиента своя ячейка или группа ячеек (но сам склад не адресный). Чтобы не тратить время на сканирование ячейки, клиент идентифицируется визуально по логину. Логин в свою очередь нанесен уже на прибывший товар. В общем приёмщик должен читать информацию, и знать полку. Да, бывают ошибки, но скорость важнее.
Тут один форумчанин пытался умничать, поясню в том числе и для него. Когда имеется несколько сотен заказов клиентов, и клиент N имеет в разный период 5 заказов клиентов, в каждой строке содержится 5 строк, но представим, что по каждому из этого заказа прибыло по 1-2 строки, которые надо тут же отгрузить. Так вот, единый расходный ордер на все эти строки разом не создаётся. Создаётся вначале один ордер, затем в порядке очереди следующий итд (не важно, стоит настройка группового ордера 1 клиент 1 ордер, или же создание на каждый заказ отдельный ордер). Пока нет полной картины, что надо собрать, кладовщик не преступает к сборке
Тут один форумчанин пытался умничать, поясню в том числе и для него. Когда имеется несколько сотен заказов клиентов, и клиент N имеет в разный период 5 заказов клиентов, в каждой строке содержится 5 строк, но представим, что по каждому из этого заказа прибыло по 1-2 строки, которые надо тут же отгрузить. Так вот, единый расходный ордер на все эти строки разом не создаётся. Создаётся вначале один ордер, затем в порядке очереди следующий итд (не важно, стоит настройка группового ордера 1 клиент 1 ордер, или же создание на каждый заказ отдельный ордер). Пока нет полной картины, что надо собрать, кладовщик не преступает к сборке
(7)
ну тут надо смотреть детально. Что сколько времени занимает, можно ли с этим что-то сделать. Я так подозреваю, что основной проблемой будет запись движений документов и для исправления этого надо заново писать всю программу полностью, начиная с платформы. Но это нельзя сказать, не покопавшись в отладчике.
Или менять полностью алгоритм, сначала давать склады список, что куда отгружать, а потом уже документы проводить. Тут тоже будут свои проблемы, но, возможно, проблему можно решить как-то так
Но работает охренеть как долго, имеется ввиду процедура создания расходных ордеров.
ну тут надо смотреть детально. Что сколько времени занимает, можно ли с этим что-то сделать. Я так подозреваю, что основной проблемой будет запись движений документов и для исправления этого надо заново писать всю программу полностью, начиная с платформы. Но это нельзя сказать, не покопавшись в отладчике.
Или менять полностью алгоритм, сначала давать склады список, что куда отгружать, а потом уже документы проводить. Тут тоже будут свои проблемы, но, возможно, проблему можно решить как-то так
(3) этот механизм давно отлажен с точностью в 99% ). Тут на помощь приходят характеристики, каждая строка заказа имеет свой уникальный ID. Даже если одну туже номенклатуру закажут сотня разных клиентов, с разной ценой и сроком.
Мы уже в документе поступления видим какому клиенту принадлежит товар.
В деталях объяснять - долго
Мы уже в документе поступления видим какому клиенту принадлежит товар.
В деталях объяснять - долго
(8) И "штатный кодер" конечно же не стал заморачиваться регистрами накопления с измерением по данном id, а тупо ищет все по табличным частям документов... Не удивлюсь, если и статусы движения товара он проставляет в самом заказе, и при каждом чихе его перепроводит...
Понабирают по объявлению.
оно работает. Но работает охренеть как долго
Понабирают по объявлению.
(8)
Почему бы вам не спросить об этом вашего штатного кодера и людей, принимавших решение?
Или вы их тоже уже попросили пройти мимо?
мы имеем возможность
Ну, то есть вместо анализа и возможного использования типового решения-методики, которое учитывает максимум ситуаций, вы силами штатного кодера наклепали что-то своё и оно у вас тормозит. И вот только на этом этапе вы спрашиваете "наверное есть все таки какой-то типовой метод, который выполняет это дело быстрее". Я ничего не упустил?
Почему бы вам не спросить об этом вашего штатного кодера и людей, принимавших решение?
Или вы их тоже уже попросили пройти мимо?
(18) меня удивляет "адекватность" некоторых персонажей на подобных форумах. Где вместо конструктива начинают лепить какие-то нелепые догадки. Как называется эта болезнь?
Зачем фантазировать, и лепить максимально глупые предложения? С чего вы взяли, что мы в свое время не использовали типовые решения?
Зачем фантазировать, и лепить максимально глупые предложения? С чего вы взяли, что мы в свое время не использовали типовые решения?
Раз товар визуально идентифицируется по логину - вместо логина договорится с поставщиками чтобы к буквенному логину наносил штрихкод клиента. У вас классический кросс-докинг, когда товар с поставки не заходит на хранение, а сразу сортируется/набирается в отгрузку. Совместить приемку с сортировкой на отгрузку (возможно ступенчатая сортировка). Классическая задача любой нормальной WMS. Один приемщик-сортировщик под управлением WMS сортирует товар примерно на 10-15 заказов - в пределах досягаемости протянутых рук (плюс-минус). Товар, который не "его" - отдельно.. ну и дальше... аналог раскладывания по ячейкам. Написал тупо, долго не думая. По уму - надо внимательно смотреть на товар, на объемы заказов, возможно есть варианты обслуживания товаропотока более производительные чем те, к которым вы привыкли. А возможно у вас вполне эффективный процесс.ю Программист только тупой, ибо на складе никогда не жил и сам с рохлей не ходил, на приемке не стоял, на комплектации не работал. Поэтому и пишет херню, которая "долго работает", ибо дитя учетной системы.
.
правда, с такого описания как в (0) и (15) - фиг то поймешь. то есть сборщики, которые сидят и ждут, то есть приемщик который должен знать полку клиента...? кто что делает - трэш и угар. Какое описание задачи, так ваш программер и программит ;-)
.
Посмотрите в сторону WMS.
.
Посмотрите в сторону автоматических сортировщиков, например COMITAS.
Сходите на CeMAT-2025 (где-то в сентябре будет), будет интерес - подходите, пообщаемся.
.
правда, с такого описания как в (0) и (15) - фиг то поймешь. то есть сборщики, которые сидят и ждут, то есть приемщик который должен знать полку клиента...? кто что делает - трэш и угар. Какое описание задачи, так ваш программер и программит ;-)
.
Посмотрите в сторону WMS.
.
Посмотрите в сторону автоматических сортировщиков, например COMITAS.
Сходите на CeMAT-2025 (где-то в сентябре будет), будет интерес - подходите, пообщаемся.
(21) вот это уже другой разговор. Сразу видно, что Вы в теме)).
Все верно описали, у нас кросс-докинг + сток (но сейчас речь не о стоке).
Поставщик может нанести в виде штрихкода только ID строки. По этим самым ID оприходуется товар с помощью ТСД, визуально идентифицируется клиент по логину и кладется на соответствующую полку.
В среднем в одном документе приобретения 2000 строк.
В защиту программиста скажу. Я поэтому не применял слово программист, но довольно качественный кодер. Я сам жил на складе, и знаю все бизнес процессы в компании, и занимаюсь их аналитикой и автоматизацией. И постановкой задач занимаюсь сам.
И я тоже не был экспертом 1С. Просто пришла необходимость, и да, с кучей ошибок проделали большой путь.
Два года назад перешли в чистую от доработок базу и перешли на ордерную схему работы склада. Основной принцип сейчас - максимально задействовать типовой функционал, и не допиливать.
Проблема была с самого начала. Когда имеется несколько сотен строк, выделяются все строки со статутом "Готов к отгрузке" - "Отгрузить", а затем тоже самое со строками "Ожидается обеспечение" (заказ прибыл частично). Было подозрение, что это от того, что выделяются лишние строки "Ожидается обеспечение" по которым поступлений никаких нет. Но после некоторых доработок с отбором нужных заказов не сильно что-то поменялось. В среднем по документам "Готов к отгрузке" уходило на создание ордера около 7 сек, при типовом варианте с ручной отгрузкой. То есть это около 1 часа.
Поэтому сейчас стал смотреть в сторону WMS, но так как не до конца понимаю что это даст существенно и стал писать сюда. В нашем регионе к сожалению толково с этим проконсультировать не могут.
Ваше приглашение заинтересовало. Даст Бог - увидимся!
Все верно описали, у нас кросс-докинг + сток (но сейчас речь не о стоке).
Поставщик может нанести в виде штрихкода только ID строки. По этим самым ID оприходуется товар с помощью ТСД, визуально идентифицируется клиент по логину и кладется на соответствующую полку.
В среднем в одном документе приобретения 2000 строк.
В защиту программиста скажу. Я поэтому не применял слово программист, но довольно качественный кодер. Я сам жил на складе, и знаю все бизнес процессы в компании, и занимаюсь их аналитикой и автоматизацией. И постановкой задач занимаюсь сам.
И я тоже не был экспертом 1С. Просто пришла необходимость, и да, с кучей ошибок проделали большой путь.
Два года назад перешли в чистую от доработок базу и перешли на ордерную схему работы склада. Основной принцип сейчас - максимально задействовать типовой функционал, и не допиливать.
Проблема была с самого начала. Когда имеется несколько сотен строк, выделяются все строки со статутом "Готов к отгрузке" - "Отгрузить", а затем тоже самое со строками "Ожидается обеспечение" (заказ прибыл частично). Было подозрение, что это от того, что выделяются лишние строки "Ожидается обеспечение" по которым поступлений никаких нет. Но после некоторых доработок с отбором нужных заказов не сильно что-то поменялось. В среднем по документам "Готов к отгрузке" уходило на создание ордера около 7 сек, при типовом варианте с ручной отгрузкой. То есть это около 1 часа.
Поэтому сейчас стал смотреть в сторону WMS, но так как не до конца понимаю что это даст существенно и стал писать сюда. В нашем регионе к сожалению толково с этим проконсультировать не могут.
Ваше приглашение заинтересовало. Даст Бог - увидимся!
(23)
- существенно это даст то, что попытки в учетную систему прикрутить управление складом - это идея ниже плинтуса, WMS работает из другой логики.
.
Вот были накладные. потом к ним прикрутили ордера. потом к ним прикрутили разбиение ордеров на задания. Делают все то (и кривовато), что в WMS сделано было давнм-давно. И идут по тем же граблям, переизобретая велосипеды.
оэтому сейчас стал смотреть в сторону WMS, но так как не до конца понимаю что
- существенно это даст то, что попытки в учетную систему прикрутить управление складом - это идея ниже плинтуса, WMS работает из другой логики.
.
Вот были накладные. потом к ним прикрутили ордера. потом к ним прикрутили разбиение ордеров на задания. Делают все то (и кривовато), что в WMS сделано было давнм-давно. И идут по тем же граблям, переизобретая велосипеды.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот