При найме постоянно спрашивают про знание конфигураций. Но какая разница, какая конфигурация, для программиста?
Я все время стараюсь объяснить, что это не имеет значения)
Кто как работает с такими вопросами?

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

смотря какая ситуация с ПО на предприятии. если самобытность цветет то нах не надо, а если на типовом сидят, то надо

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

(0) ну знать внутреннее устройство конфигурации для программиста нужно? как минимум он тогда на решение задачи может потратить меньше времени, а как максимум - не будет дублировать функционал/код

(4) ну тут я бы лучше спросил про умение пользоваться БСП, БЭД, БПО )

(5) В каких регистрах хранится незавершенка в ERP?

Современные типовые - сильно специфичная штука. Если вакансия не прям вот чистого кодера по тз ни шагу влево/вправо - тогда еще может быть. А так - надо знать или быть готовым сначала разобраться.

(6) Отвечу. Да ваще по-барабану в каких.
Через месяц выходит обновление, меняются регистры/их название и все эти "знания" коту под хвост.

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

(8) Понятно, твой ценник до сотки
При условии, что ты хотя бы неплохой кодер
И да, состав этих регистров уже несколько лет так точно неизменен

(10)[И да, состав этих регистров уже несколько лет так точно неизменен]
твой ценник до 70, в 257 и 2513 "свободные" остатки претерпели 2 революции,а себестоимость расширилась Элементами затрат

(11) Ой, всё
Я про НЗП, а это три регистра, материальные, людские и прочие нераспределенные затраты, не надо мне мозг полоскать
Свободные остатки тут вообще не при чем

(10) И как вот такое комментировать?
Узкий кругозор у тебя в отрасли и соответственно качество оценки.

Вы упоролись в 2023-м году такой вопрос задавать? Что вы сможете толково напрограммировать в ЗУП или в ЕРП, если до этого только с УНФ работали? Знание конфигураций и их специфики может ускорить работу в десятки раз.

(6) Документ КорректировкаРеализации, делая корректировку, не корректирует сумму скидки в регистре "Выручка и себестоимость продаж", а документ "Сторно" делает. Почему?

(15) ты бы ещё Рому про архитектуру курсовых разниц в НУ спросил =)
это же чистый РП, без знания функционала/метаданных

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

(0) 1. Знание что там уже есть, чтобы не писать повторно. Недавний пример: ерп, надо учитывать тмц выданные в командировки, в ремонт и т.п.  можно решить банально, заводим пару категорий эксплутации «в командировке», «в ремонте». И документы Оприходование/Списание тмц в эксплуотации
2. Знание конфигураций вообще это представление о том как надо разрабатывать.

(16)бывает что на вакуху кодера-бетонщика требований как на 2 РП... откуда всё это в головах ХР?!

(0) возможно у конторы нет аналитиков и вместо ТЗ получаешь ХЗ... так вот хотя-бы небольшое знание типовых позволяет полный бред с ходу отфильтровывать

(0) >Но какая разница, какая конфигурация, для программиста?
Разница время
Которое потребуется на изучение особенностей конфы

И в качестве
Когда не начинают свой механизм движений/проводок изобретать вместо типового

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

(15) А вид корректировки какой?

(9) по-моему ЗУПеры вообще отдельная каста ), тут согласен, надо знать)

(14) как, можно пример?

Ну насколько реально вообще постоянно работать с одной и той же конфой?
Сначала задачу дают по УТ, потом по ЕРП, потом по УХ, иногда ЗУП )

два года допиливал свою типовую под клиента, вернулся на другие проекты и знание типовой уже пошатнулось )))

+27 а иногда заходишь на проект, а там типовая уже вдоль и поперек, одно название осталось..

(13) В (7) все правильно сказали, чистые кодеры нужно только кодить строго по ТЗ и цена их до сотки, потому что к ним в комплект нужно еще консультанта брать, который знает типовые

