ASchekachev
Антон Щекачев

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

Добрый день!
На текущей архитектуре без проблем можно устанавливать резерв на разных складах, а не только на том что в Заказе клиента.

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

(33) В нашем случае, резерв через документ "Резервирование товаров" устанавливаем за несколько дней до отгрузки клиенту или до начала перемещения. Потому что такие товары исключаются из автоматического распределения товаров. Считается, что они уже с очень большой вероятностью будут отгружены. Поэтому если требуется уменьшить количество по Заказу клиента, то сначала нужно уменьшить количество по Заказу на обеспечение (контроль на уровне системы), а затем уменьшить количество по Заказу клиента. Если нужно уменьшить количество по Заказу на обеспечение и есть резерв, то система не даст это сделать и нужно будет обращаться в логистику, чтобы они сняли резерв и только после этого уже уменьшать количество по Заказу на обеспечение.

(1) Павел, приветствую!
Так в большинстве случаев на сайте работ работодатель ищет программистов на поддержку. А на поддержке в большинстве случаев требуются универсальные навыки. При этом они могут быть в каждой из областей средние, не обязательно крутые. Обмен подкрутить, проконсультировать пользователей и желательно по нескольким конфигурациям, что-то допилить и т.д. Когда кто-то уже внедрил методологию, поставил автоматизацию на рельсы (пусть и не на все 100% хорошо), то задачи поддержки они уже требуют другой компетенции. Брать на каждое направление нескольких сотрудников бывает не оправданно, но тут уже нужно исходить из нагрузки на специалиста.
Другое дело, когда компании ищут специалиста, который с нуля внедрит какой-то продукт или переделает за кем-то. Тут, конечно, и ожидания у Заказчика совсем другие, чем от специалиста поддержки и к ЗП как правило вопросов вообще нет, т.к. тут в ограниченный срок нужен конкретный результат. За проектными специалистами Заказчики как правило ходят по рекомендациям или по рейтингу с сайта 1С. Другой вопрос, что рейтинг не всегда показывает реальное положение дел, но Заказчику другого инструмента не дано.
Поэтому на сайтах работ примеры резюме, приведенные в статье вполне объяснимы.
Как итог: На поддержку и на проекты нужны реально разные специалисты и в вакансиях как правило нужны те кто будет поддерживать и развивать, а не с нуля ставить на рельсы.

(30)

Цитата
Делая АРМ - имхо - сразу надо закладываться что на одном и том же "участке" может работать несколько АРМов-операторов. как-то так.

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

(28)

Цитата
то есть здесь отступили от принципа "один" как частный случай "много"

Не понял то что вы написали, от чего отступили?

(26)

Цитата
Вот получили заказ, проверили обеспеченность - всё обеспечено. Заказ ещё не отправлен. Через три дня часть партий по сроку годности - перешла границу - кто и как и когда должен проверять это?

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

(23)

Цитата

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

Тут по каждому пункту важно кто и в какой момент будет это делать?
Суть системы же не в том чтобы все уработались используя типовой функционал.
С доработкой пользователь оформляет Заказ на обеспечение и смотрит как он обеспечился, а если не обеспечился, тогда уже логистика принимает необходимые действия. В предложенном вами варианте очень уж много ручного труда и не понятно на кого будут возложены эти обязанности.
Основное это разделение ответственности. Продавец отвечает за потребность и не должен делать работу логистики. Логистика отвечает за обеспечение и не должна делать работу продавца. Система на то и нужна, чтобы помогать одним и другим достигать минимальными усилиями необходимый результат.

(18) Вы пишите п.3 об исключении серий с просрочкой из оборота, но в общем случае речь не идет о просроченных сериях.
К примеру, есть два заказа клиента, первый предъявил требования к сроку годности, а второй нет. На складе есть остатки, исходя из требований первого заказа ему серии не подходят, а второму подходят. Через пару минут после размещения первого заказа, менеджер понял, что ошибся и для позиции указал не те требования к сроку годности. Внес корректировки и с учетом новых требований, серии на остатках уже подходят и первому заказу.
Это упрощенный пример, в реальности активных заказов несколько тысяч и вариантов приводящих к изменению тоже много.
Поэтому пока не понятно:
1. Какие серии и по какому критерию исключать из оборота?
2. Кто будет и в какой момент принимать решения об исключении серий?
И самое главное пользователь после оформления заказа хочет практически сразу понимать как обеспечен его заказ.