Программисты — удалённая работа в Москве

Задачи чат-бота: сбор информации, информирование клиентов, интерактивное меню или каталог, ответы на типовые вопросы, автоматическое бронирование. Платформа: веб-сайт. Продукт: Стройтовары. Техзадание есть.

Настроить: Не запускается база после неправильного завершения работы. Конфигурация 1С: Бухгалтерия. Версия: 8.3. Найти причину отсутствия запуска базы, перенос баз на другой компьютер.

Разовая задача или временный проект.

разработка формы в visual Studio c подключением базы данных с sql. Разработка с нуля. Глава 2. Проектирование и разработка базы данных 2.1. Проектирование базы данных Первым шагом стала инфологическая модель — схема нужных сведений без привязки к конкретной СУБД. Выделено пять сущностей: «Клиент», «Тур», «Туроператор», «Бронирование» и «Пользователь». Связи такие: у одного клиента может быть несколько бронирований, а каждое бронирование относится к одному клиенту. Один тур может быть забронирован много раз, а каждое бронирование относится к одному туру. Тур предоставляется одним туроператором, а у туроператора может быть много туров. «Пользователь» хранит учетные записи сотрудников и с остальными сущностями не связан. Модель показана на рисунке 1. Рисунок 1 – модель базы данных Затем модель превратилась в ER- диаграмму базы данных Турагентства. Которая представлена на рисунке 2. Рисунок 2 – ER – диаграмма Турагентства клиента в автосервисе 2.2. Разработка базы данных и интерфейса База TravelAgency создана в SQL Server Management Studio и включает шесть таблиц: Бронирование, Клиент , Отель, Статус Оплаты, Транспорт, Тур.(рисунок 3) Рисунок 3 – Таблицы базы данных Состав столбцов и их типы описаны в таблицах 4–9. Таблица 4 – Структура таблицы Клиент № Название Тип данных Ограничения целостности Описание 1 ClientID int PRIMARY KEY, IDENTITY(1,1) Код клиента 2 FIO nvarchar(100) NOT NULL Фамилия, имя, отчество 3 Passport nvarchar(20) NOT NULL, UNIQUE Паспортные данные 4 Phone nvarchar(20) NOT NULL Контактный телефон 5 Email nvarchar(100) NULL Электронная почта Таблица 5 – Структура таблицы Отель № Название Тип данных Ограничения целостности Описание 1 id_Hotel int PRIMARY KEY, NOT NULL, IDENTITY Код отеля 2 Name nvarchar(100) NOT NULL Название отеля 3 Country nvarchar(50) NOT NULL Страна, в которой находится отель 4 Stars int NULL Количество звезд отеля (категория) Таблица 6 – Структура таблицы Тур № Название Тип данных Ограничения целостности Описание 1 id_Tour int PRIMARY KEY, NOT NULL, IDENTITY Код тура 2 Name nvarchar(150) NOT NULL Название тура 3 Date_Start date NOT NULL Дата начала тура 4 Date_End date NOT NULL Дата окончания тура 5 Hotel int FOREIGN KEY, NOT NULL Отель, в котором проживает турист 6 Transport int FOREIGN KEY, NOT NULL Транспорт, на котором добирается турист Таблица 7 – Структура таблицы Бронирования № Название Тип данных Ограничения целостности Описание 1 id_Booking int PRIMARY KEY, NOT NULL, IDENTITY Код бронирования, 2 Client int FOREIGN KEY, NOT NULL Клиент, оформивший бронирование 3 Tour int FOREIGN KEY, NOT NULL Забронированный тур 4 DateBooking date NOT NULL Дата оформления бронирования Таблица 8 – Структура таблицы Транспорт № Название Тип данных Ограничения целостности Описание 1 id_Transport int PRIMARY KEY, NOT NULL, IDENTITY Код транспорта. 2 Type nvarchar(50) NOT NULL Вид транспорта 3 Flight_Number nvarchar(20) NOT NULL Номер рейса Таблица 9 – Структура таблицы Статус_Оплаты № Название Тип данных Ограничения целостности Описание 1 Payment int PRIMARY KEY, NOT NULL, IDENTITY Код Статуса Оплаты 2 Booking int FOREIGN KEY, NOT NULL Бронь, к которой относится оплата 3 Date_Payment date NOT NULL Дата оплаты 4 Amount decimal(10,2) NOT NULL Сумма оплаты Приложение состоит из нескольких форм: окно входа, главное окно со списком клиентов (MainForm), окно туров (ToursForm), окно бронирований (BookingsForm) и форма оформления и правки (AddBookingForm). Переходы выполняются кнопками, «Назад» возвращает на предыдущий экран. Чтобы найти базу, в коде указана строка подключения, которая представлена на рисунке 4. Рисунок 4 – Строка подключения к базе данных После входа открывается главное окно, и выбирается роль. Рисунок 5– Разграничение прав в конструкторе главной формы Когда главное окно открывается из таблицы Clinets, все линии зачитываются и для каждой карточки создается, которая добавляется к панели. Когда имеется много записей, появляется скручивающая полоса. Рисунок 6- Окно клиента В окне «Туры» отображаются страна, город, отель, даты поездки и цена, а также предусмотрен фильтр по стране. Окно «Бронирования» собирает данные сразу из трех таблиц: дата и статус берутся из Bookings, страна и отель — из Tours, а ФИО клиента — из Clients. Сверху размещены строка поиска, , фильтр по статусу. Рисунок 7- Окно Бронирования Основной формой является AddBookingForm. Она поддерживает два режима работы: создание новой брони и редактирование уже существующей. Выбор тура выполняется через «живой» поиск: как только пользователь вводит очередную букву, сразу отправляется запрос по стране или названию отеля, и подходящие варианты выводятся списком. Каждая строка результата имеет вид «Турция (Rixos Premium) — 50 000 руб.». При нажатии на нее запоминается идентификатор тура, а в соответствующие поля подставляются страна и отель. Чтобы подстановка не запускала поиск заново, обработчик на это время отключается. Сохранение новой записи выполняется командой INSERT. Все значения передаются через параметры — это и безопаснее, и позволяет избежать ошибок при работе с датами. Изменение записи работает по той же схеме, но с командой UPDATE; если нужная запись не найдена, пользователь получает предупреждение. Процесс записи нового бронирования в базу данных показан на рисунке 13. Внешний вид формы представлен на рисунках 14 и 15: на рисунке 14 — форма добавления и изменения брони, на рисунке 15 — поиск тура при ее оформлении. Сохранить бронь без выбранного тура или с незаполненными полями невозможно: вместо системной ошибки пользователь увидит понятное пояснение.

