Указание нескольких клиентов в одной операции

[vanokh]

AX 4.0 SP1 -> SP2



После перехода c SP1 на SP2 словили следующее:

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


Как выяснилось изменение было внесено в международном SP2 (KB 932712 - It is possible to post one voucher with two different customer invoice transactions in the daily journal.). Нужный KB на сайте Microsoft не найден...


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

[glibs]

Связь аналитических модулей (РК в частности) с ГК поддерживается на уровне даты операции и номера ваучера. Чтобы определить соответствие, например, CustTrans и LedgerTrans еще используется тип разноски в ГК. Если в один ваучер угодит бльше одного счета клиента, то определить соответствие между проводкой ГК и проводкой по клиенту становится технически невозможно. Ну и некоторые стандартные отчеты по выверке в таком случае тоже начинают глючить.

Могу посоветовать использовать транзитный счет и два ваучера.

[sukhanchik]

2glibs:
Все это правильно... Но тогда каков смысл поля "Новая операция" (LedgerJournalName.NewVoucher) в настройках журналов ГК?
Там же вообще есть вариант "Только один код операции"

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

[glibs]

Вероятно, эта настройка должна использоваться только для журналов, в которых регистрируются операции со счетами ГК. В журналах с такой настройкой не должно быть аналитических счетов (Клиенты, Поставщики, Банковские счета, и т.п.). Это IMHO.

Что касается транзитного счета для взаимозачетов и подобного рода операций... С двумя ваучерами сложно будет делать выверку. Если два клиента находятся в рамках одного ваучера (по сути: ваучер = некая операция), понять что за операция можно. Если сделать через два ваучера и транзитный счет, то связь в БД между половинками операций не сохранится, а поиск пользователем таких операций будет затруднен.

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

[sukhanchik]

Цитата:

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

Вероятно, эта настройка должна использоваться только для журналов, в которых регистрируются операции со счетами ГК. В журналах с такой настройкой не должно быть аналитических счетов (Клиенты, Поставщики, Банковские счета, и т.п.). Это IMHO.

Ну если так то конечно.... Только как-то мне сия мысль в голову не приходила.
То что связка идет по ваучеру+дата между аналитическими и синтетическими операциями - да идет... но в общем-то никто не обещал связь один в один.
Мне больше кажется - что при проектировании архитектуры просто не было задачи однозначно связывать Cust(Vend)Trans и LedgerTrans.

Цитата:

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

С двумя ваучерами сложно будет делать выверку.
...
IMHO, здесь имеет место быть некий идеологический изъян в архитектуре Аксапты.

Это не изъян, а идеологическое следствие "натягивание" функционала "корреспонденция" на функционал "многострочная проводка" с возможностью отключения первого.
Фактически, ведь связь между парами проводок есть - только эта связь "зарыта" в скромном поле "Пакет корреспонденции" (LedgerTrans.BondBatch_RU) и построить быстрый и красивый отчет по корреспондирующей части по данным из Cust(Vend)Trans сложно.

Что делать... Аксапта проектировалась без учета требований РСБУ

[glibs]

Цитата:

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

...
идеологическое следствие "натягивание" функционала "корреспонденция" на функционал "многострочная проводка"
...

Нет. Тут дело в другом.

Все объясняется в значительно степени терминами синтетический и аналитический учет. Обычно ваучер пишется с группировкой по типу операции, тексту проводки, счету ГК и аналитике (ну дате там еще и проч.). И даже при корреспонденции нескольким аналитическим записям может соответствовать одно движение по счету ГК.

Поэтому однозначной связи между синтетическими и аналитическими операциями нет. В классическом буржуйском учете для нее как раз и служит номер ваучера.

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

[BOAL]

Вывод какой?
Разрешить обратно для наших широт. Мы разрешали. Мне кл-кл транзакции крайне нужны - на них все и живет, исторически и логически тоже.

sukhanchik, у тебя в "новой" АХ как у самого сейчас?

[vanokh]

Цитата:

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

Вывод какой?
Разрешить обратно для наших широт.

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

Занятно, аналогичная проверка для операций поставщик-поставщик изменена в локализации - проверка из международной закомментирована, вместо нее написана другая:

ledgerJournalTrans.selectLocked(false);
        select count(RecId) from ledgerJournalTrans
        index hint NumVoucherIdx
            where ledgerJournalTrans.Voucher     == _ledgerJournalTrans.Voucher &&
                  ledgerJournalTrans.JournalNum  == _ledgerJournalTrans.JournalNum &&
                  ledgerJournalTrans.AccountType == LedgerJournalACType::Vend;
        if (ledgerJournalTrans.RecId > 1)
        {
            ok      = checkFailed("@SYS29116");
            allok   = false;
        }
    }
