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

[glibs]

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

Вопросы к знающим (в т.ч. и к Mazzy).

1. Корректна ли на ваш взгляд постановка задачи?
2. Реализуема ли она в Аксапте?

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

Заранее благодарю всех ответивших.

Глеб

[Pavel]

Привет,

Цитата:

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

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

Цитата:

Изначально опубликовано glibs
1. Корректна ли на ваш взгляд постановка задачи?

В части использования существующей функциональности - нет.
Как задача для реализации - вполне уместна.

Цитата:

Изначально опубликовано glibs
2. Реализуема ли она в Аксапте?

Да. Например, в XAL есть решение по функциональности учета и обработки счетов на предоплату (реестр, печать счетов, сводная отчетность и т.д.).

С уважением.

[glibs]

Цитата:

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

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

Цитата:

Изначально опубликовано Pavel
quote:
--------------------------------------------------------------------------------
Изначально опубликовано glibs
2. Реализуема ли она в Аксапте?
--------------------------------------------------------------------------------
Да. Например, в XAL есть решение по функциональности учета и обработки счетов на предоплату (реестр, печать счетов, сводная отчетность и т.д.).

Да? Как? (в Аксапте)

[Pavel]

Привет,

Цитата:

Изначально опубликовано glibs
Насколько понял я, на прогноз движения денежных средств влияют также введенные, но не отфактурованные заказы и закупки. Вроде проверял и это действительно так. За основу в таком случае берется дата поставки. Это же написано в доке по финансам (старой) на с. 265.

Sorry, не пользуюсь Аксаптой так "интенсивно".
Хотя, не совсем понятна связь между датой оплаты и датой поставки. Так как дата оплаты считается от даты инвойса (плюс кол-во дней по условиям оплаты), который не привязан напрямую к факту поставки. Счет на предоплату можно выставить в любой момент, и фактура может зависеть не от даты поставки, а от даты акцептования товары/услуги (переобмер, акт сдачи-приемки и т.п.).

Цитата:

Изначально опубликовано glibs
Да? Как? (в Аксапте)

"Закат солнца вручую".

С уважением.

[mazzy]

Цитата:

Изначально опубликовано glibs
1. Корректна ли на ваш взгляд постановка задачи?

Хм... казалось бы, с точки зрения российского учета вполне корректна.

Цитата:

Изначально опубликовано glibs
2. Реализуема ли она в Аксапте?

Хм...
разбиваем на две подзадачи:
1. Автоматический запрет разноски закупки, если нет предоплаты
2. "Видеть эту предоплату в графике платежей"

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

2.1. Вторая задача вполне решается стандартными средствами. Можно пользоваться прогнозами по закупке или бюджетом. Для того, чтобы прогноз или бюджет участвовал в БДДС нужно установить галочку "прогноз движения средств". Но! Здесь проявляется...
2.2. некорректность постановки. А какую дату надо ставить у прогноза движения денежных средств? Платеж может осуществляться в течении месяца, начиная от сегодняшнего дня. Если в "графике платежей" поставить сегодняшнее число, то график заведомо не будет выполнен. А если поставить число через месяц, то в течении месяца для платежа может не хватить запланированных средств

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

[glibs]

Цитата:

Изначально опубликовано Pavel
Sorry, не пользуюсь Аксаптой так "интенсивно".
Хотя, не совсем понятна связь между датой оплаты и датой поставки. Так как дата оплаты считается от даты инвойса (плюс кол-во дней по условиям оплаты), который не привязан напрямую к факту поставки. Счет на предоплату можно выставить в любой момент, и фактура может зависеть не от даты поставки, а от даты акцептования товары/услуги (переобмер, акт сдачи-приемки и т.п.).

