Резервирование внутри сайта

[Andrux]

Добрый день! Можно ли сделать так, что AX2009 при резервировании товара на складах определенного сайта, с определенных складов не резервировала. Что-то вроде групп резервирования. Это, я так понимаю, только модификация, стандарт так настроить невозможно?
Например, на сайте Сайт1 находятся три склада: склад1, складБрак, складПретензия. При резервировании товара, склад1 и складБрак не должны резервироваться вместе.
Ясно, что это можно решить, если менеджеры буду конкретно задавать склад в строках заказа. Но это не подходит, т.к. к основной группе относится более, чем 1 склад, и логически, в системе, товар может лежать на разных складах в пределах одного сайта.

[Bega]

Цитата:

Сообщение от Andrux

Добрый день! Можно ли сделать так, что AX2009 при резервировании товара на складах определенного сайта, с определенных складов не резервировала. Что-то вроде групп резервирования. Это, я так понимаю, только модификация, стандарт так настроить невозможно?
Например, на сайте Сайт1 находятся три склада: склад1, складБрак, складПретензия. При резервировании товара, склад1 и складБрак не должны резервироваться вместе.
Ясно, что это можно решить, если менеджеры буду конкретно задавать склад в строках заказа. Но это не подходит, т.к. к основной группе относится более, чем 1 склад, и логически, в системе, товар может лежать на разных складах в пределах одного сайта.

Может как-то задействовать профиль учета - чтобы для склада брака он был другим, завести, например профиль "ОСНОВНОЙ" и установить его для "нормальных" складов и профиль "БРАК" для складов брака. В строках заказа указывать профиль учета "ОСНОВНОЙ".

[Andrux]

Дело в том, что мы не используем профиль учета. Эта складская аналитика отключена. Я нашел в модуле WMS как раз то что нужно: Шаблоны отгрузок, Комбинации резервирования отгрузок, Последовательности заявок на отгрузку. Но получается, что это резервирование ничего не имеет общего с резервированием по заказу и работает только при Консолидированном способе комплектации.

[Ivanhoe]

Идея с Шаблонами отгрузок (они так по русски называются?) неплохая, но, imho, не доведена до конца. Было бы не плохо иметь больше вариативности в их настройке, и чтобы они применялись при любом автоматическом резервировании, а не только по использовании Shipment.

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

[sukhanchik]

Цитата:

Сообщение от Andrux

Например, на сайте Сайт1 находятся три склада: склад1, складБрак, складПретензия. При резервировании товара, склад1 и складБрак не должны резервироваться вместе.

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

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

[Ivanhoe]

Я бы так категорично не стал "ругать" склады для брака. Есть компании, в которых склад брака, возврата и т.п. - реально отдельный склад

[sukhanchik]

Цитата:

Сообщение от Ivanhoe

Я бы так категорично не стал "ругать" склады для брака. Есть компании, в которых склад брака, возврата и т.п. - реально отдельный склад

Ну... я ж не ругал. Просто посмотрел на них с другой стороны и высказал идею. А там уж "на местах" виднее - насколько моя идея подходит для бизнеса.
Опять-таки, всегда надо смотреть причину. Возможно - что выделение отдельного склада для брака - это подстройка под систему (если есть возможность выделения - то почему бы так не сделать). Возможно - иные причины.

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

[gene]

Цитата:

Сообщение от sukhanchik

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

А чем этот способ принципиально отличается от использования существующей аналитики Профиль учета? Она позволит все это делать, причем, без программирования. Единственное ограничение, которое я вижу - это то, что аналитика Профиль учета имеет свойство Соответствующая, а значит, к одной строке заказа/журнала не могут быть привязаны складские проводки с разными профилями учета. Поэтому, например, нельзя в рамках приемки по заказу на покупку сразу отделить профилями учета брак от "нормальной" номенклатуры.

[Andrux]

Идея с профилем учета действительно жизнеспособная. Однако. насколько я помню, невозможно в складском журнале с типом Перенос изменить складскую аналитику Профиль учета (в аналитику), т.е. перевести товар из "хорошего" в "брак" простым переносом не получится.

[sukhanchik]

Цитата:

Сообщение от gene

