Развитие в экосистеме SAP
Обучение и развитие проектных команд
Станьте участником SAPLAND и получите доступ к самым интересным публикациям SAPPRO
Зарегистрироваться
Обучение и развитие проектных команд
Станьте участником SAPLAND и получите доступ к самым интересным публикациям SAPPRO
Зарегистрироваться
Развитие в экосистеме SAP
Добрый день.
Илья, не ясна фраза - "Во все мультипровайдеры добавляется признак временой зоны данных (ZTIMEZONE)."
От куда? и Зачем? Просто так хорошо говорили о уровнях абстракции и вдруг ZTIMEZONE...
Посмотрел ссылки там ничего на этот счет не нашел...
AK
Статья, на мой взгляд, очень полезная, так как демонстрирует правильный общий подход к внедрению SAP HANA. В ней охвачены как техническая часть, так и экономическая целесообразность и организационные мероприятия. С точки зрения техники правильный акцент сделан на том, что при всей инновационности HANA, все технологии, на которых она основана (я бы, в отличие от автора, выделил другие 3 кита - колоночное хранение (сжатие - его следствие), in-memory и параллелизация) достаточно давно известны в индустрии СУБД. И если для маркетинга это звучит, может быть, не очень ярко, зато с точки зрения внедрения и непредвзятой оценки дает намного больше уверенности что это не маркетинговая пустышка, а реальная работающая технология.
Также хотелось бы особо отметить, что технические люди склонны увлекаться этой технической диковиной и забывать, что на все стоит смотреть с точки зрения стратегии бизнеса и IT стратегии, и не смотрят на всю очевидность потенциальной пользы от использования HANA, к вопросу экономической целесообразности стоит подходить с максимальным вниманием.
Что касается вопроса использования текущих людских ресурсов, их знаний и навыков и проблемы перехода на HANA, то благодаря тому, что HANA, с точки зрения разработчика, просто SQL СУБД, оказалось, что после прохождения базовых курсов, разработчики и архитекторы достаточно быстро осваивают новую технологию.
Надо отметить, что статья опубликована полгода назад и за это время в стремительно развивающейся HANA произошли существенные изменения. Ключевым моментом стал официальный релиз SAP Business Suite on HANA в мае этого года, то есть то, что в статье описано как относительно далекое будущее стало реальностью. А именно, теперь можно переводить существующие решения на базе SAP ERP с традиционных реляционных СУБД на HANA.
В целом сейчас доступны три основных сценария:
1. BW on HANA
2. Business suite on HANA
3. HANA Standalone в качестве хранилища данных, с загрузкой в режиме онлайн при помощи SLT или при помощи Business Objects Data Services и с технической точки зрения клиент вправе рассмотреть любой подходящий ему вариант.
Вторым немаловажным моментом, бурно развивающимся параллельно технологическим достижениям, является политика лицензирования.Не секрет, что до последнего времени стоимость лицензий на HANA, например, для BW была весьма высока и лицензирование велось от объема RAM, в результате для больших БД, даже с учетом сжатия, цена получалась весьма внушительная. Однако с выходом Business Suite on HANA ситуация резко изменилась - в тот же день было объявлено о лицензировании HANA по той же цене, что и СУБД Oracle - 15% от стоимости лицензий, вне зависимости от объема данных! А в мае и июне прошло еще несколько маркетинговых акций, предлагающих похожую модель лицензирования и для BW! Для многих компаний это резко снизило стоимость лицензий и таким образом упростило обоснование экономической целесообразности, о которой ране шла речь.
Этот пример иллюстрирует комплексность задачи по построению архитектуры на SAP HANA. Необходимо одновременно учитывать и технические аспекты, и требования бизнес-заказчика и такие нетехнические моменты, как нюансы лицензионной политики, иначе грамотно выстроенное техническое решение рискует оказаться экономически неэффективным.
С учетом относительной молодости продукта и наличия массы нюансов, я бы рекомендовал привлекать к проекту перевода на HANA специалистов SAP или официальных партнеров.
Интересуют принципиальные различия между IM-функциональностью и PPM, в которой нет ни отчетов ни... короче ничего, но кроме этого для нее надо поднимать BI и Enterprise Portal? Я пока из различий заметил только про неограниченность иерархии в PPM и кажется ограничение в 99 уровней для IM структуры программы. Хотя глубина в 99 шагов, как мне кажется не критичное ограничение. Что еще?
LSMW - это действительно мощный инструмент, но порой жалко тратить время на создание целого проекта в нем, если требуется одноразовая загрузка небольшого количества данных (100-1000 объектов, к примеру).
Когда требовалось создать около 1000 складов, то я использовал небольшой GUI-script для автоматизации их создания. На написание скрипта ушло минут 5 и еще минут 5-10 выполнялся сам скрипт. Таким образом, бОльшая часть времени ушла просто на подготовку Excel-шаблона со списком складов.
А за статью спасибо.
Александр, спасибо большое за комментарий!
я тоже считаю, что LSMW - это инструмент, который очень и очень помогает.
Однако, одна из проблем, с которой я столкнулся при использовании LSMW методом Batch-Input - это загрузка ролей.
У меня не удалось создать запись, которая бы в один шаг создавала роль и прописывала орг.уровень; поэтому создавал две записи, и в итоге использовал три шага:
1) массовое создание ролей без профилей через LSMW (просто код, имя)
2) массовая генерация профилей через стандартную утилиту
3) массовое присвоение орг.уровней для созданных ролей.
Если есть опыт решения этой проблемы - пожалуйста, сообщите - буду благодарен.
Также, если сталкивались с другими "подводными камнями" LSMW Batch-Input - буду рад послушать.
Прошу прощения по ошибке назвал вас Сергеем.
Сергей, спасибо за полезный комментарий.
Таблица со списком сторнированных документов для метода 3 это хорошая идея.
Зря вы так про метод 4. Метод абсолютно рабочий. Вполне успешно применяется на практике. Вероятно при нескольких серверах приложений действительно возникнет описанная вами проблема, но при более простой конфигурации все Ок.
Метод с ручным заполнением номера ордера тоже на мой взгляд вполне достойный вариант. На многих предприятиях также вполне успешно работает.
Сложилось впечатление, что существует недопонимание, как работает генератор диапазонов номеров в SAP. В общем виде можно получить непрерывность номеров в системе, для этого надо чуток докрутить метод 3, но про это ниже.
1. Нумерация кассовых ордеров ведется в поле “Номер документа кассовой книги для просмотра” - Стандартное решение от SAP, ну кроме того что как было отмечено нельзя получить интервалы без разрыва, но и что более как мне кажется проблематично, это нельзя гарантировать постоянное увеличение номеров при нескольких серверах приложений, так как система произведет чтение номера из интервала, при этом каждый сервер приложение получит по номеру, далее если номер на каком-то из серверов использовался, система запросит следующий номер, но первый сервер приложения будет ждать своей очереди и может возникнуть ситуация когда нумерация будет выдана в таком порядке как 1<первый сервер>, 3<первый сервер>, 4<первый сервер>, 5<первый сервер>, 6<первый сервер>, 2<второй сервер>, 7<первый сервер>, что приводит пользователей в некоторое состояние задумчивости, особенно если номер 2 появится на следующий день.
2. Нумерация кассовых ордеров ведется в поле «Ссылочный номер документа» - Ну это уже какое-то ручное бессистемное извращение. На одном очень автомобильном заводе номер кузова который надо выбить тоже вот так вот в ручном режиме велся, т. е. там была пресс-форма и рабочий просто в ручном режиме проворачивал кольцо в цифровом блоке, нажимал кнопку, номер выбивался на кузове, а он в журнал записывал пробитый номер. Ну такая себе автоматизация, но по факту, иногда рабочий забывал провернуть колесо или не записал последний номер в конце смены, ну и следующий кузов выходил с номером двойником, что потом вызвало проблемы при регистрации такого «чуда» после покупки такого авто. Ну там шеф вхож в большие круги, заводик все таки автомобильный, поэтому приняли положение, что номер кузова может быть со слешем, который использовали для забоя последней цифры, для исключения дублирования, хотя и это им не всегда помогало... Жаль, что не все кто внедряет у себя систему тоже так не вхожи в разные большие комитеты :-), а то проблем бы не было.
3. Автоматическое формирование номера кассового ордера в поле «Ссылочный номер документа» - не очень похоже на автоматизацию, при такой реализации могут быть проблемы при одновременной параллельно работе нескольких кассиров, оба в момент запроса получат одинаковый максимальный номер из таблицы TCJ_DOCUMENTS. Опять же предлагается ручное заполнение разрывов нумерации, ну т. е. вот это самое появление разрывов, например при сторно, нужно хранить где-то на бумажках, чтобы потом использовать при операции.
4. В качестве номера кассового ордера используется номер FI-документа сформированного на основании кассового ордера — Ну тут какой-то совсем дас ист фантастишь, потому что, «В случае работы в кассе нескольких кассиров, кассир сохраняет документ, после этого звонит главному кассиру, который этот документ проводит», это зачетно, т. е. главный кассир он всегда на месте, хотя работа наверное такая. Далее предлагается использовать объекты интервалов номеров, аналог пункта 1, при этом я не так и не понял почему не образуется разрывов? Нумерация документов FI идет всегда вперед, если что-то где-то при проводке документа упадет, то номер будет пропущен и затолкать документ с пропущенным номером, уже будет не тривиально. Далее при нескольких серверах приложений получите такую же проблему как и при методе 1 из-за буферизации интервала на сервере приложения.
Я бы использовал метод 3, но доработал бы его в следующем ключе: с одной стороны, при получении нового номера использовал бы эксклюзивную блокировку таблицы с доступом в режиме WAIT, чтобы гарантировать получение уникального большего номера и его сохранение в таблицу только одним процессом. И второе завел бы таблицу сторнированных документов, куда писал бы номера документов сторно, само собой тоже используя эксклюзивную блокировку при доступе к этой таблице, при этом сначала проверял бы таблицу сторнированных документов и если там пусто, то шел бы основную таблицу за новым номером.
>>идентификатором клиента, заказчика, поставщика, материала...
Т.е. если мы тут о SAP, то основная запись клиента и материала, вот тот вот набор полей и справочников предлагается перенести в BW систему? И следовательно там вести все эти справочники? Правильно?
Здравствуйте.
"...можно хранить вместе с описаниями SAP систем на рабочей станции администратора."
Ничего нельзя хранить на рабочих станциях администратора.
Должен делаться регламентный, раз в неделю, файловый бэкап каталогов sap(бинарники/профайлы, всключая все appl-инстанции системы) и oracle.
С уважением,
Александр.
Много грамматических ошибок, неприятно читать.
Настройки в Финансах
14.07.2025Основы расчета заработной платы
14.07.2025SAP Workflow: Концепции, отчетность и работа с готовыми шаблонами
14.07.2025SAP S/4HANA Transportation Management: Планирование и выполнение
14.07.2025
Комментарий от
Сергей Теплов
| 08 августа 2013, 09:16
Этот абзац непонятен:
"В случае необходимости проведения сторно кассового ордера это возможно сделать как методов ввода обратного кассового ордера либо функции сторно в кассовой книге. При этом не образуется разрывов в нумерации кассовых ордеров."