BAF 8.3.23.2301: нужно ли обновлять платформу именно вашей фирме

Что известно о 8.3.23.2301 по состоянию на 11 сентября 2026 года

Платформа и конфигурация — не одно обновление

Упражнение: составьте паспорт каждой информационной базы

Пять вопросов, определяющих реальную потребность

Когда 8.3.23.2301 стоит устанавливать, а когда можно подождать

Безопасный порядок обновления

Контрольные сценарии для бухгалтера

Типичные ошибки, которые стоят времени

Краткая карточка решения для руководителя

Вывод: обновляйте не номер, а управляемый контур

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

Что известно о 8.3.23.2301 по состоянию на 11 сентября 2026 года

В ИТС BAS 2 сентября 2026 года опубликован BAF 8.3.23.2301. В официальном сообщении причиной выпуска названо исправление ошибки установки BAF в macOS 15.4.1 и более новых версиях. По состоянию на 11 сентября в ленте релизов ИТС не было сообщения о более новом выпуске платформы.

Это важная деталь для принятия решения. Если сотрудники устанавливают или переустанавливают BAF на соответствующих версиях macOS, релиз устраняет конкретную проблему и имеет понятную практическую ценность. Если фирма работает только в Windows или Linux, этот факт сам по себе не создаёт срочной необходимости менять платформу. Основанием могут быть другие факторы: требование нового релиза конфигурации, устранение ошибки, совместимость серверов и клиентов или рекомендация поставщика решения. Их нужно проверять отдельно.

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

Платформа и конфигурация — не одно обновление

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

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

Из этого следуют два правила:

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

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

Что показывает режим совместимости

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

Поэтому запись «платформа 8.3.23.2301» без режима совместимости неполная. Перед обновлением нужно знать оба значения, а изменять режим совместимости как побочный шаг «заодно» не стоит. Такое изменение может повлиять на собственный код, внешние обработки, обмены и расширения и требует отдельного теста.

Упражнение: составьте паспорт каждой информационной базы

Выделите на инвентаризацию 20–30 минут и не начинайте установку, пока таблица не заполнена. Для каждой рабочей и тестовой базы зафиксируйте:

1. Версию BAF. Запишите полный номер из окна сведений о программе. Для клиент-серверной базы отдельно уточните версию серверного кластера.
2. Название и версию конфигурации. Не ограничивайтесь словом «BAS»: нужны точное название решения, редакция и релиз.
3. Режим совместимости. Проверьте свойство основной конфигурации в конфигураторе. Не угадывайте его по номеру платформы.
4. Поддержку и изменения. Отметьте, является ли конфигурация типовой, снята ли она с полной поддержки, какие объекты изменены и кто сопровождает доработки.
5. Расширения. Составьте перечень активных расширений, их версий, назначения и ответственных. Отдельно отметьте те, которые изменяют проводки, права, печать или обмен.
6. Клиенты. Запишите, кто работает через тонкий, толстый или веб-клиент, какие версии BAF установлены на рабочих местах, какие операционные системы используются и есть ли доступ через терминальный сервер.
7. Интеграции. Добавьте внешнюю отчётность, банк, электронный документооборот, торговое оборудование, фоновые задания, обмены между базами и подключённые сервисы.

Удобный результат упражнения — одна строка на базу: «название базы — BAF — конфигурация — режим совместимости — расширения — клиенты — интеграции — ответственный». Если в одной строке указано «неизвестно», решение об обновлении ещё не готово.

Пять вопросов, определяющих реальную потребность

1. Какую проблему должна решить новая платформа?

Сформулируйте ожидаемый результат одним предложением: «нужно установить BAF на Mac с macOS 15.4.1», «новый релиз нашей конфигурации требует эту платформу» или «поставщик подтвердил исправление воспроизводимой ошибки». Формулировка «чтобы была самая новая» не даёт критерия успеха и не оправдывает риск простоя.

2. Есть ли официальное требование именно для вашей конфигурации?

Проверьте описание релиза конфигурации, рекомендуемую или минимальную версию BAF и известные ограничения. Если планируется сначала обновить прикладное решение, а уже затем платформу, убедитесь, что промежуточная комбинация также поддерживается. Не полагайтесь на опыт другой фирмы: одинаковое название BAS не гарантирует одинаковую редакцию и набор доработок.

