john_vlad, 1це потому и конкурентноспособна т.к. специалист среднего уровня (от 5 лет в среднем) в состоянии работать с "приграничными" учетными областями без привлечения узкоспецилизированных специалистов без лишней необходимости

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

а вот когда уже сталкиваешься с проблемой работающей БД получившей "родовую травму", и из того разряда где нормальный франч проведя обследование или предложит переход на что-то человеческое или доработку/переработку существующего за бешенные деньги по сравнению с первым, то приходиться и СКЛ знать и в некоторых случаях что-то кроме этого

саму бухгалтерию "до корочки" может и не надо но принципы ведения бухучета помнить надо как и методику ведения общепринятого оперативного, кадрового

авторему не нужно знать бухгалтерию и уметь программировать

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

автортипа триггеры, хранимые процедуры, в этом тоже надо уметь разбираться?

ну про первое я не скажу т.к. не использовал пока а второе и сама 1це использует и знать надо (чем сейчас и занимаюсь :) )

:) ну вот и получается что открываешь ветку регистра а там 10 измерений и ни одного реквизита хотя из них 3 можно назвать измерениями а остальное для отбора оборотов... и недоумение а почему же вот так итоги расчитываются долговато

или организация построения запросов с привлечением "галочек" в документах движений хотя спускаться до такого уровня и смысла нет... опять тормоза - но ведь программисту то было видимо всё равно как запрос строить - главное синтаксис знать а то как оно будет храниться и как отбираться - зачем это :)

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

не... ни кодером ни бухом ни знать основы БД конечно не надо... а зачем ? потом уже другие придут и будут приводить в порядок если смогут... зато все "при деле" и всем хватает на хлебъ :)

klen_, можно и запросами и компоновкой отчеты клепать

авторОТГУЛЯЛ за конкретный период исчисления и сколько МОГ отгулять

ну насколько я помню когда к ЗУП-у пробовал готовился (уже больше года прошло с тех времён по этому не бить за конкретику) то там это или вбивается в табель хотяб или из графика вытесняется фактические невыходы (а кроме этого есть ещё и планирование отпусков)... ну вобщем не важно как именно вносится инфа но констурктор запроса и компоновка тут ни причем т.к. они не для ВНЕСЕНИЯ инфы а для вывода... к тому-же отчеты по крайней мере по отпускам есть

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