(Delphi) Потрібна реалізація потоків

Шукаємо досвідченого 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.

Потрібно перепідв'язати договір оферти в футері на новий, в компанії змінився регламент Завдання на 20 хвилин

Технічне завдання: інструмент звірки рахунків з банком, картами та бухгалтеромЗагальна мета Потрібен локальний інструмент (скрипт/невеликий додаток на Python), який запускається вручну раз на 1-2 місяці на моєму комп'ютері і робить звірку між: Рахунками, які я виставив клієнтам і отримав від постачальників (PDF-файли та фото квитанцій, що лежать у пошті Gmail) Банківською випискою (Excel) Витратами по кредитним картам (Excel, може бути кілька файлів — кілька карт) Excel-файлом від бухгалтера, в який він вносить рахунки для звітності в податкову та ПДВЩо повинен робити інструмент1. Збір рахунків з пошти (Gmail) Підключення через Gmail API (OAuth) Пошук листів за заданий період (наприклад, останні 2 місяці) з вкладеннями Завантаження вкладень: PDF-файли та зображення (фото квитанцій/чеків) Розпізнавання даних з кожного рахунка: дата, сума, назва постачальника/клієнта, номер рахунка (якщо є) Для PDF — витягування тексту безпосередньо Для зображень — розпізнавання тексту (OCR), включаючи текст на івриті2. Читання Excel-файлів Банківська виписка (доходи та витрати) Один або кілька файлів витрат по кредитним картам Excel від бухгалтера зі списком внесених рахунків (в ньому є тільки сума + дата + назва контрагента, єдиного номера рахунка для співставлення немає)3. Логіка співставлення Співставлення записів між джерелами за комбінацією: сума + дата (з допустимим відхиленням) + назва контрагента (нечітке порівняння тексту, оскільки назви можуть трохи відрізнятися).4. Перевірки, які потрібно виконати A. Виставлені рахунки на всі доходиДля кожного надходження грошей у банку — перевірити, чи є відповідний рахунок, який я виставив. Якщо немає — позначити як "доходи без виставленого рахунка". B. Збережені рахунки на всі визнані витратиДля кожного витрату в банку/на картах, який відноситься до категорії визнаних витрат — перевірити, чи є збережений рахунок. Якщо немає — позначити як "витрата без збереженого рахунка". C. Звірка зі списком бухгалтераПорівняти список рахунків, які я зібрав (з пошти), зі списком, який бухгалтер вніс і відправив у податкову/ПДВ. Позначити: Рахунки, які я зібрав, але яких немає у файлі бухгалтера (можливо, не були передані або не внесені) Записи у файлі бухгалтера, для яких не знайшовся відповідний рахунок у моїй колекції D. Перевірка зарплатного листкаПеревірити, що сума, зазначена в зарплатному листку, відповідає сумі, яка фактично списана/надійшла в банку.5. Підсумковий звіт Результат — один Excel-файл з кількома листами: Доходи без виставленого рахунка Витрати без збереженого рахунка Рахунки, відсутні у бухгалтера Записи бухгалтера без відповідного рахунка Звірка зарплатного листка з банком Несумісності/проблемні рядки повинні бути візуально виділені (кольором).Технічні деталі Мова: Python Excel: pandas + openpyxl PDF: витягування тексту (pdfplumber/PyMuPDF) OCR зображень: з підтримкою івриту (бажано використовувати Claude API з підтримкою зображень замість класичного Tesseract, для кращої точності з івритом) Gmail API: google-api-python-client, OAuth (потрібно буде створити проект у Google Cloud Console — це буде зроблено замовником/виконавцем спільно) Результат зберігається як Excel-файл локально на комп'ютері Інтерфейс: достатньо командного рядка (CLI), без необхідності у веб-інтерфейсіФормат здачі Вихідний код проекту Коротка інструкція по запуску (включаючи, як підключити свій Gmail і де покласти вхідні Excel-файли) Інструкція по створенню credentials у Google Cloud Console, якщо це не було зроблено заздалегідьДодатково Готовий надати приклади структури Excel-файлів (банк, карти, файл бухгалтера) та приклади рахунків (PDF і фото) для тестування.