flytier Кстати, буду благодарен, если Вы подскажете порядок стоимости внедрения по ним (ну плюс минус валенок понятно).

Смотря какие модули внедрять.
Если внедрять только управленческий учет (взаиморасчеты, запасы, фиксы, платежи, главная книга и тп) без всякого планирования - то от 10 килобаксов (по крайней мере я столько беру, может кто и дешевле))). Естественно, никаких доработок кроме нескольких отчетов.
Если добавлять бюджетирование - то сильно зависит, надо ли объяснять и учить теории. Просто показать как вносить бюджеты и смотреть план/факт можно и бесплатно при внедрении управленческого учета (те же проводки с теми же измерениями, но бюджетные - ничего сложного). А если надо настроить контроли и научить, что же такое бюджетирование на самом деле - то тут сильно зависит от хотелок и глубины невежества )))
Так как Навик платный, для него надо прибавить стоимость лицензий, и тут главное попасть на акцию http://www.cnews.ru/news/top/index.shtml?2011/10/28/462316.

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

flytierЧтобы было чуть понятнее мои проблемы, вот одна из хотелок: "менеджер взял в руки счет, положил на сканер, а лучше сфоткал, и (барабанная дробь) появилась финансовая заявка". И это еще не все! "Эта заявка автоматом проанализировалась и, на основе накопленной в системе статистики, ей проставились недостающие реквизиты (статья затрат, ЦФО и т.п.). Менеджеру осталось только проверить и подтвердить правильность."
А что именно вы подразумеваете под "финансовой заявкой"? Какие у этого документа функции, что с ним потом дальше происходит?
И счет - он появляется "из воздуха", или есть некие предшествующие документы - ну там потребность, запрос поставщику? :)

flytierФинансовая заявка это не документ, а скорее сущность. Грубо говоря это потребность сделать платеж. Функции - в соотнесении с бюджетом, БДДС при необходимости. Далее апрув или реджект. А вот на основании апрувнутой заявки уже делается платеж.

Собственно финансовая заявка - это как раз из классического бюджетирования времен до автоматизации.

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

я примерно так и думал...
а расскажите тогда еще одну вещь.
вот есть предположим у вас подрядчик. нормальный подрядчик. вы с ним планируете и дальше работать. и принес он числа 10 акт выполненных работ. в договоре срок оплаты - 5 дней после подписания акта. и бюджет ДДС по этой статье за этот месяц полностью выбран...
где в предложении ставите запятую:
"реджектить нельзя апрувить!"
?
и как у вас выглядит этот нелегкий процесс (расстановки запятых)

flytier,
вы описали очень частую ошибку в методологии бюджетирования.
Попытка строить бюджетный контроль по бюджету ДДС - некорректна. Счет на оплату часто возникает тогда, когда фирма УЖЕ получила товары или услуги и обязана их оплатить - и что тут можно контролировать?
Если необходимо контролировать выполнение бюджета (не давать его превышать), делать это необходимо ДО возникновения обязательств - в момент заключения контракта или решения о приобретении неких услуг. И контролировать не ДДС, а бюджет закупок (бюджет доходов и расходов, скорректированный на покупку ОС и т.п.). А контроль ДДС получится автоматически.

Как это выглядит на практике.
Стандартная схема управления закупками (она очень похожа во всех распространенных на мировом уровне ERP системах) состоит из следующих этапов (каждый этап фиксируется соответствующим документом):
1. Requisition - потребность в товаре / услуге (поступает в подсистему закупок из других подсистем)
2. RfQ - запрос квоты у поставщика (к какому сроку и по какой цене сможет поставить - объявление тендера)
3. RfQ Response - ответы поставщиков (тендерные предложения)
4. PO - заказ на закупку (контракт с поставщиком, условия которого наилучшие)
5. Material Receipt - получение материалов (делают складские сотрудники, часто только количества без цен)
6. Invoice - возникновение кредиторской задолженности перед поставщиком (делает бухгалтерия)
7. Payment - оплата
Рекомендую посмотреть вот здесь:
http://www.gs1.org/gsmp/kc/ecom/xml/xml_bms
тут достаточно подробно описана сложившаяся мировая практика документооборота

Для контроля использовать документы Material Receipt, Invoice или Payment нельзя - они возникают ПОСЛЕ исполнения поставщиком своих обязательств.
Можно использовать Requisition, RfQ или PO. Чаще всего используют PO (предыдущих документов может и не быть).


Я даже картинку с примером PO привел.
Слева сверху - дата заказа.
Справа сверху - когда поставщик обещает выполнить заказ (планируемая дата возникновения кредиторки).
Слева снизу - статус заказа. Перед тем, как он станет утвержденным, может быть много этапов согласований, в том числе автоматический контроль бюджета и ручное утверждение начальником, если В РЕЗУЛЬТАТЕ выполнения заказа БУДЕТ превышен бюджет (или отмена заказа - поставщик еще НИЧЕГО не сделал, и можно отказаться без последствий).
Справа снизу - условия оплаты - через сколько времени после предполагаемого выполнения нам придется платить деньги. Фактически, утверждая заказ, начальник утверждает не только приобретение услуг, но и оплату этих услуг в оговоренные сроки .

И самое главное - этот велосипед не надо изобретать самому, он работает из коробки. Все решается с помощью настроек.

ViPRosа те получают о других ... и так прямо до целей и стратегий :):):)
ну мы ведь сейчас бюджетирование обсуждаем, а не ERP в целом

flytiers_ustinov,

я не пропал, я думаю. Промежуточный вопрос - по Вашему мнению, контроль платежей на соответствие БДДС и бюджета нужен? Или он должен производиться на шаг ранее, как Вы описали на конкретном примере.
Не нужен.
Вернее необходимо убедиться, что платёж проходит в рамках ранее утвержденного заказа. А сравнение с БДДС - лишнее.