Как планируются предоплаты?

[glibs]

Цитата:

Изначально опубликовано mazzy
Закупка. Закладка Цена/Скидка
Поле график

После установки занчения в это поле
можно воспользоваться верхней кнопкой Настройка \ График платежа.

По умолчанию, графики платежей выключены в функциональных ключах.
Включи и попробуй.

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

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

А у тебя работает? Может, просто уже поздно?

[Pavel]

Привет,

Цитата:

Изначально опубликовано glibs
Погоди. Написать отчет ума слишком много не нужно. Хотелось бы для начала разобраться, что было задумано самим Навижином.

Вряд ли тебе это поможет, однако (сейчас нет под рукой Аксапты, посмотрел как Конкорде та же самая функция работает):
1) Создал закупку 12-09-2002, указал дату поставки 15-09-2002, условие оплаты не проставил. Рассчитал потребность. Результат - оплата планируется на дату поставки 15-09-2002
2) При расчете потребностей в ДС в параметре «Поставка – Фактуры (дни)» указал значение «-5». Результат – оплата планируется на пять дней ранее даты поставки.
3) Указал в закупке условие оплаты – 10 дней. Рассчитал потребность. Результат – оплата планируется на 25-09-2002.
4) Указал в закупке условие оплаты – 10 дней. При расчете потребностей в параметре «Поставка – Фактуры (дни)» указал значение «-5». Результат – оплата планируется на 20-09-2002.

Работает более, чем понятно.
Вопрос: у тебя временной параметр по планированию есть (завтра посмотрю сам в Аксапте).

Цитата:

Изначально опубликовано glibs
Не обижайся. ОК? Просто я не программист. Я в экономическом ВУЗе учился.

Уважаю такой подход. Иначе, зачем покупать «систему с 10000 функций», чтобы самим что-то "изобретать".
Однако, позволяем себе «поправлять» где надо, потому что хорошо знаем и бизнес процессы, функциональность и технологию.

С уважением.

[komar]

Цитата:

Изначально опубликовано glibs

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

Попробуй старые описания посмотреть, по-моему в доке к 2.1 они были.

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

[glibs]

Цитата:

Изначально опубликовано komar
Попробуй старые описания посмотреть, по-моему в доке к 2.1 они были.

Эх... не застал я 2.1.

Это в международной или в российской документации? И ты про графики вообще или про возможность формировать график с указанием конкретных дат (в Заказах, Закупках и Текстовых фактурах) указанным Mazzy способом. Меня интересует именно последнее (в прошлом постинге я это не четко сказал).

[komar]

Я про графики вообще. Да там тоже достаточно поверхностное описание. То есть на что какой параметр влияет все равно не написано нигде.

[mazzy]

Цитата:

Изначально опубликовано glibs
График оплаты сам по себе на ПДДС у меня так и не повлиял.

Проверил. Действиетльно не повлиял. Забавно. Надо думать. Хочется программировать, аж руки чешутся Пока бью себя по рукам.

Цитата:

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

Хм... При отфактуровке? Разве?
Вроде При генерации платежа. ... Проверил. Точно при генерации платежа.

[glibs]

Цитата:

Изначально опубликовано mazzy
Хм... При отфактуровке? Разве?
Вроде При генерации платежа. ... Проверил. Точно при генерации платежа.

Может быть. Я с платежами толком пока рзобраться не смог. А как в Заказах и Закупках платежи генерируются? Есть ли это в доке? Или я что-то недопонял?

Цитата:

Изначально опубликовано mazzy

Проверил. Действиетльно не повлиял. Забавно. Надо думать.

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

Пример. Предположим мы планируем закупить 2 шт. чего-то 01/03 на общую сумму 100, например долларов. Предположим также, что график оплаты у нас такой (максимально простой): 50% на следующий день, 50% еще через день.

Это нам дает вот что. Предположим, что 01/03 нам приходит 1 шт. чего-то и мы это отфактуровываем в этот же день (50 долларов). Система на основании графика оплат генерирует две открытые проводки с датой оплаты 02/03 и 03/03 по 25 долларов. Допустим, что 05/03 пришла вторая шт. чего-то. Будет еще две открытые проводки по 25 долларов 06/03 и 07/03.

И как такое в ПДДС предугадать?

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

