Относительно платформы - раньше так и было.
А теперь и сама HANA - и БД и платформа. Используйте как удобнее.

Мы используем все эти 4 метода. Хотя, первый метод мы уже не используем т.к. обнаружили некорректную работу этой функции на нашем проекте.
Прошу обратить внимание читателей, что когда вы пользуетесь методом №1 (ставите * в поле сумма) при выравнивании документа (или проводке с выравниванием), то курсовые разница вся пойдет не на отдельные счета курсовых разниц, а на остальные счета документа.
вот пример при использовании *

 
в вот как должно быть, если вставлять сумму:

А данный инструмент применим для тестовой системы (контроля качества/продуктива), то есть в таких в которых система закрыта для изменений?
 
При попытке использовать этот инструмент система мне выдала сообщение "Система неизменяема", хотя в другой тестовой системе - пустила в Script без проблем.
 
Может где-то что-то упустил...
Прошу подсказать.

Под термином документ я имел именно то что написали вы "Компании могут создавать миллионы или даже миллиарды документов в день", я так думаю мы с вами об одних и тех же документах подумали. Хотя если это не так, то уточните какие именно документы имели ввиду вы.
 
Я ничего не имею против СУБД HANA, но я не понял как изменится модель работы SAP ERP при переходе от СУБД Oracle к СУБД HANA? Мне кажется, что она останется такой же как и была, хотя нет, кое какие отчеты которые перегружались в BW можно будет выполнять теперь без проблем в SAP ERP. Что же касается красот использования хранимых процедур HANA, то я так понял SAP отказывается от переносимости кода между СУБД различных производителей и далее нас ждут реальные изменения синтаксиса ABAP-а. Ну знаю одного клиента, который в такой ситуации точно не купил бы SAP ERP на HANA, так как SAP ERP на MS SQL ему реально встала дешевле и ее ему пока хватает. И кому станет хорошо, когда эту возможность у него отберут? Наверное аксапте, с чем ее и поздравляю.
 
"Real-time data processing" - Еще больше замечательно, теперь как я понимаю в скором времени в SAP ECC скоро вернут потерявшуюся букву R и будет что-то типа SAP ECC RTDP.
 
Что касается CRM, тут я не силен, но эта функциональность всегда стояла кажется отдельно со своей базой и не входила никогда в состав SAP ERP? Но я конечно так же рад, что установка CRM на СУБД HANA и ей тоже очень помогла с производительностью.
 
Кстати, по поводу систем консолидации, я чего-то думал что за эту радость отвечает уже функциональность BPC. А ей вроде как ну будет там ниже стоять HANA, ну статистическому биписишнику придет счастье, в виде реального ускорения выполнения отчетов.
 
А да, еще по поводу платформы, я все считал что платформа у нас сап нетвьювер, а СУБД даже если она очень быстрая, платформой быть не может, она же уже СУБД и ничего больше.

Олег, спасибо за Ваш содержательный комментарий.
 
Не очень понятно, что вы подразумеваете под термином документ, но тем не менее.
Если Вы имеете в виду отдельные транзакции, создаваемые пользователями системы, то да, ERP можно с полной уверенностью считать таковой. В данном смысле модель работы SAP ERP системы, существовавшая до появления SAP HANA, в полной мере отвечала такой концепции, поскольку база данных в ней использовалась лишь как хранилище информации.
Напротив, в концепции, в которую включается SAP HANA как база данных, появляется возможность переносить отдельные элементы логики приложений на уровень базы данных и за счет этого повышать производительность транзакций и отчетов..
Если же мы имеем в виду бизнес-логику приложения ERP как таковую, то при миграции на SAP HANA она не изменится. Существует также возможность включать/выключать выполнение оптимизированной на SAP HANA логики стандартных прорамм/транзакций. Стоит также отметить, что в версию ERP для SAP HANA включены дополнительные преднастроенные приложения на базе технологии HTML5 (например, MRP Cockpit). Для процессов, построенных на пользовательских разработках, оптимизацию необходимо будет делать дополнительно.
Таким образом, в случае применения SAP HANA в качестве СУБД для SAP ERP, заказчик получает не только базу данных, позволяющую обрабатывать большие объемы данных с более высокой скоростью, нежели традиционные СУБД, но и платформу для построения новых приложений на основе процессов в ERP, позволяющих анализировать информацию в режиме реального времени. Это позволяет нам говорить о  возвращении к реальному значению термина «Real-time data processing». Причем речь идет не только об ускорении выполнения традиционных отчетов, но и о функциональности, которая считалась нереализуемой ранее из-за проблем с производительностью. Примером может являться сегментация клиентов в CRM приложениях для торговых организаций. Данный процесс в традиционной архитектуре требовал накопления информации и ее переноса в BW, а теперь может выполняться непосредственно в системе CRM.
Говоря про аналитические возможности, я хотел бы отметить, что как минимум в ближайшем обозримом будущем хранилища данных будут по-прежнему строиться на основе SAP BW, теперь использующем SAP HANA в качестве СУБД и платформы для построения real-time отчетности. Связано это в основном с тем, что в настоящее время решение SAP BW предоставляет огромный объем функциональности, позволяющей, к примеру, вести предварительную обработку данных, строить системы бюджетирования и консолидации, реализовывать концепцию data aging с помощью решения NLS. Вероятно, настанет момент, когда данная функциональность будет интегрирована в единую платформу для транзакционных и аналитических систем.
 
