Как выбрать облачную 1С и проверить ее на своих задачах

На демонстрации все выглядит убедительно: база открывается, документы проводятся. Но подходит ли облако для ежедневной работы в 1С:УНФ? Мы разбираем, как проверить отчеты, обмены и восстановление базы до переноса рабочего учета — на примере работы магазина в УНФ.

Представьте первый рабочий день после переезда 1С в облако. Вы входите в базу, видите знакомые документы, открываете отчет. Пока все хорошо. Затем нужно загрузить выписку, распечатать счет с дополнительными реквизитами и отправить документ через ЭДО. Именно здесь становится понятно, насколько хорошо подготовлен переход.

Пока это только мысленная репетиция. Ее стоит превратить в план тестирования до переезда: пройти привычный рабочий день в новой среде. Если нужные операции выполняются, их результаты проверены, а условия обслуживания понятны, предложение провайдера уже можно оценивать предметно.

Стоимость подписки при этом никуда не исчезает. Просто сначала нужно разобраться, за какой состав работы вы будете платить.

Задача: определите, какие задачи решают сотрудники, какие процессы зависят от базы 1С, что необходимо сохранить после переезда в облако.

В одном из проектов мы переносили в облако 1С:УНФ интернет-магазина одежды из Екатеринбурга. Четыре сотрудника работали с файловой базой на офисном компьютере. В облаке базу разместили на разделителях — с разделением данных клиентов внутри общей информационной базы. Магазин продавал товары через собственный сайт, Wildberries и Ozon.

По мере роста продаж обмены сильнее нагружали компьютер. Часть операций с Ozon выполнялась вручную, а доработанные обмены требовали проверки после обновлений. Поэтому вместе с переносом базы специалисты пересмотрели часть используемых решений: для Wildberries подключили готовое расширение SynchroWB, для Ozon — загрузку уведомления о выкупе из XLSX-файла в УНФ. Файл сотрудник скачивает из Ozon сам: этот сценарий не означает автоматический обмен всеми данными с площадкой.

Перед запуском команда проверила работу пользователей, обмены с маркетплейсами, банк, ЭДО и фоновые задания.

Этот проект хорошо показывает, почему четырех пользователей недостаточно, чтобы назвать перенос простым. Важнее понять, какие процессы зависят от базы. Для магазина это получение заказов, обновление данных о товарах и отражение продаж в учете. Каждую такую связь нужно учитывать при проверке.

Свою ситуацию удобно описать похожим образом. Где появляются документы? Кто их обрабатывает? Какие данные приходят извне? Где сотрудники все еще переносят информацию вручную? Ответы покажут специалисту, что должно сохраниться после переезда и что имеет смысл пересмотреть.

А название конфигурации, релиз и версия платформы дадут техническую отправную точку. Эти сведения лучше приложить сразу — вместе со списком расширений и нестандартных отчетов.

За словами «1С в облаке» могут стоять разные услуги. В готовом сервисе вы получаете доступ к приложению в среде провайдера. При аренде виртуального или физического сервера нужно отдельно определить состав программ, лицензий и работ по администрированию. Поэтому первый вопрос к предложению — какую среду вы получаете и кто за нее отвечает.

В случае с интернет-магазином одежды речь идет о готовом сервисе и базе на разделителях. Для читателя здесь важны практические последствия: какие расширения разрешены, как обновляется приложение и как можно выгрузить свои данные. Наличие собственного программиста само по себе не означает, что ему будет доступен конфигуратор или изменение основной конфигурации. Эти возможности нужно согласовать для выбранного размещения до теста.

Отдельный вопрос — как сотрудники будут подключаться: через браузер, тонкий клиент или удаленный рабочий стол, если выбранный сервис поддерживает такой доступ. Способ подключения не определяет модель размещения базы. Зато от него зависит проверка печати, электронной подписи и оборудования: тестировать нужно именно будущий рабочий вариант.

На демонстрационной базе легко оценить интерфейс. Для решения о переносе полезнее взять свою повседневную задачу, особенно ту, в которой есть особенности.

Допустим, компания пользуется собственной формой счета. В нее добавлены реквизиты, нужные покупателю, и менеджер отправляет такой документ несколько раз в день. Это условный пример, но хороший кандидат для теста: открыть нужный документ, сформировать форму, проверить поля и вывести ее на используемый принтер.

Если счет выглядит иначе или печать не работает, вопрос обнаружится до переключения рабочего учета. Можно выяснить причину, согласовать настройку и повторить проверку. Намного труднее разбираться с этим в тот момент, когда покупатель уже ждет документ.

То же относится к отчетам. Для магазина на УНФ возьмем отчет «Запасы» и сверим остатки товаров. Сначала зафиксируйте момент, на который создана тестовая копия. Затем сформируйте отчет в обеих средах за один период с одинаковыми отборами по организации, складу и номенклатуре. Сравните количество по позициям, а при учете по характеристикам — еще и по размерам и цветам. Одного совпадения общего итога недостаточно: ошибка может скрываться внутри отдельных строк. Новые документы, введенные в исходную базу после копирования, нужно учитывать отдельно — иначе вы сравниваете разные состояния учета.

