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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 06.03.2006, 15:31   #1  
Konstantin I is offline
Konstantin I
Участник
 
45 / 10 (1) +
Регистрация: 07.10.2004
1.Клиенты. Считаем руками НДС сверху с суммы 632751,75
НДС получается 113 895,315
Навижн округляет 113895,32

как заставить его посчитать 113 895,31 ??? Ну кроме НДС разници конечно же.

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

Естественно есл ивсе эти хотелки возможны.
Спасибо.
Старый 05.04.2006, 11:34   #2  
Sand is offline
Sand
Участник
 
16 / 10 (1) +
Регистрация: 23.05.2003
Для 4.00Sp1:
1. А если поиграть с General Ledger Setup - VAT Rounding Type:own?
Только если это и сработает (я не уверен), то в другом случае вы, вдруг, захотите по-другому округлить и что тогда?

2. Никак. Было в 3.70 поле Calculate VAT per Lines в Sales & Receivables Setup, но сейчас функционал убит. В версии 5.00 быть может что-то и появится.
Старый 05.04.2006, 18:04   #3  
SVG is offline
SVG
Участник
 
201 / 10 (1) +
Регистрация: 15.11.2004
Навижн считает НДС правильно. Зуб даю
Читайте стандрепортменеджмент.
Старый 06.04.2006, 10:55   #4  
rov_imported is offline
rov_imported
Участник
 
176 / 10 (1) +
Регистрация: 20.01.2005
Цитата:
Сообщение от SVG Посмотреть сообщение
Навижн считает НДС правильно.
Нет-давай зуб!
На самом деле конечно же Нав считает правильно, НО:
кроме одного случая - который и описан выше - это прогисходит при настройках
округления до 2 знаков, в случаях, когда 3 десятичная цифра - 5.
Эта проблема есть. Я её встречал и в платежках(валютных) и в инвентаризации.
Более того, в инвент. эти самые ХХХ.315 в одном случае могут уйти в фин. книгу как
ХХХ.32, а в другом случае - как ХХХ.31. До сих пор нет четкого мнения а как же должно быть.
Я как правило лечу это парой строк хитрого кода суть - сначала надо округлить
до 3 знаков, потом до 2. В большинстве случаев - помогает. Но иногда - нет.
Тогда надо ещё пару строк - анализ разницы между ХХХ.315 и неокругенным ХХХ.
В зависимости от величины этой разницы надо руками округлять вверх или вниз.
В общем сложно я ответил - извиняйте, как мог...

P.S. Понятно, что никакие настройки Down по округлению использовать нельзя - только ближайшее.
Старый 06.04.2006, 12:38   #5  
Sitizen is offline
Sitizen
Участник
Аватар для Sitizen
 
305 / 10 (1) +
Регистрация: 10.01.2006
Цитата:
Сообщение от rov Посмотреть сообщение
Цитата:
Сообщение от SVG Посмотреть сообщение
Навижн считает НДС правильно.
Нет-давай зуб!
На самом деле конечно же Нав считает правильно, НО:
кроме одного случая - который и описан выше - это прогисходит при настройках
округления до 2 знаков, в случаях, когда 3 десятичная цифра - 5.
Эта проблема есть. Я её встречал и в платежках(валютных) и в инвентаризации.
Более того, в инвент. эти самые ХХХ.315 в одном случае могут уйти в фин. книгу как
ХХХ.32, а в другом случае - как ХХХ.31. До сих пор нет четкого мнения а как же должно быть.
Я как правило лечу это парой строк хитрого кода суть - сначала надо округлить
до 3 знаков, потом до 2. В большинстве случаев - помогает. Но иногда - нет.
Тогда надо ещё пару строк - анализ разницы между ХХХ.315 и неокругенным ХХХ...
Можно еще использовать финансовое округление - это когда 5 округляется вверх или вниз в зависимости от четности следующего знака. Если четный, то вверх, если не четный - вниз.
Старый 06.04.2006, 12:59   #6  
rov_imported is offline
rov_imported
Участник
 