(15) В душе не подозреваю

(16) Ню ню

(0) это спрашивают франчи.

им надо с тебя максимальный выхлоп поиметь.

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

Знание конфигурации с которой предстоит работать может не являться критичным требованием, но плюсом однозначно является. Поэтому вопрос на собеседовании более чем обоснован.
Но опять таки, что такое "знание"? Кто может похвастаться тем, что досконально знает какую-нибудь конфигурацию? Программист мог 5 лет программировать на ERP но не сталкиваться с какой-нибудь подсистемой бюджетирования, международного учёта и т.п.

(27) когда долго с нетиповым работаешь,  то да.. на типовые потом смотришь как на темный лес))

(33) >но не сталкиваться с какой-нибудь подсистемой бюджетирования, международного учёта и т.п.

А когда столкнуться офигеть что там движения по регистрам сделаны не как везде в типовой конфе а через жопу
Явно эту часть (например по ценным бумагам в ERP УХ) откуда то еще затащили

Если знание конфигураций не важно зачем тогда нужны экзамены спеца* по УТ, ЗУП, БП?
*Именно спеца, а не спеца-консультанта.
Оставили бы одного спеца по платформе и все.

(36) много сдающих?

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

(29) Ну это не так, разработчик по ТЗ зарабатывает не меньше программистов со знанием ERP, там есть некоторые другие нюансы. Есть примеры среди коллег, грубо говоря, люди со знанием почти всего стека конф (ERP+ДО+ЗУП+БП+некоторые отраслевки) уходили в чистую разработку, потом все говорили, что приходится прокачиваться именно в части разработки, чего никогда не случилось бы, когда в типовых копаешься и работаешь от обновления до обновления ERP.  И ТЗ - не панацея, иногда аналитики увольняются, не вписывают новые вводные, но проект не должен останавливаться, тогда нужно просто "делать хорошо" как на фиксе, пока новый аналитик разберется.

(0)
Знать надо.

Хотя их столько много ...
Я полностью не зная конфигурацию могу предложить решение лучше, чем тот кто на ней сидит.

Все так относительно ...
Полет фантазии, опыт, умение искать решение и находить информацию.

Большинство гуру конфигураций не умеют читать код.
А я его как книгу читаю.
Ну и кто кого? Все относительно.

Переход с версии 10.ххх на версию 11.001 убьет знатока конфигурации?

Мне пофиг как то. Все равно код читаю. Очень часто.

Если человек заполняет кодом = "в ручную" строку добавляемую в табличную часть "Товары" типового документа,
то что то с ним не так.

Все относительно.

(4) по факту тратишь больше. Ибо вместо того чтобы написать и забыть постоянно после обновления приходиться допиливать решения, так как 1с решила провести рефакторинг кода и обновить библиотеки. Поэтому дублирования помогает напорядок сократить время на поддержку системы зачёт небольшого увеличения времениразработки.

(36) ты хочешь 1с лешить куска масла? Для того чтобы больше собирать денег с тех кто хочет сдать экзамен.

В 1С всё не как у людей. В тру-программировании ценится умение писать понятный, адаптивный код. В программировании на 1С ценится умение по-быстрому прикрутить костыль

(45) Сталкивался я с тру программированием
И там очень часто одни костыли, вся система из них

(46) "сталкивался" и "очень часто" как-то не сильно вяжутся. Говори уж прямо, видел закостыленный проект

(47) Видел не один закостыленный проект
Проектов (реальных, не пет) совсем без костылей не видел

(10) какая ценность этого знания? ты все время туда "руками залезаешь"?

(48)+ Наиболее частый костыль это дублирование данных в таблицах
Изначально кривая (непродуманная, изобретал чел без опыта или совместное творчество без "а подумать") архитектура БД
В итоге чтобы оно побыстрей работало начинают дублировать данные

