Система авто-уведомлений о пополнении склада аналитика. На 8n8. Небольшая автоматизация для e-commerce. Раз в сутки система считает скорость продаж по каждому товару и отправляет в Telegram, что пора заказывать (с рекомендованным объемом) и на сколько дней хватает остатка. Что делаем: Забор данных: KeyCRM API (история заказов) + остатки/заказы с Rozetka (API или выгрузка) Хранение в SQLite на моем VPS (Contabo, Linux) Расчет среднего продаж, запаса в днях, точки заказа ABC-анализ: приоритизация, какой товар пополнять первым (класс A — главные по выручке — важнее) Ежедневный Telegram-бот + запуск по cron Все пороги (срок поставки, страховой запас, целевой запас) — в конфиге

Приветствую! Мне нужно визуально кастомизировать систему InvenTree (open-source) для презентации проекта кофейни. Сложный бэкэнд и интеграция с кассой (POS) не требуются — важна внешняя переделка интерфейса, чтобы показать разницу «Было / Стало». Стек проекта: Python (Django) + React (Mantine UI). Что нужно сделать в интерфейсе: Кастомный брендинг, Переименование в боковом меню и таблицах, Очистка форм от инженерных полей, Настроить один рецепт «сборки» напитка (например, Капучино), чтобы при ручном списании со склада наглядно вычитались все ингредиенты, добавить функции в виде дополнительных отчётов, и объяснение принципов работы сделанных изменений. Все конкретные детали обсудим лично. Требования к исполнителю: Опыт работы с Django и React (Mantine UI). Способность сделать задачу быстро — проект нужен для презентации. Работаем через Сейф (Безопасную сделку). В ответе начните со слова «КОФЕ», чтобы я видел, что вы дочитали до конца. Напишите ваши сроки и цену

Необходимо разработать приложение или скрипт, который будет автоматически конвертировать файлы из форматов YML или JSON в формат XLS, с последующей генерацией ссылки на выходной XLS файл для прома Требования: Входные данные: Файл в формате YML (ссылки будут предоставлены) или Файл в формате JSON (ссылки будут предоставлены, JSON не содержит дерева категорий, но каждый товар находится в отдельном массиве). Выходные данные: Файл в формате XLS с доступом через прямую ссылку. Файл должен обновляться автоматически по расписанию, например, ежедневно. Функциональные требования: Возможность указания количества дней для Наличия Под заказ для каждой входной ссылки. Приложение должно стабильно работать в условиях ограниченного по ресурсам хостинга. Желательно интуитивно понятный веб-интерфейс для управления настройками.

Необходимо внести небольшое изменение в программу, которая формирует заказы для печати. Задача: Мы добавили в ассортимент мягкое стекло с принтом. В заказах название принта будет выделено символами #...# для корректного распознавания. Пример: Мягкое стекло, #Абстракция белая# 2.0mm, Форма: Прямоугольник... Необходимо: если в тексте заказа присутствует фрагмент между символами #...#, программа должна распознать его как заказ с принтом; при формировании PDF или листа для печати такой заказ нужно выделить отдельным цветом (любым заметным, согласуем во время выполнения); остальная логика работы программы должна остаться без изменений. Пример заказа добавляю ниже для тестирования.

О проекте: Мы запускаем B2B-сервис сквозной аналитики и управления рекламными кампаниями для таргетологов и медиабаеров. Продукт будет работать с официальным Meta API. Главная техническая сложность и фокус проекта — виртуозная работа с лимитами Facebook, маршрутизация трафика между пулом наших приложений и жесткая система защиты инфраструктуры от блокировок серых рекламных аккаунтов. У нас уже есть подробное техническое задание, описана архитектура баз данных, логика балансировщика и требования к интерфейсам. Ищем исполнителя, который возьмет это в реализацию под ключ (бэкенд + фронтенд дашбордов). Что предстоит сделать (Ключевые задачи): Интеграция с Meta API: Настроить авторизацию пользователей и регулярный асинхронный парсинг статистики рекламных кабинетов. Запросы должны отправляться исключительно пакетами для экономии лимитов. Система авто-отвязки кабинетов: Написать модуль, который непрерывно мониторит статусы рекламных аккаунтов. Если кабинет улетает в бан, система должна автоматически отозвать токен доступа в течение 60 секунд, чтобы защитить наше приложение от санкций Meta. Инфраструктура прокси: Реализовать туннелирование всех запросов к API через пул SOCKS5. Обязательна жесткая привязка конкретного токена пользователя к статичному IP-адресу. Умная маршрутизация: Создать алгоритм, который будет распределять привязываемые рекламные кабинеты между несколькими нашими приложениями Facebook в заданных пропорциях для снижения рисков. Разработка интерфейсов: Создать клиентский дашборд со сводной таблицей статистики и продвинутую админ-панель для ручного управления лимитами пользователей, привязками к приложениям и пулом прокси. Ожидаемый стек технологий: Бэкенд: Python, FastAPI. Асинхронные задачи: Celery, Redis. Базы данных: PostgreSQL (или ClickHouse для статистики, на ваше усмотрение). Фронтенд: Vue.js или React (можно использовать готовые UI-библиотеки и шаблоны дашбордов, упор на функциональность, а не сложный дизайн). Требования к исполнителю: Уверенный опыт работы с Meta Graph API и Marketing API. Вы должны понимать, как работают скользящие лимиты, как читать заголовки загруженности и как работать с токенами. Понимание специфики арбитража трафика. Слова «биллинг», «бан рекламного кабинета», «бизнес-менеджер» и «фарм» не должны вызывать у вас вопросов. Опыт построения асинхронных парсеров и работы с прокси-серверами на уровне сетевых запросов. Готовность работать по четкому техническому заданию и сдавать проект поэтапно. Условия: Формат сотрудничества: Проектная работа Бюджет: Обсуждается индивидуально на основе вашей оценки технического задания. Оплата: Поэтапная, привязанная к контрольным точкам. Как откликнуться: В сопроводительном письме обязательно укажите ваш опыт работы с Meta API, прикрепите ссылки на похожие проекты (или опишите их функционал, если они под NDA) и напишите ориентировочную вилку цен и сроков на разработку подобной системы с нуля. Отклики без описания релевантного опыта работы с Facebook API рассматриваться не будут.