Планирование платежей. Прогнозирование прибылей и убытков. Часть 1 про кассовый разрыв

0. 1596 21.10.18 00:48 Сейчас в теме
Кассовый разрыв. Планирование поступлений от клиентов, списаний налогов и оплат поставщикам. И как следствие - прогнозирование прибыли или убытков.

Перейти к публикации

Вознаграждение за ответ
Показать полностью
Лучшие комментарии
58. Rustig 1596 01.06.20 22:51 Сейчас в теме
10 лет программирую в 1с, консультирую по программам, и меня всегда мучил вопрос - почему в 1с до сих пор не реализован самый базовый вариант мало-мальски финансового учета - почему до сих пор лучшие практики ведут финансовую модель в Эксель, а про 1с говорят, что его надо "пилить" и "затачивать"...
Ни в прежних программах БП 2.0, УТ 10.3, ни в новых УТ 11, БП 3.0, УНФ нет полноценного финансового учета: так чтобы было легко и удобно вводить сведения, видеть в динамике, видеть графики.
Кажется стало проясняться благодаря ребятам из
Нескучные финансы

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

Будем разбираться! :)
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. TODD22 18 21.10.18 00:58 Сейчас в теме
Планирование поступлений от клиентов, списаний налогов и оплат поставщикам.

Планирование поступлений и выплат это управление ликвидностью(платёжеспособностью) оно же бюджет движения денежных средств.
И как следствие - прогнозирование прибыли или убытков.

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

Это разные категории.

Платёжеспособность это не рентабельность, точно так же как рентабельность не спасёт от кассовых разрывов.

Как говорится, сапожник без сапог.

И без знания мат части.
Rustig; avtokom.1c; automatizator; +3 Ответить
6. Rustig 1596 22.10.18 08:55 Сейчас в теме
(1) ваш ответ не плох и не хорош. Ни рыба, ни мясо. Я вообще склонен думать, что вы мало в этой теме понимаете, и не видите подводных камней.
2. user618912_redgad 12 22.10.18 07:28 Сейчас в теме
Почему-то многие путают сущность бюджета движения денежных средств с сущностью бюджета доходов и расходов. В расчетном периоде может быть и убыток, но деньги на счете есть и наоборот.
Самый простой пример. Купили на все деньги товары. Лежат на складе. Денег на расчетном счете пока нет. Отгрузили товары покупателю. Прибыль появилась, а денег пока нет. И т.д.
5. Rustig 1596 22.10.18 08:51 Сейчас в теме
(2) многие путают. а при чем здесь это? для меня все ясно - что я хочу получить на выходе, что есть на входе. если вам что-то не ясно, задавайте вопросы, а не преждевременные выводы.
3. automatizator 292 22.10.18 07:58 Сейчас в теме
Функционально программа будет дорабатываться. Я буду продолжать разбираться в теме бюджетирования.


Собственно здесь все сказано.
Попытка родить новый продукт для планирования и бюджетирования.

(Если не ошибаюсь прогноз движения ден.средств в УТ10 -реализовано)
4. Rustig 1596 22.10.18 08:50 Сейчас в теме
(3) нет, вы не правы - продукта для планирования и бюджетирования не будет.
7. Rustig 1596 22.10.18 09:41 Сейчас в теме
Коллеги, поясню ситуацию.
Если покупатели нам должны 12 млн, а мы должны поставщикам10 млн, при этом есть 1 млн. на расчетном счете, то однозначно ответить на этот вопрос прибыльны или убыточны нельзя ни на коротком промежутке времени, ни на длинном.
Поскольку есть еще кредиты, внешние заимствования, налоги государству, зарплата сотрудникам, аренда помещения, лизинг оборудования.
По данному вопросу теория бюджетирования не дает сиюминутный и однозначный ответ. Теория бюджетирования предлагает внедрять комплекс мер и мероприятий, с помощью которых более-менее вырисовывается картина текущего положения, прогнозируется будущее положение с учетом планов продаж, планов производства, планов закупок и других планов на жизнь. Нельзя внедрить бюджетирование за один день.

Мой инструмент не будет идти по пути теории бюджетирования.
Уметь планировать поступления и списания денежных средств можно и без знаний теория бюджетирования.
Что появилось раньше: яйцо или курица?
Также и здесь, что появилось раньше: здравое умение оперировать своими финансами или теория бюджетирования?

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

