Штат программистов 1С. Есть зверинец из конфигураций 1С (ЗУП, БП, УПП и т.д.).
Как у вас в компании распределены обязанности? Кто за что отвечает и по какому принципу?

сколько всего ИБ ?

(1) понимаю, что количество баз важно, но хочется ответов, как у вас дела обстоят.

Вася за все прикладные объекты начинающиеся с букв от А до С, а Петя от Т до Я.

Никогда не делаю жесткого разграничения между конфигурациями.

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

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

(2) из связки упп + бп + зуп
практически уверен, что нетиповая должна быть только одна
=> возникает вопрос -- зачем штат ?

с точки зрения руководства должно быть так кто эффективнее умеет делать что-то тот тем и занимается. :)

(6) как ты потом кто-то будет подменять кого-то ?

(7) Найти и исправить ошибку пока главный пильщик базы в отпуске любой сможет. Но именно дорабатывать должен один. У базы должна быть ответственная *опа и только одна.

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

(8) А бывает ещё парное программирование

(10) групповое =)

(8) А не руководитель ли это?

(12) *это = эта

(10) бывает. практикует кто https://ru.wikipedia.org/wiki/Парное_программирование?

(12) Ну если руководитель альтруист-энтузиаст, он назначит себя. Если нет - назначит ответственного на каждую базу.

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

По направлениям: закупки, продажи, склад, финансы и т.д. Зависит от объема доработок конечно, т.е. вполне возможно, что в какой-то организации один прог может вести несколько направлений

(16) Это разделение для упр. базы. Типовые ЗУП,БП ведет кто-то один и как правило просто обновляет =)

Я отработал в компании, где делилось подобным образом. Точно могу сказать, что (4) - наилучший путь к хаосу, особенно если учет сложный и много чего допилено. Чтоб держать все под контролем, руководителю придется вникать в мельчайшие детали. Вместо взаимозаменяемости достигается торможение в разработке в несколько раз. Взаимозаменяемость - это миф. Перекидываемые с участка на участок проги находятся вечно в цейтноте. Твердо уверен, что разделение кодеров должно быть по зонам:
-Рег. учет (финансовый) + ЗУП;
- Производство;
- Торговые и складские процессы;

Если не хватает загруженности, участки можно совмещать.
Как я уже сказал, это для высоконагруженных систем.

(17) когда типовые, то так.

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

(18) Похоже, что там практиковалось костыльное программирование. При адекватном - никакого хаоса нет, а вопрос пользователя или неожиданная ошибка - повод для уточнения/исправления/до-документирования источника. А взаимозаменяемость - это не миф, но время на вникание, конечно, требует. Но не двухнедельного, конечно же.

(20) +1

скорей всего там переписывалось всё и вся

(20), (21) Вы не работали с высоконагруженными системами - сразу видно

Как распределю, так и будет :)

(23) то есть привязки к конфигурации нет?

(24) Объясни, что нужно постоянно делать в ЗУПе и БП, чтобы еще их делить между прогами?

(20) Особо углубляться не буду, слегка прокомментирую.
Например, у вас стоит упр база УПП 1.2, внедренная лет 5 назад, выгрузки в УПП1.3, или же БП2.0. Склад работает на альтернативной WMS, которая связана выгрузками-загрузками с упр. ядром на УПП1.2. В обмене регистрируется порядка 1500-200 объектов за 10 минут. У вас 15 филиалов. Взаимозаменяемый прог делает корректировку небольшую срочную в заказе покупателя, которая рассчитана на интерактивную работу. И прогу, который в основном занимается интеграцией, выносят мозг, потому что обмен встал колом. Он конечно найдет, но не сразу, потратит 40 минут - 2 часа. Это только маленький пример, к чему приводит взаимозаменяемость.

(25) например, конфы перепилены, сотрудников свыше 1000, вытирание соплей у пользователей, обновления, возможно обмен с управленкой (РИБ), хотелки разного рода (их обсуждение, утверждение, документирование) - как-то так.

(24) Нет. Обычно по функциональному признаку. Кто-то зряплатой занимается, кто-то БУ/НУ, кто-то в производстве шарит... В зависимости от того, кто в чем сечет лучше. По крайней мере везде, где работал, такое деление было.

(26) Я, похоже, действительно чего-то не знаю или с чем-то не работал, но как может встать обмен, если пряморукий доделал кнопку на форме?

(22) в 2008 году видел конфу комплексная 77
вернее то, что от неё осталось (где 1/4 -- это комплексная, остальное 3/4 допил)
по факту весь этот допил никто не использовал, а удалять было жалко
хотя там наипростейщий учёт -- продажа товаров с агентскими схемами

У нас например сейчас так, я занимаюсь БП и ЗуП. (17) Ну я не только обновляю. БП сильно допиленная, ЗуП немного подпиленная. еще один человек занимается документооборотом. И мы каждый своим занимаемся, но в момент отсутствия заменяем друг друга. Также несколько человек на не 1с базы. 2 на одну базу, 4 на другую. Как у них разделение сказать не могу. Ну и есть нащальника который в случае сильной нужды может перераспределить задачи.

(29) Прог может использовать команды или процедуры, которые рассчитаны на некие интерактивные действия. Может использовать типа: Вопрос, ЭлементыФормы, вызывать процедуры обновления реквизитов, может дать операторам право работать с каким-то новым реквизитом, а у юзера, на которого рассчитан обмен, такого права не быть... Не использовать команды препроцессора, проверяя клиент это или сервер... Да мало ли еще что.

*(32) Описка. Реквизит = регистр.

