XML price list export function for the website

Synchronization of Microsoft Access and CRM SalesDrive. Data transfer from CRM to Microsoft Access in the first stage (changing the funnel status). Data transfer from Microsoft Access to CRM in the second stage (changing the status in the program).

Project Meta Implement Viber integration without using third-party CRM systems. All work with messages should be done directly in our internal CRM based on BAS / 1C 8.3.Current System BAS / 1C 8.3 Custom configuration "Customer Service" Database of over 40,000 subscribersRequired Implementation Integration through an official Viber Business provider (TurboSMS, GMS Worldwide, or another agreed service). The button "Write to Viber" in the subscriber card. Sending messages directly from BAS. Receiving incoming messages via Webhook. Automatic linking of messages to the subscriber by phone number. Complete preservation of correspondence history in the subscriber card. Displaying the time, message status, and the manager who responded. Simultaneous work of multiple managers. Message templates for quick responses. Assistance with setting up the Viber provider, API keys, and Webhook. Transfer of all source code and settings after the work is completed.Acceptance Conditions The work is considered completed after successful testing of all functions on the working database and transfer of the source code.Guarantee 1 month warranty for fixing bugs related to the implemented functionality. Further modifications are carried out by separate agreement.Result After the project is completed, managers should be able to fully work with Viber directly in BAS: write to clients, receive responses, view correspondence history, and communicate without using third-party CRMs. All source code, modifications, API keys, and settings will be transferred to the client after the project is completed.

Looking for an experienced developer (or a small team) to create an MVP mobile application — a service for urgent calls to specialists similar to Uber, Uklon. Development needed: • mobile application for iOS and Android (Flutter); • server part (REST API); • admin panel; • database. Main functionality of the MVP: registration of clients and performers; authorization; map and geolocation; order creation; search for the nearest performer; push notifications; in-app chat; ratings and reviews; order history; admin panel. Requirements: experience in developing marketplaces, delivery services, taxi or similar projects; Flutter; Backend (Node.js / Laravel / Go / NestJS — ready to discuss); PostgreSQL; understanding of scalable architecture. In your response, please include: Links to applications in the App Store and Google Play. Similar projects you have developed. What architecture you propose. Approximate cost of the MVP. Development timeline. Important: looking for a specialist for long-term cooperation. Interested in the quality of architecture and the possibility of further scaling the project. Budget is negotiable with the suitable candidate.

It is necessary to correct the SQL scripts for the Postgres database. It is required to check the scripts and update data from external Excel tables and between two Postgres databases (different servers). Scripts will be run through AnyDesk using Navicat. List of data for verification and correction: 1. Products subject to repair – assignment of a mark Result: Number of records discrepancies Correction script 2. List of Categories, Groups, Subgroups – comparison with the tmp table Result: Number of records discrepancies Correction script 3. Number of products in category. Groups, subgroups. (statistics) – Comparison by table, identification of discrepancies Result: Number of records discrepancies Correction script 4. List of spare parts in the system with category, group, subgroup - Comparison by table, identification of discrepancies, elimination of discrepancies Number of records discrepancies Correction script 5. Repair items related to spare parts - Comparison by table, identification of discrepancies, elimination of discrepancies Discrepancy table Correction script 6. Reconciliation of balances and SN Discrepancy table

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.