Немного комментариев от меня:
- Комментарии общего характера:
1) Мешать в одном тексте русскую и английскую терминологию теоретически можно, а практически - это моветон. Сейчас я исправил, просьба более так не поступать. 2) "Статус VB, ND" - это незнание матчасти, это не статус, а тип ППМ в основной записи материала. Сейчас я исправил, на будущее совет перепроверять в системе, прежде чем писать на форум что-либо. Иначе в лучшем случае поднимут на смех, а в худшем просто не будут отвечать. 3) Знаки препинания придумали не просто так, они в разы облегчают восприятие текста. Многократно уже советовал, повторюсь еще раз: прогоняй перед публикацией текст через спелл-чекер Ворда, это поможет устранить 90% ошибок. 4) Ссылаться в тексте поста на собственные Z-разработки (в данном случае - Store Keeper Material Report, Stock Keeper Morning Report) бессмысленно и глупо, об этом даже написано в правилах. Их никто не видел, кроме консультантов, которые писали под них ТЗ, и абаперов, которые их программировали. Прочим консультантам и пользователям SAP они неизвестны по умолчанию. Либо (другой вариант) - опять-таки незнание матчасти (я уже сильно подозреваю, что так оно и есть).
- Комментарии по существу:
1) Неужели (если требуется отдельная аналитика затрат в контроллинге по 60 ремонтным участкам) не судьба размножить МВЗ (кост-центры)? Или просто никто не решился пока представить начальству объем работы по размножению МВЗ в контроллинге vs. объем работ по установке логистики раком, чтобы сделать это средствами логистики? Думаю, уже пора.
2) Обе модели снабжения ремонтной службы имеют право на существование (при этом модель To-Be даже менее приоритетна, на мой взгляд, поскольку сильно зависит от дисциплины поставщиков запчастей в плане исполнения сроков их поставки). Я, безусловно, понимаю, зачем менеджмент хочет сократить объем запасов запчастей на складе (сокращение заморозки оборотного капитала в этих запасах и затрат на содержание самого склада), но я бы подумал еще двадцать раз, прежде чем внедрять такую модель (а конкретно - что будет лучше: слегка избыточный запас на складе под ремонты или остановка оборудования из-за того, что поставщик дядя Вася не соизволил поставить критическую деталь под плановый ремонт вовремя).
3) Отчета, который требуется, в SAP-е в готовом виде нет, и даже написать его на АВАР-е на стандартной системе, скорее всего, не получится. Для этого нужно разделять на уровне видов документов заявки на закупку запчастей под пополнение склада и заявки под плановый ремонт. В настройках ППМ же тип заявки на закупку, который выплевывается из ППМ, определяется однозначно для завода, таким образом, если один и тот же завод и заказывает запчасти для пополнения запаса до точки заказа, и под заказы на плановый ремонт, тип заявки, получаемой из ППМ, будет один и тот же. Теоретически можно написать отчет на АВАР-е, который, анализируя тип ППМ в материале для завода (VB или PD), будет для материалов с определенным типом ППМ создавать какие-то другие заявки на основании полученных из ППМ, при этом закрывая оригинальные (к примеру, из ППМ выходят заявки вида Z1, а затем отчет для всех материалов с типом ППМ VB создает из заявок вида Z1 аналогичные заявки с видом Z2, одновременно закрывая исходные заявки Z1). Далее все несколько проще: из заявок Z1 и Z2 создаются заказы на поставку разных видов, а из них - входящие поставки разных видов (наличие входящей поставки и будет означать, что запас находится в пути от поставщика). Затем на базе всех этих данных пишется требуемый отчет. Варианты с дополнительным заводом даже не рассматриваю, ибо это (на мой взгляд) извращение.
4) Автоматический расчет планового срока доставки по какой-то логике: в стандарте нет, АВАР-ом же можно легко сделать (мне видится какой-то отчет, который по логике просчитывает для каждой ОЗМ плановый срок доставки и показывает на экране, а затем пакетно обновляет ОЗМ, соответствующие выделенным строкам отчета + вариант, где все обновляется автоматически в фоновом режиме). Подобные забавы, работающие в продуктивном режиме, я видел, вполне доступная разработка.
_________________ С уважением, Admin e-mail: admin @ sapforum.ru
|