КР в клиентах DAX2012 R3

[ksenia]

Коллеги, приветствую!
Возник вопрос по расчету реализованной курсовой разницы в расчетах с клиентами DAX2012 R3.
Ситуация следующая: при сопоставлении проводок система вместо одной проводки в ГК по сумме курсовой разницы делает две - одну на минус, другую на плюс, при сложении они дают верный результат, но их две. И аналитики у них разные. Собственно, две их именно из-за аналитик.Источник этих двух разных наборов аналитик, по мнению системы, проводка по списанию себестоимость номенклатуры Дт90 Кт41 (для системы это две проводки по Дт и Кт с сильно разными аналитиками).
Начали копать, откопали вот что: класс CustVendTransExchAdjDistController_RU метод insertDistributionsFromGeneralJournal
Там написано вот что:
ledgerPostingType = CustBalance
currentDefaultLedgerDimension = 62.01

protected Amount insertDistributionsFromGeneralJournal(CustVendTrans _custVendTrans, LedgerPostingType _ledgerPostingType, Map _dimensionMap)
{
    GeneralJournalAccountEntry  generalJournalAccountEntry;
    GeneralJournalEntry         generalJournalEntry;
    SubledgerVoucherGeneralJournalEntry subledgerVoucherEntry;
    Amount                      ret;
    ;

    while select LedgerDimension, sum(TransactionCurrencyAmount) from generalJournalAccountEntry
        group by LedgerDimension
        join RecId from generalJournalEntry
        join TableId from subledgerVoucherEntry
        where generalJournalAccountEntry.PostingType    != _ledgerPostingType
            && generalJournalAccountEntry.PostingType   != LedgerPostingType::Tax
            && generalJournalEntry.RecId                 == generalJournalAccountEntry.GeneralJournalEntry
            && generalJournalEntry.Ledger                == currentLedger.RecId
            && subledgerVoucherEntry.GeneralJournalEntry == generalJournalEntry.RecId
            && subledgerVoucherEntry.AccountingDate      == _custVendTrans.TransDate
            && subledgerVoucherEntry.Voucher             == _custVendTrans.Voucher
    {
        ret = this.addDimensionAmount(
            currentDefaultLedgerDimension,
            generalJournalAccountEntry.LedgerDimension,
            generalJournalAccountEntry.TransactionCurrencyAmount,
            _dimensionMap,
            ret
        );
    }
    return ret;
}

Собственно, вот в этих двух строчках

generalJournalAccountEntry.PostingType    != _ledgerPostingType
            && generalJournalAccountEntry.PostingType   != LedgerPostingType::Tax

система и находит проводки с разными аналитиками и пытается как-то начислить КР на 62-м счете на каждый из наборов аналитик (может это неправильное выражение, но как иначе объяснить, не знаю...) в корреспонденции с 91-м счетом

Не можем понять, в чем великий смысл? Как сделать так, чтобы проводка была одна с исходными аналитиками 62-го счета?
Спасибо!

[EVGL]

Привет Ксения, великий смысл в том, что например при работе с проектами вы можете создать аналитику "проект". Когда в один счет попадает несколько проектов, то аналитика в заголовке одна, а в строках счета - разная с разными проектами. Курсовую разницу можно рассматривать как отдельный вид прибыли по проекту, но тогда надо расщеплать аналитику по строкам, что и было реализовано в AX2012.
Если это не нужно, то достаточно удалить "лишние" сегменты из настройки Accounting Structures счета ГК по курсовой разнице, не так ли?

[ksenia]

У нас выключены Accounting Distributions

[EVGL]

Мне казалось, что это не играет роли? В любом случае КР в AX2012 вычисляется как бы по строкам счета, а не по заголовку. При этом в нереализованной разнице есть настройка Аналитика = "Таблица", то в реализованной разнице такой настройки нет.

Еще вариант решения помимо удаления сегмента с аналитикой для счета: задать фиксированную аналитику в плане счетов.

[ksenia]

Кроме того, не очень понимаю, причем тут ситуация с договорами. Ок, когда имеют место accounting distributions действительно имеет смысл расщепить КР по аналитикам (логично, потому что 62-й счет при таком подходе наследует аналитику из строк). Но именно расщепить, т.е. это будет сумма с одним и тем же знаком, которая в сумме дает общую КР.
Но здесь-то у нас получается одна сумма с +, другая с -, их сумма - верная, но это не разбиение по аналитикам (бить-то нечего на самом деле, у нас одна строка в заказе), т.е. пример:
Должна быть КР на сумму 210,61, система сделала 2 проводки:
одну на 1 990,20, другую на -1 779,59.

[EVGL]

Ох. Это, наверное, какой-то русский изврат. Конечно должно быть 210. Не встречался с таким поведением на своих проектах кроме того, где мы в Швейцарии начали использовать русскую корреспонденцию. Попробуйте ее отключить для пробы и посмотреть, что будет?

[ksenia]

Цитата:

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

Ох. Это, наверное, какой-то русский изврат. Конечно должно быть 210. Не встречался с таким поведением на своих проектах кроме того, где мы в Швейцарии начали использовать русскую корреспонденцию. Попробуйте ее отключить для пробы и посмотреть, что будет?

Вооооо, именно в этом-то и вопрос. Откуда растут ноги у этого изврата. Возможно, это просто ошибка. В АХ2012 мы наталкивались на несколько ошибок в стандарте именно с курсовой разницей. Но ошибка ли это? Управляемо ли такое поведение? Вот вопрос