А чем этот способ принципиально отличается от использования существующей аналитики Профиль учета? Она позволит все это делать, причем, без программирования. Единственное ограничение, которое я вижу - это то, что аналитика Профиль учета имеет свойство Соответствующая, а значит, к одной строке заказа/журнала не могут быть привязаны складские проводки с разными профилями учета. Поэтому, например, нельзя в рамках приемки по заказу на покупку сразу отделить профилями учета брак от "нормальной" номенклатуры.

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

[gene]

Цитата:

Сообщение от Andrux

Идея с профилем учета действительно жизнеспособная. Однако. насколько я помню, невозможно в складском журнале с типом Перенос изменить складскую аналитику Профиль учета (в аналитику), т.е. перевести товар из "хорошего" в "брак" простым переносом не получится.

Неверно. Возможность изменения профиля учета в журналах переноса и заказа на перемещение регулируется параметром "Наследование\ Перенос" аналитики Профиль учета в группе складских аналитик. Есть одно ограничение - в любом случае нельзя переносить между профилями учета, относящимися к разным видам деятельности. Но, думаю, для учета брака и т.п. это и неактуально.

Цитата:

Сообщение от sukhanchik

Грубо говоря фразы "Профиль учета" и "Состояние" - имеют совершенно разный смысл.
Кроме того, аналитика Профиль учета - все же разрабатывалась не для целей учета состояния товара

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

[Andrux]

В общем да, профиль учета - просто находка, ну блин не включили) решили, что т.к. ответ хранения нет - то и не понадобится. А включать доп. складскую аналитику с уже существующими складскими операциями - это самоубийство

[Индра]

Цитата:

Сообщение от Andrux

А включать доп. складскую аналитику с уже существующими складскими операциями - это самоубийство

Почему бы нет. Полный перенос остатков. Заодно и порядок в данных наведете

[Vals]

А склад брака - карантин?

[dn]

Цитата:

Сообщение от gene

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

Возможно не всё так просто. Брак может быть выявлен среди товаров для продажи и среди товаров на ответственном хранении. И хорошо бы разделять свой и чужой брак.
На мой взгляд для учета брака было бы неплохо использовать отдельную складскую аналитику "качество". Но если профиль учета не используется по прямому назначению, то вполне логично его задействовать под брак...

[Bega]

Цитата:

Сообщение от Andrux

В общем да, профиль учета - просто находка, ну блин не включили) решили, что т.к. ответ хранения нет - то и не понадобится. А включать доп. складскую аналитику с уже существующими складскими операциями - это самоубийство

Все-таки можно попробовать без суицида. Написать джоб (или скрипт SQL), который включает профиль, далее бежит по все InventDim и для записей, где есть склад проставляет соответствующий профиль учета (в складах нужно заполнить). Дальше проверить основные операции. Возможно потребуется очистить профиль для настроек местоположения InventItemLocation, настроек InventItemInventSetup (Purch, Sales). Не знаю, как будет работать корусовский ритейл (вы на нем?), но в стандартном не должно быть много сюрпризов.

[Ivanhoe]

Согласен, что разово включить одну аналитику и заполнить ее однозначным значением, например, с привязкой к складу, не должно быть большой проблемой. Проводки, остатки, документы - главное не пропустить ничего.

[Andrux]

Буду работать с профилем учета. Это наиболее приемлемый выход. Кроме всего, профиль учета позволяет настроить приоритет подбора профилей учета при резервировании (вот и шаблон резервирования как в модуле WMS).
По идее, чтобы включить профиль учета, нужно выполнить настройки профилей, привязать профиль к сладу, и обновить InventDim со значением склад. При этом не изменять аналитики, проставленные в InventItemPurch(Sales, Invent)Setup.Я рано начал паниковать . Единственное, активация профиля доставит неудобство пользователям, т.к. эта аналитика является первичной, и всегда должна быть заполнена в строках заказов, журналов и пр., по аналогии с аналитикой Сайт.

[gene]

Цитата:

Сообщение от Andrux

Кроме всего, профиль учета позволяет настроить приоритет подбора профилей учета при резервировании (вот и шаблон резервирования как в модуле WMS)

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