Все совпадения имен и дат случайны — в статье описан собирательный образ клиента.
Предыстория. История 1. Однажды обратился клиент (на УТ 10.3):
Директор:
— Рустем, непонятно прибыльны мы или нет? Покупатели нам должны 6 млн.р., а мы должны поставщикам 5 млн.р. Непонятно, какие товары и под какие заказы у нас на складе лежит товар? При этом деньги на расч./счете есть.
— С товарами и заказами я вам помогу — есть у меня готовое решение. облегчающее жизнь продавцам: //infostart.ru/public/662365/
Установил я им эту обработку, показал отчеты по взаиморасчетам с контрагентами — тут кредиторка, а тут дебиторка — смотрите, мол, чаще, подписывайте с контрагентами акты сверок чаще. Знаю, стало легче решать оперативные вопросы по заказам. Следующие несколько месяцев они не обращались. Через полгода:
— Рустем, давай вернемся к прошлому вопросу. Сейчас нам должны 12 млн. р., а мы должны 10 млн.р. Как в 1С посмотреть прибыльны мы или нет?
— В прошлый раз суммы были меньше, и я думал, что после моей консультации, задолженность будет уменьшаться, что вы начнете работать с дебиторкой. А как такое возникло, что задолженность увеличилась?
— Проекты крупные, оплаты с отсрочкой платежа, обороты растут.
— В 1С нет готового отчета, чтобы увидеть — прибыльны вы или нет. А сейчас вы как анализируете это? Чем пользуетесь?
— Вот есть эксель-таблица. Все здесь веду. Вот дебиторка, вот кредиторка.Она совпадает с отчетом 1С.
— Мне надо подумать….
Думал я долго, потому что через два-три месяца собственники провели аудит, подняли вопрос об убытках и банкротстве фирмы, расстались с директором. Последние события проходили на фоне банкротства двух крупных банков, в которых были открыты расч./счета фирмы, что также сыграло свою роль.
История 2. На днях обратился клиент:
Директор:
— Рустем, ты не против подождать с оплатой услуг? У нас продажи с отсрочкой платежа, налоги только заплатили, зарплату, сервер сгорел, купили новый…
Я согласился. Но де-жавю не давало покоя — я помню, как подобное начиналось и чем закончилось — неумение прогнозировать доходность на длинном и коротком промежутке приводит к плохому результату. А главное, что для клиента при отсутствии инструмента прогнозирования, наращивать обороты чревато…
История 3. Да я и сам не знаю, какая у меня доходность на длинном промежутке. Как говорится, сапожник без сапог.
Начало. До сих пор я решал задачи, которые ставили и оплачивали клиенты. Впервые я начинаю решать задачу, которую ставлю себе сам — придумать и реализовать инструмент, который позволит понять "прибылен ли бизнес или убыточен".
Концепция проработана на бумаге — как оказалось, задача достаточно сложная, чтобы с наскоку ее запрограммировать.
Первая версия инструмента представлена в публикации в качестве концепции. Разработана на платформе 1С:Предприятие 8.3 (8.3.11.3034), на демо-конфигурации "Управление торговлей", редакция 10.3 (10.3.46.2). Файл дтшника вы сможете скачать в следующих статьях. Под данной публикацией накопилось много комментариев, которые раскрывают идею работы.
Итак, создан документ "График оплат", с помощью которого фиксируются планируемые доходы и расходы (поступления и списания денежных средств). У расходов есть признак "Очередность платежа":
1. Первая очередь — так называемые обязательные платежи (налоги, банковские комиссии за ведение расч.счета и другие платежи, по которым нельзя получить отсрочку);
2. Вторая очередь — оплата поставщику и другие платежи, по которым можно получить отсрочку платежа на коротком промежутке времени;
3. Третья очередь — оплата работ и услуг, по которым можно получить отсрочку платежа на длинном промежутке времени или вовсе не заплатить (например, с чем часто встречаюсь — что можно не заплатить 1с-нику или дизайнеру — такого рода предложения я осуждаю, но для демонстрации инструмента моделирую именно этот пример).
Моделируется ситуация:
1. На сегодняшний день имеются остатки на расч/счете. Компания ждет оплаты от покупателя двумя траншами.
2. Компания должна залпатить 1С-нику за консультации.
3. В конце месяца Компания должна заплатить налоги.
Если проведены все Графики оплат, то на графике видно, что в конце месяца Компания будет в убытке.
Если предположить, что 1С-нику можно не заплатить или отсрочить оплату до лучших времен — распроведем документ График оплаты №4 — то в конце месяца Компания сможет заплатить налоги полностью и еще останется в прибыли.
Вообще, задача может иметь более широкое развитие. Как говорится, сейчас мы решаем прямую задачу. Есть еще и обратные задачи:
1) найти оптимальную последовательность списаний ден.ср. по обязательствам так, чтобы не выходить за ноль. В нашем случае, с учетом очередности платежей алгоритм должен будет предложить пользователю — перенести оплату услуг 1С-ника на ноябрь, при условии, что будут новые поступления от клиентов.
2) для стартапов — оценка инвестиций, поиск точки безубыточности, построение бизнес-плана.
Функционально программа будет дорабатываться — будут представлены разные версии. Я буду продолжать разбираться в теме бюджетирования — описывать суть бюджетирования, его недостатки и почему это не подходит мне.
Все совпадения имен и дат случайны — в статье описан собирательный образ клиента.
См. также:
Как эффективно использовать Инфостарт NEW!
Список реализаций + структура подчиненности + реестр документов SALE’1sm
Список заказов поставщикам + структура подчиненности SALE’1sm
Список заказов покупателей + структура подчиненности SALE’1sm
Договоры для 1с-ника ТОП-скачиваний
Сетка расписания (Планировщик) нестанДАрт
Два механизма, которые ускорили работу бухгалтеров в 1С нестанДАрт
Расчет банковских (рабочих) дней нестанДАрт
Шаблоны кода в режиме 1С:Предприятие SALE’1sm
Доработка конфигурации Конвертация Данных
Планирование платежей. Прогнозирование прибылей и убытков
Ввод показателей план-факта БП 3.0 Know-how
Инвентаризация личного опыта Для новичков 1С
Большие запросы: взгляд на проблему нестанДАрт
Технология создания коммерческих разработок Know-how
Андроид-решение для создания заказов в 1С Know-how + нестанДАрт
Печать ценников с одной и двумя ценами 55х40, 100х60, 140х200
Доработки обмена "УТ 10.3 — интернет-магазина Shop-Script"
Планирование поступлений и выплат это управление ликвидностью(платёжеспособностью) оно же бюджет движения денежных средств.
Прогнозирование прибыли и убытков это управления рентабельностью оно же бюджет доходов и расходов.
Это разные категории.
Платёжеспособность это не рентабельность, точно так же как рентабельность не спасёт от кассовых разрывов.
И без знания мат части.
Почему-то многие путают сущность бюджета движения денежных средств с сущностью бюджета доходов и расходов. В расчетном периоде может быть и убыток, но деньги на счете есть и наоборот.
Самый простой пример. Купили на все деньги товары. Лежат на складе. Денег на расчетном счете пока нет. Отгрузили товары покупателю. Прибыль появилась, а денег пока нет. И т.д.
Собственно здесь все сказано.
Попытка родить новый продукт для планирования и бюджетирования.
(Если не ошибаюсь прогноз движения ден.средств в УТ10 -реализовано)
(3) нет, вы не правы — продукта для планирования и бюджетирования не будет.
(2) многие путают. а при чем здесь это? для меня все ясно — что я хочу получить на выходе, что есть на входе. если вам что-то не ясно, задавайте вопросы, а не преждевременные выводы.
(1) ваш ответ не плох и не хорош. Ни рыба, ни мясо. Я вообще склонен думать, что вы мало в этой теме понимаете, и не видите подводных камней.
Коллеги, поясню ситуацию.
Если покупатели нам должны 12 млн, а мы должны поставщикам10 млн, при этом есть 1 млн. на расчетном счете, то однозначно ответить на этот вопрос прибыльны или убыточны нельзя ни на коротком промежутке времени, ни на длинном.
Поскольку есть еще кредиты, внешние заимствования, налоги государству, зарплата сотрудникам, аренда помещения, лизинг оборудования.
По данному вопросу теория бюджетирования не дает сиюминутный и однозначный ответ. Теория бюджетирования предлагает внедрять комплекс мер и мероприятий, с помощью которых более-менее вырисовывается картина текущего положения, прогнозируется будущее положение с учетом планов продаж, планов производства, планов закупок и других планов на жизнь. Нельзя внедрить бюджетирование за один день.
Мой инструмент не будет идти по пути теории бюджетирования.
Уметь планировать поступления и списания денежных средств можно и без знаний теория бюджетирования.
Что появилось раньше: яйцо или курица?
Также и здесь, что появилось раньше: здравое умение оперировать своими финансами или теория бюджетирования?
Простого инструмента-калькулятора как управлять расходами нет.
Я не создаю продукт по бюджетированию, я создаю инструмент, который позволит увидеть финансовое положение фирмы в разрезе движения денежных средств с учетом уже имеющихся договоренностей — кто, когда и сколько будет платить, как будет меняться остаток денежных средств на расчетном счете.
Здесь не будет планов продаж отдела менеджеров — выполнить план продаж на 100%, достигнув показателей продаж на 1 млн. руб. Для меня это называется в моей системе координат — прогнозировать будущее с учетом еще не имеющихся договоренностей. Будут достигнуты договоренности или нет — вилами по воде писано. Будут достигнуты договоренности — еще не значит, что они удовлетворят текущему положению фирмы — к примеру, что лучше: продать на 300 тыс. с отсрочкой платежа на 6 мес, но с отгрузкой товаров через неделю — или продать на 50 тыс товара по предоплате? Ответ для разных фирм и их текущего финансового положения будет разным. Но для некоторых фирм — первый случай может затащить фирму в еще более глубокую долговую яму, а второй случай заработать в текущем периоде, и возможно расплатиться по аренде без начисления пени.
Подписывайтесь на сообщения — дальше будет интересней!
ИМХО, у вас проблема подходе к разделению платежей на группы для отнесения очередям и как следствие обработка этих очередей.
Если вы посмотрите на эту проблему с точки зрения бизнеса, а не фрилансера, то поймете, что все платежи нужно разделить минимум на четыре функциональные группы(типы).
С первой группой выделенной у вас, можно согласиться. две другие неправильные по смыслу.
Рассрочка платежа, это свойство любого платежа, т.е. чисто теоретически любой платеж может быть отсрочен или разделен на части, а части могут быть оплачены до или после даты платежа. Поэтому выделять в отдельную очередь концептуально не верно.
Касательно групп, то правильней разделить платежи по типам (к терминам не стоит придираться, важна суть):
1. Основной товар — товар который приносит прибыль, не уплата по нему создает будущий финансовый провал
2. Вспомогательный товар — товар оплату которого можно двигать при расчете календаря, т.к. он не создает существенных финансовых провалов.
3. Налоги, комиссии (ваша первая группа) — не оплатишь закроют бизнес
4. Собственные нужды — платить нужно но можно управлять приоритетами…
вот как то так…
(8)Неудачно нажал на энтер и уже не отредактировать предыдущий пост.
Повторюсь, все написанное ИМХО
Указанные мной группы платежей это минимум, на который надо разделить все собственные платежи при построении очереди собственных оплат.
Любой из платежей, относится к какой либо группе считая что отсрочка или оплата частями, может производиться по любому из счетов.
Построение календаря и расчет суммы оплат на конкретную дату делать в процентном соотношении по очередям : первая группа — 40%; вторая группа — 20%; третья — 20%; четвертая 10%. (понятно что процентами можно управлять)
Используя такое правило вы легко оцениваете объем очередей на конкретную дату и легко прогнозируете провалы или пики относительно прогнозируемой суммы прихода на этот день. Собственно это и требуется при принятии решения об оплате того или иного счета из той или иной очереди.
Для более тонкого управления каждой очередью, внутри очереди можно иметь динамические приоритеты. Динамические, потому что счет попадая в свою очередь, имеет в ней низший приоритет который постепенно повышается по мере наступления контрольных сроков.
Учитывать отгрузки и отсрочки оплат собственного товара, при планировании поступлений, нужно в отдельных очередях, т.к. там тоже есть не мало своих приоритетов.
(8)
кол-во очередей пока не фиксировано, категории выделил три — исходя из своего видения ситуации. подробности будут раскрыты позже — во второй части статьи.
(8)
мой документ График оплат имеет табличную часть — в которой нужно указать достигнутые договоренности по оплате — к примеру, можно указать, что платежей будет три и в разные месяцы — нужно указать даты. Как будет корректироваться плановая информация, исходя из фактических оплат — это мы с вами обсудим в следующих частях статьи.
(8)
имея инструмент, даже тот — который я выложил — версию №1 — вы вправе делить свои платежи по любым категориям очередности оплат. я не задаю жестко — есть реквизит у платежа — который вы сами заполняете цифрой.
(9)
разделите, как вам необходимо. сейчас представлена концепция. у каждого директора будет свое видение на категории. пока что я выделил три — по приоритетам — есть две крайние точки : «нельзя нарушать сроки» и «сроки можно двигать на длинном периоде», и одна категория как бы между ними «можно двигать сроки, но на пару дней» — опять-таки по договоренности с поставщиком.
(9)
идея с процентами, озвученная вами — мне не подходит, не вписывается в концепцию, или просто я не согласен.
(9)
вообще никак не понял вас, как-то не складывается. в любом случае, если люди друг друга не понимают идейно, то пора писать примеры — так что опишите пример.
(9)
откуда у вас идеи такого рода? я не согласен с ними. такого у меня не будет. пока меня не убедят в обратном.
(9)
коллеги, я склонен думать , что вы не внимательно читаете статьи — по диагонали, что ли?
учитывать отгрузки я не буду, поясню в след. части.
отсрочки оплат соб.товара уже учтено и заложено в алгоритмы.
мне нравится, что вы начали Думать.
(9)
скажите, а вы сейчас так работаете — по такому правилу? или это лишь ваши еще не реализованные идеи? я сомневаюсь, что кто-то работает по такой схеме….
(9)
тот же самый вопрос от меня, то же самое сомнение, что кто-то так работает…. вы придумали это или взяли из жизни?
(13)
2. налоги и зарплаты — условное название; неоплатил — прикрыли контору;
3. на собственные нужды — аренды помещений,ремонты транспорт и т.п.; неоплатил — торговать негде;
я закладываю другой принцип работы с платежами:
по всем платежам сроки всегда обговариваются исходя из собственных возможностей — вы договариваетесь с покупателями и с поставщиками — будет ли это частями, какими суммами и в какие дни.
Главное, что вас это должно удовлетворять — после первого раунда — вы заносите информацию в базу в документ «График оплат» — видите финансовую ситуацию в перспективе. При этом необходимо все расходы и доходы внести в эти Графики оплат.
Если вас не устраивает ситуация, вы выходите на второй раунд переговоров — покупателей просите ускорить оплату своих товаров и услуг, поставщиков просите отсрочить оплату их товаров и услуг. Таким образом вы оперативно управляете ситуацией.
За занесение всей информации в документы График оплат отвечают ответственные: бухглатер за свое, менеджеры за свое. Руководитель собирает и видит всю информацию и видит финансовое положение.
(13)
А если товар покупается с рассрочкой: сегодня на 30 дней, через 10 дней рассрочка на 20, через 20 дней рассрочка на 10 дней. То в этом случае дата оплаты совпадет и вы должны будете заплатить одномоментно 3000 а в приходе только 1000. Вот вам и финансовая яма. Когда таких накладок много, яма становится глубже и глубже.
Да, в этом и есть сложность управления финансами, сложность решения данной задачи. И ни одна теория бюджетирования, к которой взывают первые комментаторы, не справится с этой сложностью. То есть не даст заведомо правильный и наперед ответ, как действовать или как избежать подобных ситуаций.
(13)
Да, именно шулай.
Потому что это достижимая цель.
И реально улучшит ситуацию с ведением учета и управлением финансов.
(13)
любой график оплат берется конечно же не из неба, а исходя из текущих условий и заключенных договоренностей — договориться можно обо всем. главное, внести эти сведения в документ График оплат, далее мониторить ситуацию.
Вот вы пример привели — так если использовать мою разработку, то будет следующее:
(13)
сегодня вы видите предстоящую оплату через 30 дней, через 10 дней вы видите Совпадение — так как через 20 дней вам надо заплатить уже не одному поставщику , а двум. Уже 10 дней вы начинаете реагировать!
можете перенести сроки — нужно начать договариваться с покупателями, с внешними кредиторами, с поставщиками — но ситуацию надо минимизировать в плане риска неплатежеспособности. и т.д.
(13)
Мой инструмент позволяет разбить оплату на несколько траншей.
В любом случае разбить платеж на несколько траншей — в этом и заключается одна из сторон ведения бизнеса, переговоров, оценки рисков. Мой инструмент позволит заранее спрогнозировать такую ситуацию, и более-менее объективно подойти к аргументации своих предложений по отсрочкам.
Другой вопрос, что планы должны корректироваться по достижению очередного факта платежа — и при этом возможно будут корректироваться Очередности оплат.
С этим я согласен на 100% с вами.
(13)
Коллеги, снимите маски! Казаться лучшим мне не нужно. Написал, с чем сталкиваюсь. Это реальность — что многие услуги оплачиваются чаще по факту выполнения работ и с задержкой. Товары оплачиваются чаще по предоплате.
Пример с 1с-ником показателен и настолько прост в понимании, что мне не пришлось писать столько, сколько мы с вами обсуждаем детали проекта….
(14)
по всем платежам сроки всегда обговариваются исходя из собственных возможностей — вы договариваетесь с покупателями и с поставщиками — будет ли это частями, какими суммами и в какие дни.
Главное, что вас это должно удовлетворять
Вот именно в этом и была проблема моего заказчика, работая так, но не видя всей картины (часть покупок делалась менеджерами) возникали серьезные финансовые ямы. Причем по контрольным данным для каждого менеджера(и собственника) по отдельности, все было впорядке, а по факту «конторка» в опе…
Игнорирование сути, не означает того, что ее нет. Принципы работы инструмента могут быть разными, а выбирать надо тот который определяет будет этот инструмент полезным, или удобным, или эффективным, или простым для понимания, или обладать всеми этими достоинствами…
ИМХО. Задача программного инструмента быстро и непринужденно построить картину в перспективе, по имеющимся фактам и прогнозируемым следствиям этих фактов. А уже имея такую картину, можно «правильно» оценивать условия текущих сделок. Ведь ситуация может складываться таким образом, что при кажущейся выгодности предложения сегодня, оно может быть причиной серьезных последствий в будущем. И зная об этих проблемах можно и нужно поступить так, как сегодня не кажется выгодным.
Другими словами, чтобы принимать решение об условиях сделки надо видеть общую картину. А ее отсутствие, чаще всего является главной проблемой мелко-среднего бизнеса…
(13)
Вы как будто не поняли сути моего проекта и разработки. Ну все равно спасибо за обратную связь.
Возможно никому не влетело сразу, что я тут пытаюсь сделать.
Прогнозировать приход денег не нужно — пусть прогнозами занимаются теоретики бюджетирования и астрологи.
Надо внести в базу все договоренности с контрагентами. Если у вас что-то собираются купить, и вы договорились о сроках отгрузки, то вы значит договорились и сроках оплаты. Вот эти сроки оплаты вы вносите в базу.
(13)
я правильно вас понимаю, что вы что-то подобное уже обдумывали, но еще не реализовали и готового решения у вас нет?
вообще, я тут с вами половину своей будущей статьи раскрыл. Эх…. торопите события…
(21)
Я это понял, и считаю это достаточным, вернее убедился, что этого достаточно для 99,9% сделок.
В моем случае была одна единица номенклатуры, с очень особыми условиями, но это уже глубокие частности тут неуместные…
(20)
спасибо за вопрос-комменатрий.
я уже продумал это — и нашел более-менее оптимальное решение.
ждите продолжения статьи.
Рустам, Вы в статье кругом пишете «прибыльность», но что Вы под этим понимаете, непонятно. Вы можете на словах написать формулу этой «прибыли», которую Вы считаете? Извините, я плохо разбираю рукописный почерк.
(22)
Готовое решение было написано на 5-том
Делфи, когда интернет был только по диалапу, а термин «клиент-банк» округляло глаза у айтишников того времени… То решение спасло от банкротства тех, для кого делалось…Оговорился то я как, какое Делфи, решение было написано на Турбо Паскале 5.5… Такие дела… :-)))
(25) знаете, вы задали хороший вопрос. я ждал его.
давайте я постараюсь раскрыть вообще в целом — как я рассуждаю, как общаюсь с клиентом…
когда директор (клиент) спрашивает про прибыльность, он же спрашивает о своей ситуации в целом, я понимаю что ему важно понять что-то иное, чем валовая прибыль от продажи товара…
у него есть боль, я эту боль трансформировал (перевел) в проблему, проблему — в задачу. Сейчас я не решаю какую-то формулу прибыли, и я везде писал, что нельзя сказать прибыльна или нет. И к слову сказать теория бюджетирования, которую некоторые комментаторы пытаются сюда объединить, не дает таких ответов.
(27)
Я так не понимаю.
Давайте это «что-то иное» поймем на словах.
Движение денежных средств (приход, расход), увеличение обязательств предприятия, уменьшение их же, увеличение обязательств перед предприятием, уменьшение их же. Речь про набор всех этих показателей? И только их?
Дает, но разные.
И скорее это не теория бюджетирования, а теория бух. учета
(26) ясно, вообще я жду, что спецы выложат свои решения 1с. или укажут на готовые решения 1с…
(28) ооооо, Андрей, вы судите сложно….
(28)
Мой ответ: нет.
(28)
это не при чем.
(28)
Мой ответ: дает, но разные — это не спорное моему ответу изречение. Ваше изречение усиливает мой ответ.
Дает, но разные = Не дает однозначного ответа.
(28)
мне без разницы как вы назовете этот учет. я же назову его мониторинг платежей.
(29)Вообще программные решения по данной проблеме попадались на глаза но не в 1С, а вот в 1С я не встречал ни одного дельного. Видимо мнение, что платежный календарь это «офлайн отчет», слишком устойчиво укрепилось в этой среде.
(28)
Думаю что половина собственников мало-среднего российского бизнеса, перечисленных терминов просто не поймут.
Мне например недавно формулировали проблему(от чего эта тема свежа в голове), которая звучит примерно так «… надо периодически вынимать деньги из оборота на другие цели, но собственник хочет это делать так, чтобы не убить текущий бизнес. Особенность бизнеса в том, что в день делается около сотни полных и частичных оплат по счетам». Получить объективный ответ от имеющихся коммерческого управляющего и бухгалтера-экономиста, он не может или получает отрицательный ответ.
(32)
Мне например недавно формулировали проблему(от чего эта тема свежа в голове), которая звучит примерно так «… надо периодически вынимать деньги из оборота на другие цели, но собственник хочет это делать так, чтобы не убить текущий бизнес. Особенность бизнеса в том, что в день делается около сотни полных и частичных оплат по счетам». Получить объективный ответ от имеющихся коммерческого управляющего и бухгалтера-экономиста, он не может или получает отрицательный ответ.
Если заменить «обязательства» на «кредиторскую» и «дебиторскую» задолженность — я думаю, поймут все или почти все.
(30)
мне без разницы как вы назовете этот учет. я же назову его мониторинг платежей.
платежи — это выплаты и поступления денег. А Вы писали, что еще и дебиторку и кредиторку мониторите, правильно?
(34) нет, так я не писал. найдите, пож-та, мою цитату, которую мне нужно прокомментировать для вас.
мне кажется, я очень подробно написал в статье, еще детальнее ответил на вопросы Черноморнефтегаза.
(33) нет, не получится у вас так… 🙁
(33) я больше чем уверен, что вы пытаетесь угадать решение этой задачи, нежели ее решали и у вас есть практический опыт решения такого вопроса, как
(32)
в УТ 10.3 нет механизма, который позволит понять ситуацию и сколько денег можно вытащить на новые проекты — так называемые внутренние инвестиции, реинвестиции прибыли.
думаю, что в унф и ут 11 и ерп 2.0 этого тоже нет…хотел бы услышать спецов, кто работает с ерп 2.0, ут11, унф… жду спецов и их мнение
(37)
Если Вы посмотрите на комментарии еще раз, Вы увидете, что я вообще не комментировал задачу из п.32.
И не угадали: платежный календарь мы автоматизируем постоянно. Но на более крупных бюджетах — примерно на проектах от 200 тыс. руб. Ничего не имею против бюджетных решений
(38) прошу прощения, если что
1) я ответил вам на пост 33.
мне показалось, что вы высказали свое мнение по вопросу.
я думаю, что оно некорректное.
2) вы задаете наводящие вопросы про прибыльность, дебиторку, кредиторку — да, исходя из ваших вопросов, я понимаю, что вы решали другую задачу.
и я считаю, что вы теперь думаете, что текущая постановка из п.32 подходит под рамки ваших решений. я сразу сказал вам, что не пытайтесь — не получится.
подобную задачу вы не решали, иначе бы не задавали наводящих вопросов про прибыльность, дебиторку, кредиторку.
3) платежный календарь не стоит 200 тыс, видимо у вас проект глобально был или сейчас связан с другой задачей, в которой автоматизация платежного календаря занимает 10-ое место.
я хотел бы по существу вопроса вести диалог. просто с вашими вопросами или комментариями диалог вести сложно — к примеру, ваше сообщение
(33)
подразумеваю что вы сталкивались с другими задачами.
лучше опиши свой опыт, приложите скрины.
тут уже задали тон переписки теоретики бюджетирования, и возможно я вас зря и преждевременно отнес к хейтерам. так что «если есть возможность дружить — зачем воевать ?»
Пропустил вопрос заданный ранее…
(12)
скажите, а вы сейчас так работаете — по такому правилу? или это лишь ваши еще не реализованные идеи? я сомневаюсь, что кто-то работает по такой схеме….
В неявном виде финансовый управляющий всегда принимает решение, оплатить новый товар или часть 1Снику за работу… 🙂 Если оплат много, то всегда получается что часть идет на товар, часть на содержание конторы, часть на штрафы — вот вам и проценты в неявном виде.
Но основная идея процентных установок для очередей, заключалась в том чтобы автоматизированно предлагать ведомость оплат на сегодня.
Программа получала выписку из банка, и на на сумму средств на расчетном счете, на основании процентов выбирала из очередей счета и частичные суммы которые надо оплатить.
Управляющий открывал такую сформированную ведомость и рассматривал что предложила программа. Иногда предложенное не устраивало и ведомость формировалась в ручную, но чаще в нее просто вносились изменения в предложенный программой вариант. Кстати даже полное ручное формирование ведомости заключалось в том, что в нее заносились обязательные счета и если денег на Р/С было больше, то дальше нажималась кнопка заполнить из избранной очереди или из всех очередей.
Второй эффект мне объяснил сам заказчик уже разруливая свои проблемы.
Правило для очереди на собственное обеспечение, позволило обязать управляющего не тратить все на товар, с которого он получал свои бонусы, но и заботится о состоянии торговых точек оплачивая всякие мелкие ремонты, торговое оборудование и прочие расходы без которых точка превращается в сарай в котором никто работать не хочет.
(39)
Спасибо, Рустем. Сразу не успеваю, в течение трех дней постараюсь написать подробный ответ.
(40) возможно мы с вами обсуждаем одну и ту же идею — разбить каждое списание ден.средств на несколько траншей — я как раз заложил такую возможность в разработку — на видео и на картинках видно, что у документа График оплат есть табличная часть, в которой указывается порядок платежей — в какой день какая сумма — при этом траншей может быть несколько. Заложить в табличную часть кнопку и алгоритм автоматического разбиения по процентам , к примеру, 40%, затем 60% — это уже плюшки сверху и не составит труда — а также можно и вручную посчитать — в любом случае это не может быть решено в одностороннем порядке — такое разбиение надо согласовать с поставщиками, и уже после , имея договоренность на руках в устной форме или на бумаге, прописать график оплат в несколько этапов.
спасибо
(43) вы продемонстрировали очередное шаблонное решение.
про «матрицу» я вас не понял, да и разбираться уже неохота.
если интересно, следите за проектом — через пару месяцев выложу описание своей концепции подробно и соот-но разработку
(0) в копилку идей и концепций:
также в копилку
для истории — нашел такую разработку
по цене — сильно экономный вариант
Хоть я к ней не стремлюсь — и я решаю узкую задачу — все же я рад, что есть такие разработки — не сильно дорогие
Альтернативный взгляд на БДДС с точки зрения «ларьков»? А что, может и взлететь, взлетела же Магазька…
(43)
Понимаете, не проблема ввести 100 платежей, она решается легко (с точки зрения умственных затрат) А вот проблема контролировать и управлять этим потоком.
На больших предприятиях это делается (хорошо/плохо не важно), а вот если такие потоки случаются у микро/мелких предпринимателей, то для 99,9% из них это серьезная проблема. Вот именно для таких предпринимателей и нужен платежный календарь, не как статический отчет, а как интерактивный инструмент.
(50)
Платежный календарь — это не реестр платежей, он по смыслу должен быть интерактивным. Кто его делает статичным?
(48)
Это и есть наш продукт)
(51)Внезапно…
Покажите мне интерактивный платежный календарь в типовом решении 1С, вот честно, я не знаю такого. А тем белее для микро/мелких бизнесов.
(52) теперь понятна ваша позиция — скептически задаете вопросы, но не даете советов и не подсказываете. Действуете, как настоящий партизан в тылу врага. Можете больше не участвовать в дискуссии — только время занимаете.
(53) Черномор, бросайте пустое дело — спорить с Андреем Панаковым. У него уже есть готовое решение, переубедить его — это дорогого будет стоить — ваших нервов, времени и как следствие денег.
(53)
Насколько я знаю типовые решения 1С, в них или вообще не делают платежный календарь, или делают интерактивным. В нетиповых — честно, тоже ни в одном не помню. Возможно, что-то забыл.
(54)
У меня нет цели обсуждать чужие продукты, чтобы рекламироваться. Вы просто негативно реагируете практически на любые комментарии и вопросы — принимаете в штыки, думаете, что к Вам относятся скептически, задают негативный тон.
А что советовать и подсказывать, пока не уточнил предметную область продукта?
Сейчас она более ли менее ясна — вроде хороший продукт.
Нечего подсказать. Ну разве что постепенно уходить от планирования поступлений по датам — я уже написал, что с ним обычно есть трудности.
Тут, имхо, основной совет и подсказка разработчику — нейтральнее реагировать на критику, даже если она есть, и уже тем более когда ее нет. А по самой программе — смотреть на требования пользователей и по ним решать задачи. Вы это пока и так делаете, не вижу каких-то нерешенных проблем.