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

Быстрее всего получить список товаров с общими реквизитами можно так:
1) Заходишь в список товаров
2) Правой клавишей мышки по списку и в контекстном меню "Вывести список"
3) Меню "Файл" > "Сохранить как" и выбрать формат Excel.
Но это без картинок.

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

Далее соединить в Excel первую таблицу со всей доп информацией и таблицу с картинками - это плевое дело для любого, кто пишет в своем резюме "опытный пользователь Ms Office" :)

В модуле объекта документа найдите или создайте процедуру ПередЗаписью и туда пишите установку вашего времени. Получится что-то типа такого:

Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
   // какой-то текст, который был ранее...
   Дата = КонецДня(Дата); // или НачалоДня(Дата)
КонецПроцедуры // ПередЗаписью

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

Какой-то бред написан...

В системе 1С-Предприятие все данные внутри базы (конфигурация и ее версия тут не важны) хранятся в Юникоде (кроме варианта 7.7 - там действительно было в виндузовской кодировке). Сохранение любой информации по-умолчанию происходит в кодировке UTF-8, если явно не указать какую-то другую.

Если нельзя - будут ли проблемы с работой сайта, если оставить таблице cp1251?

Вы написали какой-то сайт на PHP и MySQL (судя по тегам), а теперь хотите от абсолютно незнакомых людей угадать: будут ли у вас проблемы??? Вас самого ничего не смущает в вашем вопросе? :)

Если в таблице ТоварыНаСкладах такого поля нет, то значит нужно делать ЛЕВОЕ СОЕДИНЕНИЕ с таблицей, где эти поля есть. Или не делать... В текущей постановке у такого вопроса не может быть ответа (разве что от экстрасенсов).

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

ВЫБРАТЬ
ТоварыНаСкладахОстатки.Организация,
ТоварыНаСкладахОстатки.Номенклатура,
ТоварыНаСкладахОстатки.Номенклатура.ОсновнойПоставщик,
ТоварыНаСкладахОстатки.ВНаличииОстаток

ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, Организация = &Организация) КАК ТоварыНаСкладахОстатки

То что вы описали и есть стандартное решение.

Мы в часть справочников добавили реквизит "Не используется", а в формах списка/выбора при открытии накладываем отбор, что бы такие элементы не показывать пользователю. Тут же на формах прячем кнопку "Показать скрытые", которая снимает этот отбор для случая работы с архивными данными (к примеру, выбрать в отчет по старому периоду). Но это была УТ10. Возможно, что подобный функционал уже внесли в состав БСП - не рыл в данном направлении, не знаю...

Судя по набору слов, которые вы применили, у вас очень мало опыта в создании решений на PHP и вовсе нет понимания в работе с 1С. Поясню:

1) Вы ссылаете на статью, где есть пример создания XML-файла с помощью инструментов работы с DOM. Можно и так. А можно сделать XSLT-трансформацию вашего представления заказа в тот вид, который вам дали для интеграции с 1С. А можно и вовсе не заморачиваться и писать просто текстовый файл. Все зависит от вашего мастерства в PHP-программировании и контекста выполнения скрипта.
1.1) Насколько я понял Yii2 - это фреймворк для создания интерфейсов, а не набор базовых библиотек. Поэтому искать в нем средства выгрузки заказа в файл бесполезно - он не знает что такое "заказ". Он знает только, что такое грид, который подгружает данные с вашей базы заказов.

2) Дропбокс не имеет никакого отношения к 1С (и никогда не имел). Решения на платформе "1С Предприятие 8" (и некоторые 7.7) умеют получать данные из файлов, из внешних СУБД, запрашивать их по HTTPS или с FTP, сами выставлять к себе доступ и получать данные по REST-сервисам, SOAP или даже по COM-соединению (а если подключать библиотеки, то каналы связи ограничены только фантазией разработчика). В вашем случае вам дали четкое ТЗ на разработку, где есть описанный XML-формат заказа и место, куда файл нужно выгружать (на дропбокс, но точно так же могли потребовать на Яндекс-диск) - к 1С эти данные не имеют прямого отношения, просто так захотели разработчики, с которыми вы контактируете.

Буду благодарен, у кого был опыт и примерный алгоритм скажет как действовать, чтобы не набивать лишний раз шышки, так как не было опыта по интеграции

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

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

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

