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