Планирование закупок - выбор поставщика

[slava09]

Есть два поставщика материала\сырья. Есть договоренность с обоими, что в течении периода выкупим у них какой-то объем товара. Цены и условия доставки у них примерно одинаковые. Надо равномерно (или в каком-то соотношении) нагрузить их планом закупок. Каким образом в Аксе выкрутится?
Ведь при планировании поставщик или выбирается из номенклатуры или расчитывавется по условиям цена\доставка.

[Vals]

Введите прогноз закупок для этих поставщиков.

[slava09]

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

[komar]

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

Или ставится задача на основании плановых продаж распределить во времени жестко заданный объем закупок (так мне видится Ваша потребность)?

[slava09]

Цитата:

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

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

Или ставится задача на основании плановых продаж распределить во времени жестко заданный объем закупок (так мне видится Ваша потребность)?

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

[komar]

Не видел людей, которые задавались бы вопросами использования бюджета ГК. Тех, которые писали свое бюджетирование - видел.

[slava09]

Цитата:

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

Не видел людей, которые задавались бы вопросами использования бюджета ГК. Тех, которые писали свое бюджетирование - видел.

Я скорее задаюсь вопросом: что нужно доделать на основании стандартного механизма, как все связать воедино. Думаю, что стержень системы: "план счетов - бюджет" вполне приемлем в качестве базы для реализации схемы бюджетирования средней сложности.
Ожидал, что меня начнуть "давить" сентенциями в духе: "а как вы думаете реализовать бюджет...?", "а как вы думаете увязать бюджет и ...?", "а вы думали, что реализация бюджета... невозможна?" и т.д.

[glibs]

Цитата:

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

...
Не видел людей, которые задавались бы вопросами использования бюджета ГК.
...

Приходите, на меня посмотрите.

Правда, я не вопросами задаюсь, а просто использую :-)

В корыстных целях :-)

Цитата:

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

...
Есть два поставщика материала\сырья.
...

А вы по четным месяцам закупайте у одних, а по нечетным у других.

Если не устраивает — обоснуйте почему. А то я "харчами перебирать" не хуже вас могу.

Цитата:

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

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

Думаете, вы первый такой?

:-)

Или самый умный?

:-)

Не хотелось бы вас расстраивать... но подкину вам несколько свежих идей.

Насчет прогнозного планирования не поддерживаю. Это брутто-потреность.

Аксапта неплохо считает чистую потребность. Да и для бюджетирования она имеет куда больший прикладной смысл.

Спланированные закупки (вовсе не обязательно их планировать по тому же сводному плану, по которому вы считаете календарный график производства) ReqTrans можно перетащить... в прогноз закупок (в отдельностоЯщую модель). Что дальше с ними сделать можно, догадываетесь?

В прогнозах звакупок не хватает фиксированной даты оплаты, профиля разноски, способа оплаты (а в нем выделенного счета "закрытия" (settle account) или проще говоря счета, на который прогноз ДДС пойдет вместо счета из профиля разноски по поставщику), ну, возможно, договора и графика оплаты (типа "раз мед — так половниками").

Послле этого всего еще немного сноровки и терпения — и будет у вас не только прогноз закупок в лучшем виде, но прогноз ДДС в максимально натуральной (правдоподобной) форме.

Ну и не забывайте про прогнозные проводки по закупкам и заказам.

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

Цитата:

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

...
Думаю, что стержень системы: "план счетов - бюджет" вполне приемлем в качестве базы для реализации схемы бюджетирования средней сложности.
...

Прогрессивно думаете. Приветствую и поддерживаю.

[slava09]

Цитата:

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

Думаете, вы первый такой? :-) Или самый умный? :-) Не хотелось бы вас расстраивать... но подкину вам несколько свежих идей.

ни на первого ни на второго не претендую по этой же причине не расстраиваюсь

Цитата:

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

Насчет прогнозного планирования не поддерживаю. Это брутто-потреность.Аксапта неплохо считает чистую потребность. Да и для бюджетирования она имеет куда больший прикладной смысл.

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

Цитата:

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

Ну и не забывайте про прогнозные проводки по закупкам и заказам.

А вообще, glibs, в очередной раз выражаю благодарность за помощь по существу, ну и еще за понимание.
+5

[glibs]

Цитата:

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

