Одной из причин, по которой мне нравится платформа NetSuite, является «гибкость» для преобразования вашей реальной бизнес-ситуации в стандартный рабочий процесс ERP.
Во многих отраслях розничной торговли продуктами питания и бакалейными товарами ежедневно совершается огромный объем транзакций в точках продаж, которые необходимо интегрировать с серверной финансовой и логистической системой. Мы всегда предпочитаем получать «Сводку данных о продажах» в основном потоке продаж, а не охватывать все необработанные транзакции POS.
Давайте посмотрим на следующий пример бизнес-кейса сети магазинов Donut:
Мы собираемся построить следующую логику на платформе Suite-Cloud:
- Пользовательская запись: для хранения необработанных данных POS, таких как номер счета, количество, сумма.
- Сценарий сопоставления/уменьшения: группировка и объединение необработанных данных POS в заказ на продажу по определенному времени (например, дню), проданным товарам и местоположению (например, магазину).
1.Пользовательская запись
На самом деле, использовать Suite-Builder для создания пользовательской записи очень просто. Самая сложная вещь — это настраиваемое поле «IsSycned», которое представляет собой тип флажка. Предлагается избегать дублирования синхронизации.
2. Сценарий сопоставления/уменьшения
Скрипты Map/Reduce работают в 5 этапов, эти этапы:
Этап 1: получение данных ввода
Этот этап вызывается один раз в начале вашего скрипта. На этом этапе мы определяем и/или собираем исходные данные, которые мы хотим, чтобы этот скрипт обрабатывал. Мы строим сохраненный поиск, чтобы вернуть запись, которая не синхронизирована и создана сегодня.
Этап 2. Этап сопоставления
Возвращая объект caseSearch. на этапе getInputData(), скрипт выполняет поиск и вызывает функцию map() для каждого результата. Если есть 10 результатов (т. е. 10 транзакций POS), фаза функции карты будет вызываться 10 раз. Для каждого раза функция карты будет подготавливать пару свойств ключа и значения для следующей фазы.
В нашем примере ключ представляет собой строку, состоящую из внутреннего идентификатора местоположения и внутреннего идентификатора товара (т. е. от 3 до 20, что эквивалентно «Центральному торговому центру»). - ” D-002 Глазированный малиновый пончик).
Значение представляет собой целую часть объекта json, который содержит все данные каждого POS-данных. (Все столбцы поиска на этапе 1)
3 замечания по этапу карты
- Когда данные вводятся на этапе карты, это строка данных JSON. Нам нужен метод
JSON.parse(context.value)для разбора строки JSON и создания объекта Javascript.
2. Если для этапа сокращения требуется только простой набор данных (например, количество проданных пончиков), мы можем установить значение value: itemsQTY.
3. На этом этапе вызывается самоопределяемая функция Updated_Custom_Table() для обновления настраиваемого поля «IsSycned» с False на True во избежание дублирования в следующем запланированном задании.
Этап 3. Перемешивание
Этот этап происходит автоматически, и нам не нужно писать какой-либо код для его выполнения. На этом этапе перемешивания NetSuite упорядочивает или перемешивает все данные таким образом, чтобы объединялись все значения с одним и тем же ключом.
Результатом этапа перемешивания является серия уникальных ключей, значениями которых является массив всех данных из функции map() с совпадающим ключом. В нашем примере одни и те же товары в одном и том же магазине будут сгруппированы для следующего этапа.
Этап 4. Сокращение фазы
Все ингредиенты готовы. Фаза сокращения — это «основной шаг» вашего скрипта, который точно создает/обновляет заказ на продажу. Каждый раз, когда вызывается reduce(), система предоставляет пару свойств Key и Value(s) для объектов контекста. В нашем примере ключ представляет собой внутренний идентификатор местоположения + внутренний идентификатор элемента, значения содержат массивстроковых объектов, содержащих всю транзакцию POS.
Например: при вызове ключа 3–20 (т. е. «Центральный торговый центр» — «D-002 Глазированный малиновый пончик») возвращается следующий массив:
Затем мы будем использовать 2 цикла, чтобы суммировать все количество и количество вместе в каждом цикле ключа.
Наконец, выполняется 3 набора самоопределяемых функций для создания и обновления заказов на продажу. Основное предложение — создавать 1 заказ на продажу для каждого магазина (местоположения) в день.
Этап 5. Подведение итогов
Это заключительный этап скрипта map/reduce. Эти этапы позволяют вам вести журнал и возвращать ошибку.
Заключение (Зачем нам нужен скрипт Map Reduce?)
Вам может быть любопытно, почему нам нужен скрипт Map Reduce для выполнения этого простого примера. Ответ — большие объемы данных. Представьте, что мы обрабатываем не 10 записей, а десять тысяч записей. Это лучшая идея для ситуаций, когда данные можно разделить на небольшие независимые части для выполнения.
Кроме того, мы также можем установить ограничение параллелизма (количество заданий, отправленных для карты и этапов сокращения) в развертывании. Это означает, что эти этапы могут выполняться параллельно для обработки больших объемов данных за короткий период времени.
Что дальше?
Поняв основную логику Map Reduce, мы можем улучшить сценарий M/R следующим образом:
- Добавьте функцию преобразования, чтобы преобразовать заказ на продажу в доставку/выставление счетов для продажи, чтобы обновить статус запасов.
- Создайте связь (гиперссылку) между POS-транзакцией и заказом на продажу и т. д.
- ** Дизайн и код Уилсона Ченга.
Вы можете скачать код в моем Github
