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

Для продаж в магазине надо SAP интегрировать с POS терминалами, это понятно.
Но при продажах на машиностроительном заводе тоже хочется иметь возможность быстро работать с клиентом.

Реально хотелось бы
1 BAPI_MATERIAL_AVAILABILITY для кучи материалов
2 bapi (46C) для создания исх поставки

А всех устраивает, как реализованы авансовые платежи?

Да уж....
Меня все занимает вопрос, как западные юзеры работают?
Или они таким образом с безработицей борются?

а в чем проблемы?

есть такое в 5.0 (может и в 4.6С тоже есть?), правда для внутреннего использования, но реально работает:

правда не все там создашь, например упаковку.

От версии к версии смотрю на возможность создания поставок из внешнего приложения. Пока полностью реально работающего не видел.

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

хотя бы проверяла всех партнеров из сбытового заказа

Это еще полбеды - проверка уже заработала. Насчет партнеров - я тоже так считаю, но наши эфайщики сказали, чтоб не заморачивался, а проверял только заказчика.

А вот раздражает то, что ТАП создается только при наличии плана фактурирования. А как только к заказу есть план фактурирования, система отказывается фактурировать позиции обычным способом (если не перепиливать правила копирования). Я про это спрашивал здесь: http://sapboard.ru/forum/viewtopic.php ... 0%ED%F1%2A

действительно, пятачок... Век живи, век учись - дураком умрешь . Спасибо, на досуге посмотрим

Вообще то можно создать поставку без заказа и даже не зная покупателя и потом правильно ее отфактурировать. Сама поставка должна быть LO или аналогичная. Создать на вымышленного партнера (DUMMY). В процедуре определения партнеров сделать так, что обязателен для определения только партнер типа SH=DUMMY. Когда покупатель определился - добавить в отгрузку партнера типа SP - уже реального покупателя. После этого фактурировать. Единственная проблемма это то, что в тр VL02N нельзя изменить партнеров после проводки в FI, но применив ноту 52754 партнеров можно менять в VL02.

Вот все тут про экраны, да отдельные пожелания говорят, а про блоки функциональности кот наплакал. Внесу свои две копейки.

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

вот, пришло в голову

в 46С хотелось бы иметь простой способ скрытия (именно скрытия - не исключения) записей видов условий в схеме цен в заказе

простой пример - вид условия используется как "технический", для расчета других условий или как триггер. Зачем его показывать пользователю?

А может быть, эта возможность имеется уже?

Как было сказано в фильме "Догма": "У торчка здравая мысль...".
Да, среди предложенного есть весьма логичные и понятные идеи, но вряд-ли хоть одна из них будет когда-нибудь реализована в стандарте системы.
Во-первых, к моему большому сожалению, в последнее время Сбыт как функциональность почти не развивается. Добавляются какие-то мелочи, но по большому счету ничего принципиально нового в SD после версии 4.6С не появилось. Все силы (при этом, индусов, а не немцев ) брошена на CRM, который вроде как заменяет весьма приличную часть SD. Поэтому нам, бедным, ничего не достается. Так крохи с барского стола. Да и я бы еще подумал, стоит ли индусов подпускать к давно работающей функциональности. Они же все опошлят!
Во-вторых, дополняя во-первых, стратегически развивать модуль SD САПу не нужно. Вопросы дизайна интерфейсов очень редко встают на этапе продажи системы клиенту - продается функциональность как таковая. А она есть. И вообщем-то может многое. А с интерфейсом "встречаются" уже конечные пользователи.
Ну и в-третьих. Вы можете со мной не согласиться, но функционал SD, да и интерфейсы тоже, могут дать приличную фору некоторым другим областям системы. Поэтому даже если будут "улучшать" ERP, то при выборе места "где копать" выберут не Сбыт.

P.S. А мне все равно SD нравится!