А вообще в SAP много таких вещей, про которые AX пока только мечтать может

[Aleck]

Цитата:

Сообщение от В гостях:))

Есть ответ из сап-тусовки!!) Я на протяжении двух-трех лет вел и поддерживал этот проект.
Ответ на вопрос "почему не удалось использовать стандартное саповское бюджетирование" - потому, что ничего общего с бюджетированием проект не имел)

Кто только через этот проект не прошел

Цитата:

Сообщение от В гостях:))

Проект включал в себя реализацию трех задач:
1. Сбор потребностей в материалах от структурных подразделений
2. Некий "MRP-расчет" на центральном складском хозяйстве
3. Формирование плана закупок и северного завоза

Сложность реализации в саповском стандарте была серьезной - надо понимать, что никакой функциональности SAP ERP клиент на тот момент не использовал (ни учета запасов, ни плана производства из которого бы рождались потребности в материалах, ни плана строительства и т.д. - вообще ничего). И при этом хотел решить (и решил) узкую задачу в короткий срок.

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

Решил в САПе или в связке САП с самописным приложением сбоку?
Только ли сжатые сроки препятствовали?)
Почему ничего нет? есть нулевые запасы и потребность в материалах, указанная в заявках подразделений. В чем проблема посчитать по этим заявкам план закупок, расценить его, утвердить, выполнить и проконтролировать соблюдение лимитов?
Не укладывается в некий "стандарт"?

[В гостях:))]

Alex, Вы - тролль) Это мой последний ответ по этому поводу, который не имеет ничего общего к теме ветки - заранее предупреждаю..

1. Еще раз - никакого бюджетирования там не было. Это к Вашему предыдущему сообщению

2. Ответ на вопрос - "Решил в САПе или в связке САП с самописным приложением сбоку?": решил в САПе. Через год посчитал, что дороговато держать пользовательские лицензии САП для пользователей-заявителей. И вынес ввод потребностей на отдельное приложение.

3. Ответ на вопрос "Почему ничего нет?" - есть данные о НЕНУЛЕВЫХ запасах, которые в изначальном варианте ЗАГРУЖАЛИСЬ в систему. Есть данные о сроках поставок, особенностях навигации и северного завоза, особенностях планирования MRP для разных групп материалов и разных подразделений. Есть данные о потребностях.
4. Ответ на вопрос "В чем проблема..?":
Проблемы в том, что очень много данных нужно "загружать-перегружать" (из разных источников, некоторым из которых нельзя верить). В том, что "расценить" потребность нужно ручками по примерно 50 тыс позиций в течение максимум двух недель. Проблема в том, что при большом объеме неликвидных запасов подразделения склонны заказывать новые закупки, а снабжение - "распихивать" имеющиеся запасы. Проблема в том, что заявителей примерно 1500-2000 тысячи человек, которых нужно быстро обучить. Проблема в том, что безграничные потребности сталкиваются с ограниченными возможностями.
В общем, проблем было много разных - если хотите, могу как-нибудь рассказать за кружкой пива)
5. Ответ на вопрос "Не укладывается в некий стандарт?" - безусловно, задача решалась, мягко говоря, не совсем стандартная для ERP-системы. Обычно для решения этой задачи в ERP нужно внедрить практически все логистические модули, одни из которых являются источниками потребностей в материалах, а другие - источником данных о запасах. Мы вместо это сделали "MRP-калькулятор" на стандартных объектах ERP.

Кстати, раз уж мы об этом заговорили - в соседней ветке Вами был поставлен вопрос об использовании Oracle на Юнимилк Так вот именно для аналогичной задачи ("высокоуровневый MRP в рамках всего холдинга") Oracle Process Management и используется на данный момент, насколько я знаю.

PS сорри, но тему для себя закрыл - мы просто мешаем коллегам обсуждать функциональность ERP-решений. Дальше только за кружкой пива)

[Aleck]

Цитата:

Сообщение от В гостях:))

Alex, Вы - тролль) Это мой последний ответ по этому поводу, который не имеет ничего общего к теме ветки - заранее предупреждаю..

PS сорри, но тему для себя закрыл - мы просто мешаем коллегам обсуждать функциональность ERP-решений. Дальше только за кружкой пива)

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

[Vals]

Цитата:

В Джиди планирование ведется между складами/цехами и от компаний не зависит. Есть проблема в том что планирование DRP/MRP при одном прогоне планирования создает документы перемещения между складами (двухточечные - отгрузка/приемка) только одного типа.

Спасибо за развёрнутые ответы.


О Microsoft Dynamics AX

Цитата:

1. Работа нескольких компаний

Можем вести все компании (Юр лица холдинга) в одной базе. Разделять можем по юр лицам. Иногда филиалы реализуют как склады, в случае, когда филиалы не ведут собственного баланса или сложной отчётности.

