Пока сижу вояю мини-торговельку типа семерошной 9.Х с минимальным составом документов,
чисто по базовым механизмам пробежаться: константа - справочник - документ - регистр - отчет.
на обычных формах пока.

На что посоветуете пристальное внимание обратить?

выкинь обычные формы, учи только управляемы....

от обычных форм только вред будет тебе.

(1) опередил

(1) Да пока хоть с директивами заморачиваться не прийдется.

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

(3) ты не понимаешь, УФ - это иной мир, от слова совсем....

с 7.7 переучиватся на УФ проще чем с 8.1 ОФ на УФ

(0) проект сделать на УФ аналог ТиС 7.7. возможно бы взлетел, но всякие маркировки, торговое оборудование и др. а также их дальнейшая поддержка. ну нафиг

(6) Это не ради продакшена, просто тренировка.

(0) да и ОФ нужно забыть, как уже писали выше, это путь в никуда

(1) Не проблема, пару дней на ОФ потрачу, потом на УФ переключусь.

(7) для тренировки скачай какие ни будь материалы по УФ (с задачами) и тренируйся

(9) понимаешь, в ОФ и УФ самые обычные вещи делаются по разному.

например попробуй вывести картинку из реквизита "хранилища" на форму для ОФ и УФ, очень простой пример а очень показательный :)

(11) Да, я уже понял по обычному выбору каталога :)

(0) На ОФ долго не засиживайся. Когда в первом приближении ознакомишься, читай вот это: https://infostart.ru/1c/articles/198766/
Тут суть не в формах, а в концепциях построения приложения. ОФ продолжает традиции 7.7 (толстый клиент). УФ - настоящая клиент-серверная разработка под тонкого клиента (параллельная разработка клиентской и серверной части).
Если въедливый и любишь системный подход - читай "профразработку". Лучшая книжка от 1С в части качества написания (ну, что от первой редакции вошло).
Если в SQL шаришь, то проблем с запросами не будет. Если не шаришь - тогда это тема отдельного разговора. Если с запросами уже копенгаген - ищи видеокурсы по СКД.

(13) а что такое SQL?

(14) "Прямые запросы" на семерке писал? Ну там 1С++, rainbow, вот это все?

(15) шо?

Да я прикалываюсь.

гы. фишер купился.

Да хтож тебя знает. Хочешь дельных советов по обучению - озвучивай текущую планку знаний. Не все тут твои фолловеры.

(19) Запишу в планы https://infostart.ru/1c/articles/198766/ спасибо!

(20) Да там на 15 минут. Зато все ударения расставляет по местам. Славься Злой Бобер!

(0) Тяжко будет
C++ и Qt проще выучить чем 1С УФ с клиент-сервером и всеми отказами от синхронности и модальности

Зато как легко после 10 лет на 1с УФ будет перейти на ++... Радуйтесь)

(22) Да, ну. Что там учить в 1с УФ? Как элементы расположить и ключевое слово "объект" добавить при обращении к реквизитам формы ?

(0) вроде как сама 1С позиционирует свой бизнес как на 80% консультации/внедрение и на 20% разработка. Рекомендую вообще не открывать конфигуратор и сконцентрироваться на изучении какой-нибудь типовой.

(24) еще несколько магических заклинаний нужно выучить, типа РеквизитФормыВЗначение()

ну и неплохо бы для начала выкурить БСП, чтобы велосипедостроением не заниматься в дальнейшем

(22) я знаю C++ и Qt и еще много страшных слов.

Канбан конечно же пили

Ну и если с языком скл знаком, то особых сложностей не будет

(27)

самое тяжелое - это осознать, что реквизиты формы и реквизиты объекта это разные сущности и живут по разным правилам. Мне до сих пор тяжело понять каким надо было быть укуренным, что бы разделить контекст данных на клиентский и серверный.... По чему-бы просто не сделать 100% работу на сервере кроме самых элементарных реакторов на клиенте....

второе что лично мне плохо давалось - это то, что таблицы значений не возможно передавать с клиента на сервер и обратно, то есть весь мощнейший механизм сортировок, поиска, сверток таблиц теперь можно делать исключительно на сервере а учитывая, что между двумя серверными методами ТЗ невозможно сохранить кроме как через файл или через хранилище, то считай для форм ТЗ практически не используется теперь и на 50% своей мощи.....

третье - не возможность на клиенте получить значение реквизита через точку.

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

(27) так и я знаю слегка С++ и Qt и хорошо знаю УФ
И могу сказать что первое сильно проще в целом (но оно более системное и низкоуровневое)
А второе проще освоить если уже знакомо например веб-программирование с его разделением на фронт и бэк

(30) >каким надо было быть укуренным, что бы разделить контекст данных на клиентский и серверный.... По чему-бы просто не сделать 100% работу на сервере кроме самых элементарных реакторов на клиент

в курсе что сча веб это по сути js в браузере и сложные сайты они на фронте рисуются, просто голые данные с бэка от сервисов тянут

(32)+ От древнего подхода с формированием целиком страниц на сервере (как было в php и прочих) давно уже отошли в массе
Целиком страницы с сервера только если статика для ускорения, и всякие кэширования в CDN

Все на сервере - это путь фузины

Вообще нормальному прогу, знакомому с ООП восьмерка не должна вызывать трудностей.
Как раз с 7 в этом плане куда сожнее

А если в себе есть опыт то и клиент сервер должен быть очень понятен

*вебе

(35) Там пофиг на ООП, скорее все наоборот процедурное и функциональное

// (30): да создай ты уже на клиенте вот ето:
ОписаниеТипа = Новый ОписаниеТипов("ТаблицаЗначений");
КлиентскаяПолноценнаяТаблицаЗначений = Новый(ОписаниеТипа.Типы()[0]);
// и используй "весь мощнейший механизм сортировок, поиска, сверток" прямо на клиенте...

(30): и этта... "между двумя серверными методами ТЗ невозможно сохранить кроме как через файл или через хранилище" -- а через массив структур - никак?

(40)+: в смысле сворачивать в массив струкрур и возвращать на клиент - а потом с клиента отдавать обратно на сервер и там разворачивать?

ЗЫ: а через хранилище - оно разве не попытается сериализовать? и ТЗ разве сериализуется?
(и вроде на сервере вообще ничего не хранится между вызовами, state-less - не?)

(30) Да ну ведь ерунда же.
Кто работал с чем-то другим кроме клюшек все это прекрасно знает. На том же Swing-е в яве это уже в конце 90-ых были все эти менеджеры компоновок. Паттерну MVC уже за 30 лет.
Единственное "ноу-хау" от 1С это весь код в одном файле держать и разделять этими дурацкими НаСервере, НаКлиенте и т.д. На мой взгляд очень сомнительное ноу-хау, гораздо понятнее если бы модули были это были разные модули, было бы однозначно понятно в каком контексте сейчас находишься и что доступно.

(43) Да мое мнение тоже было бы логичней и меньше путаницы с разными файлами модулей серверным и клиентским

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

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

(45) так мы же не спорим. ТЗ это ошибки молодости. Пора остерегаться и на каждую сртировку иметь регистр сведений с СКД и прочими ЗАГСами.

Я бы после (0) попытался бы разобрать на уровне кода одну тем
У например взаиморасчётов или обеспечение в ут11

(31) Братья я с Вами С++ и Qt. Что там 1С так и не сделали интерактивную проверку по xsd https://github.com/sikuda/schemacheck