Прогноз движения средств по бюджетам

[Елена Сысовская]

Цитата:

Изначально опубликовано Lesh
"Пришлось этот счет в следующем месяце перекраивать. :-((

!!! :-(

[glibs]

Цитата:

Изначально опубликовано mazzy
glibs, может статью напишешь?

Хм...

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

Твое предложение пока натолкнуло меня на следующую идею http://technet.navision.com/workspac...tribId=1&wso=1

[glibs]

Цитата:

Изначально опубликовано Lesh
...В принципе может это и здравая мысль закачивать бюджет из Ёхеля...

И не говорите, до самого только дошло.

Цитата:

Изначально опубликовано Lesh
...Однако по поводу счетов я с Вами не соглашусь. Бюджетные статьи, Центры стоимости и другую бюджетную аналитику переносить на план счетов смысла нет - слишком много субсчетов придется делать...

Вы затронули слишком большую тему, чтобы делать столь конкретные выводы.

"Центры стоимости", т.е. центры затрат и центры доходов (прибыли) — да! Это финансовая аналитика.

"Бюджетные статьи" — уточните, пожалуйста, термин.

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

В общем, нужно смотреть.

Цитата:

Изначально опубликовано Lesh
...Бюджетную классификацию лучше строить на уровне финансовой аналитики...

Я считаю, что не всю. См. выше.

Но! Если все-таки построить статьи бюджета на финансовых аналитиках, то эти аналитики попадут и на соответствующие счета "ПДДС" (LedgerCov), а именно суммы по этим счетам пойдут в разрезе аналитик, которые будут стоять в соответствующем счете бюджета или проводки ГК, которые породят проводки в LedgerCov. А дальше их можно просто дстать финансовыми отчетами. Т.е. тогда не понятно, зачем вам еще распределение по субсчетам ГК в этом случае.

Цитата:

Изначально опубликовано Lesh
...Правда ее тоже придется слегка переписать, чтобы поддерживала иерархии, но это не сложно...

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

Цитата:

Изначально опубликовано Lesh
...Проблему я вижу в следующем - если есть субсчета, скажем 50 счета, то придется заставить экономистов планировать бюджет в разрезе этих субсчетов...

50-й счет — это касса? Т.е. у вас бюджет строится по кассовому методу? Ой! Кажется, я теперь начинаю понимать, что вы задумали...

Только это... глядите... Ведь Аксапта не очень то предполагает использование субсчетов на счетах денежных средств. Например, если вы заведете 50.01, 50.02, ... то вам придется завести столько же касс (расчетных счетов), чтобы на них делать разноску. Или подставлять счета разноски в каждый момент вручную, что есть утопия.

Аксапта предполагает работу с одним-двумя балансовыми счетами для расчетных счетов и кассы. Вся аналитика по счетам ведется в банковском модуле (международная версия) и + касса (СНГовская). Если вы хотите видеть оборот по счетам денежных средств в разрезе статей бюджета, то тогда все действительно придется пихать в финансовую аналитику. Но только стоит ли это таких затрат? Ведь в каждой оплате придется указывать статью затрат бюджета (финансовую аналитику). И не одну. А если это предоплата, и черт его еще знает, что мы фактически за это получим? Всякое ведь бывает, хотя это не должно быть нормальной ситуацией. Ну и потом представьте себе, что мы делаем платеж за десять товаров/услуг (допустим, это одна закупка), у каждого из которых свой набор финансовых аналитик. Вам придется ввести этот платеж 10 строчками журнала платежей. А это повлечет 10 платежек...

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

Цитата:

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

Увы, тоже не понял.

[Lesh]

Уважаемый Glibs, спасибо Вам за отзывчивость. Честное слово - очень приятно общаться. Тема тут действительно очень обширная, но интересная и в Ахарте мало паханная. Ряд компаний (таких как IBS например) предпочитают ставить Comshare или OFA или еще что нибудь, поддерживающее бюджетирование, поверх Ахарты. Однако решения такого уровня требуются далеко не всегда, а бюджет хоть в каком то виде нужен всегда, вот и приходится крутиться...

Теперь по поводу ДДС: речь действительно идет о кассовом методе (мне нужно было сразу уточнить, извините). Можно спорить что лучше - построить прогнозный баланс и косвенным методом расчитать ДДС или сразу учитывать факт по приходу и расходу денег. Однако, в конечном итоге все зависит от клиента и его методологии. Мне пока попадаются те, кто от косвенного метода отказывается. В результате - бюджетную классификацию приходится делать на аналитике (не повесишь же ее на субсчета ден. средств). Если нужен пример классификатора, то самый простой вид это отчет ДДС (форма №4) - расшифровка текущей деятельности, инвестиционной и финансовой.
Учет фактического исполнения бюджета действительно перекладывается на плечи рядовых тетушек труженниц, только страшного ничего нет. И это работает. И никто пока не загнулся от непосильной работы. (проверено на объемах порядка 100 платежек в день) По исходящим платежам бюджет проставляет, как правило ПЭО, т.к. расход денег требует дополнительного одобрения. Тут как раз удобно реализовать контрольную функцию бюджета, т.е. лимит по исходящим платежам.

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

Фактическое исполнение в системе реализовать удобно, а вот с планированием, на мой взгляд, проблемы. Если у нас один 50, один 51, один 52 счет, то все достаточно просто, но как только они начинают почковаться по субсчетам, тут и вылезают все НО с планированием бюджета. Вы зря иронизируете, на прошлом внедрении у клиента было 15 субсчетов на 51 счете (тут много зависит от территориальной распределенности компании, от ее юридического стройства и т.д.). Вариантов я не вижу, Ахарта заставляет планировать отдельно по каждому счету. Иногда это подходит, а вот что делать если нужен бюджет ДДС, но без разбивки по субсчетам. Другими словами как исключить план счетов (как классификацию) из планирования по статьям бюдежета? Именно это я имел ввиду, когда говорил про планирование в разрезе только итоговых счетов.

С уважением,
Lesh.

[glibs]

Цитата:

Изначально опубликовано Lesh
...Ряд компаний (таких как IBS например) предпочитают ставить Comshare или OFA или еще что нибудь, поддерживающее бюджетирование, поверх Ахарты...

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

Тем не менее, не раз видел людей, которые раньше работали со специализированными программными продуктами в области бюджетирования и при виде бюджетирования в Аксапте громко кричали "Фи-и-и!" и топали ногами. Речь при этом шла об удобстве ввода даных, необходимости поддержки бюджетного документооборота (составили — отправили на согласование — получили назад с комментариями — отправили новую версию (при этом старую тоже сохранили и можем сравнивать что было и что стало) — снова получили назад...), а также о необходимости готовых методик для анализа (это у нас национальная проблема — бюджетирование все хотим, но как им пользоваться не знаем и хотим готовые методики (не у всех, конечно, но у многих)).

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

По идее, все это безобразие должно быть интегрировано в Аксаптовский MRP. Только пока не могу понять, как. По идее, что-то должно породить потребность. Если речь идет о номенклатуре, то это м.б. строка складского журнала. А если не о номенклатуре... ? Интересный вопрос, однако. Ну и складской журнал плохо сопоставим с бюдетом...

Цитата:

Изначально опубликовано Lesh
...Можно спорить что лучше - построить прогнозный баланс и косвенным методом расчитать ДДС или сразу учитывать факт по приходу и расходу денег...

??? Извините, совсем ничего не понял.

Цитата:

Изначально опубликовано Lesh
...Если нужен пример классификатора, то самый простой вид это отчет ДДС (форма №4) - расшифровка текущей деятельности, инвестиционной и финансовой...

Ура! Наконец-то вы перешли на конкретику.

Цитата:

Изначально опубликовано Lesh
...Тут как раз удобно реализовать контрольную функцию бюджета, т.е. лимит по исходящим платежам...

Ну да, при кассовом методе это работает даже при предоплатах.

Цитата:

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

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

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

И это еще при оплате мы должны знать, что кому пойдет.

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

Хм... Вообще я знаком только с методиками построения бюджетов по методу начислений. Живого кассового никогда не видел. Может я чего недопонимаю? Если вдруг у вас есть ссылочка на место в Internet, где можно увидеть пример бюджета, составленного по кассовому методу (а еще лучше методика по его составлению и контролю), поделитесь, пожалуйста.

Цитата:

Изначально опубликовано Lesh
...насколько я понимаю тут создается один ваучер с несколькими проводками по ГК в нем...

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

Цитата:

Изначально опубликовано Lesh
...Вы зря иронизируете, на прошлом внедрении у клиента было 15 субсчетов на 51 счете
...
Ахарта заставляет планировать отдельно по каждому счету. Иногда это подходит, а вот что делать если нужен бюджет ДДС, но без разбивки по субсчетам. Другими словами как исключить план счетов (как классификацию) из планирования по статьям бюдежета?...

А я вовсе не иронизирую.

Почему же Аксапта заставляет планировать по каждому (суб)счету? Уточните. Если вас интересует оборот по всем денежным счетам без привязки к отдельным субсчетам, то я не вижу здесь проблемы. Хуже было бы, если бы было наоборот. Фактические обороты в приведенном вами случае с субсчетами размажутся по субсчетам. А распределение в бюджете можно настроить на один из субсчетов. Вам, как я понимаю, ПДС не нужно видеть по субсчетам. А по аналитикам вы его и так увидите. Если вы настроите финансовый отчет таким образом, чтобы он суммировал обороты по всем субсчетам денежных счетов (строка с типом "Итог"), то в результате вы получите прогноз оборота по денежным счетам одной цифрой без детализации по субсчетам. Точно также можно будет получить фактический оборот по всем денежным счетам одной цифрой. Далее их можно смотреть в разрезе аналитик (т.е. бюджетых статей).

Цитата:

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

Т.о. планировать и учитывать на итоговые счета не нужно.

Ну и потом, смотрите. В Аксаптовский "ПДДС" попадают обороты на основании введеных, но не отфактурованых заказов и закупок. Счет, на который планируются такие обороты подставляется из профилей разноски и реально зависит только от группы поставщиком (упрощенно). Субсчета тут ну никак планироваться не будут. Т.о. реальный ПДС по субсчетам вы не получите даже в теории. Даже если вы в профиле для каждого поставщика постараетесь указать его субсчет, вы не сможете распределить суммы между кассой, рублевым и валютными счетами (50, 51, 52).

Только я вот чего понять не могу. Может вы объясните? У меня есть подозрение, что оборот по 50-му, 51-му и 52-му счетам в Аксапте при кассовом бюджете должны не расчитываться аксаптовской функциональностью "ПДДС", а вводиться как бюджетные данные, т.е. в фоме бюджетных проводок с аналитикой по статьям затрат. Или я все-таки далек от понимания бюджетирования по кассовому методу?

[tony]

И опять бью челом, увспецы!

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

Оказывается, при расчете ДДС по прогнозу продаж в части оплаты подставляется счет плана счетов, указанный в:
Расчеты с клиентами / Параметры / Главная книга и налог / Разноска / Профиль разноски

И опять выходит, что сей прогноз ДДС возможно настроить на один счет Плана счетов для прогноза продаж по ВСЕМ клиентов. Ни каких тебе разных способов оплаты - всех в один котел.

Увспецы, если кто знает, как по-другому назначить счет для разноски ДДС по прогнозу продаж, ужжжжасно буду благодарен

[glibs]

Цитата:

Изначально опубликовано tony
...Оказывается, при расчете ДДС по прогнозу продаж в части оплаты подставляется счет плана счетов, указанный в:
Расчеты с клиентами / Параметры / Главная книга и налог / Разноска / Профиль разноски

Ув. tony,

Позвольте с вами не согласиться.

Счет ликвидности проставляется именно в профиле разноски клиентов. И аксаптовский "ПДДС" будет строиться с учетом счета, указанного в профиле, с которым будет разнесен заказ. Можете проверить. У меня 3.0 СП1 СНГ, но думаю, в остальных версиях будет работать аналогично.

Цитата:

Изначально опубликовано tony
...И опять выходит, что сей прогноз ДДС возможно настроить на один счет Плана счетов для прогноза продаж по ВСЕМ клиентов. Ни каких тебе разных способов оплаты - всех в один котел...

Не, не так. Во первых, "счет продаж" — это не расчетный счет, а то, что в российском плане счетов обозначено цифрами "90.1". В зависимости от того, что вы будете продавать, продажи по заказу могут спрогнозироваться на несколько субсчетов данного счета. Например, в украинском плане счетов есть отдельные субсчета для готовой продукции, товаров и услуг, а GAAP требует раздельного отражения доходов и расходов по видам деятельности.

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

Вы можете убедиться в этом создав заказ на продажу и просмотрев запрос "Запросы\Прогноз движения средств" (из формы заказа). Изменение таких параметров, как условия оплаты, график оплаты, дата оплатить до приводят к автоматическому пересчету аксаптовского "ПДДС". Изменение профиля разноски, счетов реализации и задолженности и некторых других параметров можно будет увидеть только после выполнения Расчета прогноза движения средств (в периодических операциях в ГК (либо удалив заказ и создав его заново)).

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

To all:

PS. Если я не последний, кому это стало известно, сообщаю, что процедура расчета потребности в валюте учитывает остатки на счетах денежных средств. Только остатки, почему-то она берет по состоянию "на вчера" и сегодняшние проводки по счетам денежных средств не учитывает. Проверено на 3.0 СП1 СНГ, 3.0 СП1 (международная).

[tony]

Ув. glibs,

или у меня просто глюк в программе, но если все так, как Вы говорите, это вполне меня обрадовало бы, но

Пару уточнений:

1. я имел в виду прогноз движения средств именно в части оплат:

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

2. что Вы имеете в виду под "профилем разноски клиента"? условия и виды оплыты или отгрузки? я и с тем и с этим игрался, прогнозируемые оплаты идут все равно на тот счет, что в Параметрах. А отдельного поля "Разноска" в форме клиентов - хоть убей нету

Может, подскажите поподробнее, где эта злополучная разноска, которая ставится для каждого клиента?

3. Счет "Реализация" я знаю

В остальном согласен, перед Вашими изысками преклоняюсь и подтверждаю

[glibs]

Ув. tony,

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

В прогнозе продаж действительно профиль не указывается, а берется из настроек ГК. Только ваша фраза:

"...И опять выходит, что сей прогноз ДДС возможно настроить на один счет Плана счетов для прогноза продаж по ВСЕМ клиентов..."

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

А вот условия оплаты, увы, берутся из настроек жестко и от клиентов не зависят.

[tony]

Ув. glibs,

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