Галактика в вопросах и ответах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что касается

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

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

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

St.Anislav

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

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

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

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

Приведу пример (вряд ли он вас убедит, но все же):
есть 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.
Каждая позиция СФ соответствует соотв. позиции накладной, потому и суммы одинаковые.

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

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

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

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

Меняем настройку "использовать неокругленные значения при выделении НДС" в "Нет" (настройка упомянута выше), цену ставим 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.
Понимаете? Когда НДС включен в цену, значение "цена без НДС" становится, так сказать, виртуальным, расчетным, и точно его получить невозможно. Вот укажите мне, ГДЕ в накладной на отпуск указана цена без НДС при входимости налогов в цену? А нигде. Нет его.

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

Торг12

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