AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 14.10.2016, 10:39   #1  
ksenia is offline
ksenia
Участник
Аватар для ksenia
 
291 / 28 (1) +++
Регистрация: 11.10.2003
Адрес: Москва
КР в клиентах 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-м счете на каждый из наборов аналитик (может это неправильное выражение, но как иначе объяснить, не знаю...) в корреспонденции с 91-м счетом

Не можем понять, в чем великий смысл? Как сделать так, чтобы проводка была одна с исходными аналитиками 62-го счета?
Спасибо!
Старый 14.10.2016, 10:51   #2  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Привет Ксения, великий смысл в том, что например при работе с проектами вы можете создать аналитику "проект". Когда в один счет попадает несколько проектов, то аналитика в заголовке одна, а в строках счета - разная с разными проектами. Курсовую разницу можно рассматривать как отдельный вид прибыли по проекту, но тогда надо расщеплать аналитику по строкам, что и было реализовано в AX2012.
Если это не нужно, то достаточно удалить "лишние" сегменты из настройки Accounting Structures счета ГК по курсовой разнице, не так ли?
Старый 14.10.2016, 11:02   #3  
ksenia is offline
ksenia
Участник
Аватар для ksenia
 
291 / 28 (1) +++
Регистрация: 11.10.2003
Адрес: Москва
У нас выключены Accounting Distributions
Старый 14.10.2016, 11:08   #4  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Мне казалось, что это не играет роли? В любом случае КР в AX2012 вычисляется как бы по строкам счета, а не по заголовку. При этом в нереализованной разнице есть настройка Аналитика = "Таблица", то в реализованной разнице такой настройки нет.

Еще вариант решения помимо удаления сегмента с аналитикой для счета: задать фиксированную аналитику в плане счетов.
Старый 14.10.2016, 11:12   #5  
ksenia is offline
ksenia
Участник
Аватар для ksenia
 
291 / 28 (1) +++
Регистрация: 11.10.2003
Адрес: Москва
Кроме того, не очень понимаю, причем тут ситуация с договорами. Ок, когда имеют место accounting distributions действительно имеет смысл расщепить КР по аналитикам (логично, потому что 62-й счет при таком подходе наследует аналитику из строк). Но именно расщепить, т.е. это будет сумма с одним и тем же знаком, которая в сумме дает общую КР.
Но здесь-то у нас получается одна сумма с +, другая с -, их сумма - верная, но это не разбиение по аналитикам (бить-то нечего на самом деле, у нас одна строка в заказе), т.е. пример:
Должна быть КР на сумму 210,61, система сделала 2 проводки:
одну на 1 990,20, другую на -1 779,59.
Старый 14.10.2016, 11:21   #6  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Ох. Это, наверное, какой-то русский изврат. Конечно должно быть 210. Не встречался с таким поведением на своих проектах кроме того, где мы в Швейцарии начали использовать русскую корреспонденцию. Попробуйте ее отключить для пробы и посмотреть, что будет?
Старый 14.10.2016, 11:29   #7  
ksenia is offline
ksenia
Участник
Аватар для ksenia
 
291 / 28 (1) +++
Регистрация: 11.10.2003
Адрес: Москва
Цитата:
Сообщение от EVGL Посмотреть сообщение
Ох. Это, наверное, какой-то русский изврат. Конечно должно быть 210. Не встречался с таким поведением на своих проектах кроме того, где мы в Швейцарии начали использовать русскую корреспонденцию. Попробуйте ее отключить для пробы и посмотреть, что будет?
Вооооо, именно в этом-то и вопрос. Откуда растут ноги у этого изврата. Возможно, это просто ошибка. В АХ2012 мы наталкивались на несколько ошибок в стандарте именно с курсовой разницей. Но ошибка ли это? Управляемо ли такое поведение? Вот вопрос
Старый 14.10.2016, 11:54   #8  
ksenia is offline
ksenia
Участник
Аватар для ksenia
 
