Budget: 5000 UAH Deadline: 3 days
Good day. I can help with the task. But on the condition of either having a copy of the database. Or a stable connection to the server with a copy of the database.
Hello.
There is such a technical task.
It is necessary to set restrictions on the shipment of products with a specified remaining shelf life. That is, it is necessary to establish a restriction in % or in months (there should be a choice) and products that do not meet the restriction cannot be sold to the customer.
For example, I set a minimum remaining shelf life of 12 months, which means that in the customer's order, when pulling the batch, products with a remaining shelf life of less than or equal to 12 months cannot be included, even if such products are available in stock.
This also applies to the restriction in % of the total shelf life.
For example, if the total shelf life is 24 months, that is 100%.
If we specify that the remaining shelf life must be 70%, it means (24/100*70=16.8 months) that products with a remaining shelf life of more than 16.8 months will be included in the order.
If we specify 50%, then accordingly, products with a remaining shelf life of more than 12 months can be included in the order.
If the total shelf life is 36 months and with a restriction of 70%, products with a remaining shelf life of more than 25.2 months will be included in the order.
These settings must be made in the contract with the counterparty.
If no restrictions are set, the program pulls batches from the available stock using the FIFO method.
If a restriction is set in months, it is not possible to set a restriction in % for the same contract, and vice versa, if a restriction is set in %, the field for setting the restriction in months becomes inactive.
When deleting a set restriction, both fields are active; when setting any restriction in one field, the other becomes inactive.
In the case where more products are ordered than are available in stock, the program splits the ordered unit line into several lines according to the batches that will be sold, taking into account the restrictions, and creates another line indicating the quantity that cannot be sold due to the absence of available stock that can be sold. That is, if 1000 units are ordered, of which we can sell 500 units, and the other 500 are either not in stock or have an unsuitable shelf life, the program creates a separate line for these 500 units with an empty batch.
All these actions are performed by clicking the button to fill in batches using the FIFO method.
When clicked again, the program should not duplicate lines with empty batch values.
The settings must be performed via AniDesk through our user.
Budget: 5000 UAH Deadline: 3 days
Good day. I can help with the task. But on the condition of either having a copy of the database. Or a stable connection to the server with a copy of the database.
Development of a Power App, support for me as a beginner. Canvas App, assistance in developing the Screen Help in developing the data structure for the App Programming functions Assistance in creating Date-verse Tables
We are looking for an experienced Shopify developer to create a full-fledged online store from scratch with mandatory integration with Amazon. What needs to be done: Integration with Amazon as the foundation of the project: synchronization of products, inventory, and orders between Shopify and the seller account on Amazon. The store setup is built with this integration in mind from the very beginning. Store setup: theme customization, catalog structure, product cards, cart, checkout — everything is aligned with the logic of integration with Amazon. Technical optimization for AI visibility (GEO): structured data, llms.txt file, content optimization for AI assistant responses (ChatGPT, Perplexity, AI Overviews, etc.), proper semantic markup of pages. Basic SEO setup: meta tags, sitemap, loading speed, mobile responsiveness. Connecting payment systems. Installing necessary applications (reviews, email marketing, analytics, etc.). Testing the store before launch.
Need help rethinking and building a clean relational schema for an internal operational system on Airtable. The current database is already in use by the team, but it has grown organically: the structure is partially flat, some tables/views are actively used, while others are hardly used, and documents currently rather "pull" information into Airtable, although ideally Airtable should become the source of truth and generate the necessary operational artifacts. What is needed is not just help with forms or automations, but structural work: analyzing the current logic, designing a relational schema, creating a clean new database/instance, documentation, and recommendations for migrating to the new schema. And potentially even implementation. System context: There are two main directions: Feedback system A system for collecting and processing signals from external advisors, focus groups, internal teams, and stakeholders. It should support: signal log; advisor tracking; feedback intake; synthesis dashboard; status/gates/recommendations; close-the-loop logic. Product catalog The product catalog currently has about 400 entries, approximately 100 of which are active/live. It is necessary to better structure products, statuses, relationships, data sources, lifecycle/gate logic, and reporting. Current state: Airtable already exists and is used by the team. The current data accuracy is about 80%. The schema is mostly flat, not relational. Only the first few tables/tabs are actively used: Some validation gates, tasks/decisions, and dashboard views are currently hardly used. There is no PII. Any work with the live base must be done with maximum caution: no changes in production without agreement. The ideal approach is to analyze the structure and build a new clean base separately in Sandbox. What needs to be done: Phase 1 — Audit & architecture recommendation Look at the current structure of Airtable. Determine which tables/fields/views are actually needed, which are duplicated, which can be merged or removed. Propose a relational data model. Describe the main entities, relationships, primary keys, linked records, lookup/rollup logic. Propose a clean schema for the Project + Product catalog. Determine which dashboards/interfaces are needed for different users. Prepare a short architecture memo or schema map. Phase 2 — Build clean Airtable base Create a new clean Airtable base/instance. Set up tables, fields, linked records, views, basic interfaces. Set up basic dashboard/reporting logic. Prepare a migration map: how to transfer data from the old structure to the new one. Document the structure so that the team can maintain it after handover. If necessary, propose an automation strategy, but without excessive complexity. Expected deliverables: Airtable schema map. A new clean Airtable base. Tables + relationships + key fields. Views/interfaces for main users. Migration recommendation. Short documentation for the team. Governance recommendations: who enters data, who approves changes, which fields are mandatory, how to avoid duplication. Optionally: 1 short handoff call / Loom walkthrough. Important security/access rules: No PII. No dangerous tokens or personal integrations. AI/MCP/ChatGPT/Claude cannot be connected to live Airtable. If access to the existing base is needed, it must be read-only or through export/screenshots/structural description. Any records/changes are made only in the new test/clean base, not in live production. Who I am looking for: The ideal candidate has experience in: 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. In your response, please indicate: Examples of Airtable bases or systems you have built. Whether you have experience transforming a flat Airtable structure into a relational schema. How you would approach audit → schema design → build. An estimated number of hours for Phase 1. Your hourly rate or fixed-price proposal for the first phase. Whether you are willing to work under an NDA. Work format: It is preferable to start as soon as possible. Initially, a small paid discovery/audit can be done, after which we can move to the full build.
Need to update the offer agreement in the footer to a new one, the company has changed its regulations Task will take 20 minutes