Вопрос к знатокам Аксапты: Как завести заявку на покупку материалов?

[tav]

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

[Valery]

Сводное планирование генерит заявки на закупки, анализируя заказы, производственные заказы, наличные запасы и т.д. Как все это настроить - в руководстве пользователя. Коротко не ответишь. Точнее задайте вопрос.

Например, роль заявок на закупку (а, точнее, на пополнение запасов) могут играть неразнесенные строки складских журналов. Если в карточках номенклатур настроены параметры покрытия, то сводное планирование запланирует закупки

[tav]

В данном случае речь идет о разовых заявках сформированных вручную.
Например у подразделения предприятия существует
бюджетная статья расхода, скажем, на канцелярию. Что
они будут закупать никому пока неизвестно до тех пор, пока
не возникнет потребность в том или ином товаре.
Фактически механизм выглядит следующим образом: все подразделения
сбрасывают заявки в отдел снабжения в соответствии с
их потребностями и бюджетами. Снабжение рассматривает
заявки на предмет их удовлетворения. Если заявка принимается
должен быть сформирован заказ на закупку.
Я рассматривал здесь 2 варианта:
1. Регистрация заявок в прогнозном плане с тем чтобы их можно было перенести в сводный план. В этом режиме пока неясно как разделить заявки от разных подразделении.
2.Формирование заказов (скажем с типом "журнал") с последующей схемой утверждения и переводом в заказ. Недостаток у этого метода - подразделение заказчик не всегда знает поставщика, а в заказе это обязательный атрибут.

[Valery]

Думаю для этих целей, может подойти тот вариант, о котором я говорил.

Заводится виртуальный (или реальный) склад снабжения. Все отделы регистрируют свои заявки в складских журналах. Можно сделать название журнала "Заявки в снабжение". Если все подразделения заданы как склады, то используется журнал переноса, если как коды аналитики, то прибыль\убыток.
Сводное планирование, в случае нехватки запасов по данным позициям создаст заявки на закупки, которые должны пройти утверждение.

[mazzy]

Есть по крайней мере два варианта:
= Завяка это то, что в Аксапте называется "прогноз закупок"
= Заявка это то, что в Аксапте является строкой в сводном планировании

Есть еще один интересный вариант
= Заявка - это то, что в Аксапте называется "Закупка"

Мне больше нравится последний вариант.
Но не всем он подходит.

[ldv]

Я бы обратил внимание еще на функциональность Журнала регистрации накладных. Заявка в момент когда еще не известно что будет покупаться вносится в журнал регистрации накладных. Далее она одобряется/ не одобряется и т.п. В момент же, когда становится известно, что мы будем покупать создается Закупка и запись журнала регистрации накладных связывается с закупкой.

[mazzy]

Не знаю.
А разве накладные из журнала регистраци накладных хоть где нибудь учитываются?

Их же ни скопировать, ни проверить исполнение.
Или я чего то не понял

[ldv]

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

[Starling]

Есть следующий БП:
1. Сотрудники компании отправляют поставщику заявки, данные для которых рассчитываются в Excel с учетом существующих остатков, спроса прошлых периодов и т.д. при помощи различных методов прогнозирования. Модуль сводное планирование пока не используется.
2. Поставщик принимает эти заявки, и отвечает на них инвойсом, в который входят разные строки заявок.
3. Инвойс принимается компанией, в нем анализируются цены, общие и товарные скидки. И по нему же формируется кредиторская задолженность, и начисляются накладные расходы.
4. В дальнейшем анализируют отклонение между тем, что было в заявке и тем, что вошло в инвойс. По каждой заявке сохраняется информация о том, что заказано и что получено. Данная информация нужна для того, что бы не отправлять поставщику повторную заявку, так как в большинстве случаев в рамках следующего инвойса недостающее количество будет закрыто.

Вопрос, можно ли при помощи стандартной функциональности покрыть требования этого БП. Мне кажется нет. Вижу следующее решение:
1. Заявки делать закупками с типом предложение
2. По факту получения инвойса создавать в системе закупку с типом закупка, в которую включать строки заявок (модификация). При этом хранить в системе информацию о том, с какой строки заявки, какое количество вошло в данный инвойс и уменьшать количество в заявке (модификация).
3. Работать с полученной закупкой в рамках стандартной функциональности.
Что можете посоветовать? может, есть более грамотное решение?
Буду благодарен за советы.

[slava09]

Цитата:

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

2. По факту получения инвойса создавать в системе закупку с типом закупка, в которую включать строки заявок (модификация).

