В компанию требуется Ведущий программист 1С

Сведения о работодателе

Город: Санкт-Петербург
Расположение: Приморский район, 15 мин. до м. Старая Деревня / Комендантский проспект
Сведения о компании
Компания "Агро-Альянс", http://www.agro-al.ru/

Пожелания к кандидату

Опыт разработки 1С более 4 лет, наличие сертификатов Специалист приветствуется, знание БСП, клиент-серверного взаимодействия, знание прикладных конфигураций УПП 1.3, ЗУП 2.5/3, БП 3, понимание ООП, бизнес-процессов в оптовой торговле и производстве, управленческого и бухгалтерского учета.

Обязанности

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

Оплата труда

130000 руб. на руки, "белая".

Условия работы

УПП 1.3, ЗУП 2.5, БП 3. 90 юзеров, несколько офисов: юг, Сибирь и ДВ. В отделе 4 программиста. Подчиняется руководителю отдела. Есть парковка. Собственная продукция сотрудникам отпускается по себестоимости.

Оформление по ТК.
ДМС.
Рабочий день с 10:00 до 18:00.

Контакты

Контактное лицо: Кирилл Шевченко
E-mail: [email protected]

(128) Да пока не за что :))
Просто для информации: человек делал проекты на полторы и три тысячи сотрудников.

(130) Пришло резюме от соискателя, который оптимизировал ЗУП, в котором считалось 20000 сотрудников. Конечно, все можно проверить, но что есть то есть.

(129) Да, одна из причин. Хочу ЗУПы все вывести в одну ИБ и перейти на более старший релиз. Там основная причина - с обновлениями, они приходят иногда весьма поздно, хотя на ЗУП 3 намного оперативнее апдейты на ИТС вывешиваются.

(132) Перенос ЗУПа - это не приоритетная задача, думаю этот процесс на следующий год запланировать.

(131) Ну, оптимизировал, это пока ни о чем.
Я проведение 70000 документов в БП 3.0 оптимизировал, при этом это не требовало даже мало-мальского знания БП 3.0 :))

(134) А что там в БП оптимизировать? Там регистр один, бухгалтерский.

(135) Точнее, хозрасчетный.

(133) Вот да, тоже хотел сказать, я хоть в ЗУП разбираюсь как свинья в апельсинах, но, насколько я понял, все сейчас пляшут под 6-НДФЛ.
И я бы в этом году программу не менял, а то можно много крови сдать в процессе этой смены.

Ну и фраза "Проведение 70000 документов" оптимизировал. А 100000, значит, неоптимально проведутся?

(135) Ну не, не все так просто.
Там есть рассчитанные итоги, их граница, параллельное проведение и пр. варианты оптимизации.

(138) Не, просто был определенный SLA, что каждый месяц (или квартал, уже не помню) требуется перепроводить порядка 70 — 100 тысяч документов.
И время перепроведения неделя — полторы не устраивает физически, отчетность же нужно сдавать.

+(140) А SLA был в том, что нужно было, чтобы это проводилось ну хотя бы 4 — 5 дней.

(140) У меня есть в практике такие решенные кейсы. Только там немного другие входные данные, но суть та же. Поэтому, вас понимаю.

(134) "Я проведение 70000 документов в БП 3.0 оптимизировал"
Пакетное проведение? Оно существует? )

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

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

(137) Ктото пляшет, а ктото написал пару проверочных отчетов для расчетчиков и не парится, хотя два десятка обособок и под 10 тыс сотрудников)

(144) Идея "вменяемого учета" плохо сочетается с "работа задним числом".

(25) Почему к сожалению? Плохо справляется на удаленке?

(61) Я бы делал так: АРМ пишем на 1С. Отдельная конфа с интерфейсом "под палец". Данные - во внешней SQL-базе. С основной базой обмен либо через хттп-сервис, либо напрямую из SQL-базы АРМ-ов. Сроки пока озвучить сложно. Нужно уточнять задачу.

(149) Лучше сделать полный АРМ на 1С и упрощенный в виде веб-клиента (одностраничник для браузера или любого движка v8).
Подобный веб-клиент открытый (html/css/js) и легко допиливаемый кучей веб спецов как и с 1С дела.

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

(150)+ Причем экономия на лицензиях 1С это мелочи по сравнению с другими преимуществами.

Как вопрос удобства интерфейса, надежности и кроссплатформенности. Веб-клиент введенные данные может хранить у себя и передавать когда восстановится связь в 1С на сервер.

(146) ох, как я тебе не верю... ну точнее тебе может и верю - ты  не паришься, а вот расчетчики... а еще по концу года с 2-НДФЛ сводить...

(152) Твое дело. 6 НДФЛ мы сдаем без проблем, и с 2НДФЛ сверяем уже сейчас - есть ньюансы, но ничего особенного