176 / 10 (1) +
Регистрация: 20.01.2005
Цитата:
Сообщение от Sitizen Посмотреть сообщение
Можно еще использовать финансовое округление - это когда 5 округляется вверх или вниз в зависимости от четности следующего знака. Если четный, то вверх, если не четный - вниз.
Круто - не знал. Но в Нав. вроде в настройках такого нет? Или есть?
Ну и типа как не поможет - число ХХХ.3159 в таком случае будет ХХХ.316 и далее ХХХ.32 -
что не есть гуд.
Или имеется ввиду знак перед 5-кой?
Старый 06.04.2006, 13:58   #7  
Sitizen is offline
Sitizen
Участник
Аватар для Sitizen
 
305 / 10 (1) +
Регистрация: 10.01.2006
Цитата:
Сообщение от rov Посмотреть сообщение
Цитата:
Сообщение от Sitizen Посмотреть сообщение
Можно еще использовать финансовое округление - это когда 5 округляется вверх или вниз в зависимости от четности следующего знака. Если четный, то вверх, если не четный - вниз.
Круто - не знал. Но в Нав. вроде в настройках такого нет? Или есть?
Ну и типа как не поможет - число ХХХ.3159 в таком случае будет ХХХ.316 и далее ХХХ.32 -
что не есть гуд.
Или имеется ввиду знак перед 5-кой?
Нет в Нав такого нет.
Имеется в виду знак после 5. Т.е. ХХХ.3159 (9-ка нечетная) округляется до ХХХ.315, а ХХХ.3152 (2 - четное) - до ХХХ.316.
С первого взгляда выглядит не правильно, но если взять массив данных, то при таком округлении погрешность будет меньше, чем при математическом округлении.
Только вот, честно говоря, не знаю, как это объяснить на формулах.
Старый 06.04.2006, 16:38   #8  
Konstantin I is offline
Konstantin I
Участник
 
45 / 10 (1) +
Регистрация: 07.10.2004
Цитата:
Сообщение от SVG Посмотреть сообщение
Навижн считает НДС правильно. Зуб даю
Читайте стандрепортменеджмент.
И в этом случае ???:
2.Поставщики. Алгоритм подсчета НДМ насколько я понял: Сумма всех строк без НДС + считаем 18% получаем сумму счета.
Хочу считать НДС В каждой строке,а не скопом, как это настроить.


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

Вот какой из алгоритмов верный ?!
Старый 06.04.2006, 16:52   #9  
rov_imported is offline
rov_imported
Участник
 
176 / 10 (1) +
Регистрация: 20.01.2005
Цитата:
Сообщение от Константин I Посмотреть сообщение
Вот какой из алгоритмов верный ?!
К сожалению этот вопрос тоже больной.
На мой личный взгляд, вариант Навижн более правильный - он гарантирует
выполнение равенства: "сумма без НДС по документу*18%"=Сумма НДС по документу.
Основной объект учета (по крайней мере в РФ ) - это документ. В целом документ. А не его строки.
И при любых проверках и сверках, как налоговых так и пр. органов проверяться будут суммы
именно документа, а не строк.
А при варианте расчета НДС построчно достаточна велика вероятность, что НДС сложенный по строчкам
ни фига не совпадет с НДС в целом по документу.
Старый 07.04.2006, 17:50   #10  
Konstantin I is offline
Konstantin I
Участник
 
45 / 10 (1) +
Регистрация: 07.10.2004
Цитата:
Сообщение от rov Посмотреть сообщение
Цитата:
Сообщение от Константин I Посмотреть сообщение
Вот какой из алгоритмов верный ?!
К сожалению этот вопрос тоже больной.
На мой личный взгляд, вариант Навижн более правильный - он гарантирует
выполнение равенства: "сумма без НДС по документу*18%"=Сумма НДС по документу.
Основной объект учета (по крайней мере в РФ ) - это документ. В целом документ. А не его строки.
И при любых проверках и сверках, как налоговых так и пр. органов проверяться будут суммы
именно документа, а не строк.
А при варианте расчета НДС построчно достаточна велика вероятность, что НДС сложенный по строчкам
ни фига не совпадет с НДС в целом по документу.
сумма без НДС по документу*18%"=Сумма НДС по документу это в системе равенство. а вот если взять бумажный документ (входящий, сделанный в какой нить 1С), то это равенство мало того что не выполняется, но и бухгалтерии требуется вести учет исходя из сумм указанных в документе и никого не волнует, что в самом документе-бумажном не верно...
Старый 24.04.2006, 17:29   #11  
a_mitin is offline
a_mitin
Участник
 