А стандартным "Копирование из..." нельзя воспользоваться?

Цитата:

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

При этом хранить в системе информацию о том, с какой строки заявки, какое количество вошло в данный инвойс и уменьшать количество в заявке (модификация).

Очень похоже на функциональность контрактов. Может ее как-то можно будет поюзать?

[Starling]

Цитата:

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

А стандартным "Копирование из..." нельзя воспользоваться?

Скорее всего так и буду делать. Вопрос в том: можно ли отследить по какой заявке какое количество уже вошло в закупку?

Цитата:

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

Очень похоже на функциональность контрактов. Может ее как-то можно будет поюзать?

Нет контрак тут не подойдет, так как при использовании контракта имеем: 1 контрак - N закупок, а мне нужно N заявок - 1 закупка

[glibs]

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

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

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

[Starling]

Цитата:

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

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

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

Так же есть маленькое уточнение к БП: между заявкой и инвойсом есть стадия получения подтверждения от поставщика, как в этом случае ее отразить?
Вообще в терминах аксапты это перевод скл. проводки из статуса Приходы - предложения в статус Заказано. Изменить этот статус можно только для закупки в целом, а мне нужно только для отдельных ее строк.

Цитата:

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

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

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

Цитата:

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

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

Такой вопрос: вы говорите либо проекты либо план продаж, а в чем собственно отличие? И там и там одни и теже таблицы используются, только вызываются из разных мест. Или я что-то путаю?
Итого при данном подходе получается следующее:
1. Все заявки создаются в прогнозе закупок, при этом используем уровень поставщик – номенклатура. Т.к. ввод прогнозов на уровне групп мне не подходит.
2. По факту получения подтверждения от поставщика, делаю обычную закупку и корректирую прогноз закупок (вот тут, кажется все равно модификация). Инвойсы приходят один к одному с подтверждением и тут проблем уже нет.
3. Делаю отчет (а может уже и есть такой) что осталось в прогнозе, что уже было подтверждено или получено.
Получается так. Ни чего не забыл?

[glibs]

Цитата:

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

...
Можно, но все скидки (а в моем случае это общая и товарная) будут рассчитаны для закупки, а не для инвойса (накладной).
...

Общую скидку при обработке накладной можно задать. А "товарную" вы сами себе рассчитываете или поставщик вам ее рассчитывает?

Цитата:

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

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

Было бы неплохо, если бы вы конкретизировали, о каких именно расходах речь идет.

Цитата:

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

...
Автоматических расчет накладных расходов в данном случае работать не будет.
...

Если по строкам, то будет. А что за автоматические накладные расходы?

Цитата:

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

...
Так же есть маленькое уточнение к БП: между заявкой и инвойсом есть стадия получения подтверждения от поставщика, как в этом случае ее отразить?
Вообще в терминах аксапты это перевод скл. проводки из статуса Приходы - предложения в статус Заказано. Изменить этот статус можно только для закупки в целом, а мне нужно только для отдельных ее строк.
...

Удачный пример неправильно поставленной задачи.

Например, можно отменить строчку закупки, обнулив количество К поставке.

Цитата:

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

Такой вопрос: вы говорите либо проекты либо план продаж, а в чем собственно отличие?
...

Просто мало кто в России покупает модуль Проекты. Поэтому я и написал "Если не пользоваться проектами...".

А так вы все правильно говорите, конечно.

Цитата:

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

...
1. Все заявки создаются в прогнозе закупок, при этом используем уровень поставщик – номенклатура. Т.к. ввод прогнозов на уровне групп мне не подходит.
2. По факту получения подтверждения от поставщика, делаю обычную закупку и корректирую прогноз закупок (вот тут, кажется все равно модификация). Инвойсы приходят один к одному с подтверждением и тут проблем уже нет.
3. Делаю отчет (а может уже и есть такой) что осталось в прогнозе, что уже было подтверждено или получено.
Получается так. Ни чего не забыл?
...

А зачем корректировать прогноз в п.2? Откуда вы тогда будете брать исходное количество в заявке?

А вообще, конечно, лучше заставить себя приспособиться к потребностям сразу.

[ds1678]

Цитата:

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

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

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

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

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

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

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

[Starling]

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

Цитата:

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

Общую скидку при обработке накладной можно задать.

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

Цитата:

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

А "товарную" вы сами себе рассчитываете или поставщик вам ее рассчитывает?

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

Цитата:

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

Было бы неплохо, если бы вы конкретизировали, о каких именно расходах речь идет.