[ksenia]

Цитата:

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

Вооооо, именно в этом-то и вопрос. Откуда растут ноги у этого изврата. Возможно, это просто ошибка. В АХ2012 мы наталкивались на несколько ошибок в стандарте именно с курсовой разницей. Но ошибка ли это? Управляемо ли такое поведение? Вот вопрос

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

[VORP]

Как предположение - Distributions отсутствуют в заказах(а речь наверное о них, раз упоминается 41 счёт). Зато они присутствуют в FTI, и там "дистрибутится" именно 90 счёт(который в корреспонденции с 62). Может быть делали для FTI, и зацепили заказы. Кроме того, этот код может использоваться для расчёта курсовой по закупке(там тоже есть диструбушены). Возможно, в выборку запроса попадают лишние проводки(41 и Д90), наверное их там быть не должно, они же никак не связаны с выручкой и как бы "внутренние". Как вариант, можно попробовать исключить их из этого запроса по PostingType - SalesConsump кажется и что то ещё хотя бы для эксперимента. Суммы получаются такими, наверное, след образом 210 + 1780(Дт90) = 1990 и -1780(там пропорция считается вроде - и дебеты с кредитами не суммируются).

[ksenia]

Цитата:

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

Как предположение - Distributions отсутствуют в заказах(а речь наверное о них, раз упоминается 41 счёт). Зато они присутствуют в FTI, и там "дистрибутится" именно 90 счёт(который в корреспонденции с 62). Может быть делали для FTI, и зацепили заказы. Кроме того, этот код может использоваться для расчёта курсовой по закупке(там тоже есть диструбушены). Возможно, в выборку запроса попадают лишние проводки(41 и Д90), наверное их там быть не должно, они же никак не связаны с выручкой и как бы "внутренние". Как вариант, можно попробовать исключить их из этого запроса по PostingType - SalesConsump кажется и что то ещё хотя бы для эксперимента. Суммы получаются такими, наверное, след образом 210 + 1780(Дт90) = 1990 и -1780(там пропорция считается вроде - и дебеты с кредитами не суммируются).

Возможно. Это мы и пытаемся понять. Мы нашли место, которое закомментировать - и все будет хорошо, но хотелось бы понять суть. Пока все выглядит, как баг стандарта.

[VORP]

Ну суть в том что в расчёт пропорции ошибочно попадают проводки по 41 и Дт90 их надо оттуда исключить, как это было сделано с проводками типа Tax:
generalJournalAccountEntry.PostingType != LedgerPostingType::Tax
Возможно, что надо ещё и Корр счёт исключать. Действительно похоже на баг стандарта, но странно что на него никто до сих пор не натыкался и всё ещё не пофиксили - ведь получается что курсовая по заказу считается неправильно. Хотя, может быть, валютные заказы на продажу не так и много у кого есть...

[ksenia]

Цитата:

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

. Действительно похоже на баг стандарта, но странно что на него никто до сих пор не натыкался и всё ещё не пофиксили - ведь получается что курсовая по заказу считается неправильно.

Мы в принципе уже поняли, как исправить, но действительно странно, что никто раньше с этим не сталкивался....

[VORP]

Не могу воспроизвести Ваш сценарий, этот код вообще не вызывается при сопоставлении валютного заказа и валютной оплаты. Подскажите пожалуйста, какой метод расчёта курсовой у Вас стоит и стоит ли RU в настройках компании? Если можно, было бы интересно посмотреть на stack trace который приводит к этому методу. В каких валютах накладная и оплата?

[Ivanhoe]

Собственно да, чтобы что-то советовать нужно привести скриншоты ваших настроек курсовых.

[ksenia]

Регион - RUS
Метод расчете КР - итого за период
В Параметрах валюты активизированы параметры только для USD, для раздела Клиенты\Заказы установлена "разноска ГК" = "Счет отклонения себестоимости товаров" и настроены 91-е счета.
К слову, если я поменяю "разноска ГК" = "По накладным", то проводка будет одна (хорошо), но на 90-й счет из накладной (плохо).

[VORP]

Воспроизвёл, да. Честно говоря не понял почему код стал отрабатывать - у меня тоже стояло Счет отклонения себестоимости товаров. Но даже в этом случае создавалась одна проводка сначала. Ключевым моментом является различие аналитик 41 и 90 счетов в заказе, чтобы при суммировании в цикле они не давали ноль. Аналитика и туда и туда берётся из строк заказа - как вы добились чтоб они отличались - какая то аналитика настроена по умолчанию на 90 м например?

[VORP]

В общем, это ошибка в любом случае. Другое дело что при одинаковых наборах аналитик на 41 и 90 Дт она не проявляется. Если ситуация когда этот набор аналитик отличается часта, то приоритет ошибки будет выше. Пожалуйста, зарегистрируйте багу, если ещё не зарегистрировали.

[ksenia]

Цитата:

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

В общем, это ошибка в любом случае. Другое дело что при одинаковых наборах аналитик на 41 и 90 Дт она не проявляется. Если ситуация когда этот набор аналитик отличается часта, то приоритет ошибки будет выше. Пожалуйста, зарегистрируйте багу, если ещё не зарегистрировали.

Зарегистрировали уже :-)
Добиться разных аналитик проще простого - достаточно иметь для 90 и 41 счета совсем разные структуры счета.
В любом случае, спасибо!

[zhan]

Microsoft выпустил исправление данной ошибки.
KB Article Number : 3208362 RU - Wrong revaluation amounts