Все просто. Пока Заказ/Закупка не отфактурованы (соответствуующие статусы на закладке Количество в строках Заказов/Закупок) они считаются такими, которые будут отфактурованы в дату поставки (либо на текущую дату, если она больше даты поставки). Условия оплаты (количество дней отсрочки) из заголовка Заказа/Закупки применяются. Отфактурованное количество - не учитываются, т.к. оно учитываются по открытым проводкам в соответствующих модулях. Там с условиями оплаты все как вы написали (могут отличаться от заголовка Заказа/Закупки).

Цитата:

Изначально опубликовано Pavel
"Закат солнца вручую".

Что, совсем вручную? Так любой дурак может. А зачем тогда Аксапта? Хочу не вручную!

[glibs]

Цитата:

Изначально опубликовано mazzy
разбиваем на две подзадачи:
1. Автоматический запрет разноски закупки, если нет предоплаты

Этого я не просил. А при чем это?

Цитата:

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

Какие они счастливые люди!

Стоп!
А нам они как продают? Обычно, вроде как по предоплате.

Цитата:

Изначально опубликовано mazzy
2.1. Вторая задача вполне решается стандартными средствами. Можно пользоваться прогнозами по закупке или бюджетом. Для того, чтобы прогноз или бюджет участвовал в БДДС нужно установить галочку "прогноз движения средств".

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

Цитата:

Изначально опубликовано mazzy
Но! Здесь проявляется...
2.2. некорректность постановки. А какую дату надо ставить у прогноза движения денежных средств? Платеж может осуществляться в течении месяца, начиная от сегодняшнего дня. Если в "графике платежей" поставить сегодняшнее число, то график заведомо не будет выполнен. А если поставить число через месяц, то в течении месяца для платежа может не хватить запланированных средств

Насчет даты - не понял. Сегодня у нас пока еще 9-е число. Предположим, вводим закупку 9 октября. Будет платиться на пять дней раньше. Это 4-е октября. Вот 4-го хотелось бы видеть потребность в денежках.

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

Хм.

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

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

Завтра продолжим. Сегдня голова уже не варит.

[mazzy]

Цитата:

Изначально опубликовано glibs
Этого я не просил. А при чем это?

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

Цитата:

Изначально опубликовано glibs
Какие они счастливые люди!
Стоп! А нам они как продают? Обычно, вроде как по предоплате.

И не говори.
А продают они там по постоплате. В кредит, в основном.

Цитата:

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

т.е. ты хочешь чтобы было удобнее?
Удобство можно и попрограммировать. Но опять же подумать как сделать это минимальными усилиями.

Цитата:

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

Могу, конечно, ошибаться... но вроде на прогноз влияет только состояние сопоставлено/несопоставлено.

Цитата:

Изначально опубликовано glibs
Насчет даты - не понял. Сегодня у нас пока еще 9-е число. Предположим, вводим закупку 9 октября. Будет платиться на пять дней раньше. Это 4-е октября. Вот 4-го хотелось бы видеть потребность в денежках.

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

Ты расписал немного другую схему. А если честно, то совсем другую

Цитата:

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

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

Цитата:

Изначально опубликовано glibs
В стандартном механизме Закупка уже отфактурована (послеоплата). Основанием для расчета потребности является открытая проводка (задолженность) по поставщику. Уйдут деньги, сопоставят оплату с проводкой - и нет потребности.

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

На БДДС влияет не отфактурованность, а сопоставленность.
Как только появятся деньги, неразнесенную закупку уже можно сопоставить.

[komar]

...хочется восполнить. На прогноз ликвидности последний раз смотрел год назад, есть вопросы:
1. После проведения операции не исчезает ли она из прогноза?
2. И текущие остатки по счетам учитываются ли?

[glibs]

Цитата:

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

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

Точно. Я в этом смысла особого не вижу. Умышленно обмануть систему все равно удасться, если права отфактуровывать есть. А неумышленно - тут как не крути - думать все равно придется.

Цитата:

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

А продают они там по постоплате. В кредит, в основном.

Я спрашивал как они продажи НАМ оформляют. Нам то они, как правило, в кредит не продают.