Все что связанно с закупкой у иностранного поставщика:
• Транспорт
• Услуги хранения на ТЛС
• Таможенные услуги

Цитата:

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

Если по строкам, то будет. А что за автоматические накладные расходы?

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

Цитата:

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

Удачный пример неправильно поставленной задачи.

Каюсь

Цитата:

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

Например, можно отменить строчку закупки, обнулив количество К поставке.

Это не подходит, так как почти всегда в рамках следующего инвойса товар будет получен полностью
Вопросы по 2-ому вариенту:

Цитата:

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

А зачем корректировать прогноз в п.2? Откуда вы тогда будете брать исходное количество в заявке?

В принципе согласен.

Цитата:

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

А вообще, конечно, лучше заставить себя приспособиться к потребностям сразу

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

Цитата:

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

Все это верно, при условии, что для компании закупка канцелярии - не основной вид деятельности

Компания занимается дистрибуцией, так что закупка основной вид деятельности.

[Starling]

Итого у варианта 1 есть ряд минусов:
1. Нет возможности автоматически расчитать сумму общей скидки
2. Нет возможности автоматически расчитать товарную скидку
3. Нет возможности распределелить накладные на строки ()
4. Нет возможности отразить статус получения подтверждения от поставщика
Над варинатом 2 думаю.
Только кажеться мне, что прогноз закупок это не совсем заявки. Все таки прогноз и заявка вещи разные. Цепочка должна быть такая Прогноз продаж --> Прогноз закупок --> Заявка --> Закупка.

[Serg]

To Straling
Для начала я бы Вам посоветовал скорректировать понятие «заявки на приобретение» на понятие «заявка на получение», это будет ближе к логике системы и к более правильным бизнес-процессам. Каждое подразделение должно заниматься расчетом и определением потребностей для выполнения своих собственных задач, а не решать вопрос о приобретении. Последняя задача это прерогатива отдела снабжения, в помощь которому и дается сводное планирование, которое сводит в расчет текущие остатки на складах, заказные и подтвержденные закупки поставщиков, возвраты на склады, заявки на приобретения, страховые запасы и прочие ожидаемые расходы и в результате выдает обновленный план заказов на закупку.
Правда, с точки зрения управления предприятием «заявки на получение» не лучший БП, но полностью и быстро от него отказаться сложно.
Подробности (можно с демонстрацией на рабочем проекте) это уже отдельная тема.

[Starling]

to Serg
На данном этапе модуль сводное планирование не внедряется. Что с моей точки зрения верно, так как без отладки других процессов запустить сразу сводное проблематично. Кроме того возможности модуля сводное планирование не покрывают всех требований БП предприятия. Это связано с отсутствием методов прогнозирования. Прогнозы в аксапте нужно вносить только руками. Частично эти требования можно было бы покрыть, используя журналы резервного запаса, но вот на сколько этот функционал подойдет я ответить не готов, так эти БП предприятия я не анализировал.

Итого: менять уже существующую на предприятии и вполне работающую схему на данном этапе смысла нет, так как предложить что-то взамен пока нельзя. Т.е. отталкиваюсь от того, что заявки пока будут использоваться также, как это было до Аксапты. Решение я уже принял проанализировав все предложенные решения и уточнив дополнительные детали с ключевыми пользователями. Остановился на том, что заявка эта закупка с типом Предложение, инвойс – это закупа с типом Закупка. По факту создания инвойса, количество в заявки корректируется с учетом инвойса. Для корректировки заявки выбираются по методу ФИФО. Дальше все в рамках стандартного функционала. Модификация по корректировки есть, но она не очень сложная.
Как только перейдем к внедрению сводного, вот тогда наверно и будет думать о том, как существующие БП лучше оптимизировать и реализовать в Аксапте.

Спасибо за помощь.

[ds1678]

To Starling:

Цитата:

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

Компания занимается дистрибуцией, так что закупка основной вид деятельности.

Цитата:

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

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

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

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

Такая малость, как невозможность прогнозирования напрямую в Аксапте Вас не должна заставлять вас отказываться от системы планирования (подчеркиваю, не от внедрения сводного планирования, а именно от внедрения системы планирования). Это часть системы управления предприятием, при чем главная часть (см. МРП2). Экономический эффект от систем подобного класса (в т.ч. аксапты) досигается только в случае следования данному стандарту, что влечет за собой, как правило, серьезную корректировку БП предприятия.

Но вы же консультант, педложите Предприятию лучшее