(143) Только лишь пакетное проведение само по себе дает ускорение на 0%

(144) Есть другие варианты?

(155) "Точечное" (пере)проведение (не по всем регистрам) или вообще не опираться на проводки предыдущих документов для получения нужных данных (типа как в РАУЗ, но там на границах месяцев все равно все должно быть в ажуре)...

(156) Ух, круто!
Можешь сказать конкретику для реализаций?

(157) Конкретика есть в офлайновых движениях в УПП и ERP

(157) Конкретика простая, проведение документа задним числом не должно никак влиять на перепроведение документов последующих.

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

(157) Каких реализаций, в БП 3.0? Если ограничиваться прикладным кодом типовой конфы, то второй вариант не подойдет. Распараллеливание только.

(158) Пук в лужу

(159) Пук в лужу

(161) Уровень твоей аргументации понятен, вопросов не имею.

(162) Нет, еще давным давно с NS много спорили в т.ч. по реализации "строго партионного учета" как я это называю.

(160) О, прикольно.
Только что это была панацея от всех бед и надежда человечества, теперь оказывается, что возможно максимум тупое распараллеливание.
Ну ok.

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

(163) Так какая у тебя аргументация, такая и у меня

(164) Блеать, в (157) я просил про _конкретику_, а не общие идеи вечных двигателей.
Конкретика есть?

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

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

В результате от проведения "задним числом" ничего не меняется совершенно.

(165) А ты как сделал?

(170) Понятно, что так сработает. Хоть и не решит проблему авансов.
Но так неудобно.

(167) Аргументация намного более внятная, чем твоя задача "Дайте мне конкретику как не перепроводить все время документы".

Есть реальные конфигурации, в которых перепроведение всех документов не требуется для выполнения бизнес-логики.

Ни для выстроения взаиморасчетов, ни для подбора партий.

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

(173) У тебя вообще никакой аргументации.
Сказал с важным видом "Оффлайновые движения" и все сразу такие "О, бесконечно мудрый, как же мы сами до такого не додумались!", да?
Конкретика — это чуть больше, чем словосочетание из двух слов.

(172) Не бывает авансов "просто так", они всегда под конкретный "товар".

Просто необходимо распределить аванс в момент формирования документа отгрузки (указать по какой строчке какая сумма из какого аванса) и запретить менять аванс задним числом, пока отгрузка проведена.

(176)+ Так сложно понять что если есть аванс, то когда добавляем строчки в документ отгрузки, в этот момент идет "выбор партии аванса" и каждая строка будет или уже оплачена или еще нет.

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

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

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

Именно об этом тебе писали в посте (156)

(178) Это тафталогия ибо "некое закрытие месяца", просто "проведение" документов разделено на части и размазано.

(178) Ну да, поюродствуй :))
Я знаю концепцию разделения движений на онлайн и оффлайн.
А спрашивал как раз про конкретику, то есть про "распределение взаиморасчетов и подбор партий".
То есть ты хочешь сказать, что в бухгалтерии для реализаций можно легко отделить мух от котлет и это даст двукратный эффект?
Или это так, теоретические изыскания?

(180)
Причем тут какая-то там бухгалтерия?
Ты следишь за ходом дискуссии?
в (144) было высказано про то, что "Идея построения вменяемого учета для больших данных на принципе перепроведения документов" порочна.
На что ты спросил в (155) про другие варианты, подразумевая безальтернативность данного подхода.
Я тебе привожу в пример оффлайновый подход ERP/УПП - которые как раз для "больших данных",ты мне в ответ сначала про отсутствие аргументации, потом про свою бухгалтерию.

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

Принципиальных ограничений применить подобную схему для бухгалтерии нет.

Но, повторюсь, речь шла вообще про архитектуру систем, работающих с большим объёмом данных.

(181) Вообще-то дискуссия завязалась из темы оптимизации проведения реализаций в БП, не?

(182) Ты воспринял пост (144) как упрёк тебе, что ты выполнил задачу неэффективно, и начал с этим спорить.

На самом деле же, как мне кажется, он был про то, что архитектура конфигурации не должна требовать подобных работ в принципе, что это неправильно.

Именно поэтому потом пошли примеры, которые ты лихо обозначил "пуком в лужу"

В 44м релизе БП 3.0 появилось отложенное проведение.

(184) главное при формировании отчетности не забыть, про "отложенное"... ;-)

(185) Недостающие движения делаются при закрытии месяца, про него мало кто забывает.

(178) "Конкретика такая, что распределение взаиморасчетов и подбор партий может происходить вне транзакции проведения документа, отдельными заданиями. "
- но ведь все равно придется накладывать блокировки, иначе получится что два задания (например) построили свои выводы, на основании одиних и тех же данных и получится что на один док реализации 100 руб, распределится 2 оплаты по 100 руб..?

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

(187) (188) Такие баги в типовых есть