Здесь не будет планов продаж отдела менеджеров - выполнить план продаж на 100%, достигнув показателей продаж на 1 млн. руб. Для меня это называется в моей системе координат - прогнозировать будущее с учетом еще не имеющихся договоренностей. Будут достигнуты договоренности или нет - вилами по воде писано. Будут достигнуты договоренности - еще не значит, что они удовлетворят текущему положению фирмы - к примеру, что лучше: продать на 300 тыс. с отсрочкой платежа на 6 мес, но с отгрузкой товаров через неделю - или продать на 50 тыс товара по предоплате? Ответ для разных фирм и их текущего финансового положения будет разным. Но для некоторых фирм - первый случай может затащить фирму в еще более глубокую долговую яму, а второй случай заработать в текущем периоде, и возможно расплатиться по аренде без начисления пени.

Подписывайтесь на сообщения - дальше будет интересней!
8. chng 22.10.18 10:28 Сейчас в теме
ИМХО, у вас проблема подходе к разделению платежей на группы для отнесения очередям и как следствие обработка этих очередей.
Если вы посмотрите на эту проблему с точки зрения бизнеса, а не фрилансера, то поймете, что все платежи нужно разделить минимум на четыре функциональные группы(типы).
С первой группой выделенной у вас, можно согласиться. две другие неправильные по смыслу.
Рассрочка платежа, это свойство любого платежа, т.е. чисто теоретически любой платеж может быть отсрочен или разделен на части, а части могут быть оплачены до или после даты платежа. Поэтому выделять в отдельную очередь концептуально не верно.
Касательно групп, то правильней разделить платежи по типам (к терминам не стоит придираться, важна суть):
1. Основной товар - товар который приносит прибыль, не уплата по нему создает будущий финансовый провал
2. Вспомогательный товар - товар оплату которого можно двигать при расчете календаря, т.к. он не создает существенных финансовых провалов.
3. Налоги, комиссии (ваша первая группа) - не оплатишь закроют бизнес
4. Собственные нужды - платить нужно но можно управлять приоритетами...
вот как то так...
9. chng 22.10.18 11:58 Сейчас в теме +1.5 $m
(8)Неудачно нажал на энтер и уже не отредактировать предыдущий пост.
Повторюсь, все написанное ИМХО
Указанные мной группы платежей это минимум, на который надо разделить все собственные платежи при построении очереди собственных оплат.
Любой из платежей, относится к какой либо группе считая что отсрочка или оплата частями, может производиться по любому из счетов.
Построение календаря и расчет суммы оплат на конкретную дату делать в процентном соотношении по очередям : первая группа - 40%; вторая группа - 20%; третья - 20%; четвертая 10%. (понятно что процентами можно управлять)
Используя такое правило вы легко оцениваете объем очередей на конкретную дату и легко прогнозируете провалы или пики относительно прогнозируемой суммы прихода на этот день. Собственно это и требуется при принятии решения об оплате того или иного счета из той или иной очереди.
Для более тонкого управления каждой очередью, внутри очереди можно иметь динамические приоритеты. Динамические, потому что счет попадая в свою очередь, имеет в ней низший приоритет который постепенно повышается по мере наступления контрольных сроков.

Учитывать отгрузки и отсрочки оплат собственного товара, при планировании поступлений, нужно в отдельных очередях, т.к. там тоже есть не мало своих приоритетов.
11. Rustig 1596 23.10.18 08:34 Сейчас в теме
(9)
Указанные мной группы платежей это минимум, на который надо разделить все собственные платежи при построении очереди собственных оплат.

разделите, как вам необходимо. сейчас представлена концепция. у каждого директора будет свое видение на категории. пока что я выделил три - по приоритетам - есть две крайние точки : "нельзя нарушать сроки" и "сроки можно двигать на длинном периоде", и одна категория как бы между ними "можно двигать сроки, но на пару дней" - опять-таки по договоренности с поставщиком.
(9)
Построение календаря и расчет суммы оплат на конкретную дату делать в процентном соотношении по очередям : первая группа - 40%; вторая группа - 20%; третья - 20%; четвертая 10%. (понятно что процентами можно управлять)

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

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

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

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

мне нравится, что вы начали Думать.
12. Rustig 1596 23.10.18 10:18 Сейчас в теме
(9)
Построение календаря и расчет суммы оплат на конкретную дату делать в процентном соотношении по очередям : первая группа - 40%; вторая группа - 20%; третья - 20%; четвертая 10%. (понятно что процентами можно управлять)

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

