|
![]() |
#1 |
Участник
|
В том то все и дело, что при проверке у меня такая ситуация не повторяется. При этом я попробывал на двух базах: настроенная с модификациями и пустая без модификаций. Пробовал варианты со включенным налогом в сумму и нет, во всех ситуациях налог считается правильно. В связи с этим я склоняюсь к мнению, что Ваши разработчики все же могли внести модификации в функциональность связанную с заказами, ценовыми соглашениями или валютами. На самом деле, такое расхождение, при наличии модификаций в системе, можно получить разными способами. На мой взгляд, стоит заставить программиста или самостоятельно, проверить механизм получения Вашей суммы в отладчике. Таким обрабом вы абсолютно точно можете установить причину столь неприятного казуса.
Мне кажется, что люди, которые выполняли модификацию, если они "зацепили" функциональность подсчета налога, просто забыли выполнить округление результата. Такой результат, как у Вас можно получить, если после подсчета суммы налога не вызвать функцию округления (Currency::amount(Сумма, [Валюта])), тогда система может просто "обрезать" дробную часть числа.
__________________
Ax 3.0 SP3 |
|
|
За это сообщение автора поблагодарили: Venera (4). |
![]() |
#2 |
Участник
|
Спасибо за подсказки, добрый человек, будем искать...
|
|
![]() |
#3 |
Участник
|
Посмотрте настройку расчета в налоговом коде. Должно стоять:
Основание: Процент от чистой суммы Основа для расчета: Чистая сумма по строке Если стоит "Чистая сумма, указанная в счете" то НДС рассчитывается от всей суммы, а затем раскидывается на строки. Если несколько строк, могут быть отклонения. |
|
|
За это сообщение автора поблагодарили: Venera (4), Dozer (1). |
![]() |
#4 |
Участник
|
Алексей Контев, выражаю искреннюю благодарность и уважение. Это то, что надо.
|
|
Теги |
заказ, налоги |
|
![]() |
||||
Тема | Ответов | |||
вопрос про дату в range. помогите разобраться. | 5 | |||
Помогите с алгоритмом | 1 | |||
Помогите написать запрос | 7 | |||
Курсовые разницы! Помогите! | 7 | |||
Помогите новичку: импорт | 6 |
|