В 1С есть изначальный плюс что важные данные выносятся из документов в регистры (тоже в некоторой степени дублирование но продуманное)
И отчеты уже по регистрам как и ввод новых доков с проверкой

А вот системах не 1С начинают изобретать костыли, типа промежуточных итоговых документов (специальный вид, хранит итоги за период) в той же таблице
Или добавление накопительных полей в таблицу ))

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

(0) имхо по важности так 1.Знание/понимание концепций учета с вытекающими задачами. 2.Представление, как их реализовать средствами ванильного 1с. 3.Представление, как это реализовано в основных типовых

(26) если во франче сидишь, реально работать с одной конфой, но у разных клиентов.

(49) Да никакой. Чел просто решил повыпендриваться в интернете.

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

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

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

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

Программист 1С, который утверждает что знает типовые - это консультант, а не программист.
Пусть занимается своим делом.

(45) та не

(50) ха ха это бич не 1Сных учетных систем. нет у них итогов, ну нет.

2.Представление, как их реализовать средствами ванильного 1с
крамолу нагоняете, уважаемый?

(57) одинэсник славен тем, что знает и умеет в разных областях - от кодерства в 1с, экселе, МС студии и до процессов бизнеса. в отдельных случаях сам может и контракты заключать.

(12) А какой правильный ответ? Вопрос дискуссионный, спецрегистра сейчас в ERP нет, на стандартных регистрах учитывается, но это несколько другие сущности.

(40) "А я его как книгу читаю.
Ну и кто кого? Все относительно." - Читать мало...надо еще и понимать, что читаешь))

(50) без сомнения таблицы итогов удобная штука...но вы считаете, что этот "паттерн" родился в 1С?

(64) Не считаю.
Но к сожалению ваятели учетных систем "не на 1С" про него не знают.
Ладно еще когда тупо надеются на вьюхи в sql.
Но даже их не делают!

(65) *довольно часто не знают

Еще прикольно когда выносят реквизиты (ИНН, КПП и т.д.) Контрагентов в отдельные таблички, причем по их виду ЮЛ/ИП с разным набором полей
В итоге чтобы тупо найти контрагента по ИНН надо строить головоломные запросы к разным таблицам

А потом делают костыль с записью ИНН,КПП и ОГРН(ОГРНИП) в строковое поле (типа как добавили к наименованию)
И начинают искать по нему через like ))

(67) *ЮЛ/ИП/физлицо/госконтора/перевозчик - вот такая хрень была в одной системе
И тут же прикол что завести перевозчика (субподрядчик фактически) как контрагента (для продажи ему основных услуг) было низзя - ну не подумали

(68)+ Пришлось дублировать записи, отключать проверку на дубли ИНН/КПП и получать разные лулзы в итоге

[пятница]

(0) Если в организации используется конкретная конфигурация, то и программисты нанимаются конкретно под эту конфигурацию.
"Л-Логика"(с).

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

(67) ахаха......но это наверное был "стартап", современно молодежно, еще и монгодб гденибудь сбогу прикручена была)) Но не банковский софт?

PS: "Я все время стараюсь объяснить, что это не имеет значения" - имхо, всё имеет значение. Особенно во время испытательного срока при приеме на работу: Вы просто работу работаете, вариант "пытаетесь объяснить" - не проходит.

(71) угу стартап на питоне с джангой
https://big3.ru/products/asu/

но монги не было все в постгре пихали
еще прикол это новые таблички (для самых массовых сущностей) на каждый месяц (имятаблицы_дата) создавали, ибо без этого все помирало ))