тот же самый вопрос от меня, то же самое сомнение, что кто-то так работает.... вы придумали это или взяли из жизни?
40. chng 24.10.18 09:18 Сейчас в теме
Пропустил вопрос заданный ранее...
(12)
Построение календаря и расчет суммы оплат на конкретную дату делать в процентном соотношении по очередям : первая группа - 40%; вторая группа - 20%; третья - 20%; четвертая 10%. (понятно что процентами можно управлять)

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

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

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

Второй эффект мне объяснил сам заказчик уже разруливая свои проблемы.
Правило для очереди на собственное обеспечение, позволило обязать управляющего не тратить все на товар, с которого он получал свои бонусы, но и заботится о состоянии торговых точек оплачивая всякие мелкие ремонты, торговое оборудование и прочие расходы без которых точка превращается в сарай в котором никто работать не хочет.
42. Rustig 1596 24.10.18 11:10 Сейчас в теме
(40) возможно мы с вами обсуждаем одну и ту же идею - разбить каждое списание ден.средств на несколько траншей - я как раз заложил такую возможность в разработку - на видео и на картинках видно, что у документа График оплат есть табличная часть, в которой указывается порядок платежей - в какой день какая сумма - при этом траншей может быть несколько. Заложить в табличную часть кнопку и алгоритм автоматического разбиения по процентам , к примеру, 40%, затем 60% - это уже плюшки сверху и не составит труда - а также можно и вручную посчитать - в любом случае это не может быть решено в одностороннем порядке - такое разбиение надо согласовать с поставщиками, и уже после , имея договоренность на руках в устной форме или на бумаге, прописать график оплат в несколько этапов.
10. Rustig 1596 23.10.18 08:19 Сейчас в теме
(8)
все платежи нужно разделить минимум на четыре функциональные группы(типы).

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

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

имея инструмент, даже тот - который я выложил - версию №1 - вы вправе делить свои платежи по любым категориям очередности оплат. я не задаю жестко - есть реквизит у платежа - который вы сами заполняете цифрой.
13. chng 23.10.18 10:34 Сейчас в теме
Необходимо сделать оговорку, речь идет о некоемом суррогате бюджетирования для бизнеса определенного размера, когда на полноценное бюджетирование нет возможностей или средств, но потребность уже появилась.

(10)
кол-во очередей пока не фиксировано, категории выделил три - исходя из своего видения ситуации.

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

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

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

Хотите примеров, не вопрос. Одна из главных проблем работы с рассрочкой платежа это не набраться этой рассрочки на одну дату. Н
апример:
Ежедневно вы можете платить 1000 рублей поставщикам.
Если вы в один день берете товар на 1000 у трех поставщиков с отсрочкой 10, 20, и 30 дней соответственно, то все нормально и по наступлению дат оплаты, вы расплатитесь.
А если товар покупается с рассрочкой: сегодня на 30 дней, через 10 дней рассрочка на 20, через 20 дней рассрочка на 10 дней. То в этом случае дата оплаты совпадет и вы должны будете заплатить одномоментно 3000 а в приходе только 1000. Вот вам и финансовая яма. Когда таких накладок много, яма становится глубже и глубже.
Собственно если с яма образуется только условиями товарной очереди, это проблемы одного порядка, а если платежами из разных видов очередей это уже совсем другой порядок проблем.

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


(11)
Динамические, потому что счет попадая в свою очередь, имеет в ней низший приоритет который постепенно повышается по мере наступления контрольных сроков.
Откуда у вас идеи такого рода? я не согласен с ними. такого у меня не будет. пока меня не убедят в обратном.


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

ВАЖНО. Еще один неочевидный критерий для динамического приоритета - частичная оплата. Сегодня заплатили часть, приоритет оплаты понизили, через несколько дней он должен опять подняться для попадания в оплату другой части суммы...

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

(11)
коллеги, я склонен думать , что вы не внимательно читаете статьи - по диагонали, что ли?
учитывать отгрузки я не буду

Именно так, по диагонали.. особенно после идеи не заплатить 1С-нику :-))

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


(11)
откуда у вас идеи такого рода?

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

(11)
мне нравится, что вы начали Думать.