Цитата:

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

т.е. ты хочешь чтобы было удобнее?

Конечно хочу! Но считаю, что в данном конкретном случае речь идет не об излишнем комфорте, а о необходимой функциональности.

Цитата:

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

Удобство можно и попрограммировать. Но опять же подумать как сделать это минимальными усилиями.

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

Цитата:

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

Могу, конечно, ошибаться... но вроде на прогноз влияет только состояние сопоставлено/несопоставлено.

Не понял. Что значит "на прогноз влияет состояние"? В прогноз включаются либо неотфактурованное количество в Заказе/Закупке, либо открытые проводки (таковыми они считаются до тех пор, пока не сопоставлены). Еще есть бюджеты и пр.

Цитата:

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

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

А бухи тут причем? ПДДС и бухи - вещи разные. Тут речь идет о планировании cash flow, составлении графика платежей... Это задачи финансовых директоров и компнии (в смысле тех, кто им подчиняется - экономисты, наверное).

Цитата:

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

Сопоставь с платежом неотфактурованную закупку - и не будет включаться.
На БДДС влияет не отфактурованность, а сопоставленность.
Как только появятся деньги, неразнесенную закупку уже можно сопоставить.

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

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

Интересная деталь - в ПДДС попадают несопоставленные авансы (и послеоплаты тоже, причем и по клиентам, и по поставщикам) с датой разноски текущая и позже. Т.е. увеличиваю дату на 1 и мой аванс уже в ПДДС не попадает. А по Закупке снова возникает потребность в деньгах для платежа. Надо подумать. Может ПДДС нужно строить на дату в прошлом? Но тогда просроченные закупки и заказы смещаться не будут.

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

Еще интересней получилось, когда разнес платеж клиента. Заказ я не вводил. В ПДДС попала сумма платежа с отрицательным знаком - это потребность в деньгах!? Т.е. она должна была сбалансировать планируемый заказ, который бы породил в ПДДС такую же сумму, но положительную.

Получается, ПДДС идеологически не готов работать с предоплатами.

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

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

Что на это скажешь?

[glibs]

2 komar

1. Что означает "После проведения операции"? После сопоставления (в международной версии это называется закрытие проводки) проводки по контрагентам в ПДДС попадать перестают.

2. Нет.

[Pavel]

Привет,

Ну, вы тут «наколбасили»... без пол-литра не переварить. Казалось бы тема «не самая сложная». См.комментарии ниже.

Цитата:

Изначально опубликовано glibs
Что, совсем вручную? Так любой дурак может. А зачем тогда Аксапта? Хочу не вручную!

Не совсем так. «Закат солнца вручную» - это такой термин на языке разработчиков, под которым подразумевается реализация в «большой/умной системе» своих «штучек».
Имелось в виду, переписать функциональность «как надо».

Цитата:

Изначально опубликовано glibs
Все просто.

Позвольте не согласиться. С точки зрения системы и «нажатия в ней кнопок» – Да, просто.
С точки зрения бизнес процессов компании и их адекватного, оптимального отражения – Не просто.

Цитата:

Изначально опубликовано glibs
Пока Заказ/Закупка не отфактурованы (соответствуующие статусы на закладке Количество в строках Заказов/Закупок) они считаются такими, которые будут отфактурованы в дату поставки (либо на текущую дату, если она больше даты поставки).

Еще раз. Счет на оплату может быть выставлен поставщиком в ЛЮБОЙ момент. Дата счета на оплату и дата поставки напрямую НЕ СВЯЗАНЫ (в общем случае). С закупкой проще, есть функциональность регистрации и одобрения полученных от кредиторов счетов. С заказами не так.
Тоже с фактурой – признание задолжности и проведение ее в системе НЕ СВЯЗАНО напрямую с датой отгрузки. Потому что:
- есть момент перехода прав собственности
- транспортировка/хранение/перегрузка товара
- акцептование количества/качества
- признание факта получения услуги
- оформление претензий по отгрузке
Все это НАПРЯМУЮ влияет на дату признания задолжности и ее сумму и «разрывает» четкую связь с датой поставки.
Можно привести много примеров.

