Sapforum.Biz
Логистика => Управление материальными потоками (MM) => Тема начата: Lubjen от Июль 14, 2010, 01:36:13 pm
-
Было в старой ИСУ возможность ведения нескольких карточек ОЗМ с одним и тем же наименование но сразными характеристиками (например разные поставщики товаров). Теперь руководство решило что необходимо что была только одна карточка ОЗМ. Партионый учет.
Вопрос.
Как вести учет остаков по поставщикам товаров по одному и тому же товару (Одно наименование товара)?
Заводить несколько карточек с одним и тем же наименованием для разных поставщиков нельзя. А учет остатков вести как то надо. Может как то через признаки. Но нужно учитовать что отпостащика по одному и тому же товару в месяц может быть несколько поставок как следствие несколько партий который в ОЗМ не ведутся.
Нужен совет, помощь в решении данной проблемы.
-
Было в старой ИСУ возможность ведения нескольких карточек ОЗМ с одним и тем же наименование но сразными характеристиками (например разные поставщики товаров). Теперь руководство решило что необходимо что была только одна карточка ОЗМ. Партионый учет.
Вопрос.
Как вести учет остаков по поставщикам товаров по одному и тому же товару (Одно наименование товара)?
Заводить несколько карточек с одним и тем же наименованием для разных поставщиков нельзя. А учет остатков вести как то надо. Может как то через признаки. Но нужно учитовать что отпостащика по одному и тому же товару в месяц может быть несколько поставок как следствие несколько партий который в ОЗМ не ведутся.
Нужен совет, помощь в решении данной проблемы.
Стандартом - никак, признаки тоже не помогут, к чему Вы их будете прикручивать? К документам материала?
Но у вас партии, а с их помощью, можно отследить любые движения товара, в том числе от какого поставщика пришла та или иная партия.
Дополнительно можно вести признак в партии, типа "Поставщик", но в любом случае отчёты по остаткам надо будет писать самому.
-
Дополнительно можно вести признак в партии, типа "Поставщик", но в любом случае отчёты по остаткам надо будет писать самому.
+ быстродействие отчетов в ряде случаев может быть не на том уровне, которого бы хотелось
-
+ быстродействие отчетов в ряде случаев может быть не на том уровне, которого бы хотелось
И что ты предлагаешь?
-
И что ты предлагаешь?
Я не консультант ММ, лишь констатирую "ABAP-факты", полезно знать.
-
Ну раз не хотите заводить под каждого поставщика отдельный ОЗМ, ну остается тогда например код поставщика 4-5 первых символов партии, а остальные тогда 6-5 символов партии будет порядковый номер партии поставки в рамках одного поставщика... Опять же вы наверное захотите потом еще и стоимости вести, так что партия + вид оценки.
-
Ну раз не хотите заводить под каждого поставщика отдельный ОЗМ, ну остается тогда например код поставщика 4-5 первых символов партии, а остальные тогда 6-5 символов партии будет порядковый номер партии поставки в рамках одного поставщика... Опять же вы наверное захотите потом еще и стоимости вести, так что партия + вид оценки.
Т.е. не используя признак, а используя кодировку номера партии, можно существенно увеличить скорость выборок по партиям? :)
Думаю им это не подойдет, длина поля CHARG = 10 символов, в 5 символов не получится заложить код поставщика.
2Dmitriy - пример кода не набросаешь, как выбрать по признаку "Поставщик" все партии?
-
Т.е. не используя признак, а используя кодировку номера партии, можно существенно увеличить скорость выборок по партиям? :)
Думаю им это не подойдет, длина поля CHARG = 10 символов, в 5 символов не получится заложить код поставщика.
2Dmitriy - пример кода не набросаешь, как выбрать по признаку "Поставщик" все партии?
Ты все верно пишешь про скорость. Если включать в CHARG, то для ограничения по поставщику придется использовать LIKE 'xxxxx%', что, естественно, замедлит работу оператора SELECT. В случае с признаком будет JOIN с еще 2-я таблицами (AUSP & CABN). Понятно, что лучше, когда поставщик "напрямую" в таблице, как и для любой другой ключевой аналитики.
Код пока не набросаю, если поискать про признаки, то можно найти. Вопрос получения значений и прочее неоднократно обсуждался.
P.S. Система пока не доступна...
-
Тема "Работа с классификацией в системе" (http://sapforum.biz/index.php/topic,170.msg708.html#msg708), если что. ;)
-
Т.е. не используя признак, а используя кодировку номера партии, можно существенно увеличить скорость выборок по партиям? :)
Да нет просто будет работать стандарт без всяких заморочек...
Думаю им это не подойдет, длина поля CHARG = 10 символов, в 5 символов не получится заложить код поставщика.
Паганель, прежде чем говорить, особенно о цифрах, давай будем считать. Итак я не знаю сколько поставщиков и сколько там поставок от одного поставщика, поэтому делим партию по пополам, на 5+5 и так ПЯТЬ цифр в десятичной системе это 100 000 записей поставщиков и столько же поставок от каждого поставщика, но если перейти уже к шестнадцатеричной системе, то число FFFFF это 1 048 575 записей поставщиков и это только первые 6 букв английского алфавита, а их там еще в запасе 20, короче думаю хватит на всех. Так что добавляете к поставщику поле типа внутренний код ММ и дальше кодируете их в партиях ну если поставщики уже есть и не хочется терять их визуальное определение по кодам.
-
В случае с признаком будет JOIN с еще 2-я таблицами (AUSP & CABN).
Вот откопал свой древний код, ещё бы столько же эти признаки не видеть.
SELECT SINGLE ausp~atwrt INTO lv_atwrt FROM ausp
JOIN cabn ON cabn~atinn = ausp~atinn " Внутренний признак
WHERE ausp~objek = lv_objek " Ключ объекта
AND ausp~mafid = 'O' " Хардкод
AND ausp~klart = '041' " Хардкод
AND cabn~atnam = 'ABAP_RULIT'. " Хардкод, имя признака
Можно обойтись одной AUSP, если известен ATINN (банально посмотреть в БД), только если хардкодить, то нужно учесть, что для одного и того же признака поле может принимать различные значения в мандантах разработки, теста и продуктива.
P.S. А по приведенной выше ссылке (http://sapforum.biz/index.php/topic,170.msg2761.html#msg2761) Удав всё популярно разъяснил насчет скоростей, с доказательствами. ;)
-
Да нет просто будет работать стандарт без всяких заморочек...
Паганель, прежде чем говорить, особенно о цифрах, давай будем считать. Итак я не знаю сколько поставщиков и сколько там поставок от одного поставщика, поэтому делим партию по пополам, на 5+5 и так ПЯТЬ цифр в десятичной системе это 100 000 записей поставщиков и столько же поставок от каждого поставщика, но если перейти уже к шестнадцатеричной системе, то число FFFFF это 1 048 575 записей поставщиков и это только первые 6 букв английского алфавита, а их там еще в запасе 20, короче думаю хватит на всех. Так что добавляете к поставщику поле типа внутренний код ММ и дальше кодируете их в партиях ну если поставщики уже есть и не хочется терять их визуальное определение по кодам.
Причем тут к-во? Я про длину кода поставщика.... часто для кодирования дебиторов/кредиторов используют ЕДРПОУ, длина которого- 10 символов.
А вот про внутренний код поставщика, это идея хорошая, правда как я понимаю, это поле в карточке кредитора тоже придется делать через ту же классификацию.
За ссылку спасибо, забыл что была такая тема .....
Ну вот и результаты:
Чтение 1500 классификаций:
1. через BAPI ~ 20 с.
2. через SELECT из INOB + AUSP + CAWN + CAWNT ~6 c.
Всем спасибо, думаю дальше додумаются сами.
-
Причем тут к-во? Я про длину кода поставщика.... часто для кодирования дебиторов/кредиторов используют ЕДРПОУ, длина которого- 10 символов.
А вот про внутренний код поставщика, это идея хорошая, правда как я понимаю, это поле в карточке кредитора тоже придется делать через ту же классифика
Ладно раз не понял, причем тут длинна, тогда проехали... ;D
-
Причем тут к-во? Я про длину кода поставщика.... часто для кодирования дебиторов/кредиторов используют ЕДРПОУ, длина которого- 10 символов.
Длина кода поставщика...ну если в Украине то вроде как восемь....
-
Ладно раз не понял, причем тут длинна, тогда проехали... ;D
Проехали так проехали, что я не понял, тут я вот точно уже не понимаю, идея хорошая, есть несколько недостатков (имхо), но как вариант, если не будет другого выхода, думаю можно ее использовать.
Длина кода поставщика...ну если в Украине то вроде как восемь....
Ошибся, приму во внимание
-
Проехали так проехали, что я не понял, тут я вот точно уже не понимаю, идея хорошая, есть несколько недостатков (имхо), но как вариант, если не будет другого выхода, думаю можно ее использовать.
В самой парии так же есть куча полей, например вот партия поставщика... кстати а какие там недостатки?