Добрый день, Коллеги.

Столкнулся с такой проблемой. Выполняется цикл распределения фактических затрат с МВЗ на CO-заказы (транз. KSV5). Базой распределения служит стат. показатель (тип 2). Смотрю результаты распределения и вижу, что на один заказ, по которому в соответствующем периоде не было стат. показателя, упали копейки, причем по каждому из распределяемых видов затрат. Не могу понять, в чем дело. Цикл не итеративный.

Глюк, какой-то...может нота есть?

Пробовал (чего я только уже не пробовал ) искать ноту. Ничего подходящего нет.

а может цикл кумулятивный?

нет, цикл не кумулятивный.

Может какая-нибудь ошибочка в сегменте с которого приходят суммы? Мало вероятно что это глюк....скорее всего что то в циклах

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

Отрицательных значений нет. Я уж и не знаю на что грешить.

Еще раз хорошенько проанализировал этот цикл распределения и вот что нашел:

1. В качестве получателей система определяет все заказы, по которым в текущем году были введены стат. показатели, независимо от месяца. Это скорее всего связано с таблицей COSR, откуда система берет данные по стат. показателям. Так как данные для всех периодов содержатся в одной позиции этой таблицы.

2. Те копейки, что упали на заказ (в качестве получателя он есть, хоть и база распределения для него равна 0), это ошибки округления, т.е. разница между суммой на отправителе и общей суммой на всех получателях, для которых в данном периоде были введены стат. показатели.

Вопрос: почему система отнесла эти ошибки округления именно на тот заказ, для которого не были введены стат. показатели. Вот этого я никак пока не пойму.

а на заказах точно не затесалось постоянных статпоказателей?

Точно. Да и в результатах выполнения цикла для этого заказа стоит база распределения 0.

Поднимем тему.
У нас аналогичная ситуация.
нашёл ноту по этой проблеме, в которой объясняется механизм распределения округлений по некомулятивным циклам
727097
в ней:
A rounding difference of 0.01 EUR remains, which must be allocated to a receiver. This rounding difference is distributed as follows in non-cumulative cycles:

1.The receiver which is last in alphanumeric sequence gets the rounding difference if its tracing factor is unequal to zero and if it is not a sender in another segment of the cycle.
2.If the last receiver does not fulfill these conditions, the first receiver to fulfil these conditions is searched for.
3.If none of the receivers fulfills the two conditions, the last receiver gets the rounding difference.

у нас стат показатель по последнему заказу = 0 и казалось бы пункт 1. для нас не подходит , а округления упорно на него распределяются.
Я выставил сообщение в САП. но они утверждают, что система работает корректно - т.к. стат показатель был физически введён в систему. вот выдержка из переписки :

Dear Mr.Ovchinnikov,

I have now reviewed the cycle CLOSE5 on Your system.
The reason for the system behaviour is as explained in note #727097.
....
However in Your cyclce CLOSE 5 the following three segment produce
rounding deltas:
OVHD25 and PACKGE
....
In both of the segments the "last" order number is 700378 and
in BOTH segments the order has a receiver tracing/weighting factor
maintained (please compare the cycle maintenance in transaction KSV3).
....
Thus according to note #727097 this order will receive the rounding
deltas. I am sorry if this specific "symptom" description is a little
misleading in the note description of #727097.
However at this stage the system works correctly.

Кто-нибудь разделяет точку зрения, что всё же система работает не корректно, т.к. распределять на последний заказ со стат показателем = 0 не правильно.
Mist , как вы решали проблему ?

Нам САП отписался примерно в том же духе. Проблему так и не решили, списали эти копейки на технический заказ и закрыли на 91 счет.

http://sapboard.ru/forum/viewtopic.php?f=6&t=32329&p=321224&hilit=%D1%80%D0%B0%D1%81%D0%BA%D0%BB%D0%B0%D0%B4%D0%BA%D0%B0#p321224

примерно точно такая же трабла....проблема не решена до сих пор, всё ждет свободные времена, некогда заняться ей.

Пока в процессе переписки с САП.
посмотрите ноту 730838.
нам она не помогла, со слов САП :
Councerning the rounding issue. I've taken a look into your system to see why the note have no impact on the result. I've found that you use the transfer price. In such case it can't be the changed rounding rule applied. Normally the receiver with zero base could be selected out (so it isn't processed and can't the rounding differece). Nevertheless this can't be applied when transfer price is activated.
I'm sorry that I can't give you more possitive answer.

изучаем ответ ... про трансферные цены

upd

действительно, если трансф цены не активированы ( в дебаге поменяли ), то отклонения не распределяются на последний заказ по которому база = 0. может кто-нибудь рассказать , почему активированные трансферные цены влияют на работу циклов распределения или более точнее, на распределения отклоенений ? сапу тоже задали его