записки, в которые можно заглянуть, когда понадобится
О сколько нам открытий чудных (R3 Retail)
Запись от Wamr размещена 17.10.2014 в 18:14
Краткий перечень неожиданностей, с которыми встретился при знакомстве с Retail.
1. Установка. Количество устанавливаемых и неустанавливаемых компонент из раздела Retail инсталятора. Надо изучить инструкцию и попробовать несколько раз чтобы понять, что куда и в какой последовательности устанавливается.
2. Способ обмена данными. За всеми сервисами асинхронного и синхронного обмена, обменными базами и пр. лежит обмен файлами через расшаренную папку, в которую одна сторона кладет, а вторая читает файлики.
3. Базы. Где какие базы и какая часть ритейла к ним обращается удалось понять не сразу, а после нескольких попыток установить и настроить связи.
4. Сервисы. После установки сервисов надо править их config файлы ручками, чтобы они нормально могли взаимодействовать между собой и DAX, и чтобы смотреть их логи.
5. Джобы. Чтобы заработали джобы по выгрузке данных надо запустить процедуру генерации классов обмена.(Схема канала розничной торговли - Создание классов)
6. Операторы POSа. Привязка сотрудников (и клиентов) к некоторому магазину осуществляется через указания в них "адресной книги" связанной с магазином.
7. Новый клиент. Клиент заведенный на POS может не попасть в список клиентов при следующем поиске. Так как создается непосредственно в DAX через сервис и бизнес-коннектор, а ищется в локальной БД канала продаж.
8. Operation Unit. Магазин должен быть обязательно сопоставлен с Operation Unit, так как в нескольких местах именно через OU идет связывание сущностей.
9. Остатки. При просмотре остатков учитывается настройка групп магазинов и адреса связанных OU. Без настройки этого на POSе остатков со складов не увидеть.
10. Retail Transaction Service. Сервис (веб-приложение), который принимает запросы от POSа и переадресует их в статические методы одноименных классов DAX через BC. Поразила прямолинейность процесса (куча статических методов на классах) и собственно реализация, когда в один метод засунут и разбор XML и создание всех сущностей без применения каких-нибудь aif или классов генерации документов.
11. Транзакции. Чтобы начать получать данные об операциях из POSа надо выполнить процедуру перегенерации временных таблиц (почему нельзя было сразу сделать их нормальными на SYS?) настройкой джоба P-0001 (Задание планировщика - Создать промежуточную таблицу)
12. Layouts. Интерфейс POSа можно всячески поднастраивать из DAX. Однако, редактор кнопок и менюх входит в раздел Retai Headquarter инсталятора.
1. Установка. Количество устанавливаемых и неустанавливаемых компонент из раздела Retail инсталятора. Надо изучить инструкцию и попробовать несколько раз чтобы понять, что куда и в какой последовательности устанавливается.
2. Способ обмена данными. За всеми сервисами асинхронного и синхронного обмена, обменными базами и пр. лежит обмен файлами через расшаренную папку, в которую одна сторона кладет, а вторая читает файлики.
3. Базы. Где какие базы и какая часть ритейла к ним обращается удалось понять не сразу, а после нескольких попыток установить и настроить связи.
4. Сервисы. После установки сервисов надо править их config файлы ручками, чтобы они нормально могли взаимодействовать между собой и DAX, и чтобы смотреть их логи.
5. Джобы. Чтобы заработали джобы по выгрузке данных надо запустить процедуру генерации классов обмена.(Схема канала розничной торговли - Создание классов)
6. Операторы POSа. Привязка сотрудников (и клиентов) к некоторому магазину осуществляется через указания в них "адресной книги" связанной с магазином.
7. Новый клиент. Клиент заведенный на POS может не попасть в список клиентов при следующем поиске. Так как создается непосредственно в DAX через сервис и бизнес-коннектор, а ищется в локальной БД канала продаж.
8. Operation Unit. Магазин должен быть обязательно сопоставлен с Operation Unit, так как в нескольких местах именно через OU идет связывание сущностей.
9. Остатки. При просмотре остатков учитывается настройка групп магазинов и адреса связанных OU. Без настройки этого на POSе остатков со складов не увидеть.
10. Retail Transaction Service. Сервис (веб-приложение), который принимает запросы от POSа и переадресует их в статические методы одноименных классов DAX через BC. Поразила прямолинейность процесса (куча статических методов на классах) и собственно реализация, когда в один метод засунут и разбор XML и создание всех сущностей без применения каких-нибудь aif или классов генерации документов.
11. Транзакции. Чтобы начать получать данные об операциях из POSа надо выполнить процедуру перегенерации временных таблиц (почему нельзя было сразу сделать их нормальными на SYS?) настройкой джоба P-0001 (Задание планировщика - Создать промежуточную таблицу)
12. Layouts. Интерфейс POSа можно всячески поднастраивать из DAX. Однако, редактор кнопок и менюх входит в раздел Retai Headquarter инсталятора.
Всего комментариев 0
