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

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

Извините, но ваш вопрос прямо из категории: "Откликнитесь те, кто пишут слева направо. Почему вы не можете отказаться от такой своей привычки? Вот у меня есть друзья арабы и они говорят, что писать справа налево намного удобнее" :)

Просто так спроектированы IDE. Одним создателям показалось, что нумеровать строки хорошая идея, а другие посчитали, что это занимает лишнее место и вывода номера в статусе будет достаточно.

Так же не стоит забывать и о самой специфике программирования на разных языках. Для языков ООП считается дурным тоном, когда листинг кода больше одного экрана (а в каталоге проекта меньше сотни мелких файликов). В то же время для 1С во времена 7.7 был доступен всего один модуль, куда писали ВСЕ, а в последних релизах есть множество общих модулей, но их размеры часто все равно зашкаливают за сотни тысяч строк кода. Т.е. боковая панелька размером на 2 символа вроде не очень мешает, а при ширине 6-7-8 уже как-то не очень, особенно в начале модуля, где большая часть панели не занята абсолютно ни чем. А если учесть, что для 1С практически всегда нужно смотреть на другие дополнительные боковые панельки (дерево метаданных, панель свойств, синтаксис-помощник), то становится понятным идея борьбы за рабочее пространство.

А вы что ожидали увидеть? Все правильно - согласно листингу вы в ваш скрипт не передали ни единой переменной ни методом GET, ни методом POST.

Подсказка. Тело запроса <> передача параметров методом POST. Параметр - это как минимум название, а у вас только содержимое.

Или оформите правильно содержимое в переменной strJSON (если лень читать RFC, то подсмотрите правильную структуру снифером), или берите в вашем скрипте PHP полностью содержимое запроса ($HTTP_RAW_POST_DATA) - это и будет ваш JSON.

В каталоге BIN платформы есть два исполняемых файла: 1cv8c.exe - тонкий клиент и 1cv8s.exe - толстый клиент. В зависимости от того, который из них вы запустите, тот режим и получите.

Настройки в списке баз - предназначены для стартера (1cestart.exe из каталога COMMON), что бы он знал к какому из исполняемых файлов передавать управление. Но список баз для подключения так же доступен для показа и тонкому с толстым клиентам.

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

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

А что мешает заглянуть на официальный сайт?

Интегрировать можно - https://www.1c-bitrix.ua/products/cms/editions/sma... и https://www.1c-bitrix.ua/products/cms/1c/index.php В последней ссылке есть ролик по интеграции.

Модуль для УТ 11.2 - 1c.1c-bitrix.ru/ecommerce/download.php Вместе с модулем идет инструкция по установке и настройке.

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

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

Запрос = Новый Запрос("Выбрать Ссылка Из Справочник.Номенклатура Где не ЭтоГруппа");
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
    Товар = Выборка.Ссылка.ПолучитьОбъект();
    Товар.СтавкаНДС = Перечисления.СтавкиНДС.БезНДС; 
    Товар.Записать();
КонецЦикла;

А что написали Вы?
Вы отбираете свойства номенклатуры (скорее всего они у всех одинаковые = 18%) и далее работаете с массивом идентичной информации. Поскольку в вашей переменной Выборка находится ТаблицаЗначений, то значения поля СтавкаНДС1 вам с легкостью удается переопределить (бессмысленное занятие с учетом того, что после выполнения процедуры эта таблица будет удалена из памяти).
Далее вызываете метод контекста Записать() - который определен внутри модуля объекта и модуля формы элемента для объектов данных. В случае работы внутри формы элемента справочника номенклатуры вам бы удалось записать текущий элемент, но вы скорее всего работаете в обработке и в ее контексте этого метода по-умолчанию нет - поэтому получаете ошибку.

Ошибка синтаксиса языка запроса.
Вам нужно определится с тем, что вы используете. Если работаете с физической таблицей, то источник = РегистрСведений.ЦеныНоменклатуры. Если хотите виртуальную таблицу срезу последних, то даже не обязательно задавать время среза и условие (которое вы запихнули в секцию ГДЕ), но обязательно указать круглые кавычки!

ВЫБРАТЬ
| ЦеныНоменклатурыСрезПоследних.Цена,
| ЦеныНоменклатурыСрезПоследних.Валюта,
| ЦеныНоменклатурыСрезПоследних.ВидЦены,
| ЦеныНоменклатурыСрезПоследних.Номенклатура,
| ЦеныНоменклатурыСрезПоследних.Характеристика
|ИЗ
| РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, ВидЦены В(&ТипЦен) и Номенклатура В(&Номенлатуры)) КАК ЦеныНоменклатурыСрезПоследних"

Я не являюсь сертифицированным экспертом по технологическим вопросам, а так же не проходил никаких курсов типа такого http://Курсы-по-1С.рф/news/2016-10-17-new-optimiza... . Могу говорить только со стороны своего опыта. Оценить и улучшить работу своей системы без внешнего подрядчика вполне реально.

Есть два простых инструмента:
1) для того, что бы понять все ли в порядке с железом - тести Гилева. Это база данных, которая тестирует ЦП, ОЗУ и ПЗУ, а результаты выдает в сравнении с результатами других пользователей на похожем железе. Если у вас данные хуже, то это явный звоночек, что нужно апгрейдить технику или улучшыть настройку СУБД, если у вас серверная база.
2) замер производительности в режиме отладки. Он многое происходящее в системе не показывает (особенно в модели клиент-сервер), но для оценки тонких мест очень даже хорошо себя показал. Это замечательное подспорье для улучшения своих собственных (не типовых) решений.

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

Для поднятия боевого духа могу поделится тремя случаями из практики.

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

2) Когда-то давно я был разработчиком системы для маленького украинского дистрибутора. Через несколько лет это уже была компания национального масштаба с филиалами во всех областях и они пригласили меня для решения проблемы обмена. У них РБД, которой для сбора данных с филиалов теперь требовалась целая ночь. Практически весь мой код остался за эти года не тронутым и я уже знал где оптимизировать - просто раньше это не имело смысла, так как обмены укладывались в час-два. Согласовал с руководителем проекта и просто выбросил из обмена ненужные данные, подняв скорость сразу в 2-3 раза.

3) Разрабатывал систему он-лайн мониторинга. Обработка главного диспетчера собирала данные и выводила целых 15 минут, что было крайне не "оперативно". С помощью замера производительности выяснил, что большая часть времени уходит на общение с СУБД. тогда я переписал алгоритмы на использование таблиц с предварительно подготовленными данными в оперативной памяти - это позволило ускорится с 15 минут до 4-5. Далее тест Гилева подтвердил своими попугаями, что проблемы в железе. Мы использовали виртуальную машину на украинском хостинге. Арендовали за те же деньги у Хецнера в Германии и сразу получили двойной прирост быстродействия всего - монитор стал отрабатывать за 1-2 минуты. Далее немного подкрутили параметры самой виртуальной машины (поэкспериментировали с различными видами виртуального ЦП, попробовали другие режимы эмуляции) и в результате получили дополнительный небольшой прирост, который позволил обновлять монитор меньше чем за минуту.