Есть ли в САП-е САБЖ?
Если вкратце, то для бухгалтерской подгонки Solver использует метод ветвей и пределов (branch-and-bound), есть ли аналог или пример имплементации данного метода в САП-е?

Заранее спасибо!

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

Хороший вопрос. Тоже недавно задумался о возможномсти использования в SAP метода ветвей и границ, но потом просто решили использовать гораздо более простой алгоритм. А заноза в памяти осталась..

С удовольствием!

Предположим, есть следующий лист оборудования в инвалюте:

Товар Цена Кол-во Подсумма НДС Всего
Device 1 12.36 3 37.08 6.67 43.75
Device 2 34.18 15 512.7 92.29 604.99
Device 3 23.98 4 95.92 17.27 113.19
Итого : 761.93

Сумма Итого в инвалюте переводится в локальную валюту, округляется до 2 знаков за запятой и принимается за цель, на которую надо выйти.

Если мы переведем цену каждой позиции в локальную валюту, округлим до 2 знаков, умножим на количество, снова округлим результат, высчитаем НДС, округлим его и сосчитаем "Всего" и как сумму "Итого" - просуммируем все "Всего", то результат не будет равен целевой сумме из-за неизбежных ошибок округления, которые, будучи умноженными на количество, приводят к еще большим погрешностям, например:

При курсе 0.702804,
Итого = 535.49, цена1 = 8.69, цена2 = 24.02, цена3 = 16.85 и результирующая сумма 535.44 <> 535.49.

Часто в таких случаях идет т.н. "подгонка" - т.е. цена по позициям либо увеличивается на 0.01, либо уменьшается по позициям, до тех пор пока сумма не выйдет такой, "как надо". Excel Solver, как заявляется, использует метод ветвей и границ и находит решение:
цена1 = 8.63 (минус 0.06 к изначальной), цена2 = 24.05(плюс 0.03), цена3 = 16.79 (минус 0.06)

п.с. конечно, можно делать т.н. валютные разницы, и описывать поправку 535.49 - 535.44 в них - про это я в курсе

не в тему... в SAP APO есть целочисленный переборщик для оптимизации транспортировок.
Но он там как внешний процесс (отдельная прога на С с LiveCache) реализован.

Хм, понятно теперь, спасибо.
p.s.
Кстати, можно ведь и использовать для этих целей Excel, выгрузить из R/3 в него необходимые данные и через макрос запустить расчет, или вручную кнопочку нажать.

dedzinatajs, для такой задачи можно и попроще алгоритм использовать.
1. Берем дельту, подлежащую распределению и распределяем ее на позиции пропорционально их стоимостям.
2. из за округлений итоговая сумма снова не будет биться с нужной, но уже на гораздо меньшую дельту. Эту вторую дельту просто кидаем на позицию с наибольшей стоимостью.

+1
Так примерно и делаю. Только вторую дельту кидаю либо на наибольшую стоимость, либо на наименьшую (как бухи завелят ).

Это все работает, если кол-во равно 1, в случае, если например дельта - 20 копеек, а штук товара - 13. Добавили копейку к его цене, умножили на кол-во и на налог, дельта стала 20 - 15 = 5 копеек, но никуда не пропала.
Конечно, можно выгрузить данные в Эксель, прогнать Солвер и проимпортировать данные обратно - но это колка орехов микроскопом ;(

Тут просто нужно сменить перспективу мышления.
Равенство {цена*количество = стоимость} не всегда обязано выполняться.

Главное, чтобы выполрнялось равенство {округлить до двух знаков(стоимость/количество) = цена}

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