iscrafm,

и еще вопрос. За счет какого архитектурного решения обеспечивается оперативность изменения объектов в сложных цепочках?

dbisAnS1Суть всего написанного - реализовать в SAP это можно. Достичь требуемого уровня по производительности и оперативности - тоже. Это, конечно, не тривиальная работа

два замечания:
- в САПе придется ломать, а в 1С/.net/java строить. почувствуйте, что называется, разницу
- ломать (у саперов даже жаргон такой "подламывать") придется очень жесткую, плохо документировнную модель, построенную на представлениях 40-50 летней давности
Из представлений 40-50 летней давности нам за последний год пришлось использовать LP и MLP алгоритмы,встроенные в SAP APO (SCM). Использовали web-сервисы, интеграцию в режиме on line с ТСД Symbol 3900, портальные решения. Это вроде как довольно новые технологии. Или для 1С это вчерашний день?
Что касается "строить" на 1С. Не всегда целесообразно строить с 0. Или считаете, что армия российских 1С-ников вооружена сакральными бизнес-знаниями?
Про подламывать. Каюсь, в 2001 году случалось изменять стандарт. Сейчас бы того же эффекта достигаем в рамках правил по модификации, описанных в http://help.sap.com/saphelp_erp2004/helpdata/ru/c8/1978b543b111d1896f0000e8322d00/frameset.htm Опыт, знаете ли...
Про плохо документированную модель. Приведите мне пример документации 1С, хотя бы близкой по объему той, что имеется на http://help.sap.com. Например, возьмем тривиальное ценообразование в сбытовом заказе http://help.sap.com/saphelp_erp2004/helpdata/ru/de/7a8534c960a134e10000009b38f83b/frameset.htm. Или учет по ABC http://help.sap.com/saphelp_erp2004/helpdata/ru/7e/cb7d1443a311d189ee0000e81ddfac/frameset.htm Последнее тоже относится к моделям 40 летней давности?!
Поэтому предлагаю обойтись без категоричных утверждений.

iscrafm,

обязательно посмотрю

iscrafmAnS1, построение сложных цепочек на примере системы согласования документов . Небольшой ролик. Каждое действие, которое Вы видите здесь - это элементарная транзакция, которая выполняется или СУБД или Сервером приложений или клиентской Консолью. Транзакции между собой связаны в единую систему, описание которой хранится на Сервере приложений. Таким образом выстраиваются цепочки и в других задачах.

посмотрел. Интересно. Вопрос - насколько трудоемко в рамках показанного процесса на одном из этапов (перед рассылкой оповещений) делать балансировку нагрузки на исполнителей и в автоматическом или полуавтоматическом режиме осуществлять подбор ресурса? Есть в платформе относительно высокоуровневые средства, используя которые это можно реализовать?

AnS1iscrafmAnS1, построение сложных цепочек на примере системы согласования документов . Небольшой ролик. Каждое действие, которое Вы видите здесь - это элементарная транзакция, которая выполняется или СУБД или Сервером приложений или клиентской Консолью. Транзакции между собой связаны в единую систему, описание которой хранится на Сервере приложений. Таким образом выстраиваются цепочки и в других задачах.

посмотрел. Интересно. Вопрос - насколько трудоемко в рамках показанного процесса на одном из этапов (перед рассылкой оповещений) делать балансировку нагрузки на исполнителей и в автоматическом или полуавтоматическом режиме осуществлять подбор ресурса? Есть в платформе относительно высокоуровневые средства, используя которые это можно реализовать?

Понимаю, что это уже бизнес-логика, но интересна именно инструментальная для решения поддержка такого рода задач - календари, стеки...

dbisпредставления 40 летней давности:

- только прямолинейный процесс заказал/спланировал/доставил. отклонений не допускается. что заказали, то и жрите


предрассудок или слабое знание инструментов. Где конкретно не допускается отклонений? В процесс планирования SAP SCM? Или в закупочном заказе? Или в фактуре от поставщика? Везде есть работа с отклонениями. Вполне стандартная и прозрачная

dbis
- дебитора создать просто невозможно, кроме как перанально (через lsmw). какой там вебсервис - извольте ручками подготовить данные в excel, причем будьте добры заполнить все поля, включая чисто технические (группа счетов, вид оценки, вид движения и т.п.). lsmw -- это, конечно, верх эволюции


т.е? запускаем транзакцию BAPI, ищем BAPI для создания дебитора, 2-мя нажатиями мыши делаем web-сервис. Если не желаете, чтобы пользователь сервиса заполнял "лишние" поля, заполняете их сами, "высовывая" наружу только нужный интерфейс
dbisпредставления 40 летней давности:

- ограничивающая программная модель. например, вы можете создать счет-фактуру, но не можете ее изменить.

