Доброе время суток всем.

Подскажите пожалуйста, как же все таки обрабатываются в Retail розничные продажи?

Например: Выгрузка ежедневный отчетов Idoc или с помощью POS DM.

Проблема такая:

В компании нет складов, получается, что при продаже товара оптовым клиентам, товар берется грубо говоря с витрины магазина. И получается, что мы не видим реальных остатков в магазине (складов). Так как возможно необходимый товар уже продался в течении дня. А отчет по продажам в SAP мы увидим после загрузки отчетов. Из за этого срываются продажи и отгрузки оптовым клиентам.

Очень буду благодарен Вам, если наведете на умную ссылку или решение.
Честно признаюсь c Retail не сталкивался, возможно есть стандарт, или я что то не понимаю.

1. У вас системы магазина знают про запасы или на них только регистрируются продажи?
2. Системы магазина централизованы в одну БД или в каждом магазине своя БД, оторванная от остальных?

Типовая практика загрузки продаж в SAP - после закрытия на кассе смены (формирования z-отчета).
Поэтому, действительно, SAP не знает в режиме on-line запасов на магазинах.

Если нужно резервирование товаров в магазинах под оптовые продажи, надо делать on-line запрос из SAP в систему магазина с получением актуальных остатков и созданием какого-либо документа для резервирования запасов (это самый красивый вариант).

Другие варианты - делать резервирование напрямую в интерфейсе системы магазина, без SAP.

1. Да знают, в данный момент там самописная программа, но она так же не видит в онлайне.
2. В данном момент у каждого своя, но при внедрении SAP будет одна.

У коллег была практика сделать так сказать онлайн интеграцию с SAP, каждый чек = сбытовому заказу. Сказали система умерла через месяц.

"Если нужно резервирование товаров в магазинах под оптовые продажи, надо делать on-line запрос из SAP в систему магазина с получением актуальных остатков и созданием какого-либо документа для резервирования запасов (это самый красивый вариант)." Планируется полностью отказаться от самописной программы. Или вы имеете ввиду в кассовую систему?

Можно пожалуйста по подробней про это решение?

Заранее благодарен.

Загружать в SAP в режиме on-line каждый чек я вам тоже не советую.

Если у вас единственная система, которая знает продажи, накопленные с утра текущего дня - это касса, значит нужно учиться у кассы в режиме on-line эти данные получать.

Более подробно.
Вам нужно предоставить корпоративным покупателям два сервиса:
1. в режиме on-line информация о текущих запасах магазинов = текущие запасы в SAP - продажи, накопленные с начала дня.
2. В случае, если корпоративный клиент подтверждает заказ, вам нужно зарезервировать товар в магазине, чтобы его случайно не продали розничному покупателю.
Варианты:
- использовать механизм резервирования в информационной системе магазина,если такой существует или его реально разработать
- позвонить в магазин, попросить отнести товар в подсобку и наклеить стикер "под заказ корп. клиента номер xxx"

А если разделить по складам витрину и стелаж ( в верху витрины обычно небольшие запасы хранятся)

И после ежедневный z-отчет заливать на склад витрины. А опт продажи вести как обычно стандартным SD со склада стелажа.

А если допустим, товар закончился на витрине, прежде чем его переместить физически, делать проводку переноса со склада (стелажа) на склад (витрина).

Чем такой ход событий может обернуться?

P.S. Спасибо LKU за ответы и советы.

kilmir, ваше предложение улыбнуло.

Вы себе представляете трудозатраты на непрерывное раздельное отслеживание запасов товара в стеллаже и витрине на разных складах SAP с ручными проводками?
Так себе и представляю картину - приходит покупатель в магазин, видит что нужного товара нет на витрине, зато есть на стеллаже и тут на него с криком набегает продавец: "погодите-погодите, не могу вам сейчас продать, надо сначала в SAP запустить тр. MIGO и перевести запас между складами!!!"

Я рад, что поднял Вам настроение))

Я видел это себе так: Ходит консультант по залу и смотри за остатками на витрине, если их нет, то он

1 вариант - с ТСД (Терминал сбора данных) собирает данные которые снял со стеллажа и перенес на витрину, а потом выгрузил в SAP
2 вариант - без ТСД ручками, перенес в витрину, а потом пошел и забил все в систему, что перенес.

Вот что я имел ввиду)

kilmir, могу только посоветовать обсудить эту идею с вашим бизнесом.
Если не затруднит - напишите потом про их реакцию.

В общем мы нашли 2 варианта решения нашей проблемы:

1. Если наша ERP будет на HANA то попробуем реализовать чек=сбыт заказу. Надеемся HANA справится.

2. В начале смены снимать остатки в SAP и заносить в Z-табличку и списывать с нее продажи сделанные в кассе онлайн и после, в конце смены делать стандартный z-отчет и сравнивать с этой z-программой (справочником). То есть в SAP будем просматривать этот справочник. и типо получится онлайн.

Как то так. Надеюсь понятно выразился.

Чек нужно проводить не сбытовым заказом, а какой нибудь операцией ЭКТ. Чековым оборотом, или движением материала ЭКТ.

Seneman, а можно по подробнее? как же все таки выглядит это процедура?

IDOC WPBON рождает в SAP два документа:
- документ материала 251 вдв
- счет-фактуру.
Никакого заказа в интерфейсе входящего ЭКТ действительно не предусмотрено.

Понятно. Спасибо всем за ответы и помощь.

1. HANA лицензируется по объему базы. Если вы начнете тянуть на каждый чек полный сбытовой поток с заказом, поставкой, отпуском товара и инвойсом с выравниванием, база выстрелит быстро.
Во вторых, HANA даст вам выигрыш на чтении, но никак не в записи.

Кстати. А как вы собираетесь в этой концепции выравнивать оплаты в конце дня ?

2. Если у вас больше 1-го магазина, это не будет работать. Вы представляете себе количество поддержки, когда z-отчет будет расходиться по оплате кредитными картами, неверному подсчету налички, инкассации, и т.д. ?
Как вы собираетесь бороться с дубликатами (если это POS 1C) ?