Поле "Оплатить до" в строке общего журнала

[longson]

Добрый день,

Хотелось бы обсудить с вами по следующей теме

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

Вот кусочек кода из класса LedgerJournalEngine, который всю эту работу выполняет

void initFromRContractTable_RU(LedgerJournalTrans ledgerJournalTrans)
{
    RContractTable rContractTable;
    ;
    rContractTable = this.findRContractTable_RU(ledgerJournalTrans);
    if (! rContractTable)
        return;

    if (rContractTable.ContractPaymCode && ledgerJournalTrans.Invoice) // PaymTermId
    {
        this.findPayment(rContractTable.ContractPaymCode);
        ledgerJournalTrans.Due  = payment.due(ledgerJournalTrans.TransDate, rContractTable.RContractPaymDayId);
    }
    else
    {
        ledgerJournalTrans.Due = ledgerJournalTrans.TransDate;
    }

Вот у меня возникают несколько вопросов :

1. Почему это поле есть только в одной стороне, т.е если мы выбираем клиента или поставщика не в Счет, а в Корр.счет, то ничего связанного с этим не будет происходить. Вообще нет аналогичного поля для корр.счета.
2. По какой логике это поле должно принимать значение, которое определяется в справочнике договоров. Представим, что если в общем журнале хотим регистрировать оплаты от клиентов, тогда на мой взгляд целесообразнее если это поле всегда принимает значение СЕГОДНЯ. Потому что это значение после разноски будет в таблице CustTrans (VendTrans) и CustTransOpen (VendTransOpen). В этих таблицах, смысл этого поля, по-моему, только для накладной. Для оплаты оно не носит никакой дополнительной информации.
3. Вообще для чего предназначено это поле в таблице LedgerJournalTrans ?

Я по своей работе собираюсь поменять код чтобы значение этого поля в общем журнале всегда принимает значение СЕГОДНЯ. Но возможно, какие - нибудь идеи по функционалам не учитываю или не знаю ?

[twilight]

1. Зачем регистрировать оплаты от клиентов в общем журнале? По моему журнал платежей в модуле расчеты с клиентами гораздо удобнее для этой цели, ведь, в конце концов он специально и был создан для этой цели.
2. Я так думаю, что смысл может быть когда мы вводим остатки по клиентам через главный журнал, тогда можно указать дату, если нужно отслеживать сроки задолженности.

[Atar]

Цитата:

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

1. Зачем регистрировать оплаты от клиентов в общем журнале? По моему журнал платежей в модуле расчеты с клиентами гораздо удобнее для этой цели, ведь, в конце концов он специально и был создан для этой цели.
2. Я так думаю, что смысл может быть когда мы вводим остатки по клиентам через главный журнал, тогда можно указать дату, если нужно отслеживать сроки задолженности.

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

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

[glibs]

Цитата:

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

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

Потому что Аксапта нормально работает, когда в проводках есть только один клиент или поставщик. Проблема обсуждалась ранее.

Раньше (в 3.0 и ранее) система не ругалась, если в проводке (имеется в виду ваучер) участвует несколько клиентов и поставщиков. Но потом из-за этого сносило крышу некоторой функциональности. В 4.0 такие возможности существенно ограничили.

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

Про скидки по оплате и сопоставление они тоже, видимо, не знали тогда.

Вообще правильный подход в таком случае регистрировать многострочные проводки. Тогда и Профиль разноски, и Оплатить до, и Cкидки по оплате, и Сопоставление, и Аналитики, и прочий функционал доступны и для дебетового счета, и для кредитового.

Цитата:

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

...
По какой логике это поле должно принимать значение, которое определяется в справочнике договоров. Представим, что если в общем журнале хотим регистрировать оплаты от клиентов, тогда на мой взгляд целесообразнее если это поле всегда принимает значение СЕГОДНЯ. Потому что это значение после разноски будет в таблице CustTrans (VendTrans) и CustTransOpen (VendTransOpen). В этих таблицах, смысл этого поля, по-моему, только для накладной. Для оплаты оно не носит никакой дополнительной информации.
...

Ну тут вы не совсем правы. То, с какой датой Оплатить до попадет в VendTransOpen повлияет на то, с какой датой сформируется LedgerCov. А если вы знаете что это такое и с чем его едят, то дата Оплатить до в оплате для вас будет совсем не безразлична.

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

Цитата:

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

...
Вообще для чего предназначено это поле в таблице LedgerJournalTrans ?

Я по своей работе собираюсь поменять код чтобы значение этого поля в общем журнале всегда принимает значение СЕГОДНЯ. Но возможно, какие - нибудь идеи по функционалам не учитываю или не знаю ?
...

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

Я смотрел только что в 4.0. Там мне удавалось создать ситуацию, когда Оплатить до не менялось (оставалось равным дате платежа) при вводе оплаты. Договоры, правда, не использовал специально.

А вообще там... ну в общем, я только что посмотрел специально буржуйскую версию. Там заполнение поля Оплатить до зависит от того, указан или не указан номер инвойса. Соответственно система различает оплату и накладную.

Я помню, что локализаторы надругались над Оплатить до в заказах и закупках. Чтобы печатать счета на оплату, чтоли. Возможно, что и журналам ГК досталось. Похоже, в буржуйской версии общий журнал работает корректно. А в локализованной... вот так.

Если будете делать, рекомендую стремиться к стандартам из буржуйской функциональности.

[longson]

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

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

Цитата:

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

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

Тогда и смысла в поле "Оплатить до" большого нет
Вообще, посмотрите классы, которые занимаются импортом платёжек иностранных банков (эти классы видны в форме Способы оплаты при нажатии кнопки Настройка). Их необязательно импортировать в ОДИН журнал. Можно хоть в 10 , а потом пользоваться формой "Перенесённые платежи" для разноски.

[longson]

glibs: Интересно, в чем может быть проблема, если в одной проводке есть в обей стороне - клиент или поставщики ?

У нас именно AX 3.0 SP5. Поэтому технически такая возможность не ограничена, и действительно в очень многих проводках у нас так и есть.

[glibs]

Не могу найти обсуждение. Но суть в том, что отчеты по выверке ГК и модульных проводок завязываются на дату, номер ваучера и тип разноски. А если в ваучере будет несколько операций с типом Клиент или поставщик — отчет начинает работать неверно. Также проблемы возникают при использовании просмотра происхожденя ваучера ГК.

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

Если же финансовое планирование у вас организовано таки в другой системе, и вам нужно загружать именно платежи из клиент-банка... А вы пользуетесь стандартной функциональностью создания платежей или пишете свой импорт?