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

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

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

Думаю более менее понятно сообществу
Основная задача на начальном этапе - ликвидация и управление кассовыми разрывами

Как мне неспециалисту видится

Компания занимается оптовой торговлей
Соответственно все сроки поступления денег по отсрочечным отгрузкам известны, известен план закупа (то есть стоимости поставок, сроки-даты, авансовые платежи), объемы продаж и объемы закупов за месяц-квартал прогнозные тоже вообщем есть, в текущем оперативном режиме известны фактические данные по отгрузкам и закупам, известен фот, прочие регулярные затраты - закуп материалов, расходников и прочее, график уплаты налогов и их величина или пронозируемая и /или фактическая
Далее типа забиваем это все в прогу или подсасываем из других прог.
В итоге имеем некий платежный календарь (или чтото иное?) где видим картину и проблемные места
И начинаем это както использовать
Например постоянный клиент на месяце отсрочки звонит и говорит типа что трудности и долг в два ляма который должен заплатить просит еще на месяц отложить - вводим в прогу сдвиг долга и видим что наступает (_._) или не наступает. Или новый клиент обсуждаем условия на первую отгрузку ему аналогично, просит отсрочку месяц, забиваем отгрузка на лям, отсрочка месяц - видим что нифига, или предоплата или отсрочка неделя.
На каждую дату должны видеть сколько денег надо на эту дату по плану
Каждый день сегодня ждали денег от клиентов - не пришли - получаем новую картинку с новыми рисками. При этом надо както учесть что плановая дата поступления денег она почти всегда размыта плюсминус несколько дней, а план траты денег - он может быть жесткий по какимто статьям - налоги, а по каким-то тоже плюсминус пару дней

Както вот так
Думаю что задача широко известная
И неоднократно автоматизируемая
Но! Хочется все это чтобы было попроще и внятнее для тупых
Спецов с квалификацией вообщем нет
Но задачу решать хотят

То есть как всегда все

Куда смотреть в какую сторону и какие продукты?
Мегапродукт для целого холдинга не хотелось бы - его тупо не осилят...
Ибо когда надо типа но сложно то ну его нафиг, будут и дальше в экселе колбасить. Считаем что вопросы получения данных из разных источников решены.

Делал я как то планирование одной крупной фирме...
Мой тебе совет : побереги нервы и не лезь ты в это дело.

Я такое в упп делала. Штатные заявки и свой самописанный календарь.

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

(2)  давно както делал простой такой календарь http://catalog.mista.ru/public/16293/
Можно в него все запитывать подсасывать дальше
Но велосипеды строить неохота
Отстоипенило мне программирование уже
Хочу быть столбовым дворянином

(1)  скажем так что контора далеко не крупная
То есть объемы  всей этой движухи вролне обозримые

А нервы мне беречь не для кого
Так что я не боюсь
Наоборот хоть какоето развлечение

Это называется казначейством.

(5) В чем учет ведете?

(7)  см в топике - в экселе
Учетом это я бы не назвал...

(8) Основной учет в чем?

(8) казначейство у многих в экселе :)

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

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

Из того что мне попадалось на глаза
- соответствующий блок а 1с управляющем
Если совсем все мутно будет - попробую его

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

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

(11) Лоскутный учет в этом плане крайне хреновый. Часть платежей у вас в ТиС, часть в бухии будет. Реальный же поток денег цельный.

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

(13) Не взлетит. Без привязки к учету казначейство является фикцией.

(13)  деньги с кондачка не выдаются
Все траты так и делаются - по крайней мере у нас в техотделе потребности в деньгах на закуп мы всегда подаемозвучиваем заблаговременно

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

(14)  про реальный пток - считаем что не проблема выдрать нужные цифры из бухии и тиса - пробле мы не представляет

И сам ты овно мамонта

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

Считаем что интеграцию с тисом сделаем, правильные цифры получить не проблема

Вот такое в ЕРП 2 есть: https://www.dropbox.com/s/k2881lnau327gs1/Untitled%20(7).png?dl=0

https://www.dropbox.com/s/k2881lnau327gs1/Untitled%20(7).png?dl=0

http://www.dropbox.com/s/k2881lnau327gs1/Untitled%20(7).png?dl=0

(16)  пока проблем не вижу
Все так и есть на данный момент

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

(17) // Считаем что интеграцию с тисом сделаем

