Неправильный вывод суммы налогов СФ сбыт

[edward_K]

в 712 вроде есть настройка в параметрах как выводить
либо сумма пересчитываеться, либо береться с документа
в документе то что?
опять же округление видимо не до конца включено.
иначе по одной позиции было-бы нормально.
+ есть проблема в выводе в Rtf и в текстовой форме.
в RTF знаки режуться, в текстовой округляються.

[scanner]

edward_K
Вышупомянутая настройка влияет на НДС в СФ.
А по поводу то что есть настройка тянуть НДС из документа, так это только для накладных, и береться либо из ДО либо считаеться по накладной. Для СФ я такой настройки не нашел скока ни искал.

Интересная у вас проблеммка со знаками, а отчеты идентичные? У нас используються только текстовые отчеты.

[St.Anislav]

Почему выводяться разные суммы в полях по позиции и в поле итого?

Неужели объяснений недостаточно?

Что касается "почему нет контроля" - такой контроль легко осуществить простым анализом двух значений: "сумма округленных позиций" и "округленная сумма позиций" в форме СФ и выводом предупреждения - мол, суммы не сходятся, поправьте выходную форму.
Только смысл-то какой? Это работать будет только в случае наличия одной позиции в СФ (когда мы печатаем с настройкой "группировать позиции"). А что делать в моем примере? Когда есть 2 разные ТМЦ - у одной НДС = 1000.555, у другой НДС = 123.669? КАК должна выглядеть СФ?

[edward_K]

путем подгона формы можно добиться чтобы и овцы были целы и волки сыты.
1. красивый НДС в случае 18% получаеться только если цена без НДС округленна до рубля или 50 копеек( ну документ лучше выписывать что цена не входит - еще одной проблемой меньше) и кол-во не дробное.
2. Во всех других случаях проблемы будут. что-то да не пойдет
3. Логичней все таки чтобы НДС округлялся по позиции - тогда проблем будет чуть меньше.
4.Если же так не устраивает, то я накапливал позиции во времянку.
расхождение с итогом прятал в позицию с наибольшей суммой.
так можно привести суммы чтобы билось все - и строки и столбцы.
Галка тут абсолютно не причем. Математика она и в африке математика. Так что играйтесь с ценой без налогов или прячте - выбора нет.

[scanner]

St.Anislav edward_K
Ну чтож пусть так, получается все смирились. Если нельзя подстроить систему под себя, приходиться подстраиваться под систему. В данном же случае, если посмотреть немного шире, то на СФ все не заканчиваеться.

Как быть с проплатой? Получается что проплата идет по ДО, а НДС возмещаеться по книге покупок/продаж. Соответственно у нас будут разные данные.

St.Anislav
Ваш совет выверять все суммы довольно интересен. Это ж насколько автоматизированная система, что пользователям приходиться смотреть что твориться в разных документах и "подгонять" под то, что должно быть. В случае с отчетами сверки все же это выход, спасибо за идею, придеться писать.

На вопрос о том, все ли вы достаточно объяснили отвечаю. Просто хотелось услышать независимое мнение по этому поводу и поднять проблемму на всеобщее обозрение.

edward_K
По поводу того, чтобы ставить цену без НДС так идея то хорошая, только тогда цены нужно высчитывать, а так они по прайсу беруться и все.

[St.Anislav]

приходиться подстраиваться под систему

Заметьте, подстраиваться не под Галактику, а под математику:)

что должно быть

Вот! Вот! Прекрасный вопрос! "ЧТО ДОЛЖНО БЫТЬ?"!
Я уже раз ПЯТЬ просил, можно сказать - умолял:) : ну скажите, как же должно быть? Как нам печатать СФ с такими-то данными? (даже в форуме этот вопрос вам задавал - ответа не дождался). Может, все же возьмете на себя труд ответить? А то ваша позиция звучит "я не знаю, как правильно, но Галактика делает неверно". Неконструктивно.

Что касается

услышать независимое мнение по этому поводу

Мне и самому интересно было в форуме проблему обсудить - а вдруг я решения проглядел? Не проглядел...

Насчет подгона формы - это выход, но в некоторых случаях - как раз в вашем, когда СФ сформирована по 2 совершенно одинаковым накладным - это не пройдет, т.к. позиции будут различаться.

[scanner]

St.Anislav

подстраиваться не под Галактику, а под математику

Подстраиваться приходиться скорее под алгоритм расчета НДС, котрый применяеться в Галактике. Намного проще было бы считать НДС по каждой позиции спецификации и соответственно потом сумму выводить в итог. Если данную схему применить для всех документов, то суммы будут меньше теряться. Думал догадаетесь хоть на другие системы посмотреть (1С например).

[St.Anislav]