/* this code doesn't work correctly for SAD documents
    //
    //  When "Vendor" type is used on any Ledger Journal Transaction it can only
    //  exist once per "Voucher" series .
    //
    //  Since a "Vendor" type can be applied to either the primary or offset side
    //  of a transaction. This is both a qualifying factor and additional data to be
    //  validated. Although this only applies to "Daily" (GL) based journals it
    //  should not affect this validation.
    //
    if (_ledgerJournalTrans.AccountType       == LedgerJournalACType::Vend ||
       (_ledgerJournalTrans.OffsetAccount     &&
        _ledgerJournalTrans.OffsetAccountType == LedgerJournalACType::Vend))
    {
        ledgerJournalTrans.selectLocked(false);
        select count(RecId) from ledgerJournalTrans
        index hint NumVoucherIdx
            where ledgerJournalTrans.Voucher            == _ledgerJournalTrans.Voucher &&
                  ledgerJournalTrans.JournalNum         == _ledgerJournalTrans.JournalNum &&
                  (ledgerJournalTrans.AccountType       == LedgerJournalACType::Vend ||
                  (ledgerJournalTrans.OffsetAccount     &&
                   ledgerJournalTrans.OffsetAccountType == LedgerJournalACType::Vend));
        if (ledgerJournalTrans.RecId > 1)
        {
            ok      = checkFailed("@SYS29116");
            allok   = false;
        }
    }
*/

[Maxim Gorbunov]

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

[sukhanchik]

Цитата:

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

sukhanchik, у тебя в "новой" АХ как у самого сейчас?

Ну как - 2 клиента разных - пожалуйста. А вот 2 одинаковых даже - с разными профилями разноски (или договорами) - фиг.
Вообще-то сей код обитает в \Classes\LedgerJournalTransUpdateCust\checkVoucher для клиентов и \Classes\LedgerJournalTransUpdateVend\checkVoucher для поставщиков.
У нас штатный (неизмененный) код в 4.0 EE SP2. Спокойно дает сделать разноску (и такие взаимозачеты у нас есть).

[vanokh]

Цитата:

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

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

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

Цитата:

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

Ну как - 2 клиента разных - пожалуйста. А вот 2 одинаковых даже - с разными профилями разноски (или договорами) - фиг.
Вообще-то сей код обитает в \Classes\LedgerJournalTransUpdateCust\checkVoucher для клиентов и \Classes\LedgerJournalTransUpdateVend\checkVoucher для поставщиков.
У нас штатный (неизмененный) код в 4.0 EE SP2. Спокойно дает сделать разноску (и такие взаимозачеты у нас есть).

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

[Vadik]

В KB968331 немного "ослабили поводок" (для клиентов и поставщиков)

\Classes\LedgerJournalTransUpdateCust\checkVoucher

boolean checkVoucher(LedgerJournalTrans _ledgerJournalTrans)
{
    boolean ok    = true;
    LedgerJournalTrans ledgerJournalTrans;

    if (_ledgerJournalTrans.Invoice)
    {
        //  The following rule should be applied only when the invoice number is filled in.
        //  When "Customer" type is used on any Ledger Journal Transaction it can only
        //  exist once per "Voucher" series .
        //
        //  Since a "Customer" type can be applied to either the primary or offset side
        //  of a transaction. This is both a qualifying factor and additional data to be
        //  validated. Although this only applies to "Daily" (GL) based journals it
        //  should not affect this validation.
        //
        if (_ledgerJournalTrans.AccountType       == LedgerJournalACType::Cust ||
           (_ledgerJournalTrans.OffsetAccount     &&
            _ledgerJournalTrans.OffsetAccountType == LedgerJournalACType::Cust))
        {
            ledgerJournalTrans.selectLocked(false);
            select count(RecId) from ledgerJournalTrans
            index hint NumVoucherIdx
                where ledgerJournalTrans.Voucher            == _ledgerJournalTrans.Voucher &&
                      ledgerJournalTrans.JournalNum         == _ledgerJournalTrans.JournalNum &&
                      ledgerJournalTrans.TransactionType    != LedgerTransType::Fee &&
                      (ledgerJournalTrans.AccountType       == LedgerJournalACType::Cust ||
                      (ledgerJournalTrans.OffsetAccount     &&
                       ledgerJournalTrans.OffsetAccountType == LedgerJournalACType::Cust));
            if (ledgerJournalTrans.RecId > 1)
            {
                ok = checkFailed("@SYP809");
            }
        }
    }
    return ok;
}

[vanokh]

Цитата:

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

В KB968331 немного "ослабили поводок" (для клиентов и поставщиков)

Хм, в описании этого хотфикса ничего про такие изменения не сказано... Может быть имелся в виду вот этот - KB945488?

[Vadik]

Цитата:

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

Хм, в описании этого хотфикса ничего про такие изменения не сказано... Может быть имелся в виду вот этот - KB945488?

Ага, я упустил тот момент, что хотфиксы теперь кумулятивные

[vanokh]

Цитата:

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

Ага, я упустил тот момент, что хотфиксы теперь кумулятивные

Ага, я это подозревал, но не был уверен. Это где-то явно указано? А kernel rollup'ы, то бишь фиксы экзешников клиента и АОСа тоже кумулятивные?

[Vadik]

Цитата:

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

Ага, я это подозревал, но не был уверен. Это где-то явно указано?

Dynamics AX Sustained Engineering: Dynamics AX 2009 Patching

Цитата:

А kernel rollup'ы, то бишь фиксы экзешников клиента и АОСа тоже кумулятивные?

Так они всегда были кумулятивными...