(0) Это вопрос из серии "лучше быть богатым и здоровым, чем бедным и больным": лучше знать все конфигурации наизусть, чем не знать.
На мой взгляд, говорить, что "знать конфигурацию не важно" - не лучшая стратегия, это обесценивает мнение задающего вопрос и, возможно, сразу ставит Вас в оппозицию.
Попробуем провести аналогию: руководитель транспортной компании нанимает дальнобойщика на маршрут Москва-Кемерово. На собеседовании задаёт вопрос: "Вы хорошо знаете эту дорогу?".
Если незнакомый водитель ответит: "Да вообще не важно, какая будет дорога", это может показать его несерьёзный подход. "В смысле, не важно? Вы же повезёте мой ценный груз!"
Зачем задаётся этот вопрос? Наниматель переживает за свои деньги и хочет немного уверенности в том, что всё будет хорошо. Вот и надо его успокоить своим ответом, даже если ты этот маршрут только в картах видел: рассказать, как ездил по аналогичным и уже после двух рейсов знал их наизусть, что есть классный навигатор и ты опытный пользователь постоянно следишь за его обновлениями, что не останавливаешься в подозрительных местах и сразу просишь помощь у напарников, ну и конечно знаешь все правила дорожного движения наизусть.
Некоторые особо тревожные наниматели могут не успокоиться и попросить описать участки дороги Москва-Кемерово, которые ты можешь воспроизвести по памяти во всех подробностях. Особо одарённые наниматели могут начать задавать вопросы, которые лишены вообще всякого смысла в таких случаях: а Вы знаете сколько стоит котьлетька в кафе на 359-м километре ("В каких регистрах хранится незавершенка в ERP")?
Важно, во-первых, отмечать такие вопросы, чтобы понимать адекватность нанимателя и потом сделать правильный выбор, а, во-вторых, иметь заготовки с ответами, которые Вас покажут в лучшем свете: "Это ещё что, я как-то медведя на трассе спас..." (и далее красочная история, как он стал лучшим другом, ездил с тобой несколько рейсов, а сейчас подался на севера).

(45) Ну вот пришел к нам клиент с наследием "тру" программиста. Какая-то программа, работающая напрямую с БД, а что внутрях - ХЗ. Прошлый админ - что-то знает, но поверхностно, текущий вообще не знает нихрена. Только знает, как установить (по инструкции) на новый комп, как создать пользователя (делается всё напрямую через менеджер SQL).
Задача - попытаться посадить это на 1С. Начинаю разбираться, и даже не залазя в "нутри" видно, сколько там костылей, затычек стоит. Функционал который видимо планировался к использованию, а потом обрублен, причем грубо. Десятки полей, которые есть, но их нельзя редактировать, кнопки, которые никуда не идут. Явно видно, что продукт писался "наживую", перекраивался, а даже просто лишние ветки обрубить - было некогда.
Единственная помощь - знание пользователя, который работал в то время, когда программу активно допиливали.

Угу, понятный код, отсутствие костылей. Ага.

(75) ну "помойку" и на 1с сделать и делают без проблем, дело не в технологиях а в исполнителях

(33) Пару раз, в ЗУПе решал поставленную задачу без программирования и без глубокого знания ЗУПа :)
Просто посмотрел в какие регистры нужно сделать движения и нашел документы, которые их делают. Так что знать-то конечно надо, но не досконально...

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

(76) Ну просто "ценится адаптивный и читаемый код" - это вот разбивается просто об реалии мира. Бизнесу не нужен "красивый код", бизнесу нужно решение здесь, сейчас и дешево. Соответственно красивый код летит далеко-далеко. Говнокодить будут даже в дорогих проектах. Легаси будет копиться везде. Костыли были-есть-будут. Анекдот про гигантский вентилятор, воздушный шар и кладовку со швабрами - не про 1С был придуман...

(79) это глупый бизнес так делает. здесь как и везде действует правило Быстро Качественно Дешево - выбрать можно только два, третий исключается аутоматически, как любят "заказчики". умный бизнес это знает.

(79) Красивый код легче поддерживать. Что в итоге не потребует привлекать много сеньеров, а хватит только миддлов.
Но понимать это должен не бизнес а кто-то типа ведущего, техлида, архитектора.
Вот если его нет, то там труба...