Конфигурация: 1С: УНФ. Версия платформы: 8.5. Количество пользователей: от 8 чел, до 10 чел Задача: Ищем консультанта-методолога по 1С:УНФ 3.0 для запуска управленческого учёта с 01.01.2027. У нас кондитерское производство и продажи через маркетплейсы. Используем «1С:Управление нашей фирмой», текущая версия — 3.0.14.178, есть активные расширения и интеграции. Сейчас данные для управленческого баланса и ОФР собираются из УНФ, отдельных таблиц и кабинетов маркетплейсов. Баланс уравнивается расчётной строкой «Нераспределённая прибыль», независимой сверки с финансовым результатом нет. Цель проекта — начать 2027 год в новой подготовленной базе с проверенными начальными остатками и получать взаимосвязанные баланс, ОФР и отчёт о движении денежных средств. Необходимо выполнить следующие работы. Обследование текущего учёта Изучить производственный процесс, движение запасов, продажи через маркетплейсы, расчёты с контрагентами, сотрудниками, бюджетом и собственниками. Определить состав организаций, входящих в управленческую отчётность, и правила отражения операций между ними. Проверить назначение действующих расширений и интеграций. Определить, какие настройки и доработки потребуются в новой базе. Подготовить план запуска с этапами, сроками, стоимостью и перечнем данных, которые должны предоставить наши сотрудники. Разработка правил управленческого учёта Согласовать структуру управленческого плана счетов и соответствие счетов статьям баланса и ОФР. Определить правила учёта сырья, упаковки, полуфабрикатов, незавершённого производства, готовой продукции и товаров на маркетплейсах. Согласовать состав производственной себестоимости, порядок распределения общепроизводственных затрат и признания управленческих и коммерческих расходов. Определить правила учёта налогов, кредитов, процентов, вложений собственников и распределения прибыли. Разделить статьи движения денег и статьи доходов и расходов. Подготовка новой базы Создать и настроить новую рабочую базу. Сохранить старую базу и резервную копию, согласовать порядок доступа к архиву. Перенести необходимые справочники: организации, контрагентов, договоры, номенклатуру, спецификации, склады и другие используемые данные. Предусмотреть проверку дублей. Настроить план счетов, счета учёта номенклатуры и затрат, производственные документы, права пользователей, необходимые интеграции и отчёты. Подготовка и загрузка начальных остатков Заранее предоставить формы для сбора данных на конец 31.12.2026 — начало 01.01.2027 и инструкции ответственным сотрудникам. Начальные остатки должны охватывать: — деньги в банках и кассах; — сырьё, упаковку, полуфабрикаты, незавершённое производство и готовую продукцию; — товары на складах маркетплейсов, в пути и на возврате; — дебиторскую и кредиторскую задолженность, выданные и полученные авансы; — расчёты с сотрудниками, подотчётными лицами и бюджетом; — основные средства и накопленную амортизацию; — кредиты, займы и начисленные проценты; — собственный капитал. Физические запасы подтвердить инвентаризацией, остальные остатки — выписками, реестрами, актами сверки и другими подходящими источниками. Проверить и загрузить согласованные остатки. Подготовить расшифровку входящего капитала и перечень выявленных расхождений с решениями по ним. Переходящие операции между 2026 и 2027 годами Предусмотреть обработку оплат, возвратов, отчётов маркетплейсов и других документов, относящихся к операциям 2026 года, но поступающих в 2027 году. Исключить повторное признание выручки и расходов при погашении задолженности, перенесённой начальными остатками. Проверка, обучение и сопровождение запуска До начала 2027 года протестировать полный цикл на примерах наших операций: закупка, оплата, производство, передача на МП, продажа, удержания площадки, выплата, возврат и закрытие месяца. Подготовить короткие инструкции: кто, какие документы и в какие сроки оформляет. Составить регламент закрытия месяца и назначить ответственных совместно с нами. Сопроводить работу в январе и первое закрытие января 2027 года. Критерии приёмки проекта: — начальные остатки сверены с согласованными источниками; — запасы и себестоимость прослеживаются по стадиям производства; — расчёты с маркетплейсами и другими контрагентами имеют расшифровки; — баланс и ОФР формируются по единой методике; — изменение нераспределённой прибыли объясняется финансовым результатом, распределением прибыли и подтверждёнными корректировками; — ежемесячной подгонки баланса через прибыль нет; — сотрудники обучены, регламент закрытия передан; — первое закрытие января выполнено, существенные расхождения устранены. В отклике просим указать: — опыт аналогичных внедрений УНФ в производстве и на маркетплейсах; — вашу личную роль в этих проектах; — кто отвечает за методологию учёта и кто выполняет технические работы; — этапы проекта, предварительные сроки и порядок оценки стоимости; — условия сопровождения после запуска.