Одна компания выделяется для консолидации.

Цитата:

2. Работа распределительных складов и пополнение складов, особенно, с двух складов
одновременно.

С двух складов одновременно система не пополяет (В версии AX 2009 эту функцию ещё не смотрел), но организует цепочку складов по которым формирует перемещения.
С другой стороны, доли пополнения в % со складов, тоже решение не самое лучшее - слишком условное.

Цитата:

3. Общие справочники для нескольких компаний.

Изначально справочники действуют для одной компании. Если необходимо объединить справочники, то создаются группы таблиц (коллекции таблиц) которые будут работать как общие для выбранных компаний.
Итого:
1. Можно выбрать Таблицы (Справочники, транзакционные, настроечные и т.д.) для использования в нескольких компаниях.
2. Можно выбрать, в каких компаниях, какие таблицы будт общими: Компания А и Б - общий План счетов. А Компания А и С - общие Поставщики и т.д. Объективно, некоторые взаимоисключающие комбинации невозможны.
3. Если таблица общая для всех компаний, то можно настроить права доступа пользователей к различным частям в различных компаниях.

Цитата:

4. Общие справочники для двух компаний из трёх и т.д.

Выше описал - есть.

Цитата:

5. Взаимодействие, продажи-закупки-производство между компаниями.

Механизм, который По заказу в компании А, формирует Закупку (или производство) в компании Б, С, и т.д. Организован механизм сопоставления идентификаторов в справочниках разных компаний.
Таким образом можно реализовать цепочку компаний Продажа - Закупка - Производство - Субподряд и т.д. Система автоматически планирует и рассчитывает цепочку и создаёт необходимые записи в таблицах (закупки, производства)

Цитата:

6. Как увидеть общий склад по всем компаниям и как каждой конторе видеть свой.

Делается штатно в функциональности Intercompany - работа с несколькими компаниями.

Цитата:

7. Планирование по нескольким компаниям

Здесь механизмы примерно совпадают: делается также итерационно. Система делает проход по одной компании, формирует потребности, затем идёт ко второй и т.д. Настраивается Порядок проходов. Таким образом, можно оптимизирвоать цепочку, если есть отношения между компаниями: Продавец-закупщик- Производитель - субподрядчик и т.д.
Здесь я дал краткое описание механизма:
http://www.amand.ru/modules/wordpress/archives/74

[Vals]

Цитата:

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

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

Мы задались таким вопросом, так как очень часто приходится контролировать работу нескольких партнёров. Вот что написалось на эту тему:http://www.amand.ru/modules/wordpress/archives/109

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

[Vals]

Цитата:

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

А еще я тут вчера слышал стоны недовольного клиента, который узнал что в Аксапте отрицательный склад контролируется на текущую дату. И если ты вчерашним числом оприходовал 1000 изделий, то никто не помешает тебе списать прошлым годом штучек 20-30 (хотя год назад у нас и изделия-то такого на складе не было).
Позволю себе поинтересоваться как данная проблема решена в других системах. Вопрос частный - но для меня очень любопытный.

То есть в этом случае склады не закрываются, финансовые периоды не закрываются?

[fed]

Цитата:

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

То есть в этом случае склады не закрываются, финансовые периоды не закрываются?

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

[ImpCons]

Цитата:

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

2. Работа распределительных складов и пополнение складов, особенно, с двух складов
одновременно.
С двух складов одновременно система не пополяет (В версии AX 2009 эту функцию ещё не смотрел), но организует цепочку складов по которым формирует перемещения.
С другой стороны, доли пополнения в % со складов, тоже решение не самое лучшее - слишком условное.

Согласен условие не очень четкое, но можно его использовать для реализации концепции Договорных отношений с поставщиками на основании долгосрочной и оперативной закупочной компании.

Поясню на примере, как:

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

Скажем по условиям проведенного тендера на годовые закупки сырья1 должны поставлять на следующий год: поставщик1 в размере 60% и поставщик2 в размере 40% от всех закупок сырья1. Если эти поставщики являются основными нашими поставщиками (т.е. поставляют основную массу сырья), то поставки от них можно развести через разные склады поставки, например со склада поставки 1 и склада поставки 2.

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

Рассмотрим данные примера на основе плана на январь

Связи:
   сырье    склад поставщик          склад потребитель        % потребления
i.  сырье1 Склад поставки 1   Распределительный склад          60%
ii. сырье1 Склад поставки 2   Распределительный склад          40%

Потребность на распределительном складе в сырье1  на январь 20 000кг. 

При прогоне долгосрочного планирования система создаст сообщения системы планирования:
а) на основании потребности на распрделительном складе:
                                         Отправитель                      Получатель