Сергей Осин

Была у какого-то сатирика миниатюра про не понимаю. Считайте этот комментарий из того же самого разряда, про я не понимаю:
 

Прикольно написано, особенно про даже не миллиард, а миллиарды документов в день, которые создаются даже не одной, а кучей компаний, ага это ~11574/сек. Про базу ничего не скажу, но в ERP большинство объектов нумерации документов это 10 символов, т.е. скажем так 100 дней и диапазон нумерации меняем, вместе с годом кстати. Дальше про структуру документа, которая должна быть очень простой, чтобы обеспечить максимально быстрое сохранение документа в базу данных, тут я не возражаю конечно, но до сих пор не пойму почему и с какого времени было решено что SAP ERP стала просто системой хранения документов? Т.е. вот это вот ERP - это оказывается просто хранение документов? Я так понимаю вы полностью солидарны с Муковозом Ильей Сергеевичем, который давно уже как я понимаю все начиная от баланса и заканчивая остатками хранит и ведет на BW системах, для чего у него даже специально выделенные BW-консультанты по сегментам вводятся в отдел поддержки. Занятно, лет уже 8-9 назад выбросили R/3 из названия продукта, сейчас решили похоже что про этот самый R, уже забыли все, поэтому встречайте новую реинкарнацию потерявшейся буквы R в виде не очень приятного в русском звучании названии -> HANA и... и тут снова какая-то непонятка, если HANA это СУБД, а драйвер/коннектор от/к SAP ERP уже написан и работает, то зачем нам теперь BW? Если на данных ERP мы получим ускорение, ну хорошо в 100 раз, т.е. отчет формирующийся на данный момент 1 сутки, без всяких вопросов, теперь будет формироваться 864 секунды, ну т.е. чуть меньше минут 15, ну вполне вменяемо как мне кажется или на BW оно вообще будет меньше секунды. Не быстро это хорошо, но охота посмотреть на того бойца который генерит отчетность со скоростью 1 отчет = 1 секунда и при этом как-то наверное еще умудряется понять что же в этом отчете написано, тоже наверное где-то внутри у него своя HANA стоит и коннектор работает.

В моей компании активно используется порядка 10-15 тыс sku, при поступлении товара мы используем описанную выше схему. Учитывая, что обновлять данные в инфозаписях можно используя массовую загрузку- проблем не возникает.

Олег, а можете привести пару бизнес кейсов, когда можно на практике использовать этот сценарий?
 
Лично меня смущает, что поступление оценивается по ценам из инфо-записи. Т.е. нужно или актуализировать цену в инфо записи перед приходом, что не реально, или постоянно будем получать отклонения на GR/GI при фактурировании, что не понравится бухгалтерам.

Олег, а можете привести пару бизнес кейсов, когда можно на практике использовать этот сценарий?
 
Лично меня смущает, что поступление оценивается по ценам из инфо-записи. Т.е. нужно или актуализировать цену в инфо записи перед приходом, что не реально, или постоянно будем получать отклонения на GR/GI при фактурировании, что не понравится бухгалтерам.