Ситуация упрощается тем, что у вас есть определенное описание/понимание задачи (частный случай):

Цитата:

Изначально опубликовано glibs
Сегодня у нас пока еще 9-е число. Предположим, вводим закупку 9 октября. Будет платиться на пять дней раньше. Это 4-е октября. Вот 4-го хотелось бы видеть потребность в денежках.

Это можно реализовать путем модификации известной всем функции.

Цитата:

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

Надо сопоставить неотфактурованную карточку заказа/закупки с проведенным платежом. Модифицировать БДДС, чтобы обрабатывал данную ситуацию.

С уважением.

[komar]

to glibs:
так и знал, ничего не изменилось. Всегда сомневался в работоспособности этой штуки.
Нет, я имел в виду не сопоставление, а, например, отфактуровку заказа.

Проблема в том, что механизм этот кривой изначально. Не учитывает остатки по счетам - какое же тут выявление "провалов в ликвидности"? Нет отрицательных дней - это верно подмечено. Сама по себе таблица этого "прогноза ликвидности" не содержит тех данных, по которым осуществляется планирование платежей.
Мои предложения - подрехтовать графики платежей, а вместо того, чтобы базироваться на "прогнозе ликвидности" написать грамотный отчет/запрос, по которому можно планировать платежи. По Cust TransOpen, VendTransOpen, и иже с ними.

[glibs]

2 Pavel

Складывается впечатление, что мы с вами под ПДДС понимаем разные вещи.

Цитата:

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

...Казалось бы тема «не самая сложная»...

Жизнь покажет.

Цитата:

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

Не совсем так. «Закат солнца вручную» - это такой термин на языке разработчиков, под которым подразумевается реализация в «большой/умной системе» своих «штучек».

Большое спасибо за науку (это искрене).

Цитата:

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

...Имелось в виду, переписать функциональность «как надо»...
...
...Это можно реализовать путем модификации известной всем функции...

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

В данный момент мне не до конца ясен предложенный в оригинальной версии подход.

Цитата:

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

...Счет на оплату может быть выставлен поставщиком в ЛЮБОЙ момент...

Теперь по сути...

Ну причем к ПДДС счет (и дата его оплаты)?

Я себе задачу вижу так. Я планирую в следующем месяце закупить материалы. Для производства, напимер. Много материалов. Для их покупки мне понадобится много денег. Относительно много. Если денег у меня не окажется на счете, материалы мне не дадут. Тогда остановится производство и будет плохо. Я хочу знать, будут ли эти деньги у меня на р/с. Как вариант, мне может понадобиться покупка валюты. Как еще один вариант, мне может понадобиться привлечение кредита.

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

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

Аналогично с продажами и поступлениями денег.

Ну при чем здесь счет?

[ldv]

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

[mazzy]

Хм... Извините, если невпопад. Сейчас со временем не густо, а для ответа надо серьезно подумать и посидеть-проверить.

komar предложил хорошую идею. Я позавчера по дороге домой об этом же подумал.

Главное, понять суть требуемого. Из объяснений gilbs получается, что условие совсем не "по предоплате". Получается, что есть ориентировочная дата закупки, а есть ориентировочная дата оплаты поставщику.

Дополнительное условие - дата оплаты чуть раньше даты СФ. Но это не обязательно.

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

График платежей автоматически пойдет в БДДС.

2 gilbs: "спрашивал как они продажи НАМ оформляют. Нам то они, как правило, в кредит не продают"
Хороший вопрос. Надо подумать. Скорее всего берут на ручной контроль. Таких заказов у них вряд ли много. Надо подумать.