Передача при долгосрочном планировании 1 Склад поставщика 1 Распределительный склад  20 000кг*60% = 12 000 кг
Передача при долгосрочном планировании 2 Склад поставщика 2 Распределительный склад  20 000кг*40% =  8 000 кг

b) на основании потребности сформированной передачей при долгосрочном планировании
Рамочный заказ закупки 1 на январь Склад поставщика 1   20 000кг*60% = 12 000 кг
Рамочный заказ закупки 2 на январь Склад поставщика 2  20 000кг*40% =   8 000 кг

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

Проводим оперативное планирование - запускаем его раньше даты, на которую хотим получить Заказы на закупку и перемещения, на время закупки + время перемещения + время производства ГП + время доставки до клиента. Например, если это время 2 месяца, то в конце октября запускаем оперативное планирование для создание Заказов на закупку сырья, Заказов перемещения сырья до места производства, Заказов на работу(производства) + Перемещений до места возникновения спроса в ГП.

Горизонт планирования 4 месяца, корзины (периоды) планирования 1 неделя.

Настройки:
Для Рамочных заказов закупки 1 и 2, создаем условия работы поставщика, по конкретной строке рамочного заказа, т.е. в нашем примере для сырья1. Можно ставить следующие условия:
1. Дни недели в которые поставщик может отгрузить данное сырья
2. Кратность партии отгрузки сырья (если сырье может отгружаться только с какой-то кратностью)
И еще несколько параметров, регламентирующих работу поставщика с данным сырьем именно в январе.

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

Рассмотрим дальше наш пример:

Потребность на распределительном складе в сырье1  
на 4 января 5 000кг. 
на 11 января 4 000кг. 
на 18 января 6 000кг.
на 25 января 5 000кг. 

При прогоне долгосрочного планирования система создаст сообщения системы планирования:
а) на основании потребности на распределительном складе:
                                         Отправитель                    Получатель
на 4 января
Передача при оперативном планировании 1 Склад поставщика 1  Распределительный склад  5 000кг*60% = 3 000 кг
Передача при оперативном планировании 2 Склад поставщика 2  Распределительный склад  5 000кг*40% = 2 000 кг
на 11 января
Передача при оперативном планировании 1 Склад поставщика 1  Распределительный склад  4 000кг*60% = 2 400 кг
Передача при оперативном планировании 2 Склад поставщика 2  Распределительный склад  4 000кг*40% = 1 600 кг
и т.п.  ...

b) на основании потребности сформированной передачей при долгосрочном планировании
на 4 января
Заказ закупки 1   Склад поставщика 1     5 000кг*60% = 3 000 кг
Заказ закупки 2   Склад поставщика 2     5 000кг*40% = 4 000 кг
на 11 января
Заказ закупки 1   Склад поставщика 1     4 000кг*60% = 2 400 кг
Заказ закупки 2   Склад поставщика 2     4 000кг*40% = 1 600 кг
и т.п.  ... 

Генерим, т.е. создаем в системе, на основе: 
a) сообщений систем планирования для оперативной потребности, 
b) условий работы с поставщиками на рамочных заказах, 
c) на самих рамочных заказов, 
график поставок.

Затем из графика поставок генерятся уже заказы на закупку, которые будут учитывать не только текущие уточненные потребности, но и условия долгосрочного планирования и условия работы поставщика.

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

Интересно, существует ли в Аксапте или партнерском решении аналог, расписанного Графика поставок, работающего с данными, создаваемыми при проведении долгосрочного и с оперативного планирования?

[coolibin]

Цитата:

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

Я, в целом, понимаю почему так в Аксапте было сделано, но мне интересно как эту проблему в других системах обходят (и обходят ли)...

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

[Vals]

Цитата:

Интересно, существует ли в Аксапте или партнерском решении аналог, расписанного Графика поставок, работающего с данными, создаваемыми при проведении долгосрочного и с оперативного планирования?

Да, такой график можно создать. Вечером опишу подробнее.

Цитата:

Для Рамочных заказов закупки 1 и 2, создаем условия работы поставщика, по конкретной строке рамочного заказа, т.е. в нашем примере для сырья1. Можно ставить следующие условия:
1. Дни недели в которые поставщик может отгрузить данное сырья
2. Кратность партии отгрузки сырья (если сырье может отгружаться только с какой-то кратностью)

1 - В Axapta - Да, есть
2. - Да есть. Плюс - мин. партия, макс партия.
Подробнее вечером.

Ещё относительно работы с поставщиками, клиентами и складом в MS DAX есть так называемые фьючерсы и действия. Кратко - генерация сообщений (предложений) об отклонении от графика или от покрытия потребностей. Позже расскажу.

[Aleck]

