Имя: Пароль:
1C
1С v8
УТ. Проблемы с округлением сумм в реализации
0 Sun125
 
22.09.15
10:31
Конфигурация УТ 11.
Есть один большой Заказ клиента. На основании этого заказа может быть сформировано несколько реализаций. Поэтому в результате округления,если сложить все суммы по реализации, то итоговая сумма НЕ равна сумме в Заказе клиента.
Подскажите,пожалуйста, наверное многие сталкивались, кто как с этим борется?
1 Sun125
 
22.09.15
10:36
Возникают расхождения в несколько копеек. Клиент платит сумму из заказа клиента, а в итоге реализация на несколько копеек больше или меньше. Появляется остаток по контрагенту.
2 spectre1978
 
22.09.15
10:38
ну можно, например, написать обработку, которая будет делать корректировку последней реализации так чтобы общая сумма по всем реализациям совпадала с заказом.
3 Ненавижу 1С
 
гуру
22.09.15
10:38
переносите суммы из заказа "как есть"
4 spectre1978
 
22.09.15
10:39
(3) а если одна позиция заказа бьется на несколько реализаций?
5 Sun125
 
22.09.15
10:41
(4) Именно так и есть. Одна позиция разбивается на несколько реализаций.
6 VikingKosmo
 
22.09.15
10:44
Спишите эти копейки в конце месяца
7 НЕА123
 
22.09.15
10:47
(2)+1
если остаток колва = 0 то всю оставшуюся сумму.
ЗЫ.
когда колво в 0 не выходит - это да... такое счастье...
8 spectre1978
 
22.09.15
10:50
(5) Увеличить точность можно правильным расчетом суммы. Сумму реализации надо считать как количество реализации * (сумма заказа / количество заказа), и только так. Нигде не используйте цену заказа при расчетах, только (сумма заказа / количество заказа). Но все равно в конце может получиться копеечная разница, поэтому не исключено что понадобится (2).
9 exchang
 
22.09.15
10:54
(8) если цены фиксированы и указаны по договору, то это не правильно.
10 Jonny_Khomich
 
22.09.15
10:54
Товар не штучный что ли?
Отгружайте тогда целыми партиями.
Допустим в заказе 100 кг, отгружайте не по 33,3 а по 30, 30, 40.
11 exchang
 
22.09.15
10:55
сделать корректировку долга по закрытию сделки
12 spectre1978
 
22.09.15
10:57
(9) если товар весовой, то вы никогда не получите точных сумм с копейками в соответствии с договором. Потому что сотые в весе будут перемножаться на сотые в цене, и в результате выйдут десятитысячные, которые вы не сможете хранить в базе, потому что суммы округляются до сотых.
13 spectre1978
 
22.09.15
10:58
именно поэтому для подобных задач есть рекомендация не использовать цен при расчетах подчиненных документов, а использовать частное от суммы и количества.
14 НЕА123
 
22.09.15
11:01
(9)
по договору, может быть сумма = 100 за 3 шт.
реализовали 1шт, 2шт.
15 spectre1978
 
22.09.15
11:07
(14) если вы будете использовать цену заказа 33.33, вы потеряете копейку абсолютно точно, потому что суммы у вас получатся 33.33 и 66.66. А если будете использовать частное, то при присвоении суммы у вас в первом случае произойдет округление до 33.33, а во втором до 66.67, и копейку вы не потеряете.
16 exchang
 
22.09.15
13:00
Ну это дело хозяйское, все зависит от постановки вопроса. Я обозначил лишь ситуацию, когда есть допустим гос.закупка и если указано 1.99 копеек, то и во всех регламентных документах должно быть именно так. Ну а вообще конечно можно крайний документ подрихтовать
17 Azverin
 
22.09.15
13:11
(0) дописал костыль: при проведении РТУ смотрит на сумму Заказа покупателя и на ранние отгрузки, делает проверку итоговой суммы (+ зачёт аванса переписал при частичной отгрузки) и сообщает пользователю о расхождении. далее бухгалтер смотрит и подправляет сумму в РТУ.
18 Azverin
 
22.09.15
13:12
(17) *при частичной отгрузкЕ
19 НЕА123
 
22.09.15
13:16
(15)
да, в данном случае спасает. я абсолютно согласен, что для уменьшения погрешности сумма должна рассчитываться как (8).
но без (2) не обойтись.
реализация 1,1,1...
Проблемы невозможно решaть нa том же уровне компетентности, нa котором они возникaют. Альберт Эйнштейн