Протестировать: программное обеспечение. Тестировщик ПО (QA Engineer / Manual QA) Оплата: обсуждается индивидуально О проекте Ищем опытного QA-инженера для тестирования сложной программной системы, включающей несколько взаимосвязанных модулей и пользовательских сценариев. Основная задача — провести комплексное тестирование системы на различных устройствах, операционных системах и в разных браузерах, выявить ошибки и обеспечить стабильность работы продукта. Рассматриваем сотрудничество на условиях аутсорсинга с перспективой регулярного привлечения к проектам. Задачи - Проведение функционального, интеграционного и регрессионного тестирования. - Тестирование веб- и мобильных интерфейсов на различных устройствах (ПК, смартфоны, планшеты). - Проверка корректности работы системы на Android, iOS и в популярных браузерах. - Проверка сложных пользовательских сценариев и взаимодействия различных модулей системы. - Выявление, документирование и воспроизведение ошибок. - Составление тест-кейсов, чек-листов и баг-репортов. - Повторное тестирование после исправления ошибок. - Подготовка отчётов по результатам тестирования. Требования - Коммерческий опыт ручного тестирования ПО от 2 лет. - Опыт тестирования сложных веб-систем и мобильных приложений. - Понимание методологий тестирования и жизненного цикла разработки ПО. - Умение самостоятельно разрабатывать тестовую документацию. - Опыт работы с DevTools, Postman и системами баг-трекинга. - Понимание клиент-серверной архитектуры и принципов работы API. - Возможность проводить тестирование на нескольких реальных устройствах. - Самостоятельность, внимательность к деталям и системный подход к работе. Будет преимуществом: - Опыт тестирования высоконагруженных или многомодульных систем. - Опыт проверки real-time-функциональности, уведомлений, обмена файлами и пользовательских ролей. Условия сотрудничества - Первоначально — комплексное тестирование существующей системы. В дальнейшем — регулярное тестирование обновлений, нового функционала и других проектов. - Долгосрочное сотрудничество при успешном выполнении первых задач. - Оплата по договорённости в зависимости от объёма работ. Ищем специалиста, который сможет самостоятельно организовать процесс тестирования, глубоко разобраться в системе и стать нашим постоянным партнёром по обеспечению качества продукта. ТЗ приложено файлом.