(31) что в зупе допилили ?

(30) Если ты видел какие-то доработки в 2008 году, которые не использовались, это не значит что везде так

(27) Честно, я никогда не видел "перепиленного" ЗУПа. БП еще ладно. Я конечно может чего то не знаю, просветите что можно "перепилить" в ЗУПе?

(36) Например, наворотить какую-нибудь хитрую зарплату в упр. учете.

(36) 1. Я слегка допилил ЗУП 3.0, в части отпускных. Там как-то криво доначисляет ЗП по части НДФЛ, если отпуск попадает переходящий с месяца на месяц, а начисляется в прошлую ЗП. Но это из разряда "чего-то не знаю". Наверно как-то можно сделать, да я не знаю, книжек нет, на форумах не нашел.

2. Давно сталкивался с сильно перепиленной ЗУП 2.5, когда кодеры вместо обновлений вставляли свое. Было много работы по постепенному приведению к типовой.

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

(39) + так в 3.0 вообще сделали шаблоны ввода исходных данных - т.е. по сути показатели вообще практически какие-угодно можно вводить типовыми средствами. Остаются только виды расчета

(36) Как правило, допиливается интеграция со СКУД и табельный учет.

(41) про СКУД понятно, табельный учет - ты про что?

(39) Я встречал ЗУП в котором был реализован хитрый понедельный расчет зарплаты (в торговой сети), там вся сложность в была в этом понедельном расчете.

(39) Еще например есть потребность рассчитывать всякие отпуска и больничные в УУ примерно также как в БУ, по среднему заработку. Не знаю, есть ли такое в ЗУП 3.0.

Давненько я ЗУПом не занимался...

(43) Ну вообще то такое решается несколькими авансами, ведь налоги же ежемесячно начисляются

(42) Например, нужно вести несколько табелей - по регламентным подразделениям, по данным СКУД и по управленческим подразделениям...

(44) конечно можно =)

(47) Типа по одному табелю работник вышел а по другому - нет? =)

(49) Нет, по одному он работал 8 часов в дневную смену, а по другому еще 4 в ночную...

(50) Почему это в одном табеле нельзя учитывать ?

(51) Чтобы не было переработки для трудинспекции.

БП+ЗУП+Оперативная база на 7-ке - 1 прог
УАТ + КА (база по поставкам из китая) + управленческая база на 8-ке  - другой прог
УТ11 заточенная под продаже с сайта - аутсортинг

Как то так

(52) ну ясно, хорошо, хотя имхо все это - мелочи.

(52) все о чем говорили в этой ветке про ЗУП - несерьезные доработки, которые делаются один раз, я не вижу смысла на такое направление выделять отдельного прога, что-то еще он должен вести

(54) Ну да, в общем мелочи, 10% времени занимало в общем объеме. На предыдущем месте работы была практика взаимозаменяемости - все программисты по очереди работали со всеми конфигурациями, со своими задачами от и до. На нынешней - есть ведущие программисты, в целом каждый обеспечивает доработку 2-3 конфигураций - они владеют информацией в целом, знают все выполняющиеся и выполненные задачи, и прогрммисты, которые каждый работают со своей конфигурацией. Таким образом, ведущий всегда сможет заменить ведомого...

(46) ну там же не просто суммой, а по начислениям, исходя из еженедельного табеля, наверное.
(55) В ЗУПе скорее не прог нужен, а специалист по разборкам с новшествами всякими, чтобы со всякими "реформами ФСС" и "реформами ПФР" разбираться, выяснять как же работает все что 1С нового накодили.
Хотя, часто бывают и неприятные ошибки в коде, чтобы исправить которые нужен прог.

(41) > Как правило, допиливается интеграция со СКУД и табельный учет.


этот допил никак не связан с типовыми механизм начислений => не считается

(4)(16)(18)(31)(53) спасибо.

(58) Все что не связано с механизмами начисление - это не программирование, а скриптинг да ? :)

(60) дело в другом -- там один раз сделал и всё

(34) Отражение в бух учете немного допилили, расчет компенсации проезда по городам, разные доп отчеты в головную организацию, в табеле что то доделывал и т.д. не много но есть

(3) Все доработки с префиксом ББ_, Петя скучает:)

(62)

> Отражение в бух учете немного допилили,

по-подробнее


> расчет компенсации проезда по городам

это ж вид расчётов -- чего там допиливать ?
только запрос, который будет автоматом базу для этого ВР рассчитывать

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

(65) это делается внешней обработкой...

(66) а что внешние обработки сами родятся?

(66) внешняя обработка вчерашний день, сейчас расширение актуально
Хотя для ЗУП 2.5 оно врядли будет актуально

(58) Как и любой допил - это надстройка над типовым механизмом. Иначе - это уже переработка, которую нужно будет и поддерживать собственными силами. Короче - выстрел в ногу, зато - отдел никто не сократит, ибо только накатывание обновлений от поставщика конфы занимает до 2-х недель у горе-прогера... Жуть...
Но как и любая надстройка - она зависима от конфигурации конфы и алгоритмов, которые поставщик тоже меняет, но настолько редко, что разовый аврал вполне можно перетерпеть.

(67) Скачиваются из интернета, ты не знал чтоли ?

(68) уже пользуешься ? =)

(69)

> ибо только накатывание обновлений от поставщика конфы занимает до 2-х недель у горе-прогера... Жуть...

уволить


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

единственную заде может 1с подкинуть -- это переименовать ОМ/функцци/процедуры

(71) У меня все обработки такие что их через расширения делать бессмысленно

отвлеклись. мало примеров от фиксиков