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

[glibs]

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

Цитата:

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

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

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

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

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

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

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

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

To be continued...

To Pavel:

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

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

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

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