ах да, любимая фича 1С - перепроводка документов! Со всеми вытекающими последствиями. Сторно документа выполняется 2-мя нажатиями. Очень дисциплинирует и повышает качество учета. Если имеется в виду фактура сбыта, то здесь ограничений значительно меньше. Почти все можно менять, до тех пор, пока нет проводки. После этого, ежели нашли ошибку - сторнируем и создаем сф заново

dbis
- таблички, таблички, таблички... все, сколько нибудь полезные данные приходится тянуть прямо из табличек


вы их просто готовить не умеете. только без обид, но есть 2-а способа - налабать что-то с 0, или использовать готовое. Чтобы получить качественный продукт и тот и другой способ должны использовать профессионалы
dbis
- уровень презентации отсутствует как класс. транзакция экранная и транзакция программная - суть одно и то же.

используйте портальное решение, ежели Вас это так коробит
dbis
- работа с экземплярами объекта, а не с классами. в WMS вы можете настроить зону хранения "холодильник, -18 градусов", но это будет объект. невозможно получить площадь всех моих "холодильников, -18 градусов", кроме как сравнивая наименования объектов

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

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

ну и т.д. и т.п.


вы сгуляйте на форум sql server и расскажите про осмысленность ключевого поля. Замечания про первую нормальную форму будут самыми безобидными репликами

dbisвебсервисы на САПе -- это как электрогенератор на телеге. вызываются теже самые АБАП-овские ФМ.


а что они должны вызывать?? Ежели бизнес-логика реализована на этих самых ФМ?
dbis
а про докуметацию - лучше молчите. help.sap.com -- гигабайты плохосвязанных между собой текстов, мало что объясняющих. для вашего же примера - где описаны объекты/процедуры/хоть что-нибудь, как программно (вы тут недавно согласились, что придется абапить) получить схему калькуляции, зная клиента, материал и прайс-лист? по табличкам условий и последовательностей доступа предлагаете лазать?

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

и ваше сравнение с 1С просто великолепно: это же надо! нагородить такую схему расчета цен, что поседеть впору, налабать к ней 300 листов документации и говорить: "ну, что скажете? в один-це нет 300 листов документации по ведению прайс-листов??? ну и дауны"

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

Что касается схемы цен в SAP - считаю её одним из самых гибких и мощных инструментов. Причем овладеть им не так уж сложно. Девочка после института после интенсивного обучения через месяц настраивала бонусные схемы, каскадные схемы скидок от объемов и проч.

dbisвот и найдите бапи для создания дебитора, а заодно для изменения счета-фактуры... недели хватит?
по дебитору BAPI_CUSTOMER_CREATEFROMDATA или BAPI_CUSTOMER_CREATEFROMDATA1

по фактуре - ищите сами. А то это уже консалт начинается

dbisпро ключ вашу мысль не понял. при чем тут нормализация (хотите про это поговорить в контексте схемы БД САП?)? проблема в том, что ключ вынесен на обозрение пользователя и несет информативную нагрузку. как во времена IMS, когда памяти было мало, а железки стоили дорого
кто заставляет проектировщиков вкладывать смысл в кодировку?

dbisвы бапишки-то поищите...

а насчет гибкости... знаете, ER-диаграмма "сущность сама на себя завязанная многое-ко-многим" - тоже очень гибкая конструкция, только настраивать устанешь
про бапи- см. выше. Про гибкость и сложность - знаете, жизнь тоже не простая штука. Предложите альтернативу (схеме цен, не жизни :))

dbisа вы не путайте кастомеров и дебиторов. если вы прочитаете вами же рекомендованный BAPI, то поймете, что никакого отношения к дебиторам кастомер не имеет. а бапишка нужна исключительно для стыковки какой-то там онлайн системы типа CRM с ECC...

тоже мне, консультант
не путайте. кастомер в данном случае - дебитор на рынке сбыта. bapi использовалось года так с 99 для internet sale. Сейчас используется например, в CRM-ISA-R3

мне, если честно, не очень понятно Ваше упорство. Нигде ведь не говорилось, что sap система, где всё есть и все просто. Иногда приходится и пакетник нарисовать, хотя это уже конечно позавчерашний день. Опять же - не игнорируйте мой вопрос - где однозначно лучшая альтернатива? За сим со своей стороны дискуссию прекращаю - конструктива нет, увы

iscrafmAnS1
посмотрел. Интересно. Вопрос - насколько трудоемко в рамках показанного процесса на одном из этапов (перед рассылкой оповещений) делать балансировку нагрузки на исполнителей и в автоматическом или полуавтоматическом режиме осуществлять подбор ресурса? Есть в платформе относительно высокоуровневые средства, используя которые это можно реализовать?
честно говоря не совсем понял о чем Вы говорите. Не могли бы Вы расшифровать немного, можно в терминах SAP, я их хорошо понимаю. Дело в том, что не все в чем испытывает потребность NW испытывает и Искра, поэтому хотелось бы расшифровки.
например, есть сервисные заказы. При её создании хотелось бы выбрать доступный ресурс (человека). Желательно увидеть текущую загрузку персоны