Вы ошибаетесь... все уже придумано до нас... :-))) ©не мой.
На самом деле, креативные менеджеры сейчас умудряются многое не знать, забыть и заново придумывать то, что было уже давно придумано, проверено и работало как часы. (это уже не к Вам относится, просто навеяло...)
14. Rustig 1596 23.10.18 10:46 Сейчас в теме
(13)
1. за покупку товара(материала) - приносящего прибыль; неоплатил - нечем торговать;
2. налоги и зарплаты - условное название; неоплатил - прикрыли контору;
3. на собственные нужды - аренды помещений,ремонты транспорт и т.п.; неоплатил - торговать негде;

я закладываю другой принцип работы с платежами:
по всем платежам сроки всегда обговариваются исходя из собственных возможностей - вы договариваетесь с покупателями и с поставщиками - будет ли это частями, какими суммами и в какие дни.
Главное, что вас это должно удовлетворять - после первого раунда - вы заносите информацию в базу в документ "График оплат" - видите финансовую ситуацию в перспективе. При этом необходимо все расходы и доходы внести в эти Графики оплат.
Если вас не устраивает ситуация, вы выходите на второй раунд переговоров - покупателей просите ускорить оплату своих товаров и услуг, поставщиков просите отсрочить оплату их товаров и услуг. Таким образом вы оперативно управляете ситуацией.
За занесение всей информации в документы График оплат отвечают ответственные: бухглатер за свое, менеджеры за свое. Руководитель собирает и видит всю информацию и видит финансовое положение.
20. chng 23.10.18 11:19 Сейчас в теме
(14)
я закладываю другой принцип работы с платежами:
по всем платежам сроки всегда обговариваются исходя из собственных возможностей - вы договариваетесь с покупателями и с поставщиками - будет ли это частями, какими суммами и в какие дни.
Главное, что вас это должно удовлетворять

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

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

ИМХО. Задача программного инструмента быстро и непринужденно построить картину в перспективе, по имеющимся фактам и прогнозируемым следствиям этих фактов. А уже имея такую картину, можно "правильно" оценивать условия текущих сделок. Ведь ситуация может складываться таким образом, что при кажущейся выгодности предложения сегодня, оно может быть причиной серьезных последствий в будущем. И зная об этих проблемах можно и нужно поступить так, как сегодня не кажется выгодным.

Другими словами, чтобы принимать решение об условиях сделки надо видеть общую картину. А ее отсутствие, чаще всего является главной проблемой мелко-среднего бизнеса...
24. Rustig 1596 23.10.18 11:26 Сейчас в теме
(20)
Вот именно в этом и была проблема моего заказчика, работая так, но не видя всей картины (часть покупок делалась менеджерами) возникали серьезные финансовые ямы. Причем по контрольным данным для каждого менеджера(и собственника) по отдельности, все было впорядке, а по факту "конторка" в опе...

спасибо за вопрос-комменатрий.
я уже продумал это - и нашел более-менее оптимальное решение.
ждите продолжения статьи.
15. Rustig 1596 23.10.18 10:49 Сейчас в теме
(13)
Если вы в один день берете товар на 1000 у трех поставщиков с отсрочкой 10, 20, и 30 дней соответственно, то все нормально и по наступлению дат оплаты, вы расплатитесь.
А если товар покупается с рассрочкой: сегодня на 30 дней, через 10 дней рассрочка на 20, через 20 дней рассрочка на 10 дней. То в этом случае дата оплаты совпадет и вы должны будете заплатить одномоментно 3000 а в приходе только 1000. Вот вам и финансовая яма. Когда таких накладок много, яма становится глубже и глубже.


Да, в этом и есть сложность управления финансами, сложность решения данной задачи. И ни одна теория бюджетирования, к которой взывают первые комментаторы, не справится с этой сложностью. То есть не даст заведомо правильный и наперед ответ, как действовать или как избежать подобных ситуаций.
16. Rustig 1596 23.10.18 10:53 Сейчас в теме
(13)
Насколько я понимаю, ваша цель именно "ловить и показывать" собственнику такого рода проблемы.

Да, именно шулай.
Потому что это достижимая цель.
И реально улучшит ситуацию с ведением учета и управлением финансов.
17. Rustig 1596 23.10.18 11:07 Сейчас в теме
(13)
Например, поставщик лояльный и может задержка оплаты допустима. Или поставщик дал отсрочку, но позвонил и попросил ему помочь оплатить раньше. Это примеры для приоритетов оплат по критерию поставщик. По критерию товар еще проще Основной товар/не основной товар, дефицитный/не дефицитный, есть на складе/нет на складе и т.п.

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