(187) Проведение по взаиморасчетам никак не пересекается с проведением по партиям. Блокировки будут нужны только если выполнять восстановление взаиморасчетов, например, 2-мя потоками.

(187) Кажется, что задание должно быть одно.

(188) В условиях ограничений, которые диктует бухгалтерия в лице необходимости обновлять целиком набор записей по регистратору (невозможно обновить только 62 счет, к примеру), задание по партиям будет пересекаться с заданием по взаиморасчетам в момент записи по 1 регистратору.

(191) + в смысле задание, которое будет распихивать взаиморасчеты, при закрытии месяца, например)

(193) Угу и работать когда все пользователи из базы того...

(194) С чего такой вывод?

(195) А вдруг ручную операцию сделают?

(196) Собьют последовательность по конкретному контрагенту. Задание потом с этого момента его пересчитает. Остальных не будет - если нет взаимозачетов.

В ERP реализовано через РС "ЗаданиякРаспределениюРасчетовСКлиентами" или как-то так.

(191) "кажется" имхо это не "обеспечивается"
???

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

(197) угу, у мну в клюшках аналогично подпилено (конечно не так красиво наверное как в типовом решении)

(198) В типовых решениях 1 задание на каждый раздел.
(199) см. (198)

(201) то есть в типовых сделано тупо наличием всего одного задания на одно "направление"...?

(202) Да, он так и написал)

(178) > Почему-то это дало большой эффект

Т.е. ты не понимаешь причину эффекта? Почти карго-культ )

(204) >>> переадресовать (174)

(203) типа что никто вдруг не возьмет и не напишет обработку которая будет "конфликтовать" с заданием за ресурсы-данные...?
ну ладно я, могу ТАК писать, не ставить блокировки (рассчитывая только на себя), но другие...? ;-)

(206) не понял. ну может напишет, значит ошибся, надо думать что пишешь)

(206)
Блокировка тут очень попортит производительность.
Логика следующая:
Задание берёт из управляющего регистра список всех заданий с контрагентами, аналитиками, периодами, по которым требуется расчет. Потом сразу берет данные для них всех 1 запросом. Потом производит расчет - по всем. Потом обновляет управляющий регистр сведений - что такие-то такие-то задачи были сделаны, удаляет номера выполненных заданий.
Задание может работать полчаса, если ставить блокировку, то никто не сможет отменить проведение рассчитанного документа, например. Блокировка на полчаса - это серьёзная проблема, её надо избегать.

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

Т.е. нарушения бизнес-логики не происходит.

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

(154) чисто теоретически (сфероконически), при   пакетном проведении можно получать остатки не для каждого документа (пусть даже актуальные), а только на начало последовательности пакета документов.

Что-то вы сильно мудрите, господа! Делайте проще... Может нужно не все данные грузить, а только итоги смены. Может онлайн и докачки вообще погубят систему.

Почему работодатель Питер, а зарплаты Московские?

(211) да не, это просто хорошая ЗП для хорошего специалиста в СПб. в Мск такие и до 200к получают, ИМХО. пару лет назад мне в Мск предлагали на 100к на удаленку, но я бы не вывез. не могу дома работать.

удаленку с неполной загрузкой

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

(214) ты не стал (0) свое резюме слать?

(214) так вроде бы требования вполне себе обычные. Вон и ТС говорит, что резюме много набралось.

(215) нет, я же работу не ищу.

(216) резюме - много, а вот будут ли там подходящие - хз

(217) ты может быть и нет, но работа разыскивает тебя

(208) "Задание берёт из управляющего регистра список всех заданий с контрагентами, аналитиками, периодами, по которым требуется расчет."
- ну взяло.
- другая сессия/обработка/пользователь точно также "взял" эти данные и начал по ним считать... - все, (_._)

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

..типа так?

(220)
Для реализации менеджера потоков надо так.
В настоящее время статуса "выполняется" и соответствующей записи нет, в остальном все так и происходит.
Экономится какое-то время на обновлении управляющего регистра.

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

Апну ветку.

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

Продолжаем поиски.

Ок. Напоминаю свои условия: удаленно на полный день под ваш график работы. 100 на руки.

Ввысь!

(223) Чего-то мало просишь

(225) Давай трезво смотреть на вещи. :)  Хочу 150. Компания ищет в штат на 130. Удаленщик - это дополнительный головняк, да и риски дополнительные. Я думаю, что компании нет смысла платить 150 удаленщику, когда можно в штат взять на 130. К тому же, для "нашей деревни" и 100 - хороший уровень.

(226) Мало хочешь) Проси уж 200, а то предложат 60 в ближайший офис компании в Сибири))

(0) Что даст кандидату "понимание ООП" если ООП как такового нет в 1С на данный момент? Или же кандидату помимо 1С придется кодить на C#/C++/Java?

(228) еще один Тестовое задание