Такое ощущение, что вы не хотите понять работу механизма расчета НДС в Галактике. При соотв. настройке он работает ИМЕННО так как вы описали - т.е.

считать НДС по каждой позиции спецификации и соответственно потом сумму выводить в итог

Приведу пример (вряд ли он вас убедит, но все же):
есть 2 одинаковык накладные, в каждой - по 2 МЦ ценой (с НДС 10%) 850 руб. Итого = 2*850 = 1700 руб. НДС = 1700/11=154,54545...~154.55 (по настройке округления в накладных). Таких накладных 2, и общий НДС = 154.55*2=309.10
Если бы Галактика считала НДС как вы о ней думаете (т.е. с общей суммы), то мы получили бы НДС=(1700*2)/11=309.090909...~309.09
Теперь сформируем СФ по этим 2 накладным. Смотрим: НДС = 309.10.
Каждая позиция СФ соответствует соотв. позиции накладной, потому и суммы одинаковые.

[scanner]

St.Anislav
Ну что ж вы начинаете противоречить сами себе. привету пример. Меняем настройку "использовать неокругленные значения при выделении НДС" в "Нет" (настройка упомянута выше), цену ставим 5500 и что?

Получаем 5500/1,1=5000. Все точно и неокруглено. Попробуйте то же самое сделать в спецификации СФ. Нет Галактика выдан 5000.05. Про копейкм вы уже писали, да и я тоже писал, так что алгоритм мы разбирали и был он немного не таким как вы его описали в предыдущем сообщении. Ну что ж может я не прав. Опять же это не я приводил 2 алгоритма разных.

Если при даннм примере поставить вашу цену 850р, то получается невообразимое 772.734999999999. Ну и где скажите округление?

[St.Anislav]

(начинаю терять разум)
Однако, раззадорили вы меня:)
Итак, по пунктам.

Меняем настройку "использовать неокругленные значения при выделении НДС" в "Нет" (настройка упомянута выше), цену ставим 5500 и что?

Ставим настройку "при выделении НДС использовать неокругленные значения" в НЕТ (напомню, что это значит, что 10% НДС будет считаться как 0,09090000000 от общей суммы, а не 0,09090909090909...)
Создаем накладную. Цена = 5500, налоги ВХОДЯТ в цену.
Смотрим. НДС = 68*5500*0,0909=33996,60
Сумма без НДС=68*5500-33996,60=340003,40
Цена без НДС=340003,40/68=5000,05
Создаем теперь СФ на основании этого документа. И что мы видим? Цена без НДС ИМЕННО 5000,05! ГДЕ расхождения? А?

Ставим настройку в ДА - получаем сумма НДС = 68*5500/11=34 000, сумма без НДС = (68*5500-34000)/68 = 5000.00
Формируем СФ по документу - и что же видим? В ТОЧНОСТИ такие же суммы. Где же здесь расхождения?

Далее.

Алгоритм мы разбирали и был он немного не таким как вы его описали в предыдущем сообщении. Ну что ж может я не прав. Опять же это не я приводил 2 алгоритма разных.

Не надо путать алгоритм расчета НДС и проблемы округления! В самом начале у вас суммы НДС в накладной были НЕОКРУГЛЕННЫЕ, потому и были расхождения в СФ с несколькими (в вашем случае - одинаковыми) строками и итогом. При округлении значения НДС в накладных до копеек и включении НДС в цену такой проблемы в принципе не возникает (правда, возникает другая - расхождение с ДО).

Теперь насчет

Получаем 5500/1,1=5000.

В том-то и дело, что НЕ ПОЛУЧАЕМ! Когда НДС НЕ ВКЛЮЧЕН В ЦЕНУ, то алгоритм расчета НДС = сумма*ставка НДС, и копейки тут могут теряться только при, скажем так, не очень целом количестве. Тогда да, раз цена с НДС = цена*1.1, то цена без НДС = цена с НДС/1.1, тут вы правы.
Но когда НДС ВКЛЮЧЕН В ЦЕНУ, то цена без НДС = (сумма-НДС)/количество, и это отнюдь не всегда = цена с НДС/1.1.
Понимаете? Когда НДС включен в цену, значение "цена без НДС" становится, так сказать, виртуальным, расчетным, и точно его получить невозможно. Вот укажите мне, ГДЕ в накладной на отпуск указана цена без НДС при входимости налогов в цену? А нигде. Нет его.

[scanner]

ГДЕ в накладной на отпуск указана цена без НДС при входимости налогов в цену? А нигде. Нет его.

Торг12

[St.Anislav]

В Торг12 выводится расчетное значение цены без НДС, расчитывается оно точно так же как в СФ.
Уточню вопрос: в каком поле БД хранится информация о цене без НДС накладной?