Решение SAP POS by GK обеспечивает самые различные процессы на пункте продажи для всех сегментов торговли: в продовольственной розничной торговле, универмагах, аптеках, текстильной и специализированной розничной торговле.
Text of SAP POS by GK
SAP POS by GKКассовое решение для всех форматов торговли
Решение SAP POS by GK обеспечивает поддержку всех бизнес-процессов в розничных магазинах различных сегментов торговли: продовольственный ритейл, универмаги, аптеки, магазины электроники и бытовой техники, fashion, DIY, специализированные магазины и многие другие. Решение SAP POS by GK — стандарт автоматизации торгового зала, базирующийся на опыте ведущих мировых ритейлеров.
SAP POS by GK — это единственное решение, необходимое Вашему магазину. Данный программный продукт включает полный набор стандартных функций Point-of-Services, основанных на многолетнем опыте ведущих мировых ритейлеров, для любого типа оборудования и предоставляющих покупателям широкий спектр инструментов для поддержки торговых бизнес-процессов.
GK GO — scanless done right
SAP POS by GK — признанный мировой лидер среди кассовых решений, включающий Front-End приложения для всех типов кассовых систем: от классического POS, двухстрочных дисплеев кассира и покупателя или же Touch-Screen POS — до мобильных приложений POS в планшетах, смартфонах или Self-Checkout. Данное решение также включает опцию бэк-офиса в разных вариациях: от классического магазинного приложения до облачного сервиса — для централизованного управления и мониторинга. SAP POS by GK также включает в себя такие программные компоненты, как управление лояльностью и скидками, управление мультимедиа, процессинг подарочных сертификатов и многое другое. Решение гарантирует ритейлерам качественную взаимосвязь с покупателями и целевой аудиторией в условиях стремительного развития omni-channel.
POSMobile POSOpen ScaleLean Store ServerEnterprise StoremanagerEnterprise CockpitEnterprise Promotions ManagementStored Value ServerDigital Content ManagementSelf CheckoutStore Device ControlMobile Customer Experience
s s+7 (495) 215-2178
SAP POS by GK позволяет держать руку на пульсе всех изменений в розничной сети: от магазина к региону, от страны к континенту, в любое ремя, в любом месте. Компоненты Dashboard могут быть ориентированно настроены как на предоставление технической информации службе поддержки, так и на отображение экономических аспектов коммерческой деятельности компании в соответствии с индивидуальными пожеланиями топ-менеджеров.
Решение позволяет видеть оперативные данные по объектам сети в режиме реального времени, что гарантирует возможность быстрого реагирования на возникающие потенциальные проблемы, угрозы и риски. Благодаря приложению для мониторинга, коммерческие директора всех уровней обладают доступом к актуальной информации по результатам выполнения бизнес-процессов магазина, имея возможность оперативно влиять на оптимизацию продаж в магазинах и регионах.
SAP POS by GK предоставляет online информацию, включающую в себя такие данные, как данные по продажам, статистика по скидкам и акциям программ лояльности, размер среднего чека и многое другое.
GK/Retail OmniPOS
Сквозная интеграция Благодаря SAP POS by GK, Вам достаточно настроить только одну точку интеграции, и Ваши данные будут гарантированно доставлены в каждый из магазинов сети. Таким образом, Вы можете заменить многочисленные интеграционные звенья единым централизованным решением, контролирующим весь информационный поток данных компании.
Мастер-данные центральной ERP-системы, промоакции, чековые данные, финансовые документы, заказы, данные конфигураций или мультимедиа — теперь это неважно, надежный механизм SAP POS by GK гарантирует сохранность и доступность всех данных в режиме он-лайн, вне зависимости от их типа. SAP POS by GK позволяет объединить все элементы управления данных Point-Of-Services в одно удобное решение. Признанный мировой лидер в области решений для POS бесшовно объединяет все устройства в одну централизованную систему: от касс самообслуживания и прайс-чекеров до цифровых мультимедийных весов. GK Retail Bus — это платформа, созданная для обеспечения сквозной интеграции всех систем и оборудования Point-Of-Services, включая полную поддержку Omni-Channel.
Offline Merchandise Management
SAP POS by GK Offline Merchandise Management является единственным решением для управления товародвижением в магазине, которое может быть полностью интегрировано в общую транспортную шину Store Device Control. Store Device Control представляет из себя хаб данных для обмена данными между всеми компонентами GK и ERP-системой.
Вам необходимо всего одно решение для управления всей ИТ-инфраструктурой магазина, что позволит значительно упростить общую архитектуру. Решение mobile merchandise management соединяет центральную ERP-систему напрямую с каждым магазином в части бизнес-процессов по управлению товародвижением.
Данное решение гарантирует сквозную интеграцию всех процессов товародвижения магазина, включая печать ценников и этикеток. Store Device Control создан для централизованного управления всеми информационными потоками магазина. Решение представляет собой единый интерфейс между ERP системой и локальными магазинами, что гарантирует автоматическое своевременное получение актуальных данных (цены, скидки и т.д.) всеми объединенными подсистемами. Все данные передаются в центральную систему в режиме реального времени.
Enterprise StoremanagerEnterprise CockpitKPI DashboardSales Cockpit
Lean Store ServerEnterprise StoremanagerEnterprise CockpitDigital Content ManagementStore Device ControlSales Cockpit
Enterprise StoremanagerMobile DevicesLabel Poster PrintSales Cockpit
s s+7 (495) 215-2178
117105, Россия, Москва,Варшавское шоссе, 26Офисный центр «Варшавская Плаза»Т.: +7 (495) 215-21-78www.teamidea.ru
Компания TeamIdea была основана в 2004 году. На протяжении 10-и лет TeamIdea неустанно трудится во имя процветания бизнеса своих клиентов.
Почетные достижения компании говорят сами за себя: получение статуса SAP Gold Partner, премия SAP Quality Awards, успешное прохождение сертификации SAP Center of Expertise и победа в конкурсе SAP Pinnacle Awards. Следует отметить, что за 15 лет существования SAP Pinnacle Awards TeamIdea является единственной российской компанией, удостоенной столь высокой оценки!
TeamIdea помогает своим клиентам успешно управлять такими бизнес-процессами, как бухгалтерский, налоговый и управленческий учёт (контроллинг), консолидация отчётности по стандартам МСФО, торгово-закупочная и сбытовая деятельность, планирование и контроль бюджета, управление логистикой и транспортировками, управление складом (WMS, EWM), производство и ТОРО.
TeamIdea гордится своими клиентами, среди которых: Евросеть, Enter, МГТС, MSD, СОЛНЦЕ МЕХИКО, Цеппелин Русланд, Ashland, HOCHLAND, Rockwool, NETZSCH, HARMAN, Европа Уно Трейд, МТС, Безант-1, Дженерали ППФ Страхование жизни, BEKO, InCity, Медтроник, КазМунайГаз и многие другие российские и иностранные компании.
«. проект с компанией TeamIdea позволил достичь нашей основной цели: результаты взаимодействия МГТС с подрядными организациями по строительству сети GPON оперативно отражаются в операционных системах ПК УКС (для подрядчиков) и SAP ERP (для МГТС) с минимальными отклонениями по времени и корректно создаваемыми объектами», — Директор по развитию и эксплуатации ИТ ОАО «МГТС» Дурыгин В.
«. опыт компании TeamIdea в части внедрения систем планирования и бюджетирования на базе SAP BI позволил удовлетворить все необходимые компании потребности в части бюджетирования и управления затратами», — Финансовый директор ООО «ШТАДА СиАйЭс» Михаил Баранов.
«Богатый опыт компании TeamIdea в части Российской локализации системы SAP позволил существенно сократить сроки внедрения проекта. TeamIdea уделила особое внимание особенностям нашей компании, предложила гибкие решения для бизнес-процессов, учла специфику организации и фармацевтического бизнеса в Роcсии. Отдельно отмечаем профессионализм, слаженную командную работу и ответственность консультантов и программистов TeamIdea», — Финансовый директор ООО «МСД Фармасьютикалс» Дитхард Солдерер.
«В реализации проекта мы опирались на опыт компании TeamIdea, которая была главным разработчиком проектных решений и консультантом по их внедрению. TeamIdea уделила особое внимание функциональным потребностям нашей компании, учла специфику организации и ведения бизнеса Zeppelin на территории России», — Генеральный директор ООО «Цеппелин Русланд» Гуревич И. Р.
Источник: pdfslide.net
Особенности работы сотрудников СБ в программе GK
1. Особенности работы сотрудников СБ в программе GK 14 июнь 2017 г Санкт-Петербург
2. Оглавление
2
Алгоритм проверки ГК(удаление мешка, двойные инкассации)
Алгоритм проверки статуса сотрудника
Отчет по кассе(статистика)
Алгоритм проверки Возвратов(через РКУ)
Алгоритм проверки Отмены позиций
Алгоритм проверки аномальных чеков
Алгоритм проверки несанкционированного открытия ДЯ (нулевые
чеки)
Алгоритм отработки отчета по Непродаваемым товарам
Алгоритм проверки Отрицательных остатков
Алгоритм проверки проведения Markdown(уценки)
Отчет по списаниям в брак
Проверка проведения ЛИ в программе GK
Выгрузка отчета по Потерям в GK
3. Алгоритм проверки ГК
Основное меню – Главная касса – Реестр сейфа – Актуальный остаток
3
4. Алгоритм проверки ГК
5. Алгоритм проверки ГК
6. Алгоритм проверки ГК
7. Алгоритм проверки ГК
8. Алгоритм проверки РКО по ГК
• Архив отчетов – Тип отчета – Документ изъятия из главной кассы
8
9. Алгоритм проверки РКО по ГК
• Можно выгружать за определенный период времени, без
выставления периода формируется отчет за весь период времени
до архивации.
9
10. Алгоритм проверки РКО по ГК
• После формирования отчета видим все РКО по ГК, по датам с
указанием времени проведения в программе. Например, в данном
магазине за 28.01.17 проведено через ГК пять изъятий ДС с
оформлением РКО.
10
11. Алгоритм проверки РКО по ГК
11
Каждый РКО можно открыть двойным кликом или нажатием на кнопку
«Сформировать отчет», просмотреть основание создания РКО:
12. Алгоритм проверки статуса сотрудника
ДМ/ЗДМ в программу GK вносят информацию о каждом сотрудники, в том числе статус (должность
сотрудника). В соответствии со статусом сотрудник может выполнять определенные операции на РКУ.
Статус сотрудника может изменяться в ручном режиме и не имеет привязки к табелю. Отчета по изменениям
статуса нет. Можно проводить проверки путем сопоставления внесенных данных в GK и данных веб-табеля.
12
1. Выбираем закладку «Основные данные» — «Информация о Сотрудниках». Далее не вводя ни какие
данные нажимаем кнопку «Поиск».
13. Алгоритм проверки статуса сотрудника
13
Программа показывает весь список сотрудников, введенных в
программу
14. Алгоритм проверки статуса сотрудника
• Выбираем любого сотрудника (выделяем курсором)
14
15. Алгоритм проверки статуса сотрудника
• Двойным нажатием правой кнопки мыши открывается таблица с
информацией о сотруднике. Выбираем закладку «Права доступа»:
15
16. Алгоритм проверки статуса сотрудника
• Откроется таблица, в которой указаны статусы В колонке «Выбор»,
путем проставления галочки изменяется статус, а следовательно
сотрудник приобретает возможности в соответствии с
установленным статусом.
16
17. Алгоритм проверки статуса сотрудника
• Легким движением мышки наш кассир становится ЗДМ, а так как
ЗДМ это административная должность кассир автоматически
преобретает возможность проведения административных функций
на РКУ(АНН, КОР, Возвраты, Отчеты) без использования ключа.
17
Источник: ppt-online.org
Строим безопасную разработку в ритейлере. Опыт интеграции с кассовым ПО GK
Что самое сложное в проектной работе? Пожалуй, свести к общему знаменателю ожидания от процесса и результата у заказчика и исполнителя. Когда мы начинали внедрять безопасную разработку в группе GK-приложений (кассового ПО) крупного ритейлера, то на входе имели вагон времени и задачи снижения уязвимостей в коде. А вот что и как нам пришлось решать на практике, мы вам расскажем под катом.
Кстати, это уже третий пост, в котором мы делимся своим опытом выстраивания процесса безопасной разработки для крупного ритейлера. Если пропустили, можете прочитать первые две части: о безопасной разработке порталов и мобильных приложений и о безопасной разработке в группе приложений SAP.
О проекте
С этого скоупа мы начинали, когда пришли к заказчику. Согласно стартовому плану проекта, у нас были довольно вольготные сроки его реализации. Мы очень радовались, наивно думая, что сможем вести несколько проектов одновременно. В итоге мы почти все время уделяли именно кассовому ПО, потому что все оказалось гораздо сложнее. В целом, это стало самым сложным направлением интеграции, поскольку здесь требовалась наиболее серьезная автоматизация процесса.
Во-первых, мы столкнулись с мощной бюрократической машиной. Каждое действие требовало постоянных согласований, внесения в них правок, отчётов, их исправлений, запросов, ожиданий ответов и получений уточнений, которые меняли подходы и требовали серьёзных трудозатрат. А во-вторых, – с тем, что у представителей заказчика не было ни желания, ни времени нам помогать.
GK
GK – это по сути фреймворк, на основе которого можно создавать свою кастомизацию кассового ПО. Заказчик несколько лет назад выкупил у GK некоторую часть исходного кода этого софта для создания собственной версии, соответственно, это направление представляло собой очень большую группу разработки. Большая часть ПО написана на языке Java (90% проектов). Встречались и некоторые проекты, написанные на C++ с использованием довольно древних библиотек, поскольку аппаратное обеспечение было заточено под этот стек технологий. Для Windows – под Windows Server 2008 и под набор библиотек для Visual Studio, для которых данная версия ОС была последней совместимой.
В группе имелись свои жесткие процессы разработки, свои релизные циклы. Процесс ветвления был похож на Gitflow с основной веткой разработки и feature-ветками под разнообразные задачи. Однако feature-ветки могли быть в статусе разработки месяцами (часто готовые к merge, но заброшенные) и вливались прямо перед релизом, в который они по плану должны были войти.
Помимо внедрения в CI/CD мы еще внедрялись и в Jira, для чего нам пришлось создать отдельную сущность для классификации задач «уязвимость». Этот вид задачи позволял заводить уязвимости внутри Jira в соответствии с процессом разработки и работы с таск-трекером.
Направление GK имело длинный процесс разработки, когда создается feature на какой-либо функционал, а потом эта feature-ветка может жить очень долго отдельно от основной ветки разработки. Ее могут верифицировать, но не могут влить в master или development почти вплоть до самого релиза ввиду технических сложностей регрессионного тестирования и т.п.
Решение для интеграции
Когда мы пришли в группу GK внедрять Solar appScreener, мы были удивлены огромным количеством кода в проектах этого направления и предложили стандартный вариант сканирования основной ветки разработки. Разработчики сказали, что они тоже хотят получать информацию об уязвимостях и тоже хотят пользоваться анализатором, но не так, как офицеры безопасности. Им нужна была автоматизация проверки на уязвимости: единая точка входа в виде GitLab, где можно видеть все изменения. Чтобы на сканирование автоматически запускался код не только основной ветки разработки, но и всех побочных веток. При этом нужен был автоматизированный запуск из Jira и по просьбе заказчика полуавтоматизированный – из Jenkins и GitLab.
В итоге мы решили, что самым простым способом анализа ветки (в особенности для «долгих» feature-веток) будет запуск сканирования таким образом, чтобы задача в Jira при ее полном завершении (финальном push-е) переводилась в статус in review. После чего она попадала к специалисту, который может принять изменения и дать добро на старт сканирования кода на уязвимости. Иначе анализ кода по каждому push-у разработчика в репозитории создал бы адскую нагрузку и на людей, и на технику. Разработчики комитили код в репозитории не реже раза в пять минут, и при этом проекты порой содержали по 3,5 млн строк кода, одно сканирование которого, соответственно, длилось 6-8 часов. Такое никакими ресурсами не покроешь.
Стек технологий
Теперь немного о том, какой набор технологий использовался в проекте. GitLab – в качестве системы контроля версий, Jenkins – в качестве CI/CD-системы, Nexus – в качестве хранилища артефактов и Jira в качестве системы отслеживания задач. При этом сами разработчики взаимодействовали только с Jira и с GitLab, тогда как с Jenkins – инженеры, а с Solar appScreener – безопасники. Вся информация об уязвимостях в коде присутствовала в GitLab и Jira.
Поэтому пришлось организовать процесс сканирования следующим образом: в Jira задача переводилась в in review через Jenkins, так как была необходима сборка. Имелся целый стек из Jenkins-плагинов и скриптов, которые получали веб-хук из Jira. То есть помимо вида задачи «уязвимость» нам пришлось создавать в Jira еще и веб-хуки, которые при изменении проекта в GK отправлялись в Jenkins и требовали дополнительных шагов по настройке и серьёзной доработке двусторонней интеграции. Процесс был таким: когда в GK обновлялась какая-либо задача, Jira проверяла, соответствует ли эта задача тем, которые должны отправляться в Jenkins, а именно — является ли это задачей разработки. И только после этого веб-хук уходил в Jenkins, который парсил веб-хук и на основе тела запроса понимал, какому репозиторию в GitLab и какой группе работ (job-ов) нужно запускаться.
Разработчики GK выставили ряд требований при заведении задач в Jira, и мы старались их использовать по полной, чтобы получить максимальное количество информации. Благодаря этому мы смогли правильно матчить репозитории в GitLab и ветку, которую мы должны были стянуть из конкретного репозитория для ее запуска на анализ. В требованиях мы жестко прописали, что ветка в GitLab обязательно должна содержать в названии номер задачи в Jira. В принципе, это best practice, который используется повсеместно – в самой задаче должны быть метки, маркирующие, к какой части приложения/системы относится проблема.
На основе веб-хука, в котором содержалось название проекта, метки, поля с компонентами, а также ключ самой задачи и т.п., происходило автоматическое определение необходимости запуска всех задач. Часть проектов получала ответ всех значений «удовлетворительно» и после этого отправлялась на сканирование. А именно: поступал запрос в GitLab, проверялось наличие в нем данной ветки разработки, и при подтверждении система запускала сканирование новой части кода этой ветки в Solar appScreener.
Учитываем пожелания
Кадр из мультфильма «Вовка в тридевятом царстве»
Поскольку уязвимостей в GK-проектах было десятки тысяч, разработчики не хотели видеть их все. Меж тем в коде содержались порой критичные уязвимости: вставленные в код пароли, отраженные межсайтовые скриптинги, SQL-инъекции и т.п.
Разработчики планировали исправлять уязвимости в бэклоге, а прежде всего хотели видеть изменения: то есть появившиеся в новом коде уязвимости по сравнению с кодом предыдущей версии.
Однако реализованные в нашем продукте механизмы не подразумевают инкрементальный анализ для Java: анализируется байт-код, и невозможно проверить только измененные файлы, потому что теряется связность кода. Изменился один файл, использующий несколько библиотек или других пакетов, которые принадлежат тому же исходному коду, – тогда и вся информация об уязвимости теряется. Поэтому мы сразу обозначили заказчику, что в данном случае возможен анализ исходного кода только целиком, и предложили следующую схему.
Как и для остальных проектов компании, мы выстроили для GK соответствие проекта в GitLab проекту в Solar appScreener, а дополнительно провели корреляцию с веткой разработки. Чтобы разработчикам и офицерам ИБ было проще искать, мы создали файл с реестром названия группы репозиториев, конкретного проекта из этой группы и ветки в Solar appScreener.
Кроме того, разработчики хотели видеть комментарии с изменениями сразу в GitLab, и вот как мы это сделали.
Интеграция с GitLab
Сначала мы сканировали основную ветку разработки для каждого репозитория, от которой шла ветка с изменениями. Поскольку разработчики хотели видеть комментарии с изменениями сразу в GitLab, мы договорились, что если ветка переведена в статус in review, это значит, что уже есть соответствующий merge request на ее вливание.
Система проверяла, что merge request был действительно открыт, и если это подтверждалось, то Solar appScreener анализировал основную ветку разработки. Затем он сканировал ветку с изменениями, строил diff, выгружал его, получал только новые уязвимости, брал из них критичные (наш инструмент позволяет настраивать уровни критичности) и преобразовывал их описание в формат текстовых сообщений со ссылкой на данное вхождение в конкретном проекте в Solar appScreener (см.скриншот ниже). Эти сообщения отправлялись в GitLab в виде дискуссии от имени технической учетной записи. В merge request вместе с измененным кодом можно было увидеть непосредственно строку срабатывания. Её сопровождал адресованный конкретному разработчику комментарий в GitLab типа «вот здесь содержится уязвимость, пожалуйста, поправьте или закройте ее».
Таким образом, между этими двумя сканированиями мы выявляли изменения, которые привнес разработчик. Если количество уязвимостей увеличивалось, это обязательно отражалось в комментариях отчёта. Такая схема была очень удобна для всех участников, потому что в GitLab сразу же появлялись неразрешенные дискуссии, а это значит, что merge request влить нельзя. И ответственный за approve merge request’а видел, что разработчик допустил уязвимости, и их нужно закрыть.
Интеграция с Active Directory
Чтобы просматривать уязвимости через Solar appScreener, разработчикам нужны были права. Поэтому помимо всей интеграции с системами разработки и со всеми тремя скоупами мы еще интегрировались и с сервисами Active Directory. Для нас некоторую сложность представляло то, что у заказчика был чудовищно большой AD с миллионом вложенных групп, что потребовало множества оптимизаций. То есть помимо внедрения CI/CD нам приходилось в процессе решать много сопутствующих задач настройки, адаптации и оптимизации (см. скриншот ниже).
Что касается интеграции с Active Directory, разработчики GK не хотели настраивать параметры доступа в ряд проектов Solar appScreener непосредственно в AD, потому что они не были владельцами этого ресурса. В компании процесс выдачи прав доступа выглядел следующим образом: если разработке нужно было внести нового человека в группу, приходилось писать заявку в техподдержку. Там определяли, кому именно отправлять данный запрос, кто отвечает за выдачу подобных прав, действительно ли можно выдать этому человеку права, авторизованы они или нет и т.п.
Это трудоемкий процесс, которым разработчики не управляли, в отличие от GitLab.Поэтому они попросили организовать интеграцию с AD следующим образом. Они разрешают видеть уязвимости не только техвладельцам системы и офицерам безопасности, как это было сделано для других направлений, но и сделать матчинг прав в GitLab.
То есть если человек имеет права разработчика и выше (maintainer, владелец репозитория), то он может просматривать соответствующие проекты в Solar appScreener, которые относятся к этому репозиторию. Когда в Solar appScreener создавался новый проект, система запрашивала имена всех, кто состоит в GitLab в данном репозитории с уровнем доступа выше разработчика.
Список выгружался, поступало обращение в анализатор кода, который в свою очередь отправлял запрос в AD с добавлением списка отобранных людей. Все, кто состоял в данном репозитории в GitLab, получали автоматические права через свои AD-учетки на доступ к проекту в Solar appScreener. В конце всей цепочки генерился pdf-файл с отчетом по уязвимостям из анализатора кода. В отчете содержался diff, который рассылался списку пользователей проектов GK на электронную почту.
Резюме
Реализованная интеграция с кассовым ПО GK – это пример весьма масштабного проекта внедрения и автоматизации в компании процесса безопасной разработки, который был выстроен не только вокруг службы информационной безопасности, но и вокруг разработчиков. Причем в этой группе проектов так же, как и в других группах, параллельно шли сканирования основной ветки разработки: офицеры безопасности тоже заводили задачи в Jira и их верифицировали. Уязвимости заносились в бэклог и позже исправлялись.
Разработчики получили для себя удобный инструмент, встроенный в привычную среду и workflow. Так как они выбрали для себя порог из топ критических уязвимостей, которые довольно редко возникают, их нагрузка несильно возросла после внедрения. В итоге довольны оказались все участники проекта: и те, кто стремился повысить безопасность кода, и те, кому приходилось исправлять уязвимости.
Если у вас есть собственный опыт реализации практик безопасной разработки, пожалуйста, поделитесь им в комментариях!
Напомним: это третья часть цикла статей о построении процесса безопасной разработки в крупном ритейлере. В следующем посте будем подводить итоги работы над этим масштабным проектом: поговорим о том, чему мы научились в процессе, и какое развитие получил наш инструмент благодаря такому опыту.
Источник: habr.com