Ця помилка є типовою для . Помилка «Конфігурація вузла розподіленої ІБ відповідає очікуваної» є системною. В основному виникає через аварійне завершення роботи під час обміну даними по УРІБ.
Вирішити це можна досить простим способом. Розглянемо його.
Інструкція
1. Зробіть копії баз, над якими виконуватимуться роботи (У конфігураторі «Адміністрування - Вивантажити інформаційну базу»).
2. Запустіть конфігуратор головної вузла РИБ.
3. Збережіть конфігурацію центрального вузла у файлі бази даних («Конфігурація — Зберегти конфігурацію у файл…»)
4. Відкрийте конфігуратор бази підпорядкованого вузла.
Отримайте 267 відеоуроків з 1С безкоштовно:
5. Зніміть конфігурацію підпорядкованого вузла з підтримки (Конфігурація — Підтримка — Установки підтримки — Зняти з підтримки):
6. Завантажте конфігурацію бази даних («Конфігурація — Завантажити конфігурацію з файлу…»).
8. Після реструктуризації необхідно зайти режим підприємства і встановити головний вузол конфигурации. Це можна зробити з допомогою спеціальної обробки — . Обробка працює як у режимі керованого додатка, так і в режимі звичайної програми.
9. В обробці необхідно вибрати головний вузол та натиснути «Виконати»:
10. Готово! Спробуйте запустити обмін, система має коректно виконати обмін.
Для початку наводжу список скорочень, що використовуються мною:
- РІБ – розподілена інформаційна база
- ЦБ - центральна база, кореневий вузол РИБ
- УБ - віддалена база, БД віддаленого вузла РИБ
З власного досвіду можу сказати, що стикався з двома причинами виникнення помилки:
- під час прийому файлу повідомлення в УБ "впала" база, у зв'язку з чим, мабуть, і відбулася розсинхронізація між конф. ЦП та УБ;
- під MSSQL клієнт завантажив копію робочої бази та не вимкнув у копії регл. завдання автообміну, в результаті частина повідомлень у віддалені вузли формувалася з робочої БД, а частина з копії, що й призвело до розсинхронізації конфігурацій
Існує також думка, що до цієї помилки наводить використання механізму динамічного оновлення бази. Тут є сумніви, тому що з одного боку динамічне оновлення ніколи не торкається структури БД, а механізми РІБ таки працюють саме зі структурою БД, а не з прикладною її частиною, проте в РІБ використовується механізм формування цифрового підпису версії конфігурації (у Надалі називатиму її для скорочення хеш), і при зміні прикладної частини хеш природно повинен перерахуватися. Не заперечуватиму цього, ні стверджувати, т.к. якщо і стикався із цією ситуацією, то явних доказів цього не знайшов.
Для виправлення використовую 2 методики, залежно від ситуації.
ПЕРША МЕТОДИКА
Перша (найпоширеніша) неодноразово згадується і в партнерській конференції, і на інших інтернет-ресурсах, пов'язаних з 1С. Застосовується здебільшого, коли попри повідомлення про розбіжних змін, при порівнянні вручну видається, що вони ідентичні.
Послідовність дій:
- вивантажуємо з ЦП cf-файл;
- відв'язуємо УБ від РИБ (метод ВстановитиГоловнийВузол, готову обробку можна знайти у додатку чи інших публікаціях);
- замінюємо конф. УБ на вивантажений у першому кроці cf-файл, для цього користуємося меню "Завантажити конфігурацію з файлу" (а не порівняння-об'єднання!!!);
- відновлюємо ознаку РИБ для УБ.
У більшості випадків цих дій більш ніж достатньо, що відновити обмін, але не завжди...
ДРУГА МЕТОДИКА
Застосовується у разі, якщо перша методика не спрацювала, а вивантажити заново вузол неможливо.
Передісторія: у клієнта налаштовували каскадну РИБ і помилка виникла у першому рівні каскаду (другий рівень увесь цей час працював бездоганно). Розробка конфігурації велася разом з IT-службою клієнта і з виникнення помилки конфігурація ЦБ встигла кілька разів помінятися. Варіант з відкатом змін розглядався навіть у принципі, т.к. втрата частини даних та зупинення роботи кількох підрозділів були абсолютно неприйнятними. Перший варіант виправлення помилки якихось відчутних результатів не дав. У зв'язку із чим довелося шукати інші шляхи вирішення.
Прийшла думка спробувати замінити хеш файлів конфігурацій безпосередньо в XML-файлах обміну. Опис структури файлу обміну з книги Професійна розробкау системі 1С:Підприємство 8" дало слабке уявлення про формування цифрових підписівконфігурацій та змін у них, але визначило напрямок пошуку: значення Digest1 та Digest2. Решта з'ясовував суто емпіричним шляхом (тобто методом спроб і помилок), але закономірність встановити таки вийшло.
Тестові експерименти пройшли вдало. На робочих базах теж все пройшло благополучно.
Отже, послідовність дій:
- виконуємо дії 1 – 4 першої методики;
- вивантажуємо з УБ файл обміну, але з завантажуємо їх у ЦБ;
- вивантажуємо з ЦП файл обміну, але з завантажуємо їх у УБ;
- у файлі обміну з ЦБ замінюємо блок, що містить інформацію про зміни конфігурації та хеш (Digest1 і Digest2), на блок хеш з файлу УБ (приклад див. нижче)
- робимо завантаження файлу з 4-го пункту в УБ;
- обов'язково перезаписуємо файл обміну з УБ (2-й пункт)! цей файл не повинен бути завантажений під час обміну в ЦП!
- для перевірки робимо кілька послідовних обмінів.
Якщо під час обміну використовується стиск даних, або відключаємо стиск, або спочатку розпаковуємо файл, змінюємо, потім запаковуємо назад і відправляємо.
Блок файлу обміну із ЦБ
потрібно замінити на блок файлу обміну з УБ (зверніть увагу Digest1 у файла з УБ завжди дорівнює "000000000000000000000000000000000"!! !)
Перелічені дії необхідно виконувати з граничною обережністю, некоректна послідовність може спричинити повну непрацездатність РИБ. Тому перед цими діями створення резервних копій ОБОВ'ЯЗКОВО!
В іншому можу лише побажати удачі!
Помилки динамічного оновлення (або інші глюки платформи) можуть бути причинами помилок обміну розподілених інформаційних баз:
"Дані приймаються від вузла, для якого зареєстровані зміни конфігурації"
"Конфігурація вузла розподіленої ІБ не відповідає очікуваній"
Як відновити обмін?
Але почнемо не з відновлення, а з можливості провести пробмен "вручну", що буває важливо протягом дня, тому що, як завжди, все має працювати "ще вчора" :) Зробити це можна за допомогою чудових обробок, які я не пам'ятаю.ню де скачав(автори, відгукніться - залишу посилання на ваш ресурс, а з мого, якщо потрібно - видалю). Обробки дають можливість вивантажити тільки зареєстровані зміни даних у базі (за вказаним планом обміну для певного вузла!) в XML без вивантаження змін конфігурації і, якщо об'єкти конфігурації не сильно видозмінилися, тобто дуже великі шанси завантаження цих даних. Обробокті ці можна завантажити за посиланням наприкінці статті.
Щодо відновлення. Є простіші способи, що включають не всі пункти наведеного нижче списку, але вони не завжди допомагають, як, наприклад, було в одному з моїх випадків. Тому наводжу той спосіб, який допоміг мені, він оминає можливі проблеми комплексніше. Далі кроками.
Робити вказані кроки бажано тоді, коли в базі не буде користувачів. Якщо це неможливо, то Вам доведеться "допиляти" метод під себе, а отже потрібно спочатку зрозуміти його логіку.
1. Зробити резервні копії скрізь.
2. Для клієнт-серверів: відключити бази через "адміністрування сервера" і відразу підключити з установкою блокування регламентних завдань (таким чином скинеться кеш сервера). Після цього не забути перекинути в новий каталог журнал реєстрації.
3. На всіх комп'ютерах, що використовуються для відновлення, видалити базу в списку баз стартера 1С і створити заново (очиститься кеш користувача)
4. У конфігураторі (в центральній базі) додати нову константу зберегти зміни конфи.
5. Очистити всі каталоги обміну.
6. Зробити вивантаження у всі філії (поки що тільки вивантаження).
7. Спробувати завантажити отримані дані у всі філії. Звичайно прийняти зміни конфи.
Якщо скрізь все добре, йдемо далі, якщо все погано - думаємо, можливо допоможе вивантаження. cf з центральної бази і її ЗАВАНТАЖЕННЯ у філію (не порівняння-об'єднання). У підлеглому вузлі слід відв'язати базу від РИБ (допоможе в цьому обробка - завантажити нижче). Стаття з цієї теми є на infostart.ru.
8. Скасуємо реєстрацію змін для філій у ЦБ (адже всі зміни ми вже скрізь отримали). Важливо зробити на цьому етапі, щоб зміни, що накопичилися, з різних філій потрапили в інші філії. (Завантажити обробку для відв'язки-прив'язки за посиланням нижче).
9. Робимо завантаження в ЦП і якщо все добре, то робимо завантаження-вивантаження з кожною філією кілька разів для закріплення результату.
10. Все.
Можна включити виконання регламентних завдань клієнт-серверних баз.
Для профілактики проблем, що викликають цю помилку, рекомендується не робити динамічне оновлення (як мінімум кілька разів поспіль - до завантаження змін до філій), а також бажано в налаштуваннях обміну поставити галочку "вивантажувати дані тільки при успішному завантаженні".
Для початку наводжу список скорочень, що використовуються мною:
- РІБ – розподілена інформаційна база
- ЦБ - центральна база, кореневий вузол РИБ
- УБ - віддалена база, БД віддаленого вузла РИБ
З власного досвіду можу сказати, що стикався з двома причинами виникнення помилки:
- під час прийому файлу повідомлення в УБ "впала" база, у зв'язку з чим, мабуть, і відбулася розсинхронізація між конф. ЦП та УБ;
- під MSSQL клієнт завантажив копію робочої бази та не вимкнув у копії регл. завдання автообміну, в результаті частина повідомлень у віддалені вузли формувалася з робочої БД, а частина з копії, що й призвело до розсинхронізації конфігурацій
Існує також думка, що до цієї помилки наводить використання механізму динамічного оновлення бази. Тут є сумніви, тому що з одного боку динамічне оновлення ніколи не торкається структури БД, а механізми РІБ таки працюють саме зі структурою БД, а не з прикладною її частиною, проте в РІБ використовується механізм формування цифрового підпису версії конфігурації (у Надалі називатиму її для скорочення хеш), і при зміні прикладної частини хеш природно повинен перерахуватися. Не заперечуватиму цього, ні стверджувати, т.к. якщо і стикався із цією ситуацією, то явних доказів цього не знайшов.
Для виправлення використовую 2 методики, залежно від ситуації.
ПЕРША МЕТОДИКА
Перша (найпоширеніша) неодноразово згадується і в партнерській конференції, і на інших інтернет-ресурсах, пов'язаних з 1С. Застосовується здебільшого, коли попри повідомлення про розбіжних змін, при порівнянні вручну видається, що вони ідентичні.
Послідовність дій:
- вивантажуємо з ЦП cf-файл;
- відв'язуємо УБ від РИБ (метод ВстановитиГоловнийВузол, готову обробку можна знайти у додатку чи інших публікаціях);
- замінюємо конф. УБ на вивантажений у першому кроці cf-файл, для цього користуємося меню "Завантажити конфігурацію з файлу" (а не порівняння-об'єднання!!!);
- відновлюємо ознаку РИБ для УБ.
У більшості випадків цих дій більш ніж достатньо, що відновити обмін, але не завжди...
ДРУГА МЕТОДИКА
Застосовується у разі, якщо перша методика не спрацювала, а вивантажити заново вузол неможливо.
Передісторія: у клієнта налаштовували каскадну РИБ і помилка виникла у першому рівні каскаду (другий рівень увесь цей час працював бездоганно). Розробка конфігурації велася разом з IT-службою клієнта і з виникнення помилки конфігурація ЦБ встигла кілька разів помінятися. Варіант з відкатом змін розглядався навіть у принципі, т.к. втрата частини даних та зупинення роботи кількох підрозділів були абсолютно неприйнятними. Перший варіант виправлення помилки якихось відчутних результатів не дав. У зв'язку із чим довелося шукати інші шляхи вирішення.
Прийшла думка спробувати замінити хеш файлів конфігурацій безпосередньо в XML-файлах обміну. Опис структури файлу обміну з книги "Професійна розробка в системі 1С:Підприємство 8" дало слабке уявлення про формування цифрових підписів конфігурацій та змін у них, але визначило напрямок пошуку: значення Digest1 та Digest2. Решта з'ясовував суто емпіричним шляхом (тобто методом спроб і помилок), але закономірність встановити таки вийшло.
Тестові експерименти пройшли вдало. На робочих базах теж все пройшло благополучно.
Отже, послідовність дій:
- виконуємо дії 1 – 4 першої методики;
- вивантажуємо з УБ файл обміну, але з завантажуємо їх у ЦБ;
- вивантажуємо з ЦП файл обміну, але з завантажуємо їх у УБ;
- у файлі обміну з ЦБ замінюємо блок, що містить інформацію про зміни конфігурації та хеш (Digest1 і Digest2), на блок хеш з файлу УБ (приклад див. нижче)
- робимо завантаження файлу з 4-го пункту в УБ;
- обов'язково перезаписуємо файл обміну з УБ (2-й пункт)! цей файл не повинен бути завантажений під час обміну в ЦП!
- для перевірки робимо кілька послідовних обмінів.
Якщо під час обміну використовується стиск даних, або відключаємо стиск, або спочатку розпаковуємо файл, змінюємо, потім запаковуємо назад і відправляємо.
Блок файлу обміну із ЦБ
...тут йдуть блоки опису змін конфігурації...
потрібно замінити на блок файлу обміну з УБ (зверніть увагу Digest1 у файлу з УБ завжди дорівнює "000000000000000000000000000000000"!!!)
Перелічені дії необхідно виконувати з граничною обережністю, некоректна послідовність може спричинити повну непрацездатність РИБ. Тому перед цими діями створення резервних копій ОБОВ'ЯЗКОВО!
В іншому можу лише побажати удачі!
Запитання: Помилка оновлення вузла РИБ
Добридень.
Оновив основний вузол Рарус-Роздріб до 2.2.5.27, зробив обмін з парочкою вузлів РИБ - все чудово.
Почав масове оновлення решти вузлів (аналогічних "верхній парочці" (інші магазини з РІБ)) - у клієнтській частині вискакує помилка:
РозсилкаЗвітів.ЗареєструватиДаніДляАктуалізаціїСпискуРегламентнихЗадань"
відкладеного оброблювача оновлення
"РозсилкаЗвітів.АктуалізуватиСписокРегламентнихЗадань"
Виникла помилка:
"(ЗагальнийМодуль.ЗагальногоПризначення.Модуль(3502)): Помилка під час виклику методу контексту (Вміст)
Повернення Метадані.РегістриВідомостей.Містить(Об'єктМетаданих);
по причині:
Невідповідність типів (параметр номер "1").
Може, хто стикався? Пробував вже і платформу оновлювати (до максимальної 8.3.10, і перевіряв на 32-64 комп'ютерах)... не допомогло. Але тестові 2 магазини без проблем оновилися, не можу зрозуміти як так.
Відповідь:() Я так і встановлюю головний вузол. Я трохи про інше писав: після того, як обробкою вузол відв'язуєш, при наступному запуску не відразу починається оновлення конфи, а спочатку 1С відкриває вікно, в якому просить підтвердити, що вузол відв'язується. Після цього оновлюється – після оновлення вузла у списку вже немає.
Насправді, на 2.1, пам'ятаю, що оновлював таким методом, але на 2.2 щось не злетіло. Може, по запарку вже й тикав неправильну послідовність у діях)
ПО САБЖУ:
Розібрався із тим, що є. Виявилося, що недодивився:
"В одному з релізів 2.2 з'явився довідник Розсилки звітів з зумовленим елементом"Особисті дані" - довідник з цим елементом був і на 2.1.
Нюанс такий: косяки з оновленням вузлів спостерігаються на базах, які створювалися з центральної саме на релізі 2.1.9.18. Все, що створювалося на ранніх релізах - оновилося нормально. Це, напевно, і пояснює, чому пара баз у МС теж оновилися успішно, а потім пішли косяки.
Нічого вигадувати зі створенням нового елемента у довіднику та встановленням його як зумовленого не став. Переніс з копії центру на 2.1 через вивантаження XML цей елемент і повторив оновлення на проблемній "базі" - все пройшло.
() Отже користуйся методом, якщо ще знайшов відповідь.
Запитання: Помилка оновлення конфігурації
Роблю оновлення конфігурації Бухгалтерія 2.0.64.14 на 2.0.64.24. платформа 8.2.19
Відразу виникає помилка:
Помилка доступу до файлу... шлях... тимчасовий файл.tmp.
Куди дивитись?
Відповідь:вирішив того разу проблему дочекавшись нового "стабільного" релізу
Питання: Помилка у правах користувача на БСП
Вітаю вас!!! Пишу конфу на базі БСП 2.2, начебто вже і досвід є, і доки вздовж і поперек вивчив, але при першому запуску ІБ вилітає помилка:(ЗагальнийМодуль.КористувачіСлужбовий.Модуль(345)): Авторизація не виконано. Роботу системи буде завершено.
Користувач: Адміністратора не знайдено у довіднику "Користувачі".При спробі додавання користувача до довідника виникла помилка:
Помилка оновлення інформаційної бази.
Не заповнено параметр обмеження доступу:
"Можливі права для налаштування прав об'єктів".Для розробника: можливо, потрібно оновити допоміжні дані,
які впливають працювати програми. Для виконання оновлення можна:
- скористатися зовнішньою обробкою
"Інструменти розробника: Оновлення допоміжних даних",
- або запустити програму з параметром командного рядка 1С:Підприємства 8
"/С ЗапуститиОновленняІнформаційноїБази",
- або збільшити номер версії конфігурації, щоб при черговому запуску
виконалися процедури оновлення даних інформаційної бази."Натисніть, щоб розкрити...
Хотілося б почути відповіді "бувалих", для подальшого активного діалогу, можливо навіть співпраця
Відповідь:
Vdeg сказав(а):
Проблема наважилася?
У мене проблема іншого плану: додаю користувача до БСП 2.2.5.29, а він у мене або має повні права (якщо вручну додати їх), або взагалі ніякі (бачить порожній інтерфейс без єдиного довідниката документа). Тому що в типових ролях БСП взагалі немає жодних галок для доступу до конкретних (моїх) довідників та документів. Як тоді доступ на рівні записів для нового користувача буде відстежуватися???
Натисніть, щоб розкрити...
А звідки БСП має дізнатися, що у вас за довідники та як ви хочете налаштувати їм доступ?
Напевно, самим треба це зробити
Запитання: Відправка НадісланихПовідомлено Віддалений вузол не пройшов перевірку
До минулої п'ятниці наступний код чудово працював.
XdtoПідписчик = ФабрикаXDTO.Створити(ФабрикаXDTO.Тип(";));
xdtoПідписчик.DeviceID = DeviceID;
xdtoПідписчик.SubscriberType = ФабрикаXDTO.Створити(ФабрикаXDTO.Тип(";), "GCM");
Новий Серіалізатор XDTO = Новий Серіалізатор XDTO (Фабрика XDTO);
Передплатник = НовийСеріалізаторXDTO.ПрочитатиXDTO(xdtoПідписчик);
Повідомлення = Новий Повідомлення, що доставляється;
Повідомлення.Отримувачі.Додати(Підписувач);
Повідомлення.Текст = текст;
Повідомлення.ЗвуковеОповещення=ЗвуковеОповіщення.За замовчуванням;
Повідомлення.Наклейка = 1;
ДАНІАуз=ТОКЕН;
Надсилання Надісланих повідомлень. Надіслати (Сповістка, Дані Ауз, Істина);
Тепер помилка Видалений вузол не пройшов перевірку. Зламав усю голову. Ловив звернення сервера - порожнє таке відчуття, що він нікуди не звертається... Перебував на трьох різних машинах з різними осями. вичерпався.. допоможіть...
Відповідь:Вгору
Відповідь:Так, вирішив зробити образ вузла заново. При запуску вузла пише, що потрібно запустити з запустити оновлення інформаційної бази
і зробити образ знову.
Виходить це щось через криве оновлення.
Я спробував запустити з цим ключем і зробити обмін із існуючим вузлом. У вузлі жодних поновлень не запустилося, нічого перезапускати не попросив.
І в результаті в головному вузлі повідомлення знову не було прийнято з тією самою помилкою.
Що можна зробити?
Чи може змінити в головному вузлі фіктивно щось у цукерці і зробити обмін? Або він не всю конфу оновить, а тільки те, що зраджу? Я спробую вузол поки що зробити. Але чекатиму на ваші ідеї
Питання: Розподілена база – помилка при обміні не усувається
Усім добрий час доби!
Ситуація наступна.
При завантаженні обміну з периферійного вузла отримую повідомлення "Конфігурація вузла розподіленої ІБ відповідає очікуваної".
Далі дію за інструкцією.
Вивантажую конфігурацію з центральної бази CF, відв'язую периферійну базу від центрального вузла обробкою, знімаю конфігурацію в периферійній базі з підтримки, завантажую конфігурацію з файлу.
Прив'язую в периферійній основі центральний вузол обробкою.
Зберегти, застосувати.
Вивантажую ще раз обмін із центральної бази.
Завантажую у периферійну. Вивантажую обмін із периферійної бази.
Завантажую до центральної. Знову отримую повідомлення "Конфігурація вузла розподіленої ІБ відповідає очікуваної".
Але це якась реальна маячня - я ж завантажую конфігурацію в центральну базу і в периферійній базі конфігурацію ніхто не змінював.
Як перемогти таку помилку?
Відповідь:нікому і на думку не спало радити настільки очевидні речі після багаторічної лайки на демонічне оновлення:)
Питання: РИБ та оновлення
Всім привіт. Планується використання розподілених ІБ.
конфігурація змінена. Оновлення конфігурації центральної бази виконує програміст. Потім із файлами обміну ці зміни будуть передаватися до периферійних баз.
Питання таке: а як бути із запуском обробників після оновлення конфігурації бази даних і першого входу в режимі користувача?
оновлення основної конфігурації - оновлення конфігурації бази даних - виконання обробників оновлення в режимі користувача
Наприклад, було пропущено багато релізів, необхідно послідовно оновити оновитись на 3 релізи. Проблем із оновленням центральної бази не виникає, а як бути з периферійними? Необхідно також виконувати їх оновлення в 3 етапи (оновити центральну базу першим релізом, оновити РІБ, оновити центральну базу другим релізом, оновити РІБ тощо)?
Дякую всім за допомогу!
Відповідь:() тицьніть носом, не можу знайти код, який виконується під час реєстрації змін об'єкта.
Здається, що й використовувати метод ПріОправкеДаних, то головному вузлі все одно будуть накопичуватися змінені об'єкти для оправки в підлеглий вузол. А це зайві ресурси комп'ютера
Тому хочу, щоб об'єкти в головному вузлі не реєструвалися для відправки вже одразу в момент їхньої зміни (Приписи, наприклад). Де, наприклад, типової Бухгалтерії ред.3 ці об'єкти реєструються для оправки?
Запитання: [ВИРІШЕНО] Помилка звернення до інтернет-підтримки
Шановні експерти, підкажіть, будь ласка!
1С:Підприємство 8.3 (8.3.11.2899)
На сервері 1С крутяться кілька баз різних конфігурацій, у всіх інтернет-підтримка підключена та нормально працює. В т.ч. завантаження курсів валют, банків, перевірка контрагентів, СПАРК тощо.
Налаштування проксі у всіх базах прописано однаково.
Але в базах БП-3 КОРП завжди вилітає помилка:У журналі реєстрації:
Не вдалося отримати тикет аутентифікації у сервісі.
Неможливо завантажити вміст (). (ЗагальнийМодуль.ІнтернетПідтримкаКористувачівКлієнтСервер.Модуль(362)): Помилка під час виклику методу контексту (НадіслатиДля Обробки)
Відповідь = З'єднання. Надіслати Для обробки (HTTP Запит, Параметри Отримання. Ім'я Файлу Відповіді);
по причині:
Помилка роботи з Інтернетом: Віддалений вузол не пройшов перевіркуНатисніть, щоб розкрити...
Пробував і на різних версіяхплатформи (8.3.10..., 8.3.11...), і різних версіях конфігурації (3.0.54.15, 3.0.57.10).
Тестування та виправлення – теж не допомагає.
У чому може бути справа?
Невже БП-КОРП якось по-особливому ходить до інтернету?
Дякую.
Відповідь:
Відповідь від 1С (мені допомогло те, що виділено червоним):При переході було виконано оновлення БСП у складі БП із 2.4.3 на 2.4.4
У списку змін БСП 2.4.4
Підвищена безпека під час встановлення захищеного з'єднання з HTTPS інтернет-сервісами. При виявленні різних проблемз сертифікатом інтернет-сервісу, з яким виконується спроба захищеного з'єднання (сертифікат не є дійсним, застарілим або не є довіреним), з'єднання не буде встановлено.
О 8.3.10 перевірка сертифікатів у windows здійснюється засобами операційної системи." -
Встановіть останні оновлення для вашої ОС, які містять важливі оновлення системних компонент, які відповідають за роботу із сертифікатами.
Прохання також встановити останні оновленнякореневих сертифікатів, що розповсюджуються Microsoft у пакетах, що встановлюються.
Потрібна версія не нижче за IE8.0. Він містить важливі оновлення системних компонентів, які відповідають за роботу з сертифікатами.
Як правило, після встановлення всіх оновлень проблема вирішується.
Перевірте, що якщо в рядку пошуку в інтернет експлорері ввести, посилання відкривається.
Користувач, від імені якого ви працюєте, має доступ до інтернету.
Якщо це файлова база на машині клієнта - перевіряти слід на ній.
Якщо це клієнт-серверна база, то на сервері з-під користувача, під яким запущено сервер 1С.
Перевірити лише браузером IE.
Перевірте, чи відкриті порти 443 та 80
Якщо використовується проксі-сервер, перевірте, чи налаштовані дані в меню Персональні настройки.
Якщо використовується клієнт-серверна версія, то слід налаштувати сервер в такий спосіб, щоб у ньому коректно працювало підключення до Інтернету браузером IE з-під користувача, від імені якого запущено сервер 1С.
Прописав проксі саме в налаштуваннях IE користувача, під яким запущено сервер 1С - все запрацювало.
Запитання: Оновлення бух 3
Доброго дня
Бухгалтерія 3
робив оновлення з 3.0.43.208 на 3.0.43.235
помилки
перша
(ЗагальнийМодуль.ОбмінПовідомленнямиВнутрішній.Модуль(381)): Помилка під час виклику методу контексту (ЦейВузол)
по причині:
Знайдено більше одного запису
друга
Під час виклику обробника оновлення:
"ОбмінПовідомленнямиВнутрішній.ВстановитиКодЦієюКонцевоїТочки()"
Виникла помилка:
"(ЗагальнийМодуль.ОбмінПовідомленнямиВнутрішній.Модуль(381)): Помилка при викликі методу контексту (ЦейВузол)
Повернення ПланиОбміну.ОбмінПовідомленнями.ЦейВузол();
по причині:
Знайдено більше одного запису.Почитав пишуть косяк платформи спробував на різних версіях платформах
пробував взяти чисту конфу останньої версіїі просто тупо повною заміною завантажити
взагалі не допомогло завжди одне й теж. Підкажіть раптом хто стикався?
Відповідь:
вузол з істини на брехню поміняв вище писав думав не вийшло, а потім зайшов подивитися спрацювало
Завантаження...