Выбирайте по тому, где меняется работа сотрудника
Допустим, у вас уже есть 1С и вы заказываете приложение. Покупатель должен видеть товар, оформить заказ и получить подтверждение. Если разделить подрядчиков только по названиям систем, между ними останутся решения: откуда брать доступное количество, кто проверяет заказ и что показывать при ошибке.
Мы предлагаем сначала разобрать одну такую функцию. Затем можно выдать каждой команде её часть задания и назвать человека, который отвечает за весь путь. Ниже есть матрица для товара и заказа, пример договора данных и сценарии общей приёмки. По ним удобно сравнить предложения подрядчиков и увидеть работы, которые пока никто не взял на себя.
- Нужна разработка в 1С, если меняются учётные правила: например, порядок согласования заказа, реквизиты документа или расчёт доступного количества. 1С-разработчик проверяет существующий механизм и определяет, что нужно настроить или доработать.
- Нужна интеграция, если нужные данные и операции уже есть в 1С, а сайт или приложение должны ими пользоваться. Здесь проверяют доступный интерфейс обмена, права и соответствие данных двух систем.
- Нужна совместная разработка, если внешняя функция требует изменений в обеих системах. Например, приложение принимает заказ, а 1С должна проверить его по новым правилам и вернуть результат.
Если сотрудникам достаточно штатного интерфейса 1С, доработка внутри него может закрыть задачу целиком. Отдельный сайт или приложение имеет смысл, когда нужен свой путь для покупателей, партнёров или сотрудников. Разработку этого интерфейса и подготовку 1С стоит оценивать отдельными частями одного проекта.
Как мы связали приложение, админку и 1С в «Бакаеве»
В мобильном магазине «Бакаев» мы предоставили специалиста по 1С, помогли перенести локальную систему в облако и настроили API-интеграцию. Сервер синхронизации связал приложение, админ-панель и учётную систему.
Сотрудник меняет фотографию товара в админке, и она обновляется в 1С. Покупатель оформляет заказ в приложении: остаток уменьшается в админке и 1С. Изменения из 1С доходят до приложения. Команда магазина работает с данными, которые проходят весь этот путь.
Реальный проект 13FOX
Каталог в связанной системе
Админ-панель даёт сотруднику доступ к товарам, изображениям и скидкам.
Для нового проекта мы начинаем с похожего разбора действий: кто меняет карточку, кто принимает заказ, где сотрудник видит результат. Дальше фиксируем правила именно вашей базы и передаём их обеим командам.
Матрица ответственности на товаре и заказе
Ниже предложен пример разделения работ. В нём 1С задаёт учётное наименование, цену и доступное количество, а внешняя админка управляет фотографией. Ваше распределение может быть другим. Его нужно согласовать по каждому полю до разработки. ID в матрице — постоянный идентификатор товара, по которому системы находят одну и ту же карточку.
| Функция | Команда 1С | Команда обмена | Команда интерфейса |
|---|---|---|---|
| Изменение номенклатуры | Определяет ID товара, учётные поля и доступ к ним. | Настраивает сопоставление ID и передачу изменений по согласованному правилу. | Добавляет обновление карточки и сообщение о недоступности данных. |
| Изменение фотографии | Проверяет, как база принимает и хранит изображение. | Настраивает передачу фото с привязкой к товару и фиксацию результата. | Добавляет загрузку фото и показывает сотруднику итог передачи. |
| Создание заказа | Проверяет допустимую операцию, состав заказа и правила учёта. | Настраивает передачу заказа, связь номеров и обработку результата. | Создаёт форму заказа с состояниями отправки, принятия и отказа. |
| Пропал ответ после отправки | Даёт способ проверить, появился ли заказ в базе. | Настраивает сверку перед повтором по согласованному идентификатору. | Добавляет состояние ожидания проверки и доступное действие пользователя. |
Заказчик тоже участвует: ответственный за учёт подтверждает смысл полей и ожидаемый результат. Например, нужно выбрать, какое количество разрешено продавать и что означает статус «принят». Технический координатор собирает решения команд и отвечает за совместный показ результата.
Когда достаточно настройки, а когда нужно расширение 1С
Перед заказом доработки мы проверяем, может ли существующий обмен прочитать нужный товар и выполнить нужную операцию с заказом. Если возможностей хватает, остаются настройка доступа, сопоставление полей и работа на стороне внешней системы.
Платформа 1С поддерживает стандартный интерфейс OData для доступа к данным опубликованного решения. Возможность платформы нужно сопоставить с вашей конфигурацией, разрешёнными объектами, правами и размещением базы. При записи через OData штатная проверка заполнения не вызывается: обязательные поля и правила приёма заказа нужно проверить отдельно. Для 1С:Фреш проверяют условия сервиса и приложения: в его документации OData описаны настройка состава объектов и ограничения.
Когда обмену нужна отдельная операция с собственными проверками, 1С-разработчик может подготовить HTTP-сервис. Это обработчик запроса внутри 1С: он получает данные и возвращает согласованный ответ. Например, проверяет состав заказа и сообщает о принятии либо о конкретной ошибке.
Расширение позволяет добавлять функциональность отдельно от основной конфигурации. 1С описывает и HTTP-сервисы в расширениях. Расширение используют, когда нужная доработка допустима для вашей версии и среды. Совместимость и работу обмена после обновления проверяют на тестовой базе; расширение требует сопровождения.
В оценке попросите указать выбранный способ, изменяемые объекты и порядок проверки обновлений. Если нужно изменить основную конфигурацию, заранее выясните, как это повлияет на её поддержку. Сравнение способов передачи данных разобрано отдельно: CommerceML или API для интеграции с 1С.
Что записать в договоре данных между командами
Договор данных, или контракт обмена, описывает, что системы передают друг другу и как понимают результат. Он нужен обеим командам в одной версии. Например, для изменения товара запишите постоянный ID, изменённое поле, источник значения и способ проверить, что витрина его получила.
Для заказа к этому добавляются состав и количество, единицы измерения, правила цены, внешний номер, ответ 1С и допустимые переходы статуса. Значение «отправлен» сообщает о передаче запроса. Значение «принят в 1С» должно опираться на проверенный результат учётной операции.
Пример правила для пропавшего ответа. Допустим, сервер отправил заказ, а соединение оборвалось. Сначала он проверяет результат по согласованному внешнему номеру. Если заказ найден, связывает его с заказом приложения. Если результат пока неизвестен, сервер возвращает состояние ожидания сверки, а приложение показывает его пользователю. Условия повторной отправки определяют вместе с 1С-разработчиком.
Отдельно запишите, кто может менять каждое поле, что делать с устаревшей правкой и куда попадает ошибка. Например, если цена ведётся в 1С, внешняя админка не должна перезаписывать её своей сохранённой копией. При отказе в приёме заказа менеджеру нужен номер операции, понятная причина и способ передать проблему ответственному.
Способ передачи данных выбирают после этой договорённости. Подробности серверной части есть в материале об интеграции мобильного приложения с 1С. Для разделения работ важнее, чтобы обе команды одинаково понимали поля, операции и статусы.
Как принять одну функцию у двух команд
Мы предлагаем общий показ на тестовой базе: специалист по 1С, разработчик обмена и команда интерфейса проверяют один товар и один заказ. Сотрудник заказчика подтверждает, что результат соответствует его работе. Отдельные демонстрации каждой системы полезны, но общая приёмка должна пройти весь путь данных.
- Изменение товара. Меняем согласованное поле в системе, которая за него отвечает. Сверяем ID, значение и видимую карточку в другой системе.
- Обычный заказ. Оформляем заказ в интерфейсе. Проверяем товарный состав, количество, цену, номер в 1С и статус, который получил пользователь.
- Отказ и недоступность. Передаём недопустимые данные и отдельно отключаем доступ к 1С. Проверяем понятную причину, состояние заказа и инструкцию сотруднику.
- Потеря ответа и повтор. Воспроизводим разрыв после передачи заказа. Сверяем результат в 1С и поведение при повторной попытке по принятому правилу.
- Возврат к работе. Восстанавливаем доступ, проверяем ожидающие операции и итоговые данные. Фиксируем, кто исправляет ошибку и кто подтверждает восстановление.
Результаты удобно хранить в протоколе: исходные данные, действие, ожидаемый результат, фактический результат и ответственный. Тот же набор проверок пригодится после обновления 1С или приложения. Условия отмены, резервирования и продажи последней единицы добавляют, если они входят в функцию проекта.
Одна команда или два подрядчика: как сравнить предложения
Если у вас уже есть 1С-разработчик, он может сохранить ответственность за учёт и подключиться к проекту вместе с веб-командой. Назначьте координатора, согласуйте один контракт данных и включите совместную приёмку в задания обеих сторон. Тогда изменение реквизита в 1С будет иметь понятный порядок согласования с приложением.
Если заказываете комплексную систему у одного подрядчика, попросите назвать исполнителей трёх частей: 1С, сервера и интерфейса. В предложении должны быть границы работ, зависимости от вашей команды и порядок поддержки. Один договор сам по себе не объясняет, кто расследует ошибку между системами.
Смету сравнивайте по составу: обследование текущей базы, настройка или доработка 1С, сервер обмена, экраны, общие проверки, запуск и сопровождение. Например, исправление исходной номенклатуры и разработка корзины относятся к разным работам. Попросите показать, что уже включено и какие условия ещё нужно проверить.
Для команд в Москве, Санкт-Петербурге и других городах при удалённой работе заранее согласуйте доступ к тестовой среде, время совместной проверки и ответственного сотрудника. Эти условия помогают организовать проект независимо от того, сколько подрядчиков участвует.
С чего начать обсуждение своей функции
Для первого разбора достаточно названия и версии конфигурации, способа размещения 1С, описания функции и обезличенного примера. Например: «Нужно отправлять заказ из приложения. Товар находится по артикулу, но единица измерения в 1С отличается. Приём заказа завершается ошибкой». Такой пример помогает определить, где требуется доработка.
- 1С: конфигурация, версия, локальная база, серверное размещение или конкретный облачный сервис.
- Функция: что делает покупатель или сотрудник и какой результат нужен в каждой системе.
- Данные: пример товара или заказа без персональных данных; ожидаемый результат и текст ошибки, если она уже возникает.
- Команды: кто поддерживает 1С и приложение, кто подтверждает учётные правила и принимает работу.
Мы разберём эти вводные и предложим карту ответственности, обмена и совместной приёмки. Состав дальнейших работ можно обсудить на странице интеграции с 1С.
Вопросы перед заказом разработки
Кто делает приложение с 1С?
Приложение, сервер обмена и учётную часть могут делать специалисты одной компании или разные подрядчики. За 1С отвечает специалист, который знает вашу конфигурацию; за экраны и сервер отвечает команда внешнего продукта. Общий контракт данных и совместная приёмка связывают их работу.
Всегда ли нужна доработка конфигурации 1С для сайта?
Сначала проверяют существующие данные, операции и доступный обмен. Если они закрывают функцию сайта, может хватить настройки. Новые правила учёта или недостающая операция требуют отдельной работы на стороне 1С.
Можно ли заказать расширение 1С отдельно от приложения?
Да, если обе команды заранее согласовали назначение расширения, данные, ответы и проверки. До передачи работ нужно определить, кто подключает его к базе, проверяет совместимость и сопровождает после обновлений.
Кто исправляет ошибку между 1С и сайтом?
Назначенный координатор организует проверку по журналу операции и результату в каждой системе. Исполнитель исправления зависит от причины: учётная логика, передача данных или интерфейс. Этот порядок и контакты ответственных фиксируют до запуска.
Разберём, кому поручить каждую часть
Укажите конфигурацию, размещение 1С, функцию и пример ошибки. Разберём распределение работ и предложим карту ответственности, обмена и совместной приёмки.