(79)[бизнесу нужно решение здесь, сейчас и дешево. Соответственно красивый код летит далеко-далеко] ты сам себе противоречишь, дешево означает низкую стоимость владения, т.е. красивый код

(77) пара-тройка обновлений ЗУПа и смотрим на медный таз. ЗУП упорно уходит в абстрации и делать функционал без механизма представлений и методов програмного интерфеса - сизифов труд.

"абстракции" уже вовсю приходят в УТ, ЕРП и далее по списку.

(83) кстати да - функциональная сложность современных типовых выводит должность "консультант" на первые роли
и программировать в типовых стало сложнее то что хоть как-то зависит от этих самых типовых.
вернее как такового 1С программирования становится мало...
скорее какое-то конфигурирование + консалт

(0) стоит интересоваться какой объем рабочего времени будет затрачен на поддержку\консультирование.
ИМХО сейчас часто путают должности программист и консультант

(84)[как такового 1С программирования становится мало] это теория, на практике кодируется интеграция и отраслевая специфика. Даже ТОИР пилиться свой с нуля

(86) я про типовые, обновляемые типовые

Так не надо во франчи устраиваться...

(88) да кому что. тоже не перевариваю работу в таком ключе - пришел, намутил, победил. чтобы франчеры не оскорблялись - понятно, что бывает поразному. но если франчер работает "системно" с клиентом, то так или иначе его переманят на фикс.

(0) ну фиг знает кто-то тут говорил что в вебе с фреймворками дела не лучше.

Знание конфигурации реально нужно в отделах где более двух прога.
Только в таких отделах есть возможность выделить прога на конкретный участок.

По этому на вопрос про знания типовых стоит спросить про количество пирогов и внутренею организацию...

(91) Человек, который шарит в совремнных типовых, стоит очень дорого. Одно проведение и контроль изменений чего стоит. Джуны это будут делать это полгода. Считайте... Про зуп ваще молчу

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

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

именно по этому я и говорю - все зависит от размера коллектива

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

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

(94) еще бывает когда понимаешь абсурдность требований, высказываешь их заказчику, он затаивает обиду,
потом реализовываешь, даешь потестить, никто это не тестит, и более того этим функционалом в рабочей базе НИКТО и НИКОГДА не пользуется :(
но обида у заказчика остается... вот это в как?

(95) такому кодеру место в обычном франче - в перспективе больше денег принесет и станет уважаемым РП

(97) станет таким же тупым РП, который будет требовать реализовать любой каприз заказчика.
Он же делал все когда был кодером - вот и вы делайте ))

(98) да и такой РП выжмет из недальновидного, глупого заказчика еще больше денег :)
разве не цель бизнеса - получить побольше прибыли...

(99) Так это заканчивается тем, что система идет по бороде, начинается перевнедрение, а текущую компашку выгоняют пинком под зад) И не будет у неё больше прибыли с этой коровы ))

(0) что бы понять какие движения по регистру бухгалтерия делает документ "корректировка поступления" в БП3 нужно нырнуть в модуль документа и все станет понятно. А в ЕРП тебе придётся познать.. Я даже не хочу говорить что.

(101) Познать общий модуль КорректировкаПриобретенияЛокализация всего лишь

Вставлю свои 3 копейки.  У нам где то с середины 00  начался массовый переход бюджетников на 1с.  Вспоминать весело теперь - такое творилось.  Бухгалтера и иногда такое просили )))) +  плюс просили и по делу и функционал был реализован, но почти каждый считал нужным открывать конфигуратор и начинать ваять 2, 3, и т.д. слоем то что уже было реализовано. Сейчас такое вряд ли возможно.

(100) лучше прибыль полученная, чем потенциально возможная... или невозможная...

(96) объяснить человеку, что он дурак....при этом так, что-бы он еще остался тебе благодарен...этот навык стоит больших денег

