Support for Samotur and its servers
Support is needed for the self-tour program, catalog database servers, and the online server. There are 5 database servers.
Support is needed for the self-tour program, catalog database servers, and the online server. There are 5 database servers.
The client database has been collected over several years from various sources, so the phone numbers are recorded in different formats, one client exists under multiple IDs, cities are entered manually in different languages, and the region is almost never filled in. Because of this, it is impossible to properly segment the database. What needs to be done: 1. Database audit (paid separately, first stage). How many cards, how many phone numbers are out of format, how many duplicates, how many unique city entries. Based on the results — a refined estimate of the remaining work. 2. Standardization of phone numbers. All numbers should be brought to the format +380XXXXXXXXX. Numbers that cannot be unambiguously recognized should not be deleted or guessed, but listed separately. 3. Merging duplicates. Rule: one phone number = one client ID. At the same time, one client can have an unlimited number of numbers. Order history, emails, addresses, tags, and custom fields must be preserved. 4. Parsing cards that have many numbers "attached" to them. 5. Cities and regions. Names of settlements — from a single directory in Ukrainian (API of Nova Poshta or KATOHTG). The region must always be filled in so that all clients from Kyiv and the region can be exported with one filter, not separately for Brovary, separately for Irpin, etc. 6. Protection against re-contamination: normalization of phone and city at the input (website forms, integrations, manual entry) + regular background checks of new entries. Requirements: — practical experience with the SIMLA / RetailCRM (v5) API: exporting, updating, merging cards, request limits; — experience with data deduplication tasks; — understanding of Ukrainian address directories. Working conditions: full backup before any changes; initially a dry-run with a report on planned changes for approval, and only then launch on the live database; log of all operations with the possibility of rollback. No irreversible deletions without approval. In your response, please include: — timelines and cost
A centralized server system for collecting and storing data from Planfix, 1C, Meta Ads, and Google Ads is needed, as well as a web dashboard for displaying and analyzing this data. All data, change history, calculations, and aggregated metrics must be stored exclusively in the server database. The dashboard should not store or duplicate business data. It must retrieve the necessary information from the server database via API according to user requests and display it in the form of KPIs, charts, tables, and detailed reports.
We are looking for support for a project based on Yii , we need to make edits and improvements to the database, there is partially a connection with the previous contractor .....................
It is necessary to migrate the database from CRM G-PLUS to MyChatBot Database volume - 26 thousand leads 2 funnels - Call center and Sales department with their own funnels Lead cards (besides name and number) have many different fields Leads also have voice recordings of calls. These also need to be transferred I expect an approximate amount and implementation timeline from the candidate
Create a dashboard for monitoring and analyzing the performance of the company's location network (branches) in Google Business Profile (GBP) through the official Google Business Profile API. Process via a script based on Google Apps Script (link to Google Sheets). Record data in Google Sheets (which serves as a database for Looker Studio). Update: Daily (with an indication of the last update date). Create a Google Cloud service account. The script runs once a day (trigger at 03:00 AM) and sends a request to the GBP API. It retrieves metrics for the previous day for each location (locationId). Records data in a flat format (row = unique combination of Date + Branch ID + Metrics). Key Performance Indicator CardsCard NameGBP MetricDynamic FormatProfile ViewsImpressions (Search + Maps)Percentage %, Sparkline (blue)CallsLocal Services Phone CallsPercentage %, Sparkline (green)Website ClicksWebsite ClicksPercentage %, Sparkline (purple)Direction RequestsDirection RequestsPercentage %, Sparkline (orange)Average RatingAverage Review RatingAbsolute change (e.g., +0.1), Sparkline (yellow)New ReviewsNew Reviews CountPercentage %, Sparkline (turquoise)
General information It is necessary to develop a simple minimalist web system, the main purpose of which is to maintain a client database, create appointments for visits, and automate the process of confirming visits via SMS, sending one-time links through the API from the service itself. The project is being developed in stages. In the first stage, it is necessary to implement only the basic functionality (MVP) so that the system can be used in real work. After launch and testing, it will gradually be expanded with new modules.Main functionality of the first stage User authorization; Client database; Creating and editing appointments; List of appointments (or a simple calendar); Switching between points of sale; Integration with the SMS operator via API; Sending SMS with any text or link for visit confirmation; Confirmation or cancellation of the visit by the client via a one-time link; Displaying the confirmation status directly next to the client's appointment. At the initial stage, instead of a full calendar, the use of a simple list of appointments by days is allowed. Each day should contain a chronological list of bookings indicating the time, client's name, service, employee, and confirmation status. Later, this list can be replaced with a full calendar without changing the system structure. The system must have the ability to switch between points of sale. Each point of sale has its own list of appointments (or calendar), but they all use a common client database.
Task Description: Development of MCP Server for 1C EcosystemGeneral Goal To develop an intermediary layer (MCP Server) that will allow LLM agents to safely interact with the 1C information base. This will enable users to receive reports, create documents, and analyze data through a chat interface using natural language.Functional Capabilities (Tools) The server must provide AI models with a set of tools for performing the following actions: Data Reading: Searching for counterparties, obtaining stock balances, sampling product prices. Analytics: Generating management reports in text or tabular form. Actions: Creating drafts of documents (Customer Order, Invoice), changing task statuses. Metadata: Obtaining the structure of objects (what fields are in the "Employees" directory) so that the model understands what it is working with.Main Implementation Stages API Design in 1C: Preparation of HTTP services in the 1C extension that will accept requests from the MCP server. Setting up authorization (Basic or Bearer token). Development of MCP Server: Defining the input parameter schema for tools (JSON Schema). Mapping requests from MCP to OData calls or HTTP requests to 1C. Security and Limitations: Restricting access rights (Read-only by default). Limits on the volume of returned data (to avoid "crashing" the model's context window with a huge table). Testing: Connecting the server to Claude Desktop or another MCP client. Checking scenarios: "How much of the product 'Brick' is left in the main warehouse?" or "Create a draft invoice for LLC 'Vector' for 5 monitors".Expected Result A working executable file or service that registers in the MCP client configuration. When a request is entered in the chat, the AI automatically calls the necessary tool, queries 1C, and provides a structured response based on real data from the system. Important Note: The main value of this solution lies in the transition from manual report generation to the concept of "Talk to your ERP" (talking to your ERP system).
FUNCTIONAL REQUIREMENTS1.Create a new document “SVM Issuance of Certificates” •Type – select a checkbox between the options “Traditional Retail” and “Modern Retail”If the option Traditional Retail is selectedMain part: •Organization – dropdown list from Reference.Organization. •Department – dropdown list from Reference.EnterpriseStructure•Nomenclature – dropdown list from Reference.Nomenclature.•Document planning MA – selection from Document.CBH_PlanningMA.•Order warehouse – dropdown list from Reference.Warehouses.•Validity period – from, to – calendar •Cluster – dropdown list from reference SVM Cluster•Nomenclature/segment – selection of data type between Reference.Nomenclature and Reference.NomenclatureSegments, value equals and a field for numerical value (details in the prototype) Details in the technical specification attached