График оплаты не от инвойса

[Raven Melancholic]

Графики оплаты (да и в целом условия оплаты) в DAX реализованы таким образом, что базовой точкой отчета является инвойс (в российской локализации Накладная). Именно от это даты и рассчитываются показатели (вполне понятно - в буржуинстве в большинстве случаев работают так).
У нас ситуация следующая:

1. Выставляется счет на оплату (стандартный российский функционал).
2. По условиям договоров клиент обязан оплатить 30% в течении 10 рабочих дней после выставления счета.
3. 50% клиент оплачивает за два дня до отгрузки.
4. Оставшиеся 20% клиент оплачивает в течении 14 рабочих дней после отгрузки.

Если со вторым и третьим пунктом все достаточно хорошо вписывается в то, что мне известно про Аксу, то для первого пункт никак не могу придумать схему настройки графика платежей.
Есть ли возможность (может быть не лежащая на поверхности, так "как в лоб" без программирования вроде возможности нет) настроить график платежей таким образом, образом, чтобы первый платеж рассчитывался не от инвойса, а от счета на оплату? Срок между счетом и отгрузкой недетерминирован (оборудование заказное и сроки изготовления и подготовки к отгрузке зависят от многих факторов, но примерная дата отгрузки известна).
Хочется, чтобы данный механизм работал в заказе на продажу в запросе "Прогноз движения денежных средств", в настройке "График платежей" и в стандартных отчетах.
PS: для упрощения пока не заморачиваюсь по поводу частичных отгрузок, вероятности оплаты и т.п. Для начала хочется настроить для простейших случаев: вероятность оплаты счета 100%, отгрузка всех позиций заказа в один день.
Система: DAX4 SP2FP1 EE (со всеми последними обновлениями)

[VolkaD]

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

[Михаил Андреев]

Штатно такого в Аксапте нет. Но, доработка несложная, если делать по уму.

[raz]

Вопрос в догонку. Есть кто нибудь, кто использует графики платежей по клиентам? Как вы боретесь со случаем, когда клиентский платеж закрывает несколько OpenTrans-ов по графику сразу?

[glibs]

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

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

[Raven Melancholic]

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

Цитата:

Сообщение от raz

ВКак вы боретесь со случаем, когда клиентский платеж закрывает несколько OpenTrans-ов по графику сразу?

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

[raz]

Цитата:

Сообщение от Raven Melancholic

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

Просто выскочит ошибка при сопоставлении "Сопоставление невозможно: нарушение процедуры ведения книг продаж/покупок." и всё

AX3\Classes\CustVendSettle\settleNow()

            if ( ! isBadDebtAmortisation && ! this.checkIfCanBeSettled_RU(transactionDate))
            {
                throw error("@DIS8080");
            }

Мы сделали кнопочку, которая схлопывает custTransOpen, когда надо сопоставлять клиентский платеж закрывающий несколько OpenTrans-ов.

[Maxim Gorbunov]

Цитата:

Сообщение от Raven Melancholic

(вполне понятно - в буржуинстве в большинстве случаев работают так).

Не всегда. Описанный вариант тоже встречается.

Цитата:

У нас ситуация следующая:

1. Выставляется счет на оплату (стандартный российский функционал).
2. По условиям договоров клиент обязан оплатить 30% в течении 10 рабочих дней после выставления счета.
3. 50% клиент оплачивает за два дня до отгрузки.
4. Оставшиеся 20% клиент оплачивает в течении 14 рабочих дней после отгрузки.

Обычно решается с помощью включения в заказ дополнительной строки PREPAYMENT. Соответственно, на нее создаются инвойсы с нужными датами (или один инвойс с нужным графиком платежей). Когда разносится последний инвойс (при отгрузке товара), строка PREPAYMENT включается в него с отрицательной суммой (чтобы уменьшить общую сумму). В качестве бонуса: в строках последнего инвойса видно, каким образом была рассчитана сумма к оплате.

[Raven Melancholic]

Цитата:

Сообщение от Maxim Gorbunov

Обычно решается с помощью включения в заказ дополнительной строки PREPAYMENT. ...

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

Цитата:

Просто выскочит ошибка при сопоставлении "Сопоставление невозможно: нарушение процедуры ведения книг продаж/покупок." и всё

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