В голову приходит другая идея - накидать в форму Заказа/Закупки отдельную группу параметров для описания ожидаемого графика платежей. Например, Условия оплаты = 0 дней, прогноз двжения средств = -3 дня, что должно означать, что по Закупке (к примеру) платеж ожидается на 3 дня раньше, нежели отфактуровка. Возможен вариант даже для постоплаты:Условия оплаты = 20 дней, ПДДС = -3 дня, что будет означать, что деньги для оплаты задолженности понадобятся через 17 дней после отфактуровки. Отдельно можно сделать и многоэтапные оплаты. Кажется, Pavel был прав. Да и в Конкорде, я так понимаю, такая возможность заложена.

Но тут есть другой конец палки. Эти параметры же кому-то придется вводить каждый раз. Информация по ПДДС сосредоточена у финансового директора, а с Заказами/Закупками работать должен менеджер по Закупкам (Продажам).

Еще подумаю.

Уже подумал. Условия оплаты и пр. можно повесить на договор. Думаю, так будет наиболее логично. И менеджера по продажам напрягать особо не придется. Может получиться, что "и овцы целы и волки сыты". Классную функциональность с договорами придумали! До сих пор не нашел ничего, к чему бы можно было придраться с идеологической точки зрения.

Цитата:

Изначально опубликовано mazzy

Хочется программировать, аж руки чешутся Пока бью себя по рукам.

Аналогично. Да уж. И захотелось же мне во всем разобраться. Расстроился я. Что-то пока все слишком мрачно. Похоже, нужно будет доработать. Только сначала нужно определиться, как именно сделать. Ну и желательно, чтобы это делал Большой Навижин, а не все по отдельности.

[komar]

Вот еще один товарищ оценил твою идею (про модуль договоров)...

[mazzy]

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

Цитата:

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

Расскажите про договора. Или ссылку дайте, плиз.

[glibs]

Цитата:

Изначально опубликовано komar
Вот еще один товарищ оценил твою идею (про модуль договоров)...

А можно с этого момента со всеми подробностями. Для тех, кто не в курсе. А что, договора уже в модуль оформили?

[ldv]

Цитата:

А что, договора уже в модуль оформили?

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

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

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

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

[glibs]

Цитата:

Изначально опубликовано mazzy
Расскажите про договора. Или ссылку дайте, плиз.

Я так понимаю, с выходом SP4 Final Release данный вопрос уже утратил свою актуальность.

Я тут еще хотел несколько проблем поднять.

А существуют ли причины, по которым:

1. В ПДДС попадают только открытые проводки с датой не меньшей текущей. Открытая проводка по фактуре с датой оплаты на вчера в сегодняшний ПДДС не попадет. А если мы ее не оплатили вовремя?

2. Почему в ПДДС включаются неотфактурованные количества в Заказах, Закупках, Текстовых фактур, но не включаются созданные, но не разнесенные Счета-фактуры поставщиков.

По последнему вопросу у меня возник еще один вопрос. Существует ли стандартное решение для следующей ситуации?

Предположим, у нас заключен с неким поставщиком договор на аренду какого-нибудь помещения (офисного или производственного). В договоре предусмотрено внесение платежей по предоплате (до отфактуровки, т.е. акта). Задачи:

1. Не забыть о том, что в час «Х» нам нужно что-то платить.

2. Планировать подобного рода платежи в ПДДС.

Как я уже заметил, ввод платежа в Журнал счетов-фактур (поставщиков) не обеспечивает попадания суммы в ПДДС. Да и условий для предоплат там все равно нет.

Пробовал создать номенклатуру с типом «Услуга», планировать ее в Сводном планировании и пытаться на ее основе создавать Закупки с целью напоминания, но что-то совсем непонятное получилось. Похоже, что номенклатура с типом «Услуга» в Сводном планировании не учитывается. Искал на эту тему подтверждение или опровержение в доке, но не смог найти. Никто не подскажет, так ли это?

Других идей пока нет.

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

Я думал, что договора для решения этой задачи могут оказаться как нельзя кстати. В них можно было бы указывать не только сумму, но и график оплаты. А потом на это смотреть как с точки зрения того, что, когда и кому нужно не забыть проплатить (как можно смотреть открытые проводки по дате «оплатить до»), так и на предмет ПДДС (в смысле графика платежей).

Mazzy, у тебя есть идеи/информация по этому поводу?

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

Заранее всем спасибо.

[mazzy]

Цитата:

Изначально опубликовано glibs
Я так понимаю, с выходом SP4 Final Release данный вопрос уже утратил свою актуальность.

А ты оптимист

Цитата:

Изначально опубликовано glibs
А существуют ли причины, по которым:
1. В ПДДС попадают только открытые проводки с датой не меньшей текущей.

Открытая проводка по фактуре с датой оплаты на вчера в сегодняшний ПДДС не попадет. А если мы ее не оплатили вовремя?

Хороший вопрос. Непонятно.
Вообще реализация классов LedgerCovTotal и LedgerCurrencyRegUpdate
довольно странная.
Надо заметить, что дата проверяется не системная, а рабочая Аксаптовская.
Что будет, если расчет потребности запустят двое с разными рабочими датами?

Цитата:

Изначально опубликовано glibs
По последнему вопросу у меня возник еще один вопрос. Существует ли стандартное решение для следующей ситуации?

Предположим, у нас заключен с неким поставщиком договор на аренду какого-нибудь помещения (офисного или производственного). В договоре предусмотрено внесение платежей по предоплате (до отфактуровки, т.е. акта). Задачи:

1. Не забыть о том, что в час «Х» нам нужно что-то платить.

2. Планировать подобного рода платежи в ПДДС.

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

Цитата:

Изначально опубликовано glibs
Как я уже заметил, ввод платежа в Журнал счетов-фактур (поставщиков) не обеспечивает попадания суммы в ПДДС. Да и условий для предоплат там все равно нет.

Да уж, чем дальше тем чудесатее и чудесатее.
А в нормальных закупказ и заказах устновленная дата "Оплатить до" также не действует на ПДДС.

Цитата:

Изначально опубликовано glibs
Mazzy, у тебя есть идеи/информация по этому поводу?

Насчет договоров в Аксапте ничего толкового я не видел.
Знаю только, что в исходной версии такого понятия нет.
А вот с СП4 надо будет еще поковыряться.

Цитата:

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

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

Действительно, очень интересно.
Если насобираешь, что-нибудь интересное, то дай знать, плиз.

Спасибо за хорошую идею с депозитом и кредитной линией.

[komar]

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

[Ted]

Цитата:

Изначально опубликовано glibs


Хотел ввести условия платежа с отрицательным количеством дней – ругается. Принимаются только положительные значения. Других путей в голову не приходит.
Глеб

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

[glibs]

Цитата:

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

М-м-м-м... Да.

Делов то.

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

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

Очевидно, что часть вопросов снимается. Остается необходимость решения проблемы включения в ПДДС планируемых оплат, если они будут осуществляться поэтапно; планирование закупки услуг (как финансовое, так и просто чтобы не забыть вовремя заплатить); и вопрос почему открытые проводки берутся в ПДДС только если дата "оплатить до" не меньше текущей.

Спасибо!

[mazzy]

Спасибо.
Действительно красивое решение.
Действительно надо проверять.

Вот найти бы все таки описание процедуры, которая задумывалась.
Сейчас рою в документации к Аксапте 3.0. Пока не нашел...
Если и там нет, то придется проверять... Времени безумно жаль.

[glibs]

Цитата:

Изначально опубликовано mazzy
Насколько я понимаю, это должны быть закупки со статусом подписка.

А что дает «подписка»? У меня в Закупках что подписка, что не подписка – ПДДС строится одинаково. Точнее разницы не заметил.

Еще вопрос. Почему при расчете ПДДС заказы включаются с датой, указанной в заголовке заказа, а Закупки – с датой, указанной в строке закупки? И далее. Если в строке Закупки дата не указана, то берется дата из заголовка Закупки. Если и там ее не указать, то текущая дата. Если же в заголовке заказа не указать дату, то берется текущая независимо от наличия/отсутствия даты в строке Заказа.

[mazzy]

Забавно.
А что говорит Навижин?

[glibs]

Цитата:

Изначально опубликовано mazzy
Забавно.
А что говорит Навижин?

Ничего не говорит. Я лично пока не спрашивал. Хотелось бы пока самому разобраться с методологией. Ну и потом в 2.5 Большой Навижин уже ничего делать не будет (это мое личное мнение, но я почти уверен). А российский… попробую подождать 3.0. И еще я нашел на technet’е статьи и форум. Попробую пока там посмотреть. Если не поможет, тогда придется.

3.0 я пока не смотрел. Вчера скачал немного доки. Там изменений в ПДДС не видно. Описание ПДДС на уровне методологии и алгоритмов не нашел. Ах, как жаль! Хотя в целом дока содержит много новой и полезной методологической информации (хотя до многого я уже и сам додумался, но сколько времени на это ушло…).