18 / 10 (1) +
Регистрация: 24.04.2006
Цитата:
Сообщение от rov Посмотреть сообщение
Цитата:
Сообщение от Константин I Посмотреть сообщение
Вот какой из алгоритмов верный ?!
К сожалению этот вопрос тоже больной.
На мой личный взгляд, вариант Навижн более правильный - он гарантирует
выполнение равенства: "сумма без НДС по документу*18%"=Сумма НДС по документу.
Основной объект учета (по крайней мере в РФ ) - это документ. В целом документ. А не его строки.
И при любых проверках и сверках, как налоговых так и пр. органов проверяться будут суммы
именно документа, а не строк.
А при варианте расчета НДС построчно достаточна велика вероятность, что НДС сложенный по строчкам
ни фига не совпадет с НДС в целом по документу.
Вопрос действительно больной (есть ещё один из этой же серии, когда просят включить в документ колонку "Цена С НДС" ), поэтому выскажу противоположную точку зрения (тоже личный взгляд ) Если считать НДС на сумму документа, то как раз в этом случае не совпадет сумма (часто), напечатанная в стоках документа (если там напечатаны 2 знака после запятой) с суммой всего документа. А контролирующие органы могут это признать "неправильным оформлением документа".
Поэтому здесь либо - либо. Либо окруляешь построчно и честно складываешь (плохо что общая сумма НДС <>18% от суммы без НДС) либо берешь 18% от общей суммы без НДС - тогда не сходится (в общем случае) сумма НДС по строкам с общей суммой НДС в документе. Наши бухи уже даавно выбрали первый вариант и работают по нему.
ЗЫ: Может быть ещё и третий вариант - округлять построчно, суммировать, посчитать 18% от общей суммы без НДС, сравнить суммы и разницу разнести по строкам Но такой реализации я не встречал.


Цитата:
Сообщение от Константин I Посмотреть сообщение
сумма без НДС по документу*18%"=Сумма НДС по документу это в системе равенство. а вот если взять бумажный документ (входящий, сделанный в какой нить 1С), то это равенство мало того что не выполняется, но и бухгалтерии требуется вести учет исходя из сумм указанных в документе и никого не волнует, что в самом документе-бумажном не верно...
Так этож входящий - берешь в заказе покупки НДС исправляешь и всё будет хорошо. Вроде бы стандартная фича (правишь на форме статистики в строках в состоянии ТоварОтгружен).
Старый 25.04.2006, 10:50   #12  
Konstantin I is offline
Konstantin I
Участник
 
45 / 10 (1) +
Регистрация: 07.10.2004
Цитата:
Сообщение от a_mitin Посмотреть сообщение
Цитата:
Сообщение от Константин I Посмотреть сообщение
сумма без НДС по документу*18%"=Сумма НДС по документу это в системе равенство. а вот если взять бумажный документ (входящий, сделанный в какой нить 1С), то это равенство мало того что не выполняется, но и бухгалтерии требуется вести учет исходя из сумм указанных в документе и никого не волнует, что в самом документе-бумажном не верно...
Так этож входящий - берешь в заказе покупки НДС исправляешь и всё будет хорошо. Вроде бы стандартная фича (правишь на форме статистики в строках в состоянии ТоварОтгружен).
Это не автоматизация,а херня на палочке имхо. Лезть, править не камильфо...
Старый 25.04.2006, 10:57   #13  
dlelikov is offline
dlelikov
Участник
 