(13)
А если товар покупается с рассрочкой: сегодня на 30 дней, через 10 дней рассрочка на 20, через 20 дней рассрочка на 10 дней. То в этом случае дата оплаты совпадет и вы должны будете заплатить одномоментно 3000 а в приходе только 1000. Вот вам и финансовая яма. Когда таких накладок много, яма становится глубже и глубже.

сегодня вы видите предстоящую оплату через 30 дней, через 10 дней вы видите Совпадение - так как через 20 дней вам надо заплатить уже не одному поставщику , а двум. Уже 10 дней вы начинаете реагировать!
можете перенести сроки - нужно начать договариваться с покупателями, с внешними кредиторами, с поставщиками - но ситуацию надо минимизировать в плане риска неплатежеспособности. и т.д.
18. Rustig 1596 23.10.18 11:13 Сейчас в теме
(13)
ВАЖНО. Еще один неочевидный критерий для динамического приоритета - частичная оплата. Сегодня заплатили часть, приоритет оплаты понизили, через несколько дней он должен опять подняться для попадания в оплату другой части суммы...


Мой инструмент позволяет разбить оплату на несколько траншей.

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

Другой вопрос, что планы должны корректироваться по достижению очередного факта платежа - и при этом возможно будут корректироваться Очередности оплат.
С этим я согласен на 100% с вами.
19. Rustig 1596 23.10.18 11:17 Сейчас в теме
(13)
Именно так, по диагонали.. особенно после идеи не заплатить 1С-нику :-))

Коллеги, снимите маски! Казаться лучшим мне не нужно. Написал, с чем сталкиваюсь. Это реальность - что многие услуги оплачиваются чаще по факту выполнения работ и с задержкой. Товары оплачиваются чаще по предоплате.
Пример с 1с-ником показателен и настолько прост в понимании, что мне не пришлось писать столько, сколько мы с вами обсуждаем детали проекта....
21. Rustig 1596 23.10.18 11:21 Сейчас в теме
(13)
Учитывать отгрузки в финансовом инструменте действительно глупо, но ожидать(прогнозировать) приход денег на собственные счета, всеравно придется. Хотя на начальном этапе (для компаний с двумя траншами поступления денег в течении месяца), достаточно факта из банка.

Вы как будто не поняли сути моего проекта и разработки. Ну все равно спасибо за обратную связь.
Возможно никому не влетело сразу, что я тут пытаюсь сделать.
Прогнозировать приход денег не нужно - пусть прогнозами занимаются теоретики бюджетирования и астрологи.
Надо внести в базу все договоренности с контрагентами. Если у вас что-то собираются купить, и вы договорились о сроках отгрузки, то вы значит договорились и сроках оплаты. Вот эти сроки оплаты вы вносите в базу.
23. chng 23.10.18 11:25 Сейчас в теме
(21)
Если у вас что-то собираются купить, и вы договорились о сроках отгрузки, то вы значит договорились и сроках оплаты. Вот эти сроки оплаты вы вносите в базу.

Я это понял, и считаю это достаточным, вернее убедился, что этого достаточно для 99,9% сделок.
В моем случае была одна единица номенклатуры, с очень особыми условиями, но это уже глубокие частности тут неуместные...
22. Rustig 1596 23.10.18 11:23 Сейчас в теме
(13)
Нужен был платежный инструмент для оперативной работы

я правильно вас понимаю, что вы что-то подобное уже обдумывали, но еще не реализовали и готового решения у вас нет?
вообще, я тут с вами половину своей будущей статьи раскрыл. Эх.... торопите события...
26. chng 23.10.18 11:30 Сейчас в теме
(22)
я правильно вас понимаю, что вы что-то подобное уже обдумывали, но еще не реализовали и готового решения у вас нет?

Готовое решение было написано на 5-том Делфи, когда интернет был только по диалапу, а термин "клиент-банк" округляло глаза у айтишников того времени... То решение спасло от банкротства тех, для кого делалось...

