Ну вот - добрался таки все осмыслить и по случаю Международного дня сня решил забить на работу и все записать.
Кроме того, поскольку проектов у меня было много, я постараюсь некую максимальную выжимку тут запостить.
Также, я постараюсь следовать порядку вопросов в исходном Ванином сообщении:
1. Как тут уже много раз обсуждалось - есть два вида резервирования, сейловое и складское.Сейловое запрещает перемещение товара за пределы организации (то есть - разрешает его переносить, но запрещает его списывать или продавать). Складское - запрещает любые движения товара, но тем не менее, не запрещает его резервировать по сейловому. Замечу также, что меня очень веселят вопросы насчет приоретизации резервирования
Ты там напомни своим коллегам, что резервирование в заказанных и маркировка являются отражением отношения покрытия в сводном плане. Если у тебя вдруг появился более приоритетный заказ, то надо не механизм резервирования править, а механизм сводного планирования. Чтобы это сводное планирование в рамках одной номенклатуры например, порушила бы все связи покрытия, перетасовала бы данные о покрытии, а потом бы обновила маркировки и резервирования в связанных складских проводках. Более того - в системе вообще не хватает механизма, который бы позволял восстановить или создать резервирование на основании данных о покрытии. То есть: В штатной ситуации, когда ты фирмишь плановые заказы, система генерирует маркировки между складскими проводками по покрывающей и покрываемой чистым потребностям. Но вот если ты например из за какой-то внештатной ситуации создал некоторые заказы в ручную (или если у тебя пользователи направили ручками созданные заказы), то сделующее сводное планирование создаст по таким заказам покрытие, но никаких маркировок и резервов уже не будет создано. До какой-то степени, ситуацию лечит развертывание (Explosion), но проблема в том что штатное развертывание создает резервы и маркировки только для данной складской проводки. (А хотелось бы какой-то механизм который бы делал это для космбинации маски номенклатуры и маски складских аналитик). Я подобный инструмент делал, но до ума не доводил (по крайней мере масок и настроек я там не делал).
2. Резервирование в заказанных и резервирование на складе обычно жестко разделяют. Подход стандартной аксапты, при котором можно незаметно для пользователя зарезервировать 10 штук на складе и 5 штук в транзите, почти никого не устраивает. Обычно стандартную форму резервирования используют только для резервирования на складе. (Резервирование в транзите отключают галочкой). Для резервирования в транзите обычно делают свою отдельную форму, в которой выводят приходные складские проводки в статусе "Заказано" и напротив каждой позволяют поставить количество. Дальше все это превращается в маркировки и в статус "Зарезервированно в заказанных". В типичной торговой организации, сейл ДОЛЖЕН уметь четко сказать своему клиенту когда приедет его товар. Для этого надо четко поддерживать "жесткой резервации строк заказа против какого-то конкретного заказа на покупку". Если клиенту сказать что товар зарезервирован в заказанных безотносительно заказа на закупку и когда-то (ну по крайней мере до наступления конца света) приедет, то клиент пойдет к другому поставщику. Кроме того - контроль резервирования в заказаных обычно делают не по дате, а по статусу строки закупки (которого в стандарте нету). То есть - например по каким-то номенклатерам можно резеровать товар в транзите только после того как поставщик подтвердил прием заявки на поставку, по каким-то - только после того как поставщик нам накладную по факсу отправил и тп. Таким образом, возможность резервирования определяется не датой поставки, а ее вероятностью.
3. Была сделана форма переноса резервов с чужих заказов. Ну то есть - можно в своем заказе нажать на пимпочку и вывести вражеские резервы по той же номенклатуре и против каждого поставить количество. Но в каждой складской проводке пишется ответственный продавец из шапки заказа и отдельно настроены жесткие права - кто у кого может тырить резервы. Кроме того - ведется протокол переноса резервов (и вообще всех операций с резервами).
4. Во первых мы разделили понятие сейлового и складского резервирования. Честно говоря, разделили не совсем удачно, поскольку на первых порах не понимали что складское резервирование может случаться вообще без сейлового. В конце концов (уже после того как проект запустился и года два проработал), их окончательно разделили, но реализацию нельзя назвать удачной. Но как-то работает. Во вторых - мы ввели понятие пула резервов. Он начал свою жизнь просто как удобный механизм перекидки резервов. Просто можно в строке заказа кликнуть на кнопочку "Взять резерв из пула" и "Отдать резерв в пул". У пула есть права доступа. Снимать резервы я могу в любой пул, а забирать резервы могу только из пула, к которому у меня есть права доступа. В дальнейшем мы завели иерархию пулов - пул сейла, пул отдела, пул рабочей группы (может состоять из нескольких сейлов). Далее мы сделали автоматическое резервирование в транзите. После того как статус строки закупки достигает некого значения, товар автоматически резервируется в заказанных между пулами резервов в соответствии с некими настраиваемыми таблицами пропорций. После этого сейлы могут товар растащить из своих пулов под свои заказы. Далее мы сделали автоматическое удаление просроченных резервов. То есть - если складская проводка была зарезервирована более чем N дней назад но так и не была отгружена, резерв автоматически переводится в пул более высокого уровня (отдела, рабочей группы или чего-то подобного). Ну а спустя какое-то время неликвиды из пула верхнего уровня просто разрезервируются. Да, еще пожалуй замечу, что резервирование в пулы бывает только сейловое. Складские о нем не знают и они их не касается. Про перекидку резервов между заказами я написал уже. Про протоколирование операций с резервами - тоже упомянул. Думая об интеграции со сводным (которого на этом проекте не было), я бы предложил прописывать ссылку на пул резервов в прогнозах продаж и оттуда копировать в сводный план. Тогда при фирминге планового заказа можно было бы автоматом прописывать резерв в заказанных для данного пула резервов.
Почему мы это все сделали ? Ну про разделение сейлового и складского резервирования уже ivanhoe написал неплохо. А по поводу всего остального: Во многих фирмах, сейлы премируются неким процентом от маржи. В меньшей части - просто некоей долей своей базовой зарплаты помноженной на процент выполнения плана продаж. Соответственно, если я сейл, каждый раз когда я резервирую под свой заказ некоторый ходовой товар (допустим свежий iPhone), я фактически кладу в свой карман конкретные деньги. Зарезервировал 100 айфонов - считал штуку баксов в карман положил. В текущей версии аксапты, какие-либо механизмы разграничения доступа к резервам, управления резервами, протоколирования работы с резервами - отсутствуют. Как ты думаешь, что будет если в небольшую комнату - скажем метров 50 квадратных, засунуть 60 озверевших сейлов и в произвольный момент начать скидывать сверху купюры - разного номинала, разной стоимости и разной степени конвертируемости? Это - очень хорошая иллюстрация того, что случается при попытке внедрить стандартную аксаптовскую систему резервирования в среднестатистической торговой фирме. Я не уверен, что все что я тут написал нужно для всех клиентов, но
- Разделение сейлового и складского резервов - must have
- Протоколирование операций с резервами - must have
- Пулы резервов - nice to have. Вообще механизм любопытный но требуется его додумывание для производственных фирм.
- Автоматическое снятие резервов - тоже пожалуй что nice to have. Его не сложно самостоятельно реализовать если что.
Вообще вопросы в первоначальном Ванином сообщении расстраивают. Похоже у вас там опять каких-то чистых программистов набрали для разработки и каких-то MBAшников для постановки. Все-таки вопросы в стиле "К примеру, если я хочу забрать на свой заказ какие-то товары, которые уже были зарезервированы, смогу ли я это сделать?" вызывают глубокое недоумение...