Проверка оригиналности продукта по QR-коду

Необходимо автоматическое отображение схемы движения товарно-денежных потоков по приблизительному шаблону, приведенному в приложенном файле. Выходные файлы, в которых содержится исходная информация, это файлы выгрузки из баз данных в excel.

Нужна поддержка программы самотуру, серверов каталогизаторов баз данных и сервера онлайн. Серверов баз данных 5 шт.

База клиентов собиралась несколько лет из разных источников, поэтому телефоны записаны в разных форматах, один клиент существует под несколькими ID, города введены вручную разными языками, область почти нигде не заполнена. Из-за этого невозможно нормально сегментировать базу. Что нужно сделать: 1. Аудит базы (оплачивается отдельно, первый этап). Сколько карточек, сколько телефонов вне формата, сколько дублей, сколько уникальных написаний городов. По результатам — уточненная оценка остальных работ. 2. Стандартизация телефонов. Все номера привести к формату +380XXXXXXXXX. Номера, которые невозможно однозначно распознать, — не удалять и не угадывать, а вынести в отдельный список. 3. Слияние дублей. Правило: один номер телефона = один ID клиента. При этом одному клиенту может принадлежать неограниченное количество номеров. История заказов, email, адреса, теги и кастомные поля должны сохраниться. 4. Разбор карточек, на которых «навешано» много номеров. 5. Города и области. Названия населенных пунктов — из единого справочника на украинском (API Новой Почты или КАТОТТГ). Область должна заполняться всегда, чтобы одним фильтром можно было выгрузить всех клиентов Киева и области, а не отдельно Бровары, отдельно Ирпень и т.д. 6. Защита от повторного засорения: нормализация телефона и города на входе (формы сайта, интеграции, ручной ввод) + регулярная фоновая проверка новых записей. Требования: — практический опыт работы с API SIMLA / RetailCRM (v5): выгрузка, обновление, объединение карточек, лимиты запросов; — опыт задач с дедупликацией данных; — понимание украинских адресных справочников. Условия работы: полный бэкап до любых изменений; сначала dry-run с отчетом о запланированных изменениях на согласование, и лишь потом запуск на боевой базе; лог всех операций с возможностью отката. Без безвозвратных удалений без согласования. В отзыве напишите: — сроки и стоимость

Необходимо разработать централизованную серверную систему сбора и хранения данных из Planfix, 1С, Meta Ads и Google Ads, а также веб-дашборд для их отображения и анализа. Все данные, история изменений, расчеты и агрегированные показатели должны храниться исключительно в серверной базе данных. Дашборд не должен хранить или дублировать бизнес-данные. Он должен получать необходимую информацию из серверной базы через API в соответствии с запросами пользователя и отображать ее в виде KPI, графиков, таблиц и детализированных отчетов.

Общая информация Необходимо разработать простую минималистичную вебсистему, основной целью которой является ведение базы клиентов, создание записей на визиты и автоматизация процесса подтверждения визитов через SMS, отправка одноразовых ссылок через API с самого сервиса. Проект разрабатывается поэтапно. На первом этапе необходимо реализовать лишь базовую функциональность (MVP), чтобы систему можно было использовать в реальной работе. После запуска и тестирования она будет постепенно расширяться новыми модулями.Основная функциональность первого этапа авторизация пользователей; база клиентов; создание и редактирование записей; список записей (или простой календарь); переключение между торговыми точками; интеграция с SMS-оператором через API; отправка SMS с произвольным текстом или ссылкой для подтверждения визита; подтверждение или отмена визита клиентом по одноразовой ссылке; отображение статуса подтверждения непосредственно рядом с записью клиента. На начальном этапе вместо полноценного календаря допускается использование простого списка записей по дням. Каждый день должен содержать хронологический список бронирований с указанием времени, имени клиента, услуги, работника и статуса подтверждения. В дальнейшем этот список можно будет заменить на полноценный календарь без изменения структуры системы. В системе должна быть возможность переключаться между торговыми точками. Каждая торговая точка имеет собственный список записей (или календарь), но все они используют общую базу клиентов.