Всем привет!

У нас - на АЗС своя система управления, из нее в определенном формате выгружают файлы для загрузки в SAP (там таблица - объемы, цена, стоимость, вес, плотность, платежные карты и прочие необходимые параметры), потом по ним создаются в системе заказы, поставки, каждый день, потом ежемесячно фактуры.

Все настроено, работает, но работает очень долго, хотя вроде все оптимизировано, индексы созданы и т.д. На два десятка заправок данные за сутки (создание заказов-поставок + по некоторым поставкам движение материалов) грузятся час-два (это если еще материалы никто не заблокировал, кстати, может кто знает, как это обойти, чтобы проблем не было - включен регистр материалов), затем проводятся еще час-два. Может что-то неправильно у меня. Хочу понять, куда копать.

У SAP читал в изойле есть решение SCCR, но оно как я понимаю отдельных денег стоит, и непонятно, насколько оно хорошо (да еще у нас не активирован ни IS-Oil, ни Retail).

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

Здравствуйте.

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

1. Способ реализации создания системных объектов (ФМ, Batch-record, обработка IDOC)
2. Усреднённое количество позиций в документах
3. Пиковое значение количество позиций в документах (существенно только при оооочень большом числе позиций в документе, например более 5000)
4. Среднее количество создаваемых таким способом объектов (документов)

После такого описания уже можно будет что-то обсуждать. Сейчас же совершенно непонятно, что именно и в каком объёме происходит у вас "...час-два...".

Можно попробовать IDOC WPUBON из ритейлового функционала. Он генерит документ материала + SD фактуру. То есть по сравнению со стандартным сбытом не нужен сбытовой заказ и исходящая поставка.

Не пробовал его в системе с неактивированным ритейлом, но есть подозрение, что будет проводиться как миленький.

Еще плюс в том, что есть стандартные средства, чтобы запустить проводку IDOC во много потоков, за счет этого можно ощутимо ускорить загрузку.

ребята, спасибо за участие, в принципе я спрашиваю "вообще", кто чем пользуется. именно АЗС интересуют, весьма специфичная штука.
насчет "час-два", так и получается )))

LKU, про WPUBON посмотрю (попозжА), спасибо. Пока из существующего решения хочу выжать максимум.

короче, мы [s]написали в спортлото[/s] заказали у SAP сервис BPPO (входит в поддержку)
SAP провели анализ, дали рекомендации, весьма хорошие.
будем применять.
как закончу, может в кратце напишу, но мало кому интересно, много Z
и кстати как раз SAP выпустили ноту по оптимизации выборки из таблицы CKMLMV005, нота 1859645 (пока пилотная), заметно ускорилась работа

Хотел же написать
Короче, рекомендации по результатам проведенного сервиса SAP BPPO увеличили быстродействие в среднем в 3 раза.

основные затыки были в потоке документов, естественно

что помогло:
1) При вызове BAPI_SALESORDER_CREATEFROMDAT2 и BAPI_SALESORDER_CHANGE очистить в order_items_in поля ref_doc, ref_doc_it, ref_doc_ca, а нужные поля потом заполнять в USEREXIT_MOVE_FIELD_TO_VBAP.
2) Нота 105512
3) каждый год создавать новые сбытовые контракты - чтобы в потоке не копилось - это очевидно, но проконтролировал это дело, чтобы пользователи не ленились
4) ну и нота 1859645, писал в прошлый раз

надеюсь кому-то что-то окажется полезно