291 / 28 (1) +++
Регистрация: 11.10.2003
Адрес: Москва
Цитата:
Сообщение от ksenia Посмотреть сообщение
Вооооо, именно в этом-то и вопрос. Откуда растут ноги у этого изврата. Возможно, это просто ошибка. В АХ2012 мы наталкивались на несколько ошибок в стандарте именно с курсовой разницей. Но ошибка ли это? Управляемо ли такое поведение? Вот вопрос
Причем суммы эти очень интересные... Первая (которая положительная) - это, кажется сумма себестоимости продаваемой номенклатуры (???), умноженная на разницу в курсах между продажей и оплатой.
Космос какой-то.
Старый 14.10.2016, 14:32   #9  
VORP is offline
VORP
Участник
Аватар для VORP
 
146 / 95 (4) ++++
Регистрация: 26.05.2006
Как предположение - Distributions отсутствуют в заказах(а речь наверное о них, раз упоминается 41 счёт). Зато они присутствуют в FTI, и там "дистрибутится" именно 90 счёт(который в корреспонденции с 62). Может быть делали для FTI, и зацепили заказы. Кроме того, этот код может использоваться для расчёта курсовой по закупке(там тоже есть диструбушены). Возможно, в выборку запроса попадают лишние проводки(41 и Д90), наверное их там быть не должно, они же никак не связаны с выручкой и как бы "внутренние". Как вариант, можно попробовать исключить их из этого запроса по PostingType - SalesConsump кажется и что то ещё хотя бы для эксперимента. Суммы получаются такими, наверное, след образом 210 + 1780(Дт90) = 1990 и -1780(там пропорция считается вроде - и дебеты с кредитами не суммируются).
За это сообщение автора поблагодарили: ksenia (1).
Старый 14.10.2016, 14:34   #10  
ksenia is offline
ksenia
Участник
Аватар для ksenia
 
291 / 28 (1) +++
Регистрация: 11.10.2003
Адрес: Москва
Цитата:
Сообщение от VORP Посмотреть сообщение
Как предположение - Distributions отсутствуют в заказах(а речь наверное о них, раз упоминается 41 счёт). Зато они присутствуют в FTI, и там "дистрибутится" именно 90 счёт(который в корреспонденции с 62). Может быть делали для FTI, и зацепили заказы. Кроме того, этот код может использоваться для расчёта курсовой по закупке(там тоже есть диструбушены). Возможно, в выборку запроса попадают лишние проводки(41 и Д90), наверное их там быть не должно, они же никак не связаны с выручкой и как бы "внутренние". Как вариант, можно попробовать исключить их из этого запроса по PostingType - SalesConsump кажется и что то ещё хотя бы для эксперимента. Суммы получаются такими, наверное, след образом 210 + 1780(Дт90) = 1990 и -1780(там пропорция считается вроде - и дебеты с кредитами не суммируются).
Возможно. Это мы и пытаемся понять. Мы нашли место, которое закомментировать - и все будет хорошо, но хотелось бы понять суть. Пока все выглядит, как баг стандарта.
Старый 14.10.2016, 14:46   #11  
VORP is offline
VORP
Участник
Аватар для VORP
 
146 / 95 (4) ++++
Регистрация: 26.05.2006
Ну суть в том что в расчёт пропорции ошибочно попадают проводки по 41 и Дт90 их надо оттуда исключить, как это было сделано с проводками типа Tax:
generalJournalAccountEntry.PostingType != LedgerPostingType::Tax
Возможно, что надо ещё и Корр счёт исключать. Действительно похоже на баг стандарта, но странно что на него никто до сих пор не натыкался и всё ещё не пофиксили - ведь получается что курсовая по заказу считается неправильно. Хотя, может быть, валютные заказы на продажу не так и много у кого есть...
Старый 14.10.2016, 14:52   #12  
ksenia is offline
ksenia
Участник
Аватар для ksenia
 
291 / 28 (1) +++
Регистрация: 11.10.2003
Адрес: Москва
Цитата:
Сообщение от VORP Посмотреть сообщение
. Действительно похоже на баг стандарта, но странно что на него никто до сих пор не натыкался и всё ещё не пофиксили - ведь получается что курсовая по заказу считается неправильно.
Мы в принципе уже поняли, как исправить, но действительно странно, что никто раньше с этим не сталкивался....
Старый 14.10.2016, 15:51   #13  
VORP is offline
VORP
Участник
Аватар для VORP
 