2 gilbs: "Получается, ПДДС идеологически не готов работать с предоплатами."
Готов согласится только с тем, что он не знает о таком понятии и не учитывает.
А вот то, что БДДС "не готов" надо обосновывать. Надо думать.

2 gilbs: "Ты не знаешь, а в международной доке это где-то описано? Что-то не смог найти."
Я тоже.

2 komar: "не учитывает остатки по счетам"
И слава богу.

[glibs]

Цитата:

Изначально опубликовано mazzy
Главное, понять суть требуемого. Из объяснений gilbs получается, что условие совсем не "по предоплате". Получается, что есть ориентировочная дата закупки, а есть ориентировочная дата оплаты поставщику.

Дополнительное условие - дата оплаты чуть раньше даты СФ. Но это не обязательно.

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

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

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

По Заказам аналогично (реальная дата отгрузки и предполагаемая дата поступления денег на р/с).

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

Последний абзац из цитаты я не понял.

To All:

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

Цитата:

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

2 gilbs: "Получается, ПДДС идеологически не готов работать с предоплатами."
Готов согласится только с тем, что он не знает о таком понятии и не учитывает.
А вот то, что БДДС "не готов" надо обосновывать. Надо думать.

Да. Думать надо. Завтра поэкспериментирую еще. Нужно четко протестировать механизм включения в ПДДС предоплат/оплат в зависимости от даты.

To Mazzy:

Кстати, в Аксапте есть понятие предоплаты (галочка в соответствующем журнале, возможность видеть предоплаты при сопоставлении, пр). Ты говоришь, что они на Западе такими понятиями не оперируют. Это что полусается, предоплаты - это сугубо российская разработка? Или все-таки оперируют? В международной доке по поиску нашел несколько параметров для предоплат (prepayment).

[Pavel]

Цитата:

Изначально опубликовано glibs
Да. Думать надо. Завтра поэкспериментирую еще. Нужно четко протестировать механизм включения в ПДДС предоплат/оплат в зависимости от даты.

Привет,

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

С уважением.

[glibs]

Я тут немного почитал, что сам написал... подумал...

Цитата:

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

...Я имел в виду, что Закупка (Заказ) должны вводиться с "датой поставки", соответствующей реальной дате поставки. А с помощью условий оплаты кооректировать дату, когда сумма Закупки будет попадать в ПДДС...

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

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

Если посмотреть на все это с другой стороны, то вот что получается.

Можно попробовать предположить, что условия оплаты предназначены ТОЛЬКО для того, чтобы указать количество дней, в течение которых должна произойти оплата. Т.е. они используются для автоматизации заполнения даты "оплатить до" в открытых проводках, формируемых при отфактуровке. При таком подходе отрицательные дни и предоплаты действительно теряют смысл.

Начал опыты. Чувствую, закончу не скоро. Нашел в Заказах/Закупках поле "оплатить до". В старой доке его нет. Наверное, появилось недавно. Интересно. На БДДС это поле никак не влияет. Но если это поле заполнено, при отфактуровке Заказа/Закупки дата "оплатить до" сформированной проводки (которая по контрагенту) подставляется из этого поля, а не расчитывается по вышеописанному алгоритму (дата отфактуровки + число дней в условиях оплаты).

Как-то странно. Это противоречит первому предположению.

To be continued...

To Pavel:

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

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

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

Так что я пока тоже "буду думать" (с) Mazzy

[mazzy]

Цитата:

Изначально опубликовано glibs
Последний абзац из цитаты я не понял.

Закупка. Закладка Цена/Скидка
Поле график

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

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

Цитата:

Изначально опубликовано glibs
Кстати, в Аксапте есть понятие предоплаты (галочка в соответствующем журнале, возможность видеть предоплаты при сопоставлении, пр). Ты говоришь, что они на Западе такими понятиями не оперируют. Это что полусается, предоплаты - это сугубо российская разработка? Или все-таки оперируют? В международной доке по поиску нашел несколько параметров для предоплат (prepayment).

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