|
14.10.2016, 10:39 | #1 |
Участник
|
КР в клиентах DAX2012 R3
Коллеги, приветствую!
Возник вопрос по расчету реализованной курсовой разницы в расчетах с клиентами DAX2012 R3. Ситуация следующая: при сопоставлении проводок система вместо одной проводки в ГК по сумме курсовой разницы делает две - одну на минус, другую на плюс, при сложении они дают верный результат, но их две. И аналитики у них разные. Собственно, две их именно из-за аналитик.Источник этих двух разных наборов аналитик, по мнению системы, проводка по списанию себестоимость номенклатуры Дт90 Кт41 (для системы это две проводки по Дт и Кт с сильно разными аналитиками). Начали копать, откопали вот что: класс CustVendTransExchAdjDistController_RU метод insertDistributionsFromGeneralJournal Там написано вот что: ledgerPostingType = CustBalance currentDefaultLedgerDimension = 62.01 X++: 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; } X++: generalJournalAccountEntry.PostingType != _ledgerPostingType && generalJournalAccountEntry.PostingType != LedgerPostingType::Tax Не можем понять, в чем великий смысл? Как сделать так, чтобы проводка была одна с исходными аналитиками 62-го счета? Спасибо! |
|
14.10.2016, 10:51 | #2 |
Banned
|
Привет Ксения, великий смысл в том, что например при работе с проектами вы можете создать аналитику "проект". Когда в один счет попадает несколько проектов, то аналитика в заголовке одна, а в строках счета - разная с разными проектами. Курсовую разницу можно рассматривать как отдельный вид прибыли по проекту, но тогда надо расщеплать аналитику по строкам, что и было реализовано в AX2012.
Если это не нужно, то достаточно удалить "лишние" сегменты из настройки Accounting Structures счета ГК по курсовой разнице, не так ли? |
|
14.10.2016, 11:02 | #3 |
Участник
|
У нас выключены Accounting Distributions
|
|
14.10.2016, 11:12 | #4 |
Участник
|
Кроме того, не очень понимаю, причем тут ситуация с договорами. Ок, когда имеют место accounting distributions действительно имеет смысл расщепить КР по аналитикам (логично, потому что 62-й счет при таком подходе наследует аналитику из строк). Но именно расщепить, т.е. это будет сумма с одним и тем же знаком, которая в сумме дает общую КР.
Но здесь-то у нас получается одна сумма с +, другая с -, их сумма - верная, но это не разбиение по аналитикам (бить-то нечего на самом деле, у нас одна строка в заказе), т.е. пример: Должна быть КР на сумму 210,61, система сделала 2 проводки: одну на 1 990,20, другую на -1 779,59. |
|
14.10.2016, 11:08 | #5 |
Banned
|
Мне казалось, что это не играет роли? В любом случае КР в AX2012 вычисляется как бы по строкам счета, а не по заголовку. При этом в нереализованной разнице есть настройка Аналитика = "Таблица", то в реализованной разнице такой настройки нет.
Еще вариант решения помимо удаления сегмента с аналитикой для счета: задать фиксированную аналитику в плане счетов. |
|
14.10.2016, 11:21 | #6 |
Banned
|
Ох. Это, наверное, какой-то русский изврат. Конечно должно быть 210. Не встречался с таким поведением на своих проектах кроме того, где мы в Швейцарии начали использовать русскую корреспонденцию. Попробуйте ее отключить для пробы и посмотреть, что будет?
|
|
14.10.2016, 11:29 | #7 |
Участник
|
Вооооо, именно в этом-то и вопрос. Откуда растут ноги у этого изврата. Возможно, это просто ошибка. В АХ2012 мы наталкивались на несколько ошибок в стандарте именно с курсовой разницей. Но ошибка ли это? Управляемо ли такое поведение? Вот вопрос
|
|
14.10.2016, 11:54 | #8 |
Участник
|
Цитата:
Космос какой-то. |
|
14.10.2016, 14:32 | #9 |
Участник
|
Как предположение - Distributions отсутствуют в заказах(а речь наверное о них, раз упоминается 41 счёт). Зато они присутствуют в FTI, и там "дистрибутится" именно 90 счёт(который в корреспонденции с 62). Может быть делали для FTI, и зацепили заказы. Кроме того, этот код может использоваться для расчёта курсовой по закупке(там тоже есть диструбушены). Возможно, в выборку запроса попадают лишние проводки(41 и Д90), наверное их там быть не должно, они же никак не связаны с выручкой и как бы "внутренние". Как вариант, можно попробовать исключить их из этого запроса по PostingType - SalesConsump кажется и что то ещё хотя бы для эксперимента. Суммы получаются такими, наверное, след образом 210 + 1780(Дт90) = 1990 и -1780(там пропорция считается вроде - и дебеты с кредитами не суммируются).
|
|
|
За это сообщение автора поблагодарили: ksenia (1). |
14.10.2016, 14:34 | #10 |
Участник
|
Цитата:
Сообщение от VORP
Как предположение - Distributions отсутствуют в заказах(а речь наверное о них, раз упоминается 41 счёт). Зато они присутствуют в FTI, и там "дистрибутится" именно 90 счёт(который в корреспонденции с 62). Может быть делали для FTI, и зацепили заказы. Кроме того, этот код может использоваться для расчёта курсовой по закупке(там тоже есть диструбушены). Возможно, в выборку запроса попадают лишние проводки(41 и Д90), наверное их там быть не должно, они же никак не связаны с выручкой и как бы "внутренние". Как вариант, можно попробовать исключить их из этого запроса по PostingType - SalesConsump кажется и что то ещё хотя бы для эксперимента. Суммы получаются такими, наверное, след образом 210 + 1780(Дт90) = 1990 и -1780(там пропорция считается вроде - и дебеты с кредитами не суммируются).
|
|
14.10.2016, 14:46 | #11 |
Участник
|
Ну суть в том что в расчёт пропорции ошибочно попадают проводки по 41 и Дт90 их надо оттуда исключить, как это было сделано с проводками типа Tax:
generalJournalAccountEntry.PostingType != LedgerPostingType::Tax Возможно, что надо ещё и Корр счёт исключать. Действительно похоже на баг стандарта, но странно что на него никто до сих пор не натыкался и всё ещё не пофиксили - ведь получается что курсовая по заказу считается неправильно. Хотя, может быть, валютные заказы на продажу не так и много у кого есть... |
|
14.10.2016, 14:52 | #12 |
Участник
|
Мы в принципе уже поняли, как исправить, но действительно странно, что никто раньше с этим не сталкивался....
|
|
14.10.2016, 15:51 | #13 |
Участник
|
Не могу воспроизвести Ваш сценарий, этот код вообще не вызывается при сопоставлении валютного заказа и валютной оплаты. Подскажите пожалуйста, какой метод расчёта курсовой у Вас стоит и стоит ли RU в настройках компании? Если можно, было бы интересно посмотреть на stack trace который приводит к этому методу. В каких валютах накладная и оплата?
|
|
14.10.2016, 19:19 | #14 |
Участник
|
Собственно да, чтобы что-то советовать нужно привести скриншоты ваших настроек курсовых.
__________________
Ivanhoe as is.. |
|
17.10.2016, 10:06 | #15 |
Участник
|
Регион - RUS
Метод расчете КР - итого за период В Параметрах валюты активизированы параметры только для USD, для раздела Клиенты\Заказы установлена "разноска ГК" = "Счет отклонения себестоимости товаров" и настроены 91-е счета. К слову, если я поменяю "разноска ГК" = "По накладным", то проводка будет одна (хорошо), но на 90-й счет из накладной (плохо). |
|
|
За это сообщение автора поблагодарили: Logger (1), VORP (2). |
17.10.2016, 14:25 | #16 |
Участник
|
Воспроизвёл, да. Честно говоря не понял почему код стал отрабатывать - у меня тоже стояло Счет отклонения себестоимости товаров. Но даже в этом случае создавалась одна проводка сначала. Ключевым моментом является различие аналитик 41 и 90 счетов в заказе, чтобы при суммировании в цикле они не давали ноль. Аналитика и туда и туда берётся из строк заказа - как вы добились чтоб они отличались - какая то аналитика настроена по умолчанию на 90 м например?
Последний раз редактировалось VORP; 17.10.2016 в 14:38. |
|
17.10.2016, 15:11 | #17 |
Участник
|
В общем, это ошибка в любом случае. Другое дело что при одинаковых наборах аналитик на 41 и 90 Дт она не проявляется. Если ситуация когда этот набор аналитик отличается часта, то приоритет ошибки будет выше. Пожалуйста, зарегистрируйте багу, если ещё не зарегистрировали.
|
|
17.10.2016, 15:26 | #18 |
Участник
|
Цитата:
Добиться разных аналитик проще простого - достаточно иметь для 90 и 41 счета совсем разные структуры счета. В любом случае, спасибо! |
|
05.12.2016, 18:15 | #19 |
Участник
|
Microsoft выпустил исправление данной ошибки.
KB Article Number : 3208362 RU - Wrong revaluation amounts |
|
|
За это сообщение автора поблагодарили: Logger (1). |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|