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

@rasdol Есть надежда что учетная система это 1С, а САП нечто большее:)

На счет методологического решения абсолютно согласен, но...
Мы все же решаем проблему путем сложной разработки,
которая путем сопоставления приходов и расходов по логике
FIFO будет рассчитывать задолженность перед каждым из нескольких
поставщиков.

Прикупите только средств, чтобы геморрой лечить ))))
задача, конечно интересная

А потом еще и корректироваться кредиторская? Ну-у-у-у, про гемморой вам уже посоветовали...

Медицинский аспект этого вопроса был понятен с самого начала.
Но- руководство сказала "хотим"- консультанты сказали "можем"
Приходится делать

Думаю, что даже с партионным учетом, вы бы поимели меньше проблем чем с собственной разработкой.

@ ilu

Я тоже так думаю, и чем дальше - тем больше. Консультанты с опытом внедрения SAP for Retial уверяют, что партионный учет в ритэйле "кривой" !

Партионный учет в Ratail не кривой - вы наверное неправлино поняли. Просто его не рекомендуется включать - огромный объем транзакций (особенно если перестараться и включить раздельный учет по партиям ). Я глубоко убежден, что на многодесяткотысячной сравнительно быстрооборачиваемой номенклатуре невозможно организовать бизнес-процесс реального партионного учета - касса ведь вам не скажет из какой партии был продан товар (если кончено вы не свихнулись и не фигачите каждый раз новый штрих-код на партию).
Партионный учет можно организовать максимум до уровня распредцентра - использование RF терминаов становится критически важным - иначе складские проклянут вас - они физически не смогут точно работать с партиями. И уверяю вас, партии будут работать вполне нормально. Так что если устроит регистрация факта ухода конкретного товара конкретного поставщика с РЦ как состоявшегося факта продажи - welcome.
Глубоко убежден, что если вы не успеваете продавать товар в сроки предусмотренные стандарной рассрочкой поставщика (уверен, они дают ее), то что-то не порядке в датском королевстве (это утверждение не относится правда к fashion и hardgoods). А именно в пополнении запасов и закупках - возможно при внедрении системы данный вопрос и снимется - не будете морозить оборотные средства за-зря
А теперь по существу - поставленая в топике задача в общем смысле не содержит решения, если физически не будет решена задача "товар какого поставщика был продан".
Но не все так плохо, если пытаться использовать консигнационный запас поставщика с автоматическим расчетом pipeline/консигнационного запаса - это позволит разделить запас. Минус какой - кредиторка появится только после "потребления товара". Дополнительные интересные фичи: впоследних версиях появилась возможность двигать конс. запас между заводами, функция выбор запаса (точнее user_exit в ней) позволит в авторежиме подставлять нужный запас (собственный или поставщика) в документы движения товаров.

Ну в конце, если таких товаров не много, то ... партии помогут нам. Главное настроить автовыбор партии по FIFO (например) дабы руками не корячится - все равно , что прошло по физике одному богу известно...

а может и можно... вести стековую z-табличку, в которую каждый раз при приходе товара писать : товар, поставщик, дата... ну и отметку предусмотреть, что позиция закрыта.... только разработок понадобится приличное количество

Ага, и работать не будет Как говорил Станиславвский, "НЕ ВЕРЮ!!!"
Тут уже не разработки, а переписывание системы (точнее MM)

А по сути предложен партионный учет Только в сиcтсме он лучше написан, чем просто стековые Z-таблички (MBEW еще никто не отменял )

Не факт... Хотя, если постараться, то и не будет А так - идея вроде простая

А можно поинтересоваться, чем в такой ситуации поможет pipeline запас? Не стесняйтесь послать в хелп, с удовольствием почитаю

Не pipeline запас, а консигнационный запас - просто транзакция одна (и так она называется) - расчет задолженности перед поставщиком на основании "потребления" консигнационного запаса. http://help.sap.com/saphelp_erp2004/hel ... ameset.htm
http://help.sap.com/saphelp_erp2004/hel ... ameset.htm

@SAPER_KSV

Спасиюо за подробный ответ. Повторюсь, логично при таком раскладе использовать консигнацию. Тогда действительно задолженость возникает при продаже. Но не все йогурты одинаково полезны
Наша организация берет товар на реализацию, и при этом товар покупает.
Получаем налоговый кредит в размере 20 % (НДС в Украине).
Если не секрет, где внедряли Ритэйл ?

@rasdol

Именнот это и делается.Таблички, приход-расход и индикатор закрытия.
Попутно возникают проблемы с возвратами, сторно и т.д.

[quote="ukrartem"]@SAPER_KSV
Если не секрет, где внедряли Ритэйл ?

quote]

Уже давно не внедряю, а продаю . И соответственно, в курсе очень многих проектов. И пятилетний опыт внедрения не пропил еще . Догадываюсь, где вы внедряете
Не Фоззи, случайно?