(10) Интересно где вы видели хороших кодеров, до сотки...
Без знания ЕРП свободно можно получать мин 180

(0) Хороший программист может изучить местную конфигурацию за испытательный срок. Смысла в знании конкретной нет ни какого

(0)Кодер еще сможет работать по отдельным задачам, но полноценно дорабатывать конфигурацию - нет.

А кто-нибудь вообще видел 1С программистов без знаний предметной области для которой они ведут разработку? Какой-то сферический конь в вакууме - то есть я таких не знаю.
Сам факт работы с метаданными автоматически подразумевает хотя бы поверхностное понимание предметки.
Грубо говоря не существует таких программистов 1С, которые не "привязаны" к какой-либо конфигурации.

Досконально нет. Главное уметь применять БСП, т.к. почти все популярные конфигурации написаны на основе БСП.
А вот как понять "знать конфигурацию"? Большинство например кодит в КА, но задачи в основном решают по производству, хотя там есть кадровая подсистема, куда допустим программист никогда не лез

(112)
Ну, например, почему не закрылся 20 счет в бухгалтерии?
Кто то всерьез рассчитывает увидеть причину этого в коде?
Почему документ требование накладная делает проводки 19/19 при включенном раздельном учете НДС?

С одной стороны - в теории все эти вопросы должен решать консультант. Но на практике - как отличить некорректные данные от ошибки программы?
Вот 99 документов Требование накладная - делают проводки 20/10, а 100-й, кроме 20/10 еще делает проводку 19/19 - а ее быть не должно - кто должен решить эту проблему?

(0) Мне иногда из франи дают задания в бухии реализовать то что уже в нем есть. Если бы я не знал что есть или не знал как искать то я бы все реализовывал и изобретал бы велосипеды.
А так иногда тупо пальцем тыкаю чтоб они изучили как это настроить и запустить.
Пример я почему то решил что в БП нет возможности делать рассылку расчетных листов массовые группам сотрудников. Написал обработку успел его продать 3-4 компаниям. Даже выложил на инфостарт. прошло 3 года и мне случайно коллеги ткнули пальцем как это настраивается и запускается.
Правда в ТЗ было чуток другое все-таки доработка нужна была. Но это не важно. Важно что я опозорился (

(114) так можно же то что есть, говорить это я сделал?)))

(115) Я такой херней не занимаюсь. Репутация дороже чем присваивание типовой разработки.
Другое дело нашел на просторах инета разработку и допилил и выдал за свое куда ни шло.

(116) помнишь тот анекдот про фрилансера, который взял 1000 долларов за удар кувалдой?))

(117) Это был ремонтник телевизора. Он брал 10 рублей за удар молотком в ТВ. Где 1 руб за удар а 9 руб знать куда ударить.

(114) я не сказал бы что это возможности данной конфигурации, это из БСП )

(0) Кодеру знать не нужно, ему можно платить 120 и для знания  конфы можно приставить к нему  аналитика за от 200+.
или нанять кодера-аналитика со знанием конфы от 250+.
Кто что ищет и как себя видит и в роле кого и на какие доходы.

(4) Знание конфигурации, не лишает программиста взвешенного переписывания конфигурации в своих интересах, для привязывания конторы к себе родному... или проще сказать - "Подсадить на иглу" :)

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

(0) поделюсь своим небольшим опытом. Работаю в организации, где нет ни аналитиков, ни архитекторов, один я за всех. Сначала очень сложно было ориентироваться в конфигурациях, ведь в организации их аж 6. Приходилось шустро изучать, параллельно выполняя задачи, а это время, а время деньги как говорят. Спустя некоторое время набил руку, теперь полегче. Поэтому, отвечая на ваш вопрос, скажу, что ДА, знание конфигурации необходимо.

(0) Смахивет на то что зачем автомеханику по ходовой части знать какая марка машины он же разберется и починит любое авто. Ведет для каждой машины можно найти описание и схему. ))

