1С на судне теряет данные из-за спутникового канала: как это исправить

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

Почему возникает обрыв синхронизации 1С на судне

Сухогруз идёт из Новороссийска в Стамбул, судовой бухгалтер вносит акт бункеровки: топливо залили, накладную нужно провести в базе и отправить в береговой офис до конца смены. Судовая антенна VSAT на развороте теряет спутник, канал проседает почти до нуля — и как раз в этот момент 1С отправляет пакет на сервер. Сеанс подвисает, документ остаётся в статусе «в обработке», объект базы блокируется — а снять блокировку без доступа к серверу с судна уже нельзя.

Похожая ситуация — на буксирах, баржах, круизных лайнерах и научно-исследовательских судах: везде, где бухгалтерия или учётчик работают удалённо от берега, а связь идёт через VSAT или Iridium, а не через обычный провод. Разница только в частоте обрывов и в том, сколько документов накапливается между сеансами связи.

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

Пока это не исправлено, бизнес теряет конкретные вещи. Отчёт по расходу топлива не уходит на берег до дедлайна, судовой склад показывает одни остатки, а береговой офис — другие, и при следующей бункеровке баланс свести не с чем. Отдельная головная боль — задвоенные УПД от портовых поставщиков: документ завис при отправке, бухгалтер на судне ввёл его заново, а когда связь восстановилась, на берег ушли обе копии.

Как исправить обрыв синхронизации 1С при слабом канале связи

Первый шаг — уйти от постоянного соединения. Судно не должно работать в 1С через интернет в режиме реального времени: локальная база стоит на судовом компьютере и работает автономно, а с береговым офисом обменивается только пакетами изменений — распределённая информационная база (РИБ) или обмен через сообщения. Связь нужна не круглосуточно, а на несколько минут, когда канал есть: при заходе в порт или в окне устойчивого сигнала.

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

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

Что делать, если ошибка обрыва соединения повторяется каждый рейс

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

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

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

Решение — регламент, а не героизм отдельного сотрудника. Обновление 1С на судовых и береговых базах должно идти синхронно, по графику, привязанному к заходам в порт — это отдельная задача обновления 1С, которую нельзя пускать на самотёк при удалённой архитектуре. На берегу нужен мониторинг: если судно не выходило на связь дольше оговорённого срока, ответственный получает уведомление, а не узнаёт об этом от капитана постфактум. Когда проблема не поддаётся диагностике силами штатного бухгалтера, дешевле разово привлечь специалиста — сопровождение 1С и работа сисадмина стоит от 3 800 рублей в час, и разбор одного зависшего обмена обычно укладывается в пару часов.

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

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

Отдельный вопрос — защита канала. По спутниковой связи с судна уходят персональные данные экипажа, платёжные документы, иногда данные клиентов, и передавать их незашифрованным каналом рискованно не только технически, но и с точки зрения требований 152-ФЗ о защите персональных данных. Обмен между судном и берегом должен идти через VPN или другой шифрованный канал, а не открытым FTP или почтой с приложенным файлом базы.

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

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

Какую архитектуру 1С выбрать для флота компании

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

Один-два судна с несложным учётом

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

Флот с фрахтом, крюингом и несколькими судами

Когда кроме бункеровки нужно вести фрахт, расчёты с портами и крюинг, типовой функциональности 1С:Управление торговлей может не хватить, и тогда рассматривают 1С:ERP с доработкой под морскую специфику: учёт по рейсам, сверку с судовыми журналами, консолидацию баз с нескольких судов в одну.

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

Отдельно для берегового офиса, куда стекаются бумажные УПД от портовых поставщиков топлива и снабжения, есть смысл автоматизировать ввод: распознавание УПД избавляет бухгалтерию от ручного набора документов и стоит от 3 900 рублей в месяц.

❓ Частые вопросы

Можно ли использовать 1С на судне без постоянного интернета?

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

Сколько стоит перенести базу 1С флота на арендованный сервер?

Аренда сервера под 1С начинается от 1 100 рублей в месяц за пользователя. Точная стоимость зависит от числа судов, объёма базы и того, нужна ли доработка правил обмена под конкретные маршруты и документы флота.

Почему 1С на судне перестаёт синхронизироваться после каждого рейса?

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

Нужен ли VPN для передачи данных 1С по спутниковому каналу?

Да. По спутниковой связи с судна уходят персональные данные экипажа и платёжные документы, и передавать их открытым каналом рискованно с точки зрения требований 152-ФЗ. Обмен между судном и берегом стоит защищать VPN или другим шифрованным соединением.

1С:Управление торговлей хватит для учёта на судах или нужен ERP?

Для одного-двух судов с учётом бункеровки и снабжения обычно хватает 1С:Управление торговлей. Если добавляются фрахт, крюинг и расчёты с несколькими портами, типовой функциональности мало, и разумнее переходить на 1С:ERP с доработкой под специфику флота.