Округление, НДС

[SVG]

Навижн считает НДС правильно. Зуб даю
Читайте стандрепортменеджмент.

[rov_imported]

Цитата:

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

Навижн считает НДС правильно.

Нет-давай зуб!
На самом деле конечно же Нав считает правильно, НО:
кроме одного случая - который и описан выше - это прогисходит при настройках
округления до 2 знаков, в случаях, когда 3 десятичная цифра - 5.
Эта проблема есть. Я её встречал и в платежках(валютных) и в инвентаризации.
Более того, в инвент. эти самые ХХХ.315 в одном случае могут уйти в фин. книгу как
ХХХ.32, а в другом случае - как ХХХ.31. До сих пор нет четкого мнения а как же должно быть.
Я как правило лечу это парой строк хитрого кода суть - сначала надо округлить
до 3 знаков, потом до 2. В большинстве случаев - помогает. Но иногда - нет.
Тогда надо ещё пару строк - анализ разницы между ХХХ.315 и неокругенным ХХХ.
В зависимости от величины этой разницы надо руками округлять вверх или вниз.
В общем сложно я ответил - извиняйте, как мог...

P.S. Понятно, что никакие настройки Down по округлению использовать нельзя - только ближайшее.

[Sitizen]

Цитата:

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

Цитата:

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

Навижн считает НДС правильно.

Нет-давай зуб!
На самом деле конечно же Нав считает правильно, НО:
кроме одного случая - который и описан выше - это прогисходит при настройках
округления до 2 знаков, в случаях, когда 3 десятичная цифра - 5.
Эта проблема есть. Я её встречал и в платежках(валютных) и в инвентаризации.
Более того, в инвент. эти самые ХХХ.315 в одном случае могут уйти в фин. книгу как
ХХХ.32, а в другом случае - как ХХХ.31. До сих пор нет четкого мнения а как же должно быть.
Я как правило лечу это парой строк хитрого кода суть - сначала надо округлить
до 3 знаков, потом до 2. В большинстве случаев - помогает. Но иногда - нет.
Тогда надо ещё пару строк - анализ разницы между ХХХ.315 и неокругенным ХХХ...

Можно еще использовать финансовое округление - это когда 5 округляется вверх или вниз в зависимости от четности следующего знака. Если четный, то вверх, если не четный - вниз.

[rov_imported]

Цитата:

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

Можно еще использовать финансовое округление - это когда 5 округляется вверх или вниз в зависимости от четности следующего знака. Если четный, то вверх, если не четный - вниз.

Круто - не знал. Но в Нав. вроде в настройках такого нет? Или есть?
Ну и типа как не поможет - число ХХХ.3159 в таком случае будет ХХХ.316 и далее ХХХ.32 -
что не есть гуд.
Или имеется ввиду знак перед 5-кой?

[Sitizen]

Цитата:

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

Цитата:

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

Можно еще использовать финансовое округление - это когда 5 округляется вверх или вниз в зависимости от четности следующего знака. Если четный, то вверх, если не четный - вниз.

Круто - не знал. Но в Нав. вроде в настройках такого нет? Или есть?
Ну и типа как не поможет - число ХХХ.3159 в таком случае будет ХХХ.316 и далее ХХХ.32 -
что не есть гуд.
Или имеется ввиду знак перед 5-кой?

Нет в Нав такого нет.
Имеется в виду знак после 5. Т.е. ХХХ.3159 (9-ка нечетная) округляется до ХХХ.315, а ХХХ.3152 (2 - четное) - до ХХХ.316.
С первого взгляда выглядит не правильно, но если взять массив данных, то при таком округлении погрешность будет меньше, чем при математическом округлении.
Только вот, честно говоря, не знаю, как это объяснить на формулах.

[Konstantin I]

Цитата:

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

Навижн считает НДС правильно. Зуб даю
Читайте стандрепортменеджмент.

И в этом случае ???:
2.Поставщики. Алгоритм подсчета НДМ насколько я понял: Сумма всех строк без НДС + считаем 18% получаем сумму счета.
Хочу считать НДС В каждой строке,а не скопом, как это настроить.


Осталось это донести пользователям которые регистрируют сч/ф сробленные в 1С, а там по каждой строке считается НДС и лишь в конце все суммируется.

Вот какой из алгоритмов верный ?!

[rov_imported]

Цитата:

Сообщение от Константин I

Вот какой из алгоритмов верный ?!

К сожалению этот вопрос тоже больной.
На мой личный взгляд, вариант Навижн более правильный - он гарантирует
выполнение равенства: "сумма без НДС по документу*18%"=Сумма НДС по документу.
Основной объект учета (по крайней мере в РФ ) - это документ. В целом документ. А не его строки.
И при любых проверках и сверках, как налоговых так и пр. органов проверяться будут суммы
именно документа, а не строк.
А при варианте расчета НДС построчно достаточна велика вероятность, что НДС сложенный по строчкам
ни фига не совпадет с НДС в целом по документу.

[Konstantin I]

Цитата:

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

Цитата:

Сообщение от Константин I

Вот какой из алгоритмов верный ?!

К сожалению этот вопрос тоже больной.
На мой личный взгляд, вариант Навижн более правильный - он гарантирует
выполнение равенства: "сумма без НДС по документу*18%"=Сумма НДС по документу.
Основной объект учета (по крайней мере в РФ ) - это документ. В целом документ. А не его строки.
И при любых проверках и сверках, как налоговых так и пр. органов проверяться будут суммы
именно документа, а не строк.
А при варианте расчета НДС построчно достаточна велика вероятность, что НДС сложенный по строчкам
ни фига не совпадет с НДС в целом по документу.

сумма без НДС по документу*18%"=Сумма НДС по документу это в системе равенство. а вот если взять бумажный документ (входящий, сделанный в какой нить 1С), то это равенство мало того что не выполняется, но и бухгалтерии требуется вести учет исходя из сумм указанных в документе и никого не волнует, что в самом документе-бумажном не верно...