Вопрос к коллегам, занимающимися SAP/Oracle/другими системами из параллельной ветки:
Какая в этих системах процедура исправления ошибок пользователей при вводе операций. Пример - при отгрузке ошиблись и указали неверное количество, ошибку обнаружили после разнесения/постинга операции. В Аксапте для исправления надо провести сторнирующую операцию и затем провести правильную.
Как такие сутуацию решаются у Вас?

[ImpCons]

Цитата:

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

Вопрос к коллегам, занимающимися SAP/Oracle/другими системами из параллельной ветки:
Какая в этих системах процедура исправления ошибок пользователей при вводе операций. Пример - при отгрузке ошиблись и указали неверное количество, ошибку обнаружили после разнесения/постинга операции. В Аксапте для исправления надо провести сторнирующую операцию и затем провести правильную.
Как такие сутуацию решаются у Вас?

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

[glibs]

Цитата:

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

...
в корректировочном документе можно указать номер документа который он корректирует. И при указании документа в корректирующем система контролирует чтобы корректирующий документ создавался на того же кредитора, что и в исходном документе.
...

Ну вот хотя бы один из вариантов (а ведь может быть и удобнее).

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

Мне лично и первое и второе приходилось делать на проектах.

Дальше представьте себе, что случится чудо, и эта функциональность появится в буржуйской версии. Что после этого случится с восточноевропейским слоем. В общем то что с ним случится и так известно по тому, сколько мы уже ждем локализацию 5.0. И это Микрософт с его, казалось бы, возможностями согласовывать действия внутри компании и его ресурсами. Это к вопросу об отраслевых решениях, чего от них ожидать в плане качества и универсальности, а также стоимости владения.

[ImpCons]

Цитата:

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

Да, такой график можно создать. Вечером опишу подробнее.
1 - В Axapta - Да, есть
2. - Да есть. Плюс - мин. партия, макс партия.

Да само собой min, max партия в настройках условий работы с поставщиком по рамочному контракту в Джиди тоже есть и еще некоторое количество настроек, - все просто не стал перечислять.

[konopello]

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

Что данный функционал из себя представляет, по виду и дизайну это похоже на ARIS EPC диаграмму, но только в SAP (смотрите вложение).

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

Таким образом дастигаеться связывание отдельных операций в системе в единый бизнес-процесс.

Ну и еще один не большой пример, поток операций запускаеться как только ответственный сотрудник создал материал, уведомление приходит в бухгалтерию которая заполняет не дастающие данные, после того как все данные о материале заполнены ответственный сотрудник проверяет данные и разблакирует данный материал для использования.


P.S. Извиняюсь за краткость и не полнату изложения, нет времени....

[belugin]

Цитата:

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

Есть в SAP еще одна замечательная вещь, так называемый Поток операций

Workflow в Ax 2009. Правда, редактор табличный, но обещают обещают в 6 приделать визуальный из WF

[_scorp_]

Цитата:

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

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

Уведомления появились еще в аксапте в 4.0. А с появлением ролевых центров в Ax2009 для каждого пользователя появилась домашняя страничка. Эту страничку можно настроить таким образом, чтобы зайдя на неё пользователь сразу мог увидеть то, что ему нужно утвердить 10 закупок, разнести 5 накладных и список клиентов, задолженность которых превышает какой-то уровень (это например, возможностей там море). И как Вы говорите, тоже с помощью одного щелчка можно перейти непосредственно к операции и выполнить ее.

[Aleck]

Цитата:

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

Уведомления появились еще в аксапте в 4.0. А с появлением ролевых центров в Ax2009 для каждого пользователя появилась домашняя страничка. Эту страничку можно настроить таким образом, чтобы зайдя на неё пользователь сразу мог увидеть то, что ему нужно утвердить 10 закупок, разнести 5 накладных и список клиентов, задолженность которых превышает какой-то уровень (это например, возможностей там море). И как Вы говорите, тоже с помощью одного щелчка можно перейти непосредственно к операции и выполнить ее.

Вообще еще в OP для 3.0 были "мероприятия", из которых можно было выстраивать цепочки, показывать пользователю список необходимых действий и из них переходить к нужным формам...

[konopello]

Цитата:

А с появлением ролевых центров в Ax2009

к сожалению я с возможностями 2009 знаком слабо... просто в SAP меня впечатлило то что данные цепочки строяться на ARIS схемах, данные можно импортить из ARIS, к сожалению я пишу из собственного опыта, того чего я сам не видел в AX но видел в SAP, это чисто для ознакомления : )

[konopello]

Цитата:

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

Workflow в Ax 2009. Правда, редактор табличный, но обещают обещают в 6 приделать визуальный из WF

ну это не может не радовать, не знал не знал : )