Оговорился то я как, какое Делфи, решение было написано на Турбо Паскале 5.5... Такие дела... :-)))
29. Rustig 1596 23.10.18 11:53 Сейчас в теме
(26) ясно, вообще я жду, что спецы выложат свои решения 1с. или укажут на готовые решения 1с...
31. chng 23.10.18 13:58 Сейчас в теме
(29)Вообще программные решения по данной проблеме попадались на глаза но не в 1С, а вот в 1С я не встречал ни одного дельного. Видимо мнение, что платежный календарь это "офлайн отчет", слишком устойчиво укрепилось в этой среде.
25. andreypahov 23.10.18 11:26 Сейчас в теме
Рустам, Вы в статье кругом пишете "прибыльность", но что Вы под этим понимаете, непонятно. Вы можете на словах написать формулу этой "прибыли", которую Вы считаете? Извините, я плохо разбираю рукописный почерк.
27. Rustig 1596 23.10.18 11:45 Сейчас в теме
(25) знаете, вы задали хороший вопрос. я ждал его.
давайте я постараюсь раскрыть вообще в целом - как я рассуждаю, как общаюсь с клиентом...
когда директор (клиент) спрашивает про прибыльность, он же спрашивает о своей ситуации в целом, я понимаю что ему важно понять что-то иное, чем валовая прибыль от продажи товара...
у него есть боль, я эту боль трансформировал (перевел) в проблему, проблему - в задачу. Сейчас я не решаю какую-то формулу прибыли, и я везде писал, что нельзя сказать прибыльна или нет. И к слову сказать теория бюджетирования, которую некоторые комментаторы пытаются сюда объединить, не дает таких ответов.
28. andreypahov 23.10.18 11:51 Сейчас в теме
(27)
когда директор (клиент) спрашивает про прибыльность, он же спрашивает о своей ситуации в целом, я понимаю что ему важно понять что-то иное, чем валовая прибыль от продажи товара...

Я так не понимаю.
Давайте это "что-то иное" поймем на словах.
Движение денежных средств (приход, расход), увеличение обязательств предприятия, уменьшение их же, увеличение обязательств перед предприятием, уменьшение их же. Речь про набор всех этих показателей? И только их?

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

Дает, но разные.
И скорее это не теория бюджетирования, а теория бух. учета
30. Rustig 1596 23.10.18 11:59 Сейчас в теме
(28) ооооо, Андрей, вы судите сложно....
(28)
Речь про набор всех этих показателей?

Мой ответ: нет.

(28)
И только их?
это не при чем.

(28)
Дает, но разные.

Мой ответ: дает, но разные - это не спорное моему ответу изречение. Ваше изречение усиливает мой ответ.
Дает, но разные = Не дает однозначного ответа.

(28)
И скорее это не теория бюджетирования, а теория бух. учета

мне без разницы как вы назовете этот учет. я же назову его мониторинг платежей.
34. andreypahov 23.10.18 15:56 Сейчас в теме
(30)

мне без разницы как вы назовете этот учет. я же назову его мониторинг платежей.


платежи - это выплаты и поступления денег. А Вы писали, что еще и дебиторку и кредиторку мониторите, правильно?
35. Rustig 1596 23.10.18 16:19 Сейчас в теме
(34) нет, так я не писал. найдите, пож-та, мою цитату, которую мне нужно прокомментировать для вас.
мне кажется, я очень подробно написал в статье, еще детальнее ответил на вопросы Черноморнефтегаза.
32. chng 23.10.18 14:18 Сейчас в теме
(28)
Движение денежных средств (приход, расход), увеличение обязательств предприятия, уменьшение их же, увеличение обязательств перед предприятием, уменьшение их же. Речь про набор всех этих показателей? И только их?

Думаю что половина собственников мало-среднего российского бизнеса, перечисленных терминов просто не поймут.

Мне например недавно формулировали проблему(от чего эта тема свежа в голове), которая звучит примерно так "... надо периодически вынимать деньги из оборота на другие цели, но собственник хочет это делать так, чтобы не убить текущий бизнес. Особенность бизнеса в том, что в день делается около сотни полных и частичных оплат по счетам". Получить объективный ответ от имеющихся коммерческого управляющего и бухгалтера-экономиста, он не может или получает отрицательный ответ.
33. andreypahov 23.10.18 15:55 Сейчас в теме
(32)

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


