Олег, спасибо за Ваш содержательный комментарий.
 
Не очень понятно, что вы подразумеваете под термином документ, но тем не менее.
Если Вы имеете в виду отдельные транзакции, создаваемые пользователями системы, то да, 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 при фактурировании, что не понравится бухгалтерам.

ну для таблиц синтаксис INTO TABLE - тут явно древняя конструкция для таблиц с заголовком

Ну там написано INTO INTERNALTABLE, не хидерлайн, не рабочая область, вот поэтому и озадачило. Было бы что-то типа INTO WORKAREA, вопросов бы небыло.

может таблица с заголовком. Да и вообще давно не рекомендуется использовать такие штуки с ENDSELECT.