У теста должен быть понятный результат. Формулировка «вроде все работает» оставляет слишком много вопросов. «Отчет сформирован за тот же период, настройки совпадают, итоги сверены» позволяет двигаться дальше.

Вернемся к магазину. Обмен для него заканчивается тогда, когда данные оказываются на своем месте и с ними можно продолжить работу. Сообщения о завершении операции для такой проверки мало.

Поэтому на тесте стоит пройти один полный путь документа. Согласовать с техническим специалистом безопасный сценарий, выполнить передачу, найти результат в 1С и сверить значимые поля. Если это заказ, проверить товары и количество. Если банковская операция — сумму и ее отражение в учете. Конкретный набор проверок зависит от конфигурации и используемого обмена.

Заранее договоритесь, какие внешние подключения будут доступны в тестовой копии. Пробная отправка не должна превратиться в настоящий документ у контрагента или повторный заказ в рабочей системе.

Электронную подпись и оборудование тоже лучше проверять в том способе подключения, которым сотрудники собираются пользоваться. Удачная демонстрация с компьютера специалиста еще не отвечает на вопрос, как сотрудник будет работать со своего места.

Есть вопрос, который стоит задать еще до подключения: что произойдет с вашими доработками после следующего обновления?

Сейчас отчет может работать, а его дальнейшее сопровождение пока никому не поручено. Чтобы не получить неопределенность уже после переезда, нужно установить, кто проверяет совместимость, где проходит тестирование и к кому обращаться, если потребуется исправление.

Попросите проверить каждое используемое расширение, внешнюю обработку и печатную форму именно в выбранной среде УНФ. Подключение расширения и изменение основной конфигурации — разные задачи; возможность выполнить одну не подтверждает доступность другой. Зафиксируйте, кто проверяет эти решения перед обновлением и кто исправляет несовместимость.

На этом этапе становится понятнее и стоимость. В предложение должны попасть именно те доступы и работы, которые нужны компании. Иначе сравниваются две разные услуги, хотя в обоих коммерческих предложениях написано «1С в облаке».

Представим еще одну ситуацию: сотрудник ошибся, и нужно вернуться к состоянию базы до изменений. Резервная копия существует. Следующий вопрос — кто и как поможет ею воспользоваться.

Здесь полезно заранее выяснить дату доступной копии, срок хранения, порядок обращения и способ восстановления. Можно ли сначала открыть копию отдельно и проверить ее содержимое? Какие действия выполняет администратор клиента, а какие — поддержка? Есть ли дополнительные платежи?

При обсуждении восстановления важно выбрать момент, к которому нужно вернуться, и понять, какие документы появились позже. Возврат к старому состоянию не сохранит автоматически работу, выполненную после создания копии. До переключения пользователей нужно согласовать, как поступить с этими изменениями.

Заодно обсудите возможность забрать данные при смене сервиса. Для баз на разделителях в инструкции указан формат data_dump.zip. Он содержит выгрузку данных без самой конфигурации; для загрузки нужна точно такая же версия конфигурации, из которой сделали выгрузку. Поэтому одного скачанного архива недостаточно, чтобы считать обратный перенос подготовленным. Нужно проверить загрузку в подходящую среду и отдельно согласовать перенос расширений и других доработок.

Спросить «У вас хорошая поддержка?» легко. Получить из ответа полезную информацию сложнее. Предложите разобрать конкретное обращение: сотрудник не может войти в 1С перед началом рабочего дня. Каким способом связаться? Кто примет заявку? Как узнать, что происходит с ее решением?

Затем задайте другой вопрос: руководителю магазина понадобился новый управленческий отчет в УНФ. Это уже другая задача, и условия ее выполнения могут отличаться.

Зафиксируйте, какие обращения входят в обслуживание, когда доступны специалисты и как оплачиваются дополнительные работы. Режим приема заявок сам по себе не описывает сроки решения каждой задачи.

Если обсуждаете SLA — соглашение об уровне обслуживания, — разберите его на таком же примере. Когда начнется работа над обращением? Какие сроки зафиксированы и к чему именно они относятся? Ответы помогут понять, как будет устроено обслуживание после подключения.

Если провайдер предоставляет тестовый доступ, согласуйте его длительность, ограничения и возможность проверить свои сценарии. До начала теста выберите несколько задач и договоритесь, кто проверяет каждую из них. Не обязательно тестировать все возможности программы. Важнее пройти операции, без которых ваш рабочий день остановится.

Результат удобно собрать в короткую таблицу. Ниже — пример ее структуры, а не отчет о проведенном внедрении.

Теперь можно вернуться к цене. Попросите расчет для выбранной конфигурации, числа пользователей, нужных доступов и дополнительных сервисов. Если для проверенной задачи требуется отдельная работа, она тоже должна быть учтена.

Если сначала у вас было лишь общее желание перенести 1С в облако, то после такого подробного разбора у вас появится конкретное основание для принятия решения. Вы сверили отчеты, проверили обмен данными и условия сопровождения, получили ответы на свои вопросы. Если какие-то моменты остались нерешенными, вы точно знаете, кто за них отвечает и какой ваш следующий шаг. 

С таким списком можно возвращаться к разговору о переносе рабочей базы.

Реклама: ООО «ЭР Софт», ИНН 7716509296, erid: 2W5zFJbb3S1