Если заменить "обязательства" на "кредиторскую" и "дебиторскую" задолженность - я думаю, поймут все или почти все.
36. Rustig 1596 23.10.18 16:20 Сейчас в теме
(33) нет, не получится у вас так... :(
37. Rustig 1596 23.10.18 16:22 Сейчас в теме
(33) я больше чем уверен, что вы пытаетесь угадать решение этой задачи, нежели ее решали и у вас есть практический опыт решения такого вопроса, как
(32)
Мне например недавно формулировали проблему(от чего эта тема свежа в голове), которая звучит примерно так "... надо периодически вынимать деньги из оборота на другие цели, но собственник хочет это делать так, чтобы не убить текущий бизнес. Особенность бизнеса в том, что в день делается около сотни полных и частичных оплат по счетам". Получить объективный ответ от имеющихся коммерческого управляющего и бухгалтера-экономиста, он не может или получает отрицательный ответ.

в УТ 10.3 нет механизма, который позволит понять ситуацию и сколько денег можно вытащить на новые проекты - так называемые внутренние инвестиции, реинвестиции прибыли.
думаю, что в унф и ут 11 и ерп 2.0 этого тоже нет...хотел бы услышать спецов, кто работает с ерп 2.0, ут11, унф... жду спецов и их мнение
38. andreypahov 23.10.18 18:13 Сейчас в теме
(37)
я больше чем уверен, что вы пытаетесь угадать решение этой задачи, нежели ее решали и у вас есть практический опыт решения такого вопроса, как


Если Вы посмотрите на комментарии еще раз, Вы увидете, что я вообще не комментировал задачу из п.32.

И не угадали: платежный календарь мы автоматизируем постоянно. Но на более крупных бюджетах - примерно на проектах от 200 тыс. руб. Ничего не имею против бюджетных решений
39. Rustig 1596 23.10.18 23:33 Сейчас в теме
(38) прошу прощения, если что
1) я ответил вам на пост 33.
мне показалось, что вы высказали свое мнение по вопросу.
я думаю, что оно некорректное.
2) вы задаете наводящие вопросы про прибыльность, дебиторку, кредиторку - да, исходя из ваших вопросов, я понимаю, что вы решали другую задачу.
и я считаю, что вы теперь думаете, что текущая постановка из п.32 подходит под рамки ваших решений. я сразу сказал вам, что не пытайтесь - не получится.
подобную задачу вы не решали, иначе бы не задавали наводящих вопросов про прибыльность, дебиторку, кредиторку.
3) платежный календарь не стоит 200 тыс, видимо у вас проект глобально был или сейчас связан с другой задачей, в которой автоматизация платежного календаря занимает 10-ое место.
я хотел бы по существу вопроса вести диалог. просто с вашими вопросами или комментариями диалог вести сложно - к примеру, ваше сообщение

(33)
Если заменить "обязательства" на "кредиторскую" и "дебиторскую" задолженность - я думаю, поймут все или почти все.


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

тут уже задали тон переписки теоретики бюджетирования, и возможно я вас зря и преждевременно отнес к хейтерам. так что "если есть возможность дружить - зачем воевать ?"
41. andreypahov 24.10.18 10:39 Сейчас в теме
(39)

Спасибо, Рустем. Сразу не успеваю, в течение трех дней постараюсь написать подробный ответ.
43. andreypahov 27.10.18 23:06 Сейчас в теме
(39)
я ответил вам на пост 33.
мне показалось, что вы высказали свое мнение по вопросу.

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

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

(35)
Дебиторку я взял из публикации - например:
Рустем, непонятно прибыльны мы или нет? Покупатели нам должны 6 млн.р., а мы должны поставщикам 5 млн.р. Непонятно, какие товары и под какие заказы у нас на складе лежит товар?

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

3) платежный календарь не стоит 200 тыс, видимо у вас проект глобально был или сейчас связан с другой задачей, в которой автоматизация платежного календаря занимает 10-ое место.

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

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

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

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

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

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

Одному клиенту "сверху" дописали план размещений на МНО (краткосрочные депозиты, на несколько дней): пришлось писать отдельный регистр сведений и добавлять к платежному календарю новые строки с доп. расчетом прибыли от размещений на МНО. Прикладываю ТЗ (файл "2" в Excel).

В типовом "1С:Управление холдингом" (но это дорогое решение) - тоже платежный календарь, тоже группировка по счетам, тоже прикладываю скриншот (скрин "3"). Список заявок в правой части экрана (отдельное подокно), заявку можно размещать на нужный счет из её контекстного меню.
Для договоров можно составлять график платежей, из графика можно создавать заявки на платеж.

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

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