Ну вот и сделай интеграцию Документооборотов с тисом. И храни в докментообороте срезы актуальных данных для казначеев.

(22) https://www.dropbox.com/s/k2881lnau327gs1/Untitled%20(7).png?dl=0

это что ль?

(22)  покажи картинки лучше если можно ссылки на почту [email protected]

(25) https - вот с этого места строку в браузер обрежь и увидишь

(23)  для такой задачи надо документооборот поднимать? Попроще продуктов нет?

(27) с фига ли его поднимать? это самое простое, что можно поднять :)))

(17) Насчет сосать - не сомневаюсь :)

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

Коллега, Вы вероятно не совсем вникли во всю глубину задачи. Если делать по уму, и не поделку, то это вполне солидная задача.

(29) все правильно! именно так все и хочется!
и если бы я не вник во "всю глубину задачи" - я бы даже не заходил сюда ;-)

поэтому и пытаюсь понять - во что это выльется.

"И как ставить в платеж в план, не видя фактических остатков на счетах да еще с учетом уже запланированных заявок?" - именно!

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

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

(29) объемы (по количеству движений) - !совсем небольшие! (поэтому как раз самое время тренироваться).

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

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

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

(32) Надыбайте БиТ-финанс для бухии и подсмотрите там подсистему казначейства. Она имеет минусы в виде относительно относительно слабой привязки к основному учету, но Вам как раз это и нужно. А лучше вообще прикрутите ее к бухии, но плановые поступления туда втаскивайте из ТиС. Остальное все в бухии будет жить. При это исполнители казначейства бухучет вообще могут не видеть. Только казначей и бухгалтер на банковских операциях.

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

как раз и решается простыми словами "бизнес-процесс"

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

А вот по поводу решения под "солидную задачу" : так каждый меру солидности видит со своего болота и хвалит каждый кулик свое болото. В максимуме, даже в этой ветке уже озвучили - в (18) ERP2 .

Чем больше солидности, тем больше обвесок из кучи, без которой вся эта "солидность" с места не стронется.

(33) О, номуль! так вполне устроит!

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

А основные трудности при внедрении типа "0" - с чем столкнуться придется?, я так полагаю - вопросы коммуникации и регламентирования финансовой деятельности..?

(37) Трудность только одна - регламент. Тут уже халява типа позвонить Мане и попросить оплатить не прокатит. На любой платеж должны быть заявка. И каждая заявка должна быть утверждена. Или если реестр платежей согласован, то впихать туда внеплановую заявку без полноценного согласования не получится. Или если используются лимиты, то сверхлимитный платеж блокируется до отдельного его согласования. Это вызывает у пользователей когнитивный диссонанс. Типа "Было так удобно, а тут наворотили какой-то хрени!". Ну и типовой шантаж "Нам некогда! У нас продажи упадут! Мы не заплатит вовремя налог и на штраф попадем!".

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

(38)  понял
Спсб

А у вас какая система используется?

(39) БиТ-финанс для УПП. Но и родную УПП-шную в свое время применяли. В чем-то она попроще, в чем-то получше.

(38)  расход с рублевого счета на покупку валюты - тоже с заявкой?

(41) Да. Такие заявки имеют признак "казначейская". И по ним еще плановые поступления на валютный счет формируются обработкой.

А мягкий вариант возможен?
Когда использование заявок на расходование - минимально или отсутствует - то есть по факту просто регистрируем

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

(43) "По факту" вы все видите в анализе движения денежных средств. Казначейство тогда вообще на фиг не нужно. Оно по определению является планированием.

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

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

(44) ""По факту" вы все видите в анализе движения денежных средств. Казначейство тогда вообще на фиг не нужно. Оно по определению является планированием."
- ''// как a пофакту увижу ожидаемые поступления? и ожидаемые расходования? "по фактиу" я имею в виду - что расходование ДС сосбтвенно есть сразу и заявка на это расходование и собственно само расходование. если можно обойтись вообще без заявок - то на начальном этапе ок.

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

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

(46) Да. Вероятно с утверждением ее руководителем подразделения и финансистом - маршруты согласования в каждой избушке свои.

(46) Админ не должен думать о нале или безнале, он инициирует потребность и - возможно - владеет информацией о зависимости поставки от типа платежа

(46) под такие небольшие наличные суммы резервируют, как правило. Ну и в любом случае, пишется и регистрируется где-то. Вот зря документооборот боишься посмотреть :)