P.S. Кстати, одна из причин использования непериодических регистров сведения, которые подчинены справочникам (в виде указания ведущим измерением), вместо обычных табличных частей - как раз борьба с блокировками, которые возникают при обычной работе пользователей в базе с формами этих справочников. Их продвигали в эпоху конфигураций 8.0-8.2, но в новых типовых конфигурациях вернулись назад к использованию табличных частей. Пример - контактная информация.

Если хотите помощь, то уточняйте ЧТО КОНКРЕТНО вы не понимаете. Для меня тут вообще все очевидно и на все про все ленивые минуты 2 с тестированием.

Итак:
1) Вы не знаете как вообще создавать документы в дереве метаданных?
2) Вы не знаете как создать форму для вашей "Заявки на транспортировку"?
3) Вы не знаете как на форме разместить элементы формы?
4) Вы не знаете, как вызвать палитру свойств для элемента формы?
5) Вы не знаете, где в палитре свойств блок "События", в котором прописываются обработчики?
6) Вы не знаете как прописать новый обработчик?
7) Вы не знаете как проверить правильность выполненных доработок?

Успешно делал пересылку файлов с помощью бинарного реквизита в теле soap-конверта.
Технология SwA скорее всего поддерживаться не будет, так как развитие сейчас пошло больше в сторону HTTP-сервисов, как более привычных и удобных для веб-разработчиков.

Технически реализовать не сложно. Пишите скрипт по 1) выгрузке файлов из "доработанной базы" и "связанных баз", 2) далее замене файлов общих для всех баз объектов в каталогах выгрузки из "связанных баз", 3) загружайте файлы назад в связанные базы.

Единственное, что вам нужно взять во внимание (кроме отслеживания логической целостности конфигурации) в этой схеме - нельзя делать загрузку файлов в базу, которая подключена к хранилищу. Если вам так сильно нужно вносить изменения именно в хранилище (внешние системы контроля версия типа GIT по какой-то причине не подходят), то вам нужно использовать промежуточные базы и цепочка в скрипте увеличивается: 0) обновиться с хранилища, 1) тот же, 2) тот же, 3) тот же но в промежуточную базу, 4) выгрузка из промежуточной базы единого файла конфигурации CF, 5) захват конфигурации в хранилище, 6) сравнение/объединение базы подключенной к хранилищу с полученным на предыдущем шаге файлом (не уверен, что это можно сделать скриптом - возможно нужно будет явно пощелкать мышкой).

Пофантазируем. Предположим, что тебя не поставили на телефон, а сразу разрешили что-то программировать. Предположим, что тебе дают задачу "у клиента Х не проводится документ, выдает ошибку - нужно исправить". Ты лезешь в код и находишь, что ошибка из-за незаполненного реквизита. Ок, ты с чувством выполненного долга удаляешь непонятную проверку и сдаешь работу. На следующий день прибегает взмыленный начальник: "Ты что натворил? У клиента полетели все отчеты и период не закрывается!!!" - оказывается логика одной из подсистем крутится вокруг того, что тот реквизит ВСЕГДА должен быть заполнен и тебе было нужно не комментировать ошибку, а вывести сообщение пользователю, что он забыл внести важное значение...

В 2004 году, когда меня зеленым новичком взяли в одну контору программистом с нулевыми знаниями программ моей фирмы, языка программирования (FoxPro) и основ экономики/бухгалтерии (включая терминологию), меня тоже изначально посадили на телефон оператором службы поддержки. Классический рабочий день - принимал звонок, бегал в мыле между сотрудников пытаясь узнать решение проблемы, лазил в листинги в попытках разобрать логику кода..., отзванивался клиенту и решал его проблему. В результате за два месяца уже знал всю терминологию, знал особенности всех наших программ и довольно неплохо программировал на FoxPro. При этом я настолько хорошо себя зарекомендовал, что мне полностью доверили проект перевода наших российских бюджетников на новый план счетов (согласно приказа Минфина РФ от 26.08.2004 № 70н). А через год я уже по заказу одной из киевских газет написал с нуля программу для учета распространения тиража печатной продукции.

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

Ну, так используй не один параметр, а три - отдельно день, месяц и год.
А в условии напиши что-то типа такого:

ГДЕ ДЕНЬ(Т.Дата) = &День и МЕСЯЦ(Т.Дата) = &Месяц и ГОД(Т.Дата) = &Год