Разработка сервиса внутреннего карпулинга (подвоза сотрудников. Платформа: по рекомендации специалиста. Функционал сайта: Регистрация и вход, создание поездки, запись на поездку, подтверждение поездки, отчетность. Контента нет. Вводные данные Компания планирует автоматизировать процесс организации подвоза сотрудников на работу на личных автомобилях. Нужно создать инструмент, который позволит: • Водителям - заявлять о готовности везти попутчиков. • Пассажирам- записываться («бронировать» места). • Фиксировать факт поездки для бухгалтерии (основание для премии водителям). • Исключить сговор и «приписки» (нужно двойное подтверждение). Пользователи • Водители: сотрудники компании, готовые подвозить коллег на личном авто. • Пассажиры: сотрудники компании, нуждающиеся в подвозе с/ до работы. • Администратор: модерирует маршруты, выгружает отчеты, решает споры и прочее. Основной функционал Регистрация и вход: • Авторизация по корп. почте или номеру телефона. • Разделение ролей: водитель/ пассажир. • Профиль водителя: марка авто, госномер, кол-во доступных мест. Создание поездки: • Выбор маршрута из справочника. • Указание времени выезда. • Указание количества свободных мест. • Статусы: «Места есть», «Мест нет», «Поездка состоялась». Запись на поездку: • Поиск доступных поездок по направлению и времени. • Бронирование места. • Получение контакта водителя (открывается после подтверждения записи). Подтверждение поездки: • Механизм двойного подтверждения после прибытия на место. • Водитель нажимает: «Пассажиры доехали». • Пассажир нажимает: «Я доехал». • Система фиксирует поездку как «подтвержденную» только при совпадении данных от обеих сторон. • Если данные не сошлись- статус «На проверке». Отчетность: • Выгрузка реестра подтвержденных поездок в Excel (дата, водитель, пассажиры, маршрут, статус). • Фильтры по периоду, подразделению, маршруту. • Подсчет итоговой суммы для премирования. ВАЖНО: • Персональные данные не должны быть в общем доступе. Доступ только для участников конкретной поездки. • Интерфейс должен быть максимально простым (крупные кнопки, минимум текста). Что в итоге хотим получить на данном этапе: • стоимость разработки (отдельно бот, отдельно - приложение), • сроки реализации.