(48) Должен. Он определяет потребность. А вот дальше не факт, утвердят ли ее в таком виде или предложат безнал - это уже вопрос процедуры.

Смотрели своей конторой БИТ Финанс недавно.

Мне понравилось. Накручивается на БП30 либо как самостоятельная ИБ (либо на еще какие-то конфы). Три разные поставки по полноте функционала (подробности не помню).
Довольно приятный и гибкий механизм у них получился я считаю.
Есть мобильное приложение.

Но у меня финик упоротый, поэтому решили писать велосипед. Велосипед уложился примерно в 100 тыр. Единственное принципиальное преимущество нашего велосипеда - это распределение внутригрупповых платежей. Но это как бы можно было и на БИТ накрутить ИМХО.

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

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

Есть еще у Раруса Управление корпоративными финансами. Это прямой конкурент БИТ Финанс. Рекомендую покурить все продукты.

Обе конторы предлагают удобный демо-доступ. Можно просто залить какие-нить данные из БП 3.0 в демку и покрутить её пару недель и станет понятным - оно вам нужно или нет.

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

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

Понял
Спсб за инфу

Насчет политической воли - это я в курсе, проходил не раз
Тут либо проблем не будет либо проекта не будет
Возможен и третий вариант - я буду с деньгами, а их политическая воля к моим деньгам не подвязана ;-)

Но велосипед пилить не хочется. Поэтому еонечно лучше чтото типовое

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

К тому же с отрывом от основного учета как вы узнаете куда деньги делись? Ну вот Вася взял подотчет из кассы 150 тысяч. По какой статье программа должна провести эти суммы? Хорошо когда Вася берет после трат, и он знает куда он потратить, а если берёт авансом и он еще сам точно не знает сколько и по какой статье?

Или к примеру вы оплатили ООО "МТС" некую сумму авансом, как узнать сколько пошло по статье "интернет", а сколько по статье "Телефон"?

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

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

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

P.S. У нас в программе это реализовано сто лет назад в виде контроля бюджета . Т.е. 2 документа. Планирование и Расход (с контролем при проведении), которые заполняются в ручную + отчет План-факт для контроля.
А финпланирование - грубо говоря с утра посмотрели деньги на счету, сформировали отчет "за чей счет банкет" (показывает разницу между 41 и 60, т.е. оплачиваем в первую очередь тем поставщикам чей товар продан), раскидали деньги - вот и все финпланирование

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

(59) "Хорошо когда Вася берет после трат, и он знает куда он потратить, а если берёт авансом и он еще сам точно не знает сколько и по какой статье? "
- есть статья "хрен знает на что"...

(59) "Или к примеру вы оплатили ООО "МТС" некую сумму авансом, как узнать сколько пошло по статье "интернет", а сколько по статье "Телефон"?"
- "телекоммуникационные услуги" и все. если  телефон и инет будут составлять такую величину что это критично для бузинеса - я думаю найдут и во время аванса возможность узнать/указать куда именно

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

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

- ну, я вообчем самостоятельно настроил список статей ДДС достаточно вменяемый для нужд БИЗНЕСА
(
условно:
- оплата поставщику: Постоянные (основная деятельность)
- оплата поставщику: Постоянные (разовые)
)

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

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

(66) ну следует думать, что в экселе у них уже хотя бы пара-тройка сотен статей есть, просто потому, что иначе им не было бы повода ныть, что эксель их не устраивает :)

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

(50) Первое и второе предложение как связаны?

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

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

(70) "Имей ввиду, что эксель переплюнуть тяжело с точки зрения удобства рядового пользователя.
В грамотных руках эксель очень мощная программа. " - бг) на моей практике, грамотных пользователей экселя было всего 3 человека за 10 лет. Судя по возникшей проблеме, в конторе у    Злопчинского таких не наблюдается. Иначе вопрос не возник бы)

(0) хотелось затроллить Злопчинского на тему его счастья на 7ке, но я съел такое вкусное мороженко, что подобрел и отпала охота драконить)

(72) ладно, отмазка принята... ;-)

(61) Счастливые люди, со всякими госконторами дел не имеете. У них просрочка оплаты 30-60 дней считается нормой... Собственно, на этом идея учитывать планируемые поступления денежных средств и закончилась. А для планирования расхода - БИТ-Финанс. У нас программист по бухгалтерии в одно лицо внедрил за месяца 3 где-то, 2.5 года работает вроде...