Развитие в экосистеме SAP
Обучение и развитие проектных команд
Станьте участником SAPLAND и получите доступ к самым интересным публикациям SAPPRO
Зарегистрироваться
Обучение и развитие проектных команд
Станьте участником SAPLAND и получите доступ к самым интересным публикациям SAPPRO
Зарегистрироваться
Развитие в экосистеме SAP
>>идентификатором клиента, заказчика, поставщика, материала...
Т.е. если мы тут о SAP, то основная запись клиента и материала, вот тот вот набор полей и справочников предлагается перенести в BW систему? И следовательно там вести все эти справочники? Правильно?
Здравствуйте.
"...можно хранить вместе с описаниями SAP систем на рабочей станции администратора."
Ничего нельзя хранить на рабочих станциях администратора.
Должен делаться регламентный, раз в неделю, файловый бэкап каталогов sap(бинарники/профайлы, всключая все appl-инстанции системы) и oracle.
С уважением,
Александр.
Много грамматических ошибок, неприятно читать.
Евгений, спасибо.
Главное назначение инструмента BPB - это вовлечение так называемого non-SAP user в процесс концептуального проектирования.
Действительно инструмент "сырой", многие возможности BPMN в нем отсутствуют. Но, насколько я понимаю, SAP планирует его в дальнейшем развивать.
Теперь по вашему примеру. Как вы знаете в SOLAR01 процессы представлены в 3-х уровневой структуре - сценарий, процесс, шаг процесса. Именно в таком виде процессы хранятся в центральном репозитарии SAP BPR, откуда они появляются в SOLAR01.
Из структуры невозможно понять логику процесса, видно лишь последовательность выполнения шагов конкретного процесса. Чтобы появилась логика нам нужно "ручками" нарисовать ее в BPB. Причем "логика" напрямую не перенесется в SOLAR01 (там мы видим обычную структуру), увидеть ее мы сможем только в BPB.
Предположим Вы хотите добавить в свою структуру стандартный процесс, появившийся в EHP6. Как я уже говорил, все стандартные процессы хранятся в BPR, а там нет логики. Т.е. добавив новый стандартный процесс в свою структуру вам опять придется логику дорисовывать вручную в BPB.
Евгений,
Действительно мы являемся партнерами IBIS Prof. Thome AG.
Если нетрудно, дайте ссылку на материал по связке Solution Manager с Solution Builder-ом ...
Олег, спасибо за статью.
сам наблюдаю и тестирую BPB с прошлого года. действительно сыровато пока выглядит. у меня пока не получается пока провалиться внутрь "Process steps" - то ли настройки какие-то не до конца выполнил, похоже какой-то веб-сервис не авторизован, то ли просто пока это ещё не работает. (солмен 7.1 стэк 8 + 50-60 нот поверху стэка)
но выглядит конечно поприятнее аскетичных солменовских инструментов.
к сожалению у меня не получилось воспользоваться встроенной в BPB "палитрой" (как-то просмотрел её присутствие), для моделирования пробовал использовать NWDS. но всё-равно, пока BPMN весьма оторван в текущей реализации от BPB. Вот к примеру реальный пример. Производим Reverse Business Process Documentation например на EHP2 включая пользовательские разработки, получаем в итоге в SOLAR01 текущий анализ. требуется например заменить часть пользовательских разработок на появившиеся в стандарте в EHP6. по логике тут бы и сравнить стандартный процесс и пользовательский в нотификациях BPMN, но нет ни тех, ни этих... пока похоже ручками предварительно их рисовать ?
и вот ещё интересно, в апреле опубликовали материал, в котором описана связка Solution Manager с Solution Builder-ом. Это как-то будет связано с BPB ? (ну раз Вы - партнер IBIS Prof. Thome AG)
Олег, спасибо за статью.
сам наблюдаю и тестирую BPB с прошлого года. действительно сыровато пока выглядит. у меня пока не получается пока провалиться внутрь "Process steps" - то ли настройки какие-то не до конца выполнил, похоже какой-то веб-сервис не авторизован, то ли просто пока это ещё не работает. (солмен 7.1 стэк 8 + 50-60 нот поверху стэка)
но выглядит конечно поприятнее аскетичных солменовских инструментов.
к сожалению у меня не получилось воспользоваться встроенной в BPB "палитрой" (как-то просмотрел её присутствие), для моделирования пробовал использовать NWDS. но всё-равно, пока BPMN весьма оторван в текущей реализации от BPB. Вот к примеру реальный пример. Производим Reverse Business Process Documentation например на EHP2 включая пользовательские разработки, получаем в итоге в SOLAR01 текущий анализ. требуется например заменить часть пользовательских разработок на появившиеся в стандарте в EHP6. по логике тут бы и сравнить стандартный процесс и пользовательский в нотификациях BPMN, но нет ни тех, ни этих... пока похоже ручками предварительно их рисовать ?
и вот ещё интересно, в апреле опубликовали материал, в котором описана связка Solution Manager с Solution Builder-ом. Это как-то будет связано с BPB ? (ну раз Вы - партнер IBIS Prof. Thome AG)
Красиво и полезно.
Было бы не плохо добавить шаг про создание транзакции, было бы полное описание.
Так об этой теме: sapland.ru/articles/spj
Олег, в своей статье я показал практическое применение нового инструмента от компании SAP - Business Process Blueprinting, который является Add-One для SAP Solution Manager 7.1
Основное предназначение этого инструмента - визуализация процессов, описанных в рамках Business Blueprint. Это некая альтернатива стандартному графическому ракурсу, присутствующему в транзакции SOLAR01.
Так об этой теме: sapland.ru/articles/spj
Разработка SAPUI5 приложений
15.06.2026SAP HANA: Установка и администрирование
15.06.2026Настройка основных данных в Управлении проектами в SAP
16.06.2026Управление запасами и инвентаризация в SAP
16.06.2026
Комментарий от
Олег Точенюк
| 05 июля 2013, 01:32
1. Нумерация кассовых ордеров ведется в поле “Номер документа кассовой книги для просмотра” - Стандартное решение от SAP, ну кроме того что как было отмечено нельзя получить интервалы без разрыва, но и что более как мне кажется проблематично, это нельзя гарантировать постоянное увеличение номеров при нескольких серверах приложений, так как система произведет чтение номера из интервала, при этом каждый сервер приложение получит по номеру, далее если номер на каком-то из серверов использовался, система запросит следующий номер, но первый сервер приложения будет ждать своей очереди и может возникнуть ситуация когда нумерация будет выдана в таком порядке как 1<первый сервер>, 3<первый сервер>, 4<первый сервер>, 5<первый сервер>, 6<первый сервер>, 2<второй сервер>, 7<первый сервер>, что приводит пользователей в некоторое состояние задумчивости, особенно если номер 2 появится на следующий день.
2. Нумерация кассовых ордеров ведется в поле «Ссылочный номер документа» - Ну это уже какое-то ручное бессистемное извращение. На одном очень автомобильном заводе номер кузова который надо выбить тоже вот так вот в ручном режиме велся, т. е. там была пресс-форма и рабочий просто в ручном режиме проворачивал кольцо в цифровом блоке, нажимал кнопку, номер выбивался на кузове, а он в журнал записывал пробитый номер. Ну такая себе автоматизация, но по факту, иногда рабочий забывал провернуть колесо или не записал последний номер в конце смены, ну и следующий кузов выходил с номером двойником, что потом вызвало проблемы при регистрации такого «чуда» после покупки такого авто. Ну там шеф вхож в большие круги, заводик все таки автомобильный, поэтому приняли положение, что номер кузова может быть со слешем, который использовали для забоя последней цифры, для исключения дублирования, хотя и это им не всегда помогало... Жаль, что не все кто внедряет у себя систему тоже так не вхожи в разные большие комитеты :-), а то проблем бы не было.
3. Автоматическое формирование номера кассового ордера в поле «Ссылочный номер документа» - не очень похоже на автоматизацию, при такой реализации могут быть проблемы при одновременной параллельно работе нескольких кассиров, оба в момент запроса получат одинаковый максимальный номер из таблицы TCJ_DOCUMENTS. Опять же предлагается ручное заполнение разрывов нумерации, ну т. е. вот это самое появление разрывов, например при сторно, нужно хранить где-то на бумажках, чтобы потом использовать при операции.
4. В качестве номера кассового ордера используется номер FI-документа сформированного на основании кассового ордера — Ну тут какой-то совсем дас ист фантастишь, потому что, «В случае работы в кассе нескольких кассиров, кассир сохраняет документ, после этого звонит главному кассиру, который этот документ проводит», это зачетно, т. е. главный кассир он всегда на месте, хотя работа наверное такая. Далее предлагается использовать объекты интервалов номеров, аналог пункта 1, при этом я не так и не понял почему не образуется разрывов? Нумерация документов FI идет всегда вперед, если что-то где-то при проводке документа упадет, то номер будет пропущен и затолкать документ с пропущенным номером, уже будет не тривиально. Далее при нескольких серверах приложений получите такую же проблему как и при методе 1 из-за буферизации интервала на сервере приложения.
Я бы использовал метод 3, но доработал бы его в следующем ключе: с одной стороны, при получении нового номера использовал бы эксклюзивную блокировку таблицы с доступом в режиме WAIT, чтобы гарантировать получение уникального большего номера и его сохранение в таблицу только одним процессом. И второе завел бы таблицу сторнированных документов, куда писал бы номера документов сторно, само собой тоже используя эксклюзивную блокировку при доступе к этой таблице, при этом сначала проверял бы таблицу сторнированных документов и если там пусто, то шел бы основную таблицу за новым номером.