3. Одинаковы ли сервер и клиентские рабочие места?

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

4. Есть ли нетиповые доработки или расширения?

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

5. Подготовлены ли тест и возврат назад?

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

Когда 8.3.23.2301 стоит устанавливать, а когда можно подождать

Обновлять в ближайшее контролируемое окно целесообразно, если:

• нужно установить или переустановить BAF на macOS 15.4.1 или более новой версии и актуальное официальное исправление касается именно этого сценария;
• ваш текущий или планируемый релиз конфигурации прямо требует соответствующую версию платформы;
• поставщик конфигурации или сопровождения подтвердил, что релиз устраняет вашу воспроизводимую проблему;
• в фирме нужно выровнять поддерживаемые версии сервера и клиентов, а тестовый прогон уже успешен;
• откладывание блокирует работу, поддержку или запланированное обновление прикладного решения.

Не спешить только ради номера разумно, если:

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

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

Безопасный порядок обновления

1. Зафиксируйте исходное состояние. Сохраните паспорт базы, список активных пользователей, версии компонентов и параметры подключения.
2. Прочитайте информацию о релизах. Отдельно — для BAF, конфигурации, расширений и внешних компонентов. Не смешивайте четыре разных источника изменений в одну фразу «обновили BAS».
3. Создайте проверенную резервную копию. Для клиент-серверного варианта соблюдайте принятую в фирме процедуру резервирования СУБД и связанных файлов. Убедитесь, что копию можно восстановить.
4. Повторите базу в тестовом контуре. Тест должен быть достаточно похож на рабочую среду: та же конфигурация, режим совместимости, расширения, права, важные интеграции и типы клиентов.
5. Обновите только запланированный слой. Если проверяете BAF, не изменяйте одновременно конфигурацию, режим совместимости и расширения. Иначе причину сбоя будет трудно определить.
6. Выполните контрольные операции. Откройте справочники, создайте копии типовых документов, проведите их, сформируйте ключевые отчёты, проверьте печать, права, обмены и регламентные задания.
7. Сравните результат. Важны не только отсутствие сообщений об ошибках, но и одинаковые итоги, проводки, остатки, печатные формы и время выполнения привычных операций.
8. Проведите пилот. По возможности предоставьте новую среду одному опытному пользователю до массового перехода.
9. Обновите рабочий контур в согласованное окно. Сообщите пользователям, закройте сеансы, сделайте финальную копию, выполните работы и повторите сокращённый контрольный сценарий.
10. Задокументируйте завершение. Запишите новые версии, время, результаты тестов и известные замечания. Это станет исходным состоянием для следующего решения.

Контрольные сценарии для бухгалтера

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

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

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

Типичные ошибки, которые стоят времени

• Путать номер BAF с номером BAS. Из-за этого ищут новую форму отчёта в обновлении технологической платформы или пытаются исправить установщик релизом конфигурации.
• Обновлять всё одним заходом. Одновременное изменение платформы, конфигурации, режима совместимости и расширений лишает команду возможности быстро найти причину отклонения.
• Проверять только запуск. База открылась, но ошибка может проявиться при проведении, обмене, печати или ночном задании.
• Забыть о клиентах. Сервер обновили, а ноутбук руководителя, терминальная ферма или удалённый бухгалтер остались вне плана.
• Считать резервную копию гарантированным возвратом. Непроверенная копия, неизвестное время восстановления и отсутствие ответственного превращают план в надежду.
• Проводить работы перед отчётным сроком. Даже полезное обновление лучше перенести в окно, когда у команды есть время проверить результат и при необходимости откатиться.

Краткая карточка решения для руководителя

Перед согласованием работ руководителю достаточно получить от ответственного пять чётких ответов:

1. Какая точная версия BAF и конфигурации работает сейчас?
2. Какую конкретную проблему или требование закрывает 8.3.23.2301?
3. Какие базы, клиенты, расширения и интеграции подпадают под изменение?
4. Какие операции уже проверены на копии и кто подтвердил результат?
5. Сколько продлится простой и как команда вернётся к предыдущему состоянию?

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

Вывод: обновляйте не номер, а управляемый контур

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

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