Дмитрий Кинаш

Я не гуру по системному администрированию, но эксперты пишут:

...Таким образом, 32-битное приложение полностью изолируется от системы и других 64-битных приложений.Одним из следствий подобной изоляции является запрет на смешивания 32-битного и 64-битного кода в рамках одного процесса... Наиболее неприятное следствие этого запрета – невозможность использования 32-битных in-process COM объектов 64-битными процессами...

(с) Источник

Вам нужно попробовать что-то другое для печати штрихкодов. К примеру, в этой публикации можно взять компоненту и пример печати под 64х-Линукс (по комментариям - вполне рабочее решение).

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

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

Вы все правильно описали (на счет роли и видимости всеми). Наш саппорт так и работает, но не в ДО, а в специально для них написанной конфигурации.

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

Похоже на глюк платформы. Некоторое время у 1С с HTTPS все было очень печально. В последние годы ни о чем похожем не слышал.

Для начала какова цель данного вопроса?
1) Получить конечное решение вашего тестового задания и какие-то умные мысли, чтобы дополнительно блеснуть на собеседовании?
2) Или получить объяснение по механизмам, которые вам показались сложными/запутанными?

Предупреждаю, что если ответ №1, то данный вопрос и его ответы скорее всего никому кроме вас не интересны и подпадают под причину удаления "Это задание, а не вопрос".

В целом задание очень простое с очевидным решением. Но у меня есть замечания к постановщику и его требованиям к документу. Буквальное следование букве ТЗ приведет к следующей проблемной ситуации. В какой-то момент всех рыбок из конкретного аквариума продали (или временно пересадили, чтобы этот аквариум почистить). Как раз в это время приехал заранее заказанный для этого аквариума корм (документ "Покупка корма" со стоимостью этого корма). Рыбок запустили на следующий день и начали кормить закупленным кормом. В результате стоимость корма была списана, а себестоимость рыбок (не смотря на дороговизну ихней пищи) будет равна ровно стоимости их закупки. Так же есть вероятность, что в другом аквариуме корм закончится, а новый еще не привезли - будут кормить кормом этого аквариума.

Решение зависит от характера процессов и "лени" пользователей. Я бы предпочел создать документ "Кормление рыб", в котором указывал бы вес корма, который насыпали в конкретный аквариум. Известна конкретная добавочная себестоимость рыбок в каждом аквариуме - все четко как в аптеке.

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

Решение упирается в текст запроса. Варианты почему условие медленное:
1) Для условия использованы подзапросы
2) В запросе используются ИЛИ
3) Условия запроса по НЕ индексируемым полям, что требует скан в плане запроса СУБД.

Первый вариант (со сменой текста запроса динамического списка) - это глупости, не делайте так. Смена источника динамического запроса (помимо издержек на эту смену с переинициацией настроек компоновки) приводит к сбросу кеша динамического списка на стороне сервера. В моей практике был такой опыт, но у меня тогда реально разные источники были. Если можете все решить стандартными отборами, то именно так и делайте!

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

Понести и установить своё обновление другу физически можно, но это является нарушением законодательства для вас обоих. https://is1c.ru/about/pc/news/nelegalnoe-obnovleni...

АртемЪ все правильно написал.

Были идеи что веса имеют схожесть с весами графов, а номенклатурная группа выступает как дерево, но тоже говорят вроде это не так.

На это нужно отвечать: "а тогда как?". Мы тут можем разных вариантов набросать, но последнее слово остается все равно за тем, кто для вас кривое непонятное ТЗ написал.

Что не правильно?
1) ПустаяСтрока() - функция для проверки строковой переменной на наличие значимых символов (пробелы, табуляции и прочие разделители игнорируются) - явно не преднозначено для проверки суммы итогового стажа, который будет преобразовываться к строке "0" и функция всегда будет давать результат Ложь. Если итоговый стаж - это не дни итогового стажа, а дата увольнения (с названиями вам еще работать и работать - сами себя путаете), то дата преобразовывается тоже к строковому литералу, который выдаст аналогичную Ложь. Потому содержимое внутри условия никогда не будет выполнено!

2) Обращения вида "Объект." ссылаются на реквизиты вашего документа, а не на реквизиты строк табличной части! Вам нужно сперва узнать значение текущей строки табличной части (под курсором) и дальше работать уже с этой строкой.

3) Что вы там пытались присвоить в двоичном формате непонятно, но явно не в тему.

4) Предположим, что вы своими ноликами-единичками хотели обнулить дату. Тогда согласно вашей формуле вы к пустой дате добавляете сумму количество секунд от даты приема с количества секунд от даты увольнения - это где-то 4036 год получится.

UPD. Дополнено после переписки в комментариях
1) Что должно быть в Итого? По идее количество месяцев! Тип "Строка" тут ни к чему - количество это всегда тип "Число".
2) На поле табличной части вам нужно добавить обработчик события ПриИзменении с примерно следующим содержимым:

&НаКлиенте
Процедура СтажРаботыПриИзменении(Элемент)
	
	РедактируемаяСтрока = Элементы.СтажРаботы.ТекущиеДанные;
	
	// строку могли удалить и в таблице ничего нет
	Если РедактируемаяСтрока = Неопределено Тогда
		Возврат;
	КонецЕсли; 
	
	// обязательно делаем проверку данных!
	Если РедактируемаяСтрока.ДатаПриема >= РедактируемаяСтрока.ДатаУвольнения Тогда
		РедактируемаяСтрока.Итог = 0;
		Возврат;
	КонецЕсли; 
	
	// в зависимости от требуемого значения делаем расчет
	// еще важен способ округления - к меньшему целому или к большему
	ОтработаноСекунд = РедактируемаяСтрока.ДатаУвольнения - РедактируемаяСтрока.ДатаПриема;
	ОтработаноЧасов = ОтработаноСекунд / 60;
	ОтработаноДней = ОтработаноСекунд / 86400;
	
	// если нужно значение месяцев или лет, то используем сдвиги в цикле
	ОкруглятьКБольшему = Истина;  // 1 день сверху дасть дополнительный 1 месяц или 1 год
	
	ОтработаноМесяцев = ?(ОкруглятьКБольшему, 0, -1);
	СкользящийМесяц = РедактируемаяСтрока.ДатаПриема;
	Пока СкользящийМесяц < РедактируемаяСтрока.ДатаУвольнения Цикл
		ОтработаноМесяцев = ОтработаноМесяцев + 1;
		СкользящийМесяц = ДобавитьМесяц(СкользящийМесяц, 1);
	КонецЦикла;
	
	ОтработаноЛет = ?(ОкруглятьКБольшему, 0, -1);
	СкользящийГод = РедактируемаяСтрока.ДатаПриема;
	Пока СкользящийГод < РедактируемаяСтрока.ДатаУвольнения Цикл
		ОтработаноЛет = ОтработаноЛет + 1;
		СкользящийГод = ДобавитьМесяц(СкользящийГод, 12);
	КонецЦикла;
	
	// выводим значение на форму
	РедактируемаяСтрока.Итог = ОтработаноМесяцев;
	
КонецПроцедуры

Но я не умерен в том, что вам нужен реквизит стажа. Возможно было бы достаточно "виртуального реквизита" (добавленого в табличную часть на форме) действительно с типом Строки, куда при открытии и изменении выводить расчетные данные в виде "10 лет, 4 мес, 17 дней".

Очевидно, что это особенности вашего учета. Советую почитать документацию к программе.
Возможно, что на закладке "Оргтехника" предполагается вносить только МБП (лампы, степлеры и пр.), которые в учете не закрепляются за МОЛами. А если у вас МНМА (принтеры, телевизоры и пр.), то посмотрите на другие вкладки.

P.S. В конце-концов, вас же никто не убьет, если вы все ваши ОС будете вводить на закладке Мебели - главное указывать инвентарники, назначать МОЛов и указывать правильные параметры начисления износа :)

И на файловой базе можно сделать веб-сервис!

Для начала нужно собрать требования к обмену - какими данными сейчас будут обмениваться, какими возможно в ближайшем будущем. По результатам нужно описать структуру передаваемых данных в XML или JSON формате.

Теперь можно создавать веб-сервис. Его можно создать в базе управляющей компании и тогда 20 предприятий через этот веб-сервис загружают свои данные (регламентным заданием или какой-то финансист проверяет/корректирует отправляемые данные и явно нажимает кнопку в обработке выгрузки). Или можно веб-сервисы создать во всех 20 базах, а управляющая компания в удобном для себя режиме опрашивает другие базы на предмет новой информации.

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

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

Вопрос очень старый, но он все еще проиндексирован и при этом не имеет ответа. Поэтому включаем режим "экстрасенса" :)

есть xml файл на 2млн. строк, по сути база 1C

Штатно базы 1С не выгружаются в XML. В XML можно выгрузить только конфигурацию или ее элементы. База штатно выгружается в архив *.dt
Следовательно у автора вопроса есть выгрузка либо с помощью обработки "Обмен данными XML", которая позволяет хоть все данные выгрузить в XML-формате для загрузки в идентичную конфигурацию. Либо выгрузка с помощью конфигурации "Конвертация данных 2.0/1", которая выгружает указанные данные в XML-формате, который описан в этой служебной конфигурации.

Нужно как-то перенести её в SQL или что-то подобное.

Вероятно упоминается продукт MsSQL, так как SQL - это язык запросов. Практически все современные СУБД поддерживают импорт данных из файлов XML. Вот дока по MsSQL.

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

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

При описании Команды необходимо свойство "Режим использования параметра" установить в "Множественный". Тогда при выполнении данной команды на вход будет передан не параметр с ссылкой на последний выделенный элемент в списке, а массив со всеми выделенными элементами списка. Особенность - порядок ссылок в массиве соответствует порядку выделения соответствующих строк на форме списка.

Можно использовать процедуры ПриЗаписи на форме и в модуле объекта, но желательно применять подписку на событие ПриЗаписи - в этом варианте можно в едином месте организовать работу с различными документами (иначе нужно изменять типовые формы и далее иметь сложности с обновлениями).

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

Но вот не знаю как обратиться к данным.

Выше была общая стратегия, но судя по комментариям у автора проблема с пониманием азов. Вариантов обращения к данным на платформе 1С:Предприятие ровно два - это объектный (через точку начиная от имеющегося Объекта или Ссылки) и табличный (выборка нужных данных с помощью языка запросов).

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

2) Можете обратится в компанию, которая специализируется на решениях 1С (в франч или что-то похожее).

3) Можете поспрашивать знакомых - "сарафанное радио" иногда приносить хорошие варианты.

Да. Такие тесты есть.
Начните с официальной документации - Проведение нагрузочного тестирования.
Далее самый популярный тест Гилева.
На Инфостарте с десяток вариантов тестирования.
Да и просто гугление дает множество ссылок на альтернативные источники.