(120) А чем плохо наличие аналитика. Даже для программиста за 250+ ?

(125) Программисты за 250+ без аналитика не работают). Аналитик, это не только ТЗ, но и вторая линия ТП)

(126) + 1.
Еще и тестировщики.

(127) ну это в хорошей организации так

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

Ну вот работаешь ты с аналитиками и даже есть первая линия. Все равно приходится с ним нянчится. Аналитики тоже бывают разными зачастую слабые.
Так что знание конфы всегда есть плюс.
Или аналитичские способности 1с это скорее плюс чем минус.

Понимаете, если в организации есть деление на программистов и аналитиков - то ничего объяснять не надо. Они сами всё понимают и интересоваться будут насколько Вы сильны как программист.

Если в организации такого деления нет - то Вы им ничего не докажете. Они решат что Вы им лапшу на уши вешаете. С их точки зрения они ищут программиста - а этот кандидат заявляет что ему нужна дополнительная нянька.

Я в 1С пришёл в 40 лет имея очень хороший опыт программирования "в языках" и был уверен что в 1С мне будет очень легко. Синтаксис - легкотня, язык запросов - легкотня... Да вообще всё легко !

Внезапно что-то пошло не так :-) На самом деле средний бизнес просто не разделял тогда (да и сейчас не очень разделяет) программиста и аналитика. Неправы - они, но плохо то было мне ! :-)

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

(129) а решать проблему "почему не закрылся 20 счет" должен аналитик? Но если это типовая конфигурация, то и код может сбоить. И в итоге уже над решением проблемы будут работать двое, а не один сотрудник.

Так не дешевле и эффективней иметь одного специалиста чуть дороже, чем двоих но дешевле?

(131) Я в 1С пришёл в 40 лет имея очень хороший опыт программирования "в языках" . А с чем связан переход был если не секрет, вроде многие во "взрослые" языки норовят уйти из 1с, а Вы наоборот?

(129) >> "Ну, например, почему не закрылся 20 счет в бухгалтерии?"
>> При чем тут программист?

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

Хотя безусловно, в 99% случаев ответ на такой вопрос кроется именно в ошибках ведения учёта, а не в коде.

(134) Золотые ваши слова, товарищ Прапорщик! Сейчас (по крайней мере, по тем компаниям, которые попадали в поле зрения в последнее время) процветает тенденция замещать консультантов/аналитиков тупыми приемо-передаточными звеньями, которые даже в движения документа не затруднятся зайти, прежде чем переадресовывать кейс программисту. На кой черт они нужны, если все равно слово-в-слово передают то же, что им сказал клиент? В одной компании предложил руководству написать кабинет самообслуживания для обращений клиентов и разогнать их к чертовой бабушке, но поддержки не снискал, видимо кому-то нужно освоить этот ФОТ.

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

(133) В 2007 ситуация была иной. Не в столицах работы "на языках" было совсем не много, удалёнка была не развита а ехать покорять столицы мне было сложно по семейным и личным причинам.

Ну а в 1С море вакансий - практически гарантированная работа, рост ЗП.
Так оно всё и вышло, но большой неожиданностью было то, о чём я писал по поводу знаний типовых.

(125) возникает обычно вопрос, а нахрена такой программист.
Это бизнес, ничего личного.

Сдается мне что тут путают в некоторых применениях аналитика и консультанта...

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

+(139) Яркий пример когда непонимание как работает конфигурация приводит к большим трудозатратам в Расчетный листок в 8 раз увеличивает суммы хотя там делов то было..

(137) Хм. А архитектор-то нужен или как? ))

(130) дааа с такими работать, это как взять часть его работы, да перепроверить, да переделать...
а эти работнички и в ус не дуют :(

(142) + в таком случая я уж лучше сам себе все трое :)

(141) некогда глупостями типа архитектуры заниматься. давай программирувай