Svetas2026 @ Сегодня, 11:57
, переносить все старые документы в новую БД и заново их там перепроводить, чтобы получить требуемые итоги -- так себе идея..
стандартные механизмы перехода в 1С обычно предполагают перенос остатков на заданное число и ведение учета в новой БД с новой точки отсчёта оставьте старую базу 7.7 доступной, запретите изменение документов в ней и пусть будет в роли архива -- какое-то время (пару лет) оно будет актуально, потом переместится в дальний архив и доставаться будет в случае крайне редкой необходимости переход стоит делать на начало периода (год, ну или полугодие -- если сильно не терпится ), чтобы иметь возможность нормально формировать и сдавать отчетность за прошедший период (например, мы в свое время переход бухгалтерии с ПРОФ на КОРП делали в начале года)
andytg @ 08.07.25, 13:07
, upd: на всякий случай (вроде узелка на память ) в такой комбинации не работает присваивание вида
_Соединение = Новый COMObject("V83.Application"); _Соединение .Connect(_СтрокаСоединения); БазаOLE = _Соединение; // ^^^^ здесь ошибки не будет... _Док = БазаOLE.Документы.ЗаказПокупателя.НайтиПоНомеру(_НомерДок, _ДатаДок); // ^^^^ ...но здесь вылетит ошибка, т.к. на тонком клиенте не доступен менеджер документов
но если присваивание не использовать, а вместо этого везде писать, например, так
обращаясь к менеджеру документов толстого клиента, то все работает нормально и всевозможные обращения вида
_Запрос = _Соединение.NewObject("Запрос"); // или _Отбор = _Соединение.NewObject("Структура");
работают нормально, т.е. менеджер объектов из толстого клиента успешно возвращает все, что требуется, в тонкий клиент хотя, скорость, конечно, в разы медленнее, чем при использовании com-коннектора на сервере но требуемый результат успешно достигнут
при этом ровно с этой же конфигурацией, но вызываемой из 7.7, нормально работает такой вариант:
// это 7.7 V8._ЗавершитьРаботуСистемыПриВызовеИз77(); V8 = 0;
при этом в восьмерке, в модуле клиентского приложения
// это модуль клиентского приложения УНФ на 8.3 Процедура _ЗавершитьРаботуСистемыПриВызовеИз77() Экспорт Выполнить("ЗавершитьРаботуСистемы(Ложь)"); // т.к. в 7.7 нет булевых значений КонецПроцедуры
одна и та же база при вызове из 7.7 не задает никаких вопросов и корректно закрывается, а при вызове из 8.3 выводит окно запроса
Profi_1C77 @ Вчера, 18:58
, просто читать все доступные варианты в документах отгрузки и потом при активизации элемента (при начале выбора или при активизации строки) подсовывать этот список в качестве источника и затем выбор только из этого списка
нечто похожее на то, что в 7.7 называлось ИспользоватьСписокЭлементов() в форме списка справочника
Насколько необходимо использовать "V83.Application"? Фактически, происходит запуск полноценного клиента. Я всегда все задачи решал через "V83.COMConnector", он сам закрывает соединение.
я сейчас и использую V83.COMConnector и всегда использовал (ну, кроме 7.7, где его не было, а был только V77.Application) -- он в разы быстрее и удобнее
но мысль такая -- попробовать использовать сервер 1c не на windows, а на линукс, где com-технология не поддерживается -- поэтому возникла мысль перенести обмен с сервера на клиентскую машину, где windows есть и будет в любом случае (точнее, ту часть обмена, которая читает данные из вызываемой базы, потом com-соединение закрываем, считанные данные передаем на сервер и там обрабатываем уже без всяких com-технологий)
за идею про флажок спасибо, как-то упустил из виду
возникла следующая задача: есть несколько баз -- управленческая (старая и очень сильно переделанная под наши нужды УНФ 1.5.4.40 на управляемых формах) и несколько бухгалтерких баз БАС бухгалтерия КОРП, тоже на управляемых, понятное дело, формах, со всеми последними обновлениями (тоже слегка переделанных для корректного взаимодействия с измененной же УНФ, ну да не суть...)
из УНФ идет импорт данных в бухгалтерии через вызов com-объекта на сервере, сервер крутится на windows 2008R2
все это написано давно и работает корректно много лет и вопросов не вызывает (а ранее работало еще в такой связке 7.7 (комплексная) --> 7.7 (бух), потом было 7.7 (комплексная) --> 8.3 (бух) и наконец все пришло к 8.3 (унф) --> 8.3 (бух))
сейчас возникла мысль перенести серверную часть на линукс с выносом этого всего в какой-то ДЦ где-то не в Украине (оно и сейчас в ДЦ, только там недалеко на днях очень сильно прилетело, откуда и возникли мысли убраться отсюда от греха подальше )
так вот, поскольку в линуксе никаких com-объектов нет, решено реорганизовать com-обмен не на сервере, а на клиенте (который все равно на windows, т.к. Fredo и все такое...), с переносом на клиент никаких проблем нет -- вызываем из "тонкого" клиента (бух. КОРП) "толстый" клиент (УНФ), читаем данные в таблицу значений, закрываем com-объект на клиенте, таблицу значений передаем на сервер и там производим создание новых объектов на клиенте вместо v83.ComConneсtor вызываем v83.Application -- и все работает, не так быстро, но приемлемо
однако, возникла проблема -- вызываемый com-объект после отработки не хочет закрываться никак
платформа БАФ 8.3.15.1887 x64
&НаКлиенте Процедура _ИмпортДанныхНаКлиенте()
Попытка _V7 = Новый COMObject("V83.Application"); // _V7 -- это на самом деле v83 Исключение ПоказатьПредупреждение( ,"Ошибка установки соединения"); Возврат; КонецПопытки;
Попытка _V7.Connect(СтрокаСоединения); Исключение ПоказатьПредупреждение( ,"Не удалось подключиться к базе"); Возврат; КонецПопытки;
// дальше читаем данные на клиенте и грузим их в ТЗ, а потом пытаемся закрыть ставщий ненужным com-объект
_V7._ЗавершитьРаботуСистемы(Истина); // вот это не срабатывает, com-объект не закрывается и висит окно подтверждения выхода из программы (как при обычном интерактивном закрытии)
всевозможные варианты с объявлением в модуле прикладной программы (мы ж вызываем толстый клиент) экспортной процедуры
тоже ни к чему не приводят (хотя при точно таком же вызове этой же УНФ из другой БД на старой бухгалтерии 7.7 этот второй вариант нормально отрабатывает)
вопрос -- как в этом случае заставить закрыться com-объект без вывода окна запроса подтверждения закрытия программы?
перепробовал разные варианты -- ни один ни помогает
спасибо
p.s. конвертацию данных не предлагать -- я её не знаю, за 25+ лет работы с 1с никогда с ней не сталкивался и не планирую
Цитата(andytg @ 06.07.25, 2:08)
_V7._ЗавершитьРаботуСистемы(Истина);
прошу прщения, не Истина, а конечно же Ложь в качестве аргумента
600w @ Сегодня, 12:41
, тогда возьмите именно родной БАФ 8.3.19.1529 и делайте все в нем предварительно сохраните старую конфигурацию в нем использование оригинальной 1С, тем более, поздних версий типа 8.3.25, тут совершенно не нужно, т.к. спилка автоматизаторов официально работает на 8.3.19.1529 и все релизы выдает именно в нем
вангую, что дело в режиме совместимости и форматах данных конфигурации
наблюдал похожее на тестовой платформе 8.5.1 -- открываешь конфигурацию, открываешь форму документа -- и конфигуратор сразу показывает, что данные изменены, хотя ничего не менялось после сохранения в 8.5.1 и последующего открытия в 8.3.15 на некоторых документах выдает "ошибку формата потока", пока не очистишь кэш
upd: для УНФ нужна максимальная версия 8.3.17, не более (там в модулях есть)
есть такой документ прием на рабботу и там добавлены 3 поля в таблице НачисленияУдержания
вы в типовую конфу сами добавили три поля в документ, я правильно понимаю?
тогда перед обновлением откройте два конфигуратора -- со старой базой (которую будете обновлять) и новой (откуда будете обновлять), и затем скопируйте добавляемые поля из "старого" конфигуратора в "новый", сохраните изменения в новом, затем выгрузите оттуда .cf и с помощью него обновляйте старую базу
новую базу, из которой будете делать .cf, перед добавлением полей нужно снять с поддержки или включить возможность внесения изменений
Але зараз стикнувся з такою проблемою що налагодження може не працювати на різних платформах.
на портале оригинальной 1с написано, что для версии платформы 8.3.19 подходят мобильные платформы версий 8.3.19.51, .59 и .74, для которых требуется версия платформы не ниже 8.3.19.1150 (т.е. БАС версии .1529 -- подходит) а что там БАС пишет на своем сайте и что там выложено -- то такое (у них про postgres ерунда написана про минимальные и требуемые версии)
если я ничего не путаю, то это зарегистрированная ошибка последнего или предпоследнего релиза
Цитата
Код помилки: 62054 Дата публікації: 6 березня 2025 р. Опис: В документі "Відпустка" некоректно розраховується кількість робочих днів відпустки за наявності документа "Індивідуальний графік".
Profi_1C77 @ Вчера, 22:48
, можете ключ для "склейки" бух. данных с управленческими строить еще в запросе в com-базе и сразу выгружать готовую колонку -- будет еще быстрее, плюс аналогичный ключ в запросе по управленческим данным уже в СКД и в этом же запросе левое соединение с бух.данными -- будет все строиться за один проход в одном запросе, не?
andytg @ Сегодня, 9:41
, и групппировки по номенклатуре с суммами в com-запрос добавьте
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!
), чтобы иметь возможность нормально формировать и сдавать отчетность за прошедший период
Открытая тема (есть новые ответы)
Опрос (есть новые голоса)
Открытая тема (нет новых ответов)
Опрос (нет новых голосов)
Горячая тема (есть новые ответы)
Закрытая тема
Горячая тема (нет новых ответов)
Тема перемещена