Да, зря, это не хейт. Когда заходишь в какую-то область, от специалистов в этой области будут придирки к терминологии - если я зайду на математический форум и начну "матрицу" называть "квадратной табличкой" или "вектор" буду называть "стрелкой", я буду готов к соответственным комментариям) Это нормальная, штатная ситуация)
Прикрепленные файлы:
2ТЗ_МНО.xlsx
44. Rustig 1596 28.10.18 09:07 Сейчас в теме
45. Rustig 1596 28.10.18 09:14 Сейчас в теме
(43) вы продемонстрировали очередное шаблонное решение.
про "матрицу" я вас не понял, да и разбираться уже неохота.
если интересно, следите за проектом - через пару месяцев выложу описание своей концепции подробно и соот-но разработку
50. chng 02.11.18 11:19 Сейчас в теме
(43)
- ИП может вводить эти планы платежей в программу сам, но на крупном предприятии это должны делать все ответственные подразделения, это довольно большой объем. В комментарии 32 говорится про сотню платежей каждый день. Без этого потребности в деньгах получаются неконтролируемые, и нельзя понять, сколько можно вывести денег.

Понимаете, не проблема ввести 100 платежей, она решается легко (с точки зрения умственных затрат) А вот проблема контролировать и управлять этим потоком.
На больших предприятиях это делается (хорошо/плохо не важно), а вот если такие потоки случаются у микро/мелких предпринимателей, то для 99,9% из них это серьезная проблема. Вот именно для таких предпринимателей и нужен платежный календарь, не как статический отчет, а как интерактивный инструмент.
51. andreypahov 02.11.18 13:48 Сейчас в теме
(50)
Платежный календарь - это не реестр платежей, он по смыслу должен быть интерактивным. Кто его делает статичным?
53. chng 07.11.18 08:59 Сейчас в теме
(51)Внезапно...
Покажите мне интерактивный платежный календарь в типовом решении 1С, вот честно, я не знаю такого. А тем белее для микро/мелких бизнесов.
55. Rustig 1596 07.11.18 09:12 Сейчас в теме
(53) Черномор, бросайте пустое дело - спорить с Андреем Панаковым. У него уже есть готовое решение, переубедить его - это дорогого будет стоить - ваших нервов, времени и как следствие денег.
56. andreypahov 07.11.18 09:56 Сейчас в теме
(53)
Насколько я знаю типовые решения 1С, в них или вообще не делают платежный календарь, или делают интерактивным. В нетиповых - честно, тоже ни в одном не помню. Возможно, что-то забыл.
46. Rustig 1596 02.11.18 00:29 Сейчас в теме
47. Rustig 1596 02.11.18 00:31 Сейчас в теме
48. Rustig 1596 02.11.18 01:09 Сейчас в теме
для истории - нашел такую разработку https://infostart.ru/public/716153/
по цене - сильно экономный вариант
Хоть я к ней не стремлюсь - и я решаю узкую задачу - все же я рад, что есть такие разработки - не сильно дорогие
52. andreypahov 02.11.18 22:38 Сейчас в теме
(48)

Это и есть наш продукт)
54. Rustig 1596 07.11.18 09:10 Сейчас в теме
(52) теперь понятна ваша позиция - скептически задаете вопросы, но не даете советов и не подсказываете. Действуете, как настоящий партизан в тылу врага. Можете больше не участвовать в дискуссии - только время занимаете.
57. andreypahov 07.11.18 11:12 Сейчас в теме
(54)

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

но не даете советов и не подсказываете.

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

Тут, имхо, основной совет и подсказка разработчику - нейтральнее реагировать на критику, даже если она есть, и уже тем более когда ее нет. А по самой программе - смотреть на требования пользователей и по ним решать задачи. Вы это пока и так делаете, не вижу каких-то нерешенных проблем.
49. genayo 02.11.18 06:51 Сейчас в теме
Альтернативный взгляд на БДДС с точки зрения "ларьков"? А что, может и взлететь, взлетела же Магазька...
58. Rustig 1596 01.06.20 22:51 Сейчас в теме
10 лет программирую в 1с, консультирую по программам, и меня всегда мучил вопрос - почему в 1с до сих пор не реализован самый базовый вариант мало-мальски финансового учета - почему до сих пор лучшие практики ведут финансовую модель в Эксель, а про 1с говорят, что его надо "пилить" и "затачивать"...
Ни в прежних программах БП 2.0, УТ 10.3, ни в новых УТ 11, БП 3.0, УНФ нет полноценного финансового учета: так чтобы было легко и удобно вводить сведения, видеть в динамике, видеть графики.
Кажется стало проясняться благодаря ребятам из
Нескучные финансы

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

Будем разбираться! :)
Оставьте свое сообщение
Вопросы с вознаграждением