146 / 95 (4) ++++
Регистрация: 26.05.2006
Не могу воспроизвести Ваш сценарий, этот код вообще не вызывается при сопоставлении валютного заказа и валютной оплаты. Подскажите пожалуйста, какой метод расчёта курсовой у Вас стоит и стоит ли RU в настройках компании? Если можно, было бы интересно посмотреть на stack trace который приводит к этому методу. В каких валютах накладная и оплата?
Старый 14.10.2016, 19:19   #14  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Собственно да, чтобы что-то советовать нужно привести скриншоты ваших настроек курсовых.
__________________
Ivanhoe as is..
Старый 17.10.2016, 10:06   #15  
ksenia is offline
ksenia
Участник
Аватар для ksenia
 
291 / 28 (1) +++
Регистрация: 11.10.2003
Адрес: Москва
Регион - RUS
Метод расчете КР - итого за период
В Параметрах валюты активизированы параметры только для USD, для раздела Клиенты\Заказы установлена "разноска ГК" = "Счет отклонения себестоимости товаров" и настроены 91-е счета.
К слову, если я поменяю "разноска ГК" = "По накладным", то проводка будет одна (хорошо), но на 90-й счет из накладной (плохо).
За это сообщение автора поблагодарили: Logger (1), VORP (2).
Старый 17.10.2016, 14:25   #16  
VORP is offline
VORP
Участник
Аватар для VORP
 
146 / 95 (4) ++++
Регистрация: 26.05.2006
Воспроизвёл, да. Честно говоря не понял почему код стал отрабатывать - у меня тоже стояло Счет отклонения себестоимости товаров. Но даже в этом случае создавалась одна проводка сначала. Ключевым моментом является различие аналитик 41 и 90 счетов в заказе, чтобы при суммировании в цикле они не давали ноль. Аналитика и туда и туда берётся из строк заказа - как вы добились чтоб они отличались - какая то аналитика настроена по умолчанию на 90 м например?

Последний раз редактировалось VORP; 17.10.2016 в 14:38.
Старый 17.10.2016, 15:11   #17  
VORP is offline
VORP
Участник
Аватар для VORP
 
146 / 95 (4) ++++
Регистрация: 26.05.2006
В общем, это ошибка в любом случае. Другое дело что при одинаковых наборах аналитик на 41 и 90 Дт она не проявляется. Если ситуация когда этот набор аналитик отличается часта, то приоритет ошибки будет выше. Пожалуйста, зарегистрируйте багу, если ещё не зарегистрировали.
Старый 17.10.2016, 15:26   #18  
ksenia is offline
ksenia
Участник
Аватар для ksenia
 
291 / 28 (1) +++
Регистрация: 11.10.2003
Адрес: Москва
Цитата:
Сообщение от VORP Посмотреть сообщение
В общем, это ошибка в любом случае. Другое дело что при одинаковых наборах аналитик на 41 и 90 Дт она не проявляется. Если ситуация когда этот набор аналитик отличается часта, то приоритет ошибки будет выше. Пожалуйста, зарегистрируйте багу, если ещё не зарегистрировали.
Зарегистрировали уже :-)
Добиться разных аналитик проще простого - достаточно иметь для 90 и 41 счета совсем разные структуры счета.
В любом случае, спасибо!
Старый 05.12.2016, 18:15   #19  
zhan is offline
zhan
Участник
 
19 / 54 (2) ++++
Регистрация: 17.09.2008
Адрес: Москва
Microsoft выпустил исправление данной ошибки.
KB Article Number : 3208362 RU - Wrong revaluation amounts
За это сообщение автора поблагодарили: Logger (1).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
kurthatlevik: DAX2012 R3 – Playing with Retail CRT Blog bot DAX Blogs 0 28.10.2015 20:11
Перенос настроек и данных DAX2012 R3 MazterHan DAX: Функционал 8 29.05.2015 22:19
kurthatlevik: DAX2012 R3 – Playing with Retail CRT Blog bot DAX Blogs 0 21.05.2015 15:11
Недоступно администрирование и разработка после установки DAX2012 R3 Bega DAX: Администрирование 6 24.01.2015 18:18
DAX: Microsoft Dynamics AX 2012 R3 is now available! Blog bot DAX Blogs 1 02.05.2014 23:00
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:08.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.