2 / 10 (1) +
Регистрация: 14.02.2007
Есть еще одна проблема с НДС, связанная с документами в валюте. (Nav 4.00)
Пример: есть счет покупки, сумма без НДС = 9628.08 Евро, сумма НДС расчитывается системой как 1733.05, сумма с НДС = 11361.13 Евро. Курс Евро = 34.2633. При учете в фин книгу прописываются суммы в рублях: сумма без НДС = 329889.79, сумма НДС = 59380.02, сумма с НДС = 389269.81.
Т.е. система каждую сумму в валюте умножает на курс и получает сумму в рублях. А вот налоговая инспекция, например, сумму НДС считает: 389269.81*18/118 = 59380.14.
Итого по системе НДС = 59380.02, а должно быть 59380.14, разница в 12 копеек.

Может кто сталкивался и решал? И как было в 3.7?
Старый 25.04.2006, 11:44   #14  
a_mitin is offline
a_mitin
Участник
 
18 / 10 (1) +
Регистрация: 24.04.2006
Цитата:
Сообщение от Константин I Посмотреть сообщение
Цитата:
Сообщение от a_mitin Посмотреть сообщение
Так этож входящий - берешь в заказе покупки НДС исправляешь и всё будет хорошо. Вроде бы стандартная фича (правишь на форме статистики в строках в состоянии ТоварОтгружен).
Это не автоматизация,а херня на палочке имхо. Лезть, править не камильфо...
Ну автоматизируй, кто тебе не даёт. Купи у FineReaderовскую ocx-ину, заставь сканировать все входящие счета-фактуры, распознавай автоматом суммы НДС и правь автоматически в документах покупки в учетной системе (заодно и весь приход автоматом оформляй ибо какая-же автоматизация - приходится руками покупки долбить ). Ну или "построй" всех своих поставщиков и заставь их "правильно" (по твоему алгоритму) выписывать все счета-фактуры, которые они выставляют Вашей компании, а "неправильные" счета - не принимайте...

Возвращаюсь на землю - на мой взгляд сейчас больше учетных систем с построчным расчетом (имхо, могу и ошибаться), поэтому если именно так сделать в своей учетной системе при оформлении покупок - случаев необходимой правки будет меньше, но они всё равно будут.

ЗЫ: не понравилось выражение "херня на палочке"
Старый 25.04.2006, 14:55   #15  
Sancho is offline
Sancho
Administrator
Аватар для Sancho
Лучший по профессии 2017
Лучший по профессии 2009
 
1,284 / 201 (9) ++++++
Регистрация: 11.01.2006
построчный расчет в ПЕЧАТНОЙ форме приведет к расхождению сумм ВСЕГО документа.
а в самой системе суммы всего документа сходятся
клиент будет платить по тому, что ему вышлют, т.е. по ПЕЧАТНОЙ форме.
из-за этих двух копеек никогда в 0 не применятся оплаты к счетам и операции будут оставаться на децл но открытыми.

меня в одном офисе прогнули на построчный расчет, самому теперь стыдно вспоминать, что согласился.

вывод: зуб СВГ остается с СВГ, не парьте голову, используйте стандарт Нав.
Старый 25.04.2006, 15:20   #16  
a_mitin is offline
a_mitin
Участник
 
18 / 10 (1) +
Регистрация: 24.04.2006
Цитата:
Сообщение от Sancho Посмотреть сообщение
построчный расчет в ПЕЧАТНОЙ форме приведет к расхождению сумм ВСЕГО документа.
а в самой системе суммы всего документа сходятся
клиент будет платить по тому, что ему вышлют, т.е. по ПЕЧАТНОЙ форме.
из-за этих двух копеек никогда в 0 не применятся оплаты к счетам и операции будут оставаться на децл но открытыми.

меня в одном офисе прогнули на построчный расчет, самому теперь стыдно вспоминать, что согласился.

вывод: зуб СВГ остается с СВГ, не парьте голову, используйте стандарт Нав.
Что Вы хотите сказать фразой "построчный расчет в ПЕЧАТНОЙ форме приведет к расхождению сумм ВСЕГО документа." - округление только при печати? Конечно же это нонсенс. Печатать нужно только то, что сохранено в системе, и никаких проблем с применением оплаты в этом случае нет.
 

Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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