...
попивая после работы водку с пивом
...

Неужто все так плохо?

Цитата:

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

...
Вот это расшифруйте плиз:
...

Речь идет о LedgerCov.

В заказах и закупках Запросы\Прогноз движения средств. Показывает прогнозные проводки по приходу материалов/выручке от реализации и оплате задолженности.

В принципе, данный прогноз краткосрочный, но весьма точный.

Известные баги:
- Некорректно рассчитывается счет прихода в закупках (возможно, такая же беда с заказами).
- Функциональность графиков оплаты содержит серию багов и ведет себя неадекватно.
- По графику оплаты в закупках разбивается приход, а не оплата (в заказах — не помню).

[slava09]

Цитата:

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

Неужто все так плохо?

Не. Все намного хуже

Цитата:

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

Речь идет о LedgerCov.В заказах и закупках Запросы\Прогноз движения средств. Показывает прогнозные проводки по приходу материалов/выручке от реализации и оплате задолженности.В принципе, данный прогноз краткосрочный, но весьма точный.
Известные баги:
- Некорректно рассчитывается счет прихода в закупках (возможно, такая же беда с заказами).
- Функциональность графиков оплаты содержит серию багов и ведет себя неадекватно.
- По графику оплаты в закупках разбивается приход, а не оплата (в заказах — не помню).

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

[Михаил Андреев]

Цитата:

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

Известные баги:
.....
- По графику оплаты в закупках разбивается приход, а не оплата (в заказах — не помню).

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

[glibs]

Скорее второе.

Просто второе является частью системы бюджетирования.

В зависимости от задачи прогнозные проводки можно использовать и как краткосрочный весьма точный план, и как "почти факт" при сравнении с долгосрочным бюджетом. Например, при одобрении закупки (или оплаты — кому что ближе).

[slava09]

Вот теперь уловил достаточно ясно. Спасибо.

[slava09]

Ребята! Сливайте сюда все что знаете - расплачиватся буду по факту - за каждый человекооабзац каньяк в процентном отношении к полезности

[slava09]

Сориентируйте меня по такому вопросу: имея бюджет доходов, статистический график погашения (50% в этом месяце, 30% в след и т.д.), можно строить бюджет ДДС (в части поступлений).
А настроить это можно так:
1. вносим БД в бюджеты ГК;
2. В бюджете ГК делаем настройку "Настройка ппрогноза движ. ден. средств" в которой указываем процент, условия оплаты и счет расчетного счета;
3. Расчитываем ДДС;
Я правильно понимаю схему?
Тоже самое с бюджетом расходов.
Проблемы: графики оплаты (50% в этом месяце, 30% в след и т.д.) которые можно настроить в условиях оплаты не работают.

[glibs]

Цитата:

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

...
Я правильно понимаю схему?
...

Возможно, при таком подходе и условии "без допиливания", бюджет ДДС проще будет построить с помощью бюджетного калькулятора (кнопка Правка в форме бюджетов).

[slava09]

Цитата:

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

Возможно, при таком подходе и условии "без допиливания", бюджет ДДС проще будет построить с помощью бюджетного калькулятора (кнопка Правка в форме бюджетов).

Подход принципиально неправильный? Нужно по другому? Или слишком простой подход?
Калькулятор не справится с графиком оплат... если его конечно допилить.

[glibs]

Цитата:

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

...
Подход принципиально неправильный? Нужно по другому? Или слишком простой подход?
...

Как по мне, так не "неправильный".

Просто я предложил другой. Мне кажется, что он проще.

Цитата:

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

...
Калькулятор не справится с графиком оплат... если его конечно допилить.
...

Почему не справится? Справится. Копируем бюджет реализации в бюджет ДДС. При этом меняем знак, счет ГК с 70-го на 30-й, множим на 50% и без смещения. Потом то же самое, но 30% и смещение на месяц вперед.

[slava09]

Цитата:

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

Как по мне, так не "неправильный".

Просто я предложил другой. Мне кажется, что он проще.

Почему не справится? Справится. Копируем бюджет реализации в бюджет ДДС. При этом меняем знак, счет ГК с 70-го на 30-й, множим на 50% и без смещения. Потом то же самое, но 30% и смещение на месяц вперед.

Да. Только если БД измениться то БДДС не пересчитается...