Бюджет: 2000 UAH Термін: 5 днів
Да, был уже такой проект. Когда-то делал программу на базе экселя по автоматической обработке заказов с минимальным участием оператора, могу продемонстрировать. Стукните в скайп sokolv555.
Нужно сделать надстройку для екселя, которая бы связывала ексель файл и базу данных сайта на opencart 1.5.1.3 для втягивания заказов и разносил данные по ячейкам.
версия екселя 2010
Надстройка в виде отдельного ексель файла, запустив который, надстройка появляется во всех открытых ексель файлах.
Необходимые настройки которые можно задать через интерфейс надстройки (т.е. без прибегания к правке кода макроса):
- данные авторизации к базе (адрес, логин, пароль)
- с каким статусом заказа втягиваем к себе в ексель ( чтобы макрос не тянул все заказы с базы, ему нужно понимать какие из них новые , для этого указываем с каким статусом нас интересуют заказы (т.е. какой статус у новых заказов)
Список статусов нужно чтобы втягивался с сайта по нажатию кнопки, т.е. если на сайте добавятся или убавятся статусы, нажав кнопку в макросе будет актуальный список существующий статусов заказа. В настройке должна быть возможность множественного выбора, т.е. чтобы если нужно можно было втягивать заказы с несколькими статусами, например чтобы нужные статусы для втягивания отмечались галочками.
Для отбора нужных заказов для втягивания, кроме статуса заказа, нужно еще иметь возможность отбора заказа по типу оплаты.
Т.е. так же нажатием кнопки втягиваем в макрос возможные способы оплаты с базы сайта и потом выбираем галочкой с каким способом оплаты нас интересую заказы для втягивания.
Например выбираем:
Статус заказа: В обработке (этому статусу соответствует новый заказ на сайте)
И отмечаем Способ оплаты: Оплата при получении на Новой почте (Наложенный платеж)
Т.е. втянутся заказы соответствующие статусу В обработке и при этом у которых только способ оплаты «Оплата при получении на Новой почте (Наложенный платеж)»
Втягиваем следующую информацию с заказа:
• Номер заказа
• Название товара
• Артикул товара
• Стоимость товара
• e-mail
• телефон
• фио клиента
• данные по доставке.
• комментарий
Данные:
• Название товара
• Стоимость товара
• e-mail
• телефон
в екселе вписываются каждый в свою ячейку, поэтому в макросе в настройках нужно указать для каждого из этих данных в какой столбец вписывать.
А данные:
• Номер заказа
• фио клиента
• данные по доставке.
• Комментарий
• А так же дублирование телефона, e-mail и артикула в ячейку вместе.
Вписываются в одну ячейку вместе
Пример что там должно быть в общей ячейке:
#22398 Иванов Василь Петрович 0961234567
Способ доставки:Доставка Новой почтой
Отделение №1: ул. Львовская, 38л
Городок(Львовская обл.)
(Львівська область)
Україна
+380961234567
sla5е[email protected]
CS-ERU5SL
Комментарий: Наложений платіж,
Данные вносятся на открытый (активный) текущий лист документа в следующую свободную строку после занятых, определяется по столбцу “B” (может вы лучше придумаете идею)
Должна быть кнопка, Втянуть заказы, по нажатию которой начинает втягиваться заказы, согласно выставленных настроек.
И так же должно быть прямо на панели надстройки 2 поля для ввода цифр, куда можно вписать номера заказов, которые нужно втянуть, если введены цифры, тогда все настройки косательно статусов заказа и формы оплаты игнорируются и просто втягивается те номера которые указаны.
2 формы чтобы задать диапозон заказов, которые нужно втянуть если это больше чем один, если нужен один заказ, тогда цифра только в первой форме или в 2-х формах один и тот же номер. Можно сделать одну форму и чтобы макрос понимал написанное в ней, например: 100-110 то втягиваем все заказы с номера 100 по 110 включительно, если 110,113,120 – то втягиваем заказы с номерами 110,113, 120. Или если одна цифра – то это один заказ с этим номером.
Во время втягивания заказов должна быть табличка где будет отображаться информация о ходе выполнения, чтобы было понятно что сейчас происходит и когда закончится.
Заказы должны втягиватся быстро.
Макрос должен быть сделан так, чтобы если что-то пойдет не так, то это не приведет к полному зависанию екселя намертво.
Если в заказе несколько товаров, то этот блок строк выделяется заливкой, чтобы было сразу видно что эти несколько строки относятся к одному заказу.
В столбце Е «Где продано» для заказов втянутых макросом устанавливаем значение из выпадающего списка «Магазин»
Бюджет: 2000 UAH Термін: 5 днів
Да, был уже такой проект. Когда-то делал программу на базе экселя по автоматической обработке заказов с минимальным участием оператора, могу продемонстрировать. Стукните в скайп sokolv555.
Розробка додатку Power App, супровід мене як новачка. Canvas App, допомога в розробці Screen Домомога в розробці структури даних для App Програмування функцій Допомога у створенні Date-verse-Таблиць
Шукаємо досвідченого Shopify-розробника для створення повноцінного інтернет-магазину з нуля з обов'язковою інтеграцією з Amazon. Що потрібно зробити: Інтеграція з Amazon як основа проєкту: синхронізація товарів, залишків та замовлень між Shopify та обліковим записом продавця на Amazon. Налаштування магазину будується з урахуванням цієї інтеграції з самого початку. Налаштування магазину: кастомізація теми, структура каталогу, картки товарів, кошик, оформлення замовлення — все узгоджується з логікою інтеграції з Amazon. Технічна оптимізація для AI-видимості (GEO): структуровані дані, файл llms.txt, оптимізація контенту під відповіді AI-асистентів (ChatGPT, Perplexity, AI Overviews тощо), правильна семантична розмітка сторінок. Базове SEO-налаштування: метатеги, sitemap, швидкість завантаження, мобільна адаптивність. Підключення платіжних систем. Встановлення необхідних додатків (відгуки, email-маркетинг, аналітика тощо). Тестування магазину перед запуском.
Потрібно допомогти переосмислити та побудувати чисту relational-схему для внутрішньої операційної системи на Airtable. Поточна база вже використовується командою, але вона виросла органічно: структура частково плоска, частина таблиць/в’юшок використовується активно, частина майже не використовується, а документи зараз радше “підтягують” інформацію в Airtable, хоча в ідеалі Airtable має стати джерелом правди і генерувати потрібні операційні артефакти. Потрібна не просто допомога з формами чи автоматизаціями, а саме структурна робота: аналіз поточної логіки, проєктування relational-схеми, створення чистої нової бази/інстансу, документація та рекомендації щодо міграції до нової схеми. І потенційно можливо навіть впровадження Контекст системи: Є два основні напрями: Feedback system Система для збору й обробки сигналів від зовнішніх радників, фокус-груп, внутрішніх команд та stakeholders. Має підтримувати: signal log / реєстр сигналів; advisor tracking; feedback intake; synthesis dashboard; status / gates / recommendations; close-the-loop логіку. Product catalog У каталозі продуктів зараз близько 400 записів, приблизно 100 з них активні/live. Потрібно краще структурувати продукти, статуси, зв’язки, джерела даних, lifecycle/gate logic та звітність. Поточний стан: Airtable вже існує і використовується командою. Поточна точність даних приблизно 80%. Схема переважно flat, не relational. Активно використовуються лише перші кілька таблиць/вкладок: Частина validation gates, tasks/decisions і dashboard views поки майже не використовується. Немає PII. Будь-яка робота з live base має бути максимально обережною: без змін у production без погодження. Ідеальний підхід — аналіз структури та побудова нової чистої бази окремо у Sandbox. Що потрібно зробити: Phase 1 — Audit & architecture recommendation Подивитися на поточну структуру Airtable. Визначити, які таблиці/поля/в’юшки реально потрібні, які дублюються, які можна об’єднати або прибрати. Запропонувати relational data model. Описати основні entities, relationships, primary keys, linked records, lookup/rollup logic. Запропонувати clean schema для Проєкту + Product catalog. Визначити, які dashboards/interfaces потрібні для різних користувачів. Підготувати короткий architecture memo або schema map. Phase 2 — Build clean Airtable base Створити нову чисту Airtable base / instance. Налаштувати таблиці, поля, linked records, views, basic interfaces. Налаштувати базову dashboard/reporting логіку. Підготувати migration map: як переносити дані зі старої структури в нову. Задокументувати структуру так, щоб команда могла підтримувати її після передачі. За потреби — запропонувати automation strategy, але без надмірної складності. Очікувані deliverables: Airtable schema map. Нова clean Airtable base. Таблиці + relationships + key fields. Views/interfaces для основних користувачів. Migration recommendation. Коротка документація для команди. Рекомендації щодо governance: хто вносить дані, хто апрувить зміни, які поля є обов’язковими, як уникати дублювання. Опційно: 1 короткий handoff call / Loom walkthrough. Важливі security / access правила: Без PII. Без небезпечних токенів або персональних інтеграцій. Не можна підключати AI/MCP/ChatGPT/Claude до live Airtable. Якщо потрібен доступ до існуючої бази, він має бути read-only або через експорт/скріншоти/структурний опис. Будь-які записи/зміни робляться тільки в новій тестовій/чистій базі, не в live production. Кого шукаю: Ідеальний кандидат має досвід: Airtable base architecture; relational schema design; Airtable interfaces, views, forms, automations; migration/cleanup of messy Airtable bases; product operations / CRM / workflow systems; documentation and handoff; У відгуку, будь ласка, вкажіть: Приклади Airtable-баз або систем, які ви будували. Чи був у вас досвід перетворення flat Airtable structure у relational schema. Як би ви підійшли до audit → schema design → build. Орієнтовну оцінку годин для Phase 1. Ваш hourly rate або fixed-price пропозицію для першого етапу. Чи готові працювати під NDA. Формат роботи: Почати бажано найближчим часом. Спочатку можна зробити невеликий paid discovery/audit, після чого перейти до повного build.