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

Галактика 5.85.02
Есть отгрузка, налоги не входят - одна позиция:
кол-во 1910 цена 0.85 стоимость 1623.5
по док-ту сумма без ндс - 1623.5, НДС - 292.23, общая 1915.73

По этому ДО идут три платежа с суммами соответсвенно:
644.20
586.10
685.43

При привязке первых двух платежей, оплаченные налоги получаются:
98.27
89.41

А вот при привязке третьего платежа, она считает что оплаченный налог 104.56.
Если сложить эти три сумму, то получим 292.24, что отличается от отгрузочного НДС.

При попытке зарегистрировать третью С/Ф в книге продаж, вылетает сообщение, что не соответсвует НДС в отгрузке и платежах (оно и понятно, на копейку меньше должно быть). И регистрирует в книге как НДС - 104.55, Сумма с НДС 685.42 - что на копейку меньше платежа. В результате С/Ф пишется как незарегистрированная.

Может кто в курсе в чём тут дело? Почему при регистрации она правильно считает сумму НДС а при привязке ДО, расчитывает её неверно и ставит в оплаченные налоги расчетную, несмотря на то, что по отгрузке остаток НДС на копейку меньше?

Спасибо за ранее всем, кто откликнется...

Мы тоже ничего не можем поделать. Если только вручную исправлять в регистрации, если немного, а так ну и пусть.

Разъезжается на копейку... хотя думаю если сделать платежей штук 10, может вылезти и 2 копейки. Отпраил запрос в ТП сегодня - жду

Это обычная погрешность округления, чистая арифметика.
Обратите внимание на столбец НДС без округления
Сумма платежа НДС округл. НДС не округл.
644,20000 98,27 98,26780
586,10000 89,41 89,40508
685,43000 104,56 104,55712
1915,73000 292,24 292,23000

и заметьте Галактика расчитала все правильно, а результат ...
Такие погрешности могут вылезать когда идет деление (на накладные , СФ и пр.)
Ибо погрешность округления - явление природы, смиритесь
В свое время в одной о-ч-чень крупной конторе дабы уменьшить погрешности декларативно постановили устанавливать "круглые цены" без НДС.

Ну вот, были такие ровненькие столбики цифр, а теперь все в кучке
Уж извините, не знаяю как исправить

ElenaNikolaevna
Если введёте такой пример в Галактику и зайдёте в платежи, хоз.операции, оплаченные налоги, то видно, что НДС округляется до копеек.

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

Я думаю это просто "явная недоработка" программеров. Здесь нет ничего сложного найти дельту при подсчете и избавится от неё.

По крайней мере, когда в учете ТМЦ я писал ТХО АПИ по распределению ТЗР по материалам, я ведь тоже получал округленные копейки в бух.проводках (т.к. проводки могут быть только с копейками) и уже сравнивал полученную сумму с тем что должно было быть. Получал дельту и отправлял её по желанию на первую/последнюю позицию.

Всё таки дождусь ответа из ТП, посмотрю - что мне скажут.

Ну, ждите-ждите
тем более, что у вас 5.85

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

Seybukan
не пару а три

Все таки пару, так как НДС "по старому" будет действовать до 01.01.2008.
Очевидно спутали со списанием задолженности.

Галактика 5.85.02
В общем проблема для платформы Btrieve решалась просто:
Настройка "=Настройка=\Настройка\Оперативный контур\Налоги, счета-фактуры\Переразносить суммы в документе по платежу при
несоответствии с ТСД"=ДА.
Всё работает.

На MS SQL сложнее, там не отработало даже с настройкой. Проблема помещена в ПИР № 101.32288.

Алексей писал(а):На MS SQL сложнее, там не отработало даже с настройкой. Проблема помещена в ПИР № 101.32288.

Для какой версии помещена в ПИР и когда именно??

Я же написал, 5.85.02 для платформы MS SQL
Для Бтрива всё работает и так.

НУ вот, сегодня получил спец.патч для 5.85.02. Написали что это только для MS SQL - я там и проверял, работает.
Но проблемы были и под Бтривом - почему только для SQL, не знаю. Надо бы его ещё и под Бтривом проверить.

И почему спец патч, тоже не понял, нам одним что ли это надо?

Этот патч при формировании С/Ф, ПРАВИЛЬНО расчитывает оплаченные налоги в ФРО и ПРАВИЛЬНО регистрирует С/Ф в книге продаж.
Т.е. считает что бы оплаченных налогов не появилось на копейку больше положенных отгруженных.

Круто!

Наконец-то, могут ведь когда захотят...