Comments 75
Где 8.3.11?

А почему интересует именно 8.3.11? Извините, что вопросом на вопрос.

Почему нет скринов конфигуратора, а только EDT?

EDT мне больше нравится.
Потому что ждали релиз, а вышла тестовая и не в срок :(
И EDT — всего лишь бэта
Так тестовая 8.3.11 тестовая еще ж не выходила. Как же релиз без тестовой? ;)
> А почему интересует именно 8.3.11?
Меня тоже это интересует. В ней обещали починить баги клиента под Mac, приводящие к падению клиента. Пользователи Mac ждут 8.3.11 как второго пришествия.
Им некогда заниматься тем, что ждут пользователи, они чатики делают…
UFO landed and left these words here
У нас 2505 в продакшене стоит, люди работают, под виндой проблем с платформой нет. У 1с есть баг-трекер, если есть какая-то существенная проблема, я бы предложил провести диагностику и зарегистрировать ее там, вдруг, с этим столкнется кто-то еще.
UFO landed and left these words here
Эти топорные графики не стыдно выставлять на Хабр? Тут ведь не инфостарт, народ знаком с JS и canvas :)
Хотя и на инфостарте есть пару графиков на JS, но они не имеют к СКД никакого отношения…
Поддержу. Система компоновки данных — очень мощный механизм и пара круговых диаграмм вообще не раскрывает тему сисек ни одной из прелестей.
я хорошо знаком с СКД, вопрос был на тему дизайна, есть ли они, дизайнеры, вообще в 1С?
Как считаете — как именно эффектней было бы раскрыть прелести СКД?
Описать как создать достаточно сложный отчет без написания кода вручную.
А потом написать как «обрезать пользователю» все лишнее, чтобы он не испортил этот отчет настройками. Очень часть пользователю нужен надежный молоток, а с СКД получается некий мультитул. Одно неловкое движение и у пользователя вместо молотка открывается космическая горелка с голосовым управлением.
Точно, сначала дадут инструмент, а потом обижаются на то что пользователь его не умеет готовить и неправильно настраивает.
Петр, в добавок к показанному на мой взгляд стоило бы:
1. Проиллюстрировать примером использования СКД в кач-ве «движка» динамических списков
2. Рассказать про возможность программной работы с СКД и в частности с получением рез-тов ее исполнения в виде тех же таблиц значений. Это позволяет один раз реализовав какую-нибудь аццки сложную логику (пример — расчет среднесписочной численности сотрудников) иметь ее И в виде отчета И в виде данных на входе чего-нибудь еще.
1. Добавьте наконец в вычисляемые поля редактор!
2. 2 таблицы идущие подряд это кошмар, нельзя задать сквозную ширину колонок
3. если 3 строки в ячейке, то и в итоге 3 строчки
4. разбитие по страницам в СКД НЕТ
и еще 1000 «тут должен быть мат» мелочей

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

Кстати, не разу не потребовалось за много лет сделать диаграмму.
Да редактировать к примеру такое в вычисляемых полях image
это просто жесть, реально нужен редактор
В Enterprise Development Tools будет редактор для вычисляемых полей. Точнее, уже есть, просто Enterprise Development Tools пока в статусе Beta.
От этого, к сожалению, не легче. Когда выйдет EDT неизвестно, а мучиться продолжать мы будем еще долго. Плохо то что конфигуратор не хотите поддерживать.
Функциональность конфигуратора будет поддерживаться. Другое дело, что какие-то нововведения (не принципиальные — вроде поля редактора в вычисляемых полях) могут быть реализованы в EDT и не быть реализованы в Конфигураторе.
И это правильно. Конечно не от jetBrains, но хоть нормальная IDE будет. И надо всех силой на нее пересаживать. Иначе некоторые работодатели не будут переход поддерживать.
>нормальная IDE будет

Конфигуратор вполне годная IDE

>надо всех силой на нее пересаживать.

Люди при наличии выбора сами выберут более подходящее им. И не надо силой никого и никуда
Конфигуратор вполне годная IDE

Да ладно, будь еще возможность без проблем плагины писать под него, более умную контекстную подсказку, и прочие плюшки нормальных IDE — можно было бы поспорить. А так… Есть подозрения что умельцы даже в vim или emacs больше возможностей добавить смогут…

Я попробовал EDT, старый добрый конфигуратор удобнее. Может, и привыкну потом. А по теме — основы рассказали. Описывать всё не нужно, концепции вполне достаточно.

Я попробовал EDT, старый добрый конфигуратор удобнее

А в чём тогда преимущества EDT?
Она более удобна если не брать во внимание привычку, более умная, имеет возможность написания плагинов, и в целом имеет больше возможностей по умолчанию, которых в конфигураторе не будет принципиально насколько я понимаю (та же работа с гитом например и т.п.)
Мне, наоборот, с EDT обратно на Конфигуратор пересаживаться не хотелось. А что не понравилось в EDT? Не считая того, что еще не реализовано в бета-версии.
EDT на уровне интерфейса подтормаживает в сравнении с Конфигуратором. Доли секунды, но заметны. Не знаю, то ли дело в нативности Конфигуратора, по сравнению с джавовским EDT, то ли в меньшей его навороченности.

И чисто эстетически Конфигуратор кажется более… элегантным, что ли

ЗЫЖ я понимаю что за EDT будушее и ряд его фишек стоят того, чтобы на него переходить
Релиз — заменит. В принципе на бете у меня получалось полноценно работать. Но: на EDT можно разрабатывать только управляемые приложения.
Про управляемые понятно. Когда я крайний раз смотрел EDT там не было плана счетов, бухгалтерских и расчетных регистров, уже есть?
В бета-версии — насколько помню, еще не было. Ну у меня область работы специфическая.
В релизе, кончено, все перечисленное будет.
Решение понятное, но, кажется, это здорово отодвинет массовый переход на EDT
можно разрабатывать только управляемые приложения

Так как же он заменит, если толстые формы не поддерживаются?
Про поддержку существующего не забываем.
Про ограниченность тонких форм не забываем
ВСЁ существующее продолжает поддерживаться в Конфигураторе.

Большинство типовых решений от 1С (ERP, УТ, КА, БП, ...) — написаны как управляемые приложения. Для новых разработок и рекомендуется DT.
УПП?
на что можно безболезненно перейти с сильно переписанной УПП?
да и к тому же эти технологии исправно и стабильно до сих пор работают, как говорится «работает, не трогай»

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

Например те, кто имеет нормально внедренную УПП с кучей доработок.
Из типовых ЦУП (http://v8.1c.ru/expert/pmc/pmc_overview.htm), например, до сих пор на них.
А еще лучше добавить сюда локальные переменные.
Код сократиться раза в 3.
Частично проблема решается runtime средствами разработки, где есть достаточно удобные редакторы выражений. Тем более обычно сначала схема отлаживается в режиме предприятия и только потом помещается в конфигурацию.
обычно сначала схема отлаживается в режиме предприятия и только потом помещается в конфигурацию


только если нет требываний по оформлению отчета. Просто требования могут сделать формирование отчета в режиме предприятия бессмысленной тратой времени.
СКД очень мощный инструмент. С его помощью можно сделать много вещей, без кодирования. Но … бывает очень сложно сделать то, что нужно.
Это ИМХО за многие годы работы с ней.
бывает очень сложно сделать то, что нужно.

Можете привести пример?
Да вот же erwins22 написал.

А у самого, из недавнего …
Нужен отчет с диаграммами «в строку»: первая справа, вторая слева. Строк много. Для некоторых необходимо рядом размещать таблицу данных, но с расширенным и переменным описанием объектом анализа.

Всё это необходимо сохранить в ECXEL с сохранением редактирования.

В итоге 800 строк интерфейсной логики, и 4200 — расчетной/оформительской. Предупреждаю — код не Ctrl+C, Ctrl+V, а хорошо декомпозирован.

Бывает и так …
Необходимо разработать сложный отчет с двумя десятками показателей и пятком объектов анализа. Рассчитать все это в СДК можно, но управлять потом невозможно. Это выльется в десяток наборов данных, с простынями «ВЫБРАТЬ», и бойницами параметров (о них писал shumkiiv). И попробуй ошибись с объединением наборов!

Или вот ещё …
Расшифровка и макеты. Специально ездил за книгой Хрусталёвой чтобы разобраться вот с этим …

Ну, не заходит оно.

Далее …
Программное управление параметрами отчета, его структурой: скрыть добавить группировку, убрать параметры при отсутствии какой-то группировки … и подобное. Всё это требует наличия какой-то библиотеки, и её использование ПриКомпоновкеРезультата.
Управление структурой отчета – всегда боль. И всячески нужно скрывать возможность порчи настроек пользователем. Об этом тоже писали.

Говорю об этом в противовес мнению «СДК – это супер отчеты без программирования».
Опять, же ИМХО, но СДК плохой механизм.
Насколько я понимаю, СКД одна из 3-х запатентованных технологий 1С (вместе с механизмом поддержки конфигурации и периодических расчетов), поэтому воспроизведение в какой-либо форме будет преследоваться по закону?
PeterG Статья про 1с на Хабре и ни одного комментария про код кириллицей.
Можно считать это победой.
Верным путём идёте.

По моему все претензии к языку обычно идут не от русскости, а от бедности синтаксиса, разве не? Не, конечно бывают отдельные индивидуумы, но по моему их даже на хабре минусили обычно.
Вот что нет await многие недовольны.

для каждого цикл
конеццикла

пофиг
Вы про отсутствие асинхронности? Так она есть, правда реализована очень неудобно, но есть.
Знаю и использую ассинхронность в 1с.
Работает, но сделано платфорниками для платфомиников, но не для программистов 1с, сделано так, что бы не менять язык, просто добавлением большой кучи функций(ассинхронных аналогов) и т д.
А хотелось бы в современном мире чувствовать себя человеком, как например те кто пишет на python
erwins22
но сделано… не для программистов 1с

Тут не поспоришь. Реализация асинхронности действительно отвратительная.
Почему нет? Вот вы же написали :)
Остальным, видимо, есть о чем-то другом поговорить.
Only those users with full accounts are able to leave comments. Log in, please.