Вітаю.
Є таке ТЗ.
Потрібно зробити обмеження по відвантаженню продукції з вказаним залишковим терміном придатності. Тобто потрібно встановити обмеження у % або в місяцях (повинен бути вибір) і продукція, яка не відповідає обмеженню не може бути реалізована клієнту.
До прикладу, я встановлюю мінімальний залишковий термін придатності 12 місяців і це значить, що в замовлення покупця при підтягуванні серії не може попасти товар з залишковим терміном менше або дорівнює 12 місяців навіть якщо такий товар є у вільному залишку на складі.
Це саме стосується обмеження у % від загального терміну придатності.
До прикладу загальний термін придатності 24 місяці це 100%.
Якщо ми вкажемо що залишковий термін придатності повинен бути 70% то це значить (24/100*70=16,8місяців)що в видаткову потрапляє продукція з залишковим терміном придатності більше ніж 16,8 місяців.
Якщо вкажемо 50% то відповідно більше 12 місяців може попасти у видаткову.
Якщо загальний термін 36 місяців і при обмеженні 70%, у видаткову потрапляє продукція з залишковим терміном більше ніж 25.2місяці.
Ці налаштування мають робитись в договорі з котрагентом.
Якщо обмеження не встановлено, то програма тягне серії з наявних у вільному залишку по методу ФІФО.
Якщо встановлюється обмеження в місяцях то паралельно встановити обмеження в % неможливо на один і той самий договір і навпаки якщо встановлюється обмеження у % то віконце для встановлення обмеження в місяцях стає неактивним.
При видаленні встановленого обмеження два віконця активні при встановленні будь якого обмеження в одне віконце, друге стає неактивним.
В випадку якщо замовлено продукції більше ніж є у вільному залишку, програма розбиває рядок замовленої одиниці на декілька рядків відповідно до серій, які будуть реалізовані, враховуючи обмеження, і створює ще один рядок де вказується кількість, яка не може бути реалізована через відстутність залишків, які можуть бути реалізовані. Тобто якщо замовлено 1000 одиниць з яких ми можемо реалізувати 500 одиниць, а інші 500 або відсутні на залишку або з непідходящим терміном, то програма створює окремий рядок на ці 500шт з пустою серією.
Ці всі дії виконуються при натисканні кнопки заповнити серії по методу ФІФО.
При повторному натисканні програма не повинна дублювати рядки з пустими значеннями серії.
Налаштування має виконуватись через AniDesk через нашого користувача.
Бюджет: 750 UAH Термін: 3 дні
Готов виконати ваше завдання під ключ.
Даю гарантію на виконану роботу.
Для розрахунку точної вартості, потрібно обговорити декілька питань.
Вітаю, Влад.
У вас КУП 2.5 редакція вже?
15 липня 2024
Добрий день.
Так.
Вірно - 2.5.
Потенційному виконавцю.
Замовник не надає доступ до віддаленого столу. Лише Енідеск, який підключить вас до компа замовника, а звідти до сервера РДП... З усіма чудовими наслідками такого підключення. Або копія бази, з якою можна працювати лише в SQL, бо в файловому варіанті вона працює дуууже повільно.
Успіхів.
Розробка додатку 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.
Потрібно перепідв'язати договір оферти в футері на новий, в компанії змінився регламент Завдання на 20 хвилин