В компанию требуется Ведущий программист 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]

Ветка с Волшебником согласована.

Уже переезжаю

(2) *шутка

Отличная вакуха

Вообще, 130к для СПБ... сладко

неплохо.

Очепятка: 120 сотрудников, это я скопипастил с прошлой вакухи.

(7) главное, чтобы в ЗП очепятки не было

Командировки в Сибирь и ДФ бывают?  конфигурация компьютера программиста? отпуск делится?

Это ж тот бизнес-центр, который тогда ветром раскачивало? Да, понимаю, за что такие деньги.

(9) я думаю при зп 130к можно не беспокоиться о конфигурации компьютера...

Эта вакансия появляется с завидной регулярностью.
Старые сотрудники куда исчезают? :)

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

(9) Командировки бывают, но пока не планируется. Отпуск как договориться. Конфигурация современная, с ССД на борту, зеон/i5-i7, монитор 27".

(0) БЦ лахта?

(12) Расширение штата. Компания прикупила еще предприятие на Урале.

(15) Ресо

(15) БЦ РЕСО

Поехать чтоли в Питер жить.

(10) Не слышал о таком.

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

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

(0) Удаленщиков рассматриваете? Условия: 100 000 на руки, под ваш часовой пояс.

+23 на полный рабочий день.

(23) К сожалению, у нас уже есть сотрудница на удаленке. Новых на такие условия не рассматриваем.

(23) Давно бы уже переехал, и получал бы 150

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

(26)  Пока не могу. Ребенок учится в хорошем лицее. Закончит - перееду.

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

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

(0) а из текущих на эту должность никто не тянет? обидно наверное им

(29) есть бизнес-аналитик, который общается с пользователями и ставит задачу; "ведущий" там не в смылсе тим-лид, а просто показатель скилла (требуется не тупить и грамотно кодировать от соискателя).
130 в белую на руки без обязанностей менеджера или аналитика для Мск - это очень неплохо.

(30) Есть ведущий программист, но он на другом важном проекте. Есть еще крупные внутренние проекты, не хватает ресурсов.

(30) Я работала в одной конторе, в которой было 2 ведущих... и 2 обычных...
И мы обычными не командовали, только советы давали, как лучше, красивей и эффективней сделать...

(0) можно тоже тестовое задание, если не сложно, на мыло из личной карточки?
Спасибо.

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

еще и белая..
по-моему даже франчи такое не обещают

(36) в больших конторах такое бывает

(36) У нас в деревне уже третья контора белую обещает...

Франчи...

(0) Мне тоже тестовое...

Да давайте уже в общий доступ:)

(0) по делу, без розовых воздушных замков.
Вопрос: ДМС - это что?

(42) Добровольное Медицинское Страхование

А где вы увидели про тестовое задание?

(44) это я себе попросил

Мне бы его придумать, это тестовое задание. А на это время надо.

(42) ДМС - это добровольное мед страхование.

(46) ну вот приду я на собеседование, и о чем мы говорить будем?

(44) Если будет наплыв кандидатов, скорее всего попросят сделать что-то для некоторого ранжирования.

(45) типа сам будешь искать, а тут есть готовое?

(49) нет, просто хочу себя проверить. Неплохие условия, если норм будет - обсужу со своим работодателем увеличение белой составляющей.

(48) "за жизнь", "за прошлые разработки", а покажи ка мне на ноуте чего делал.
По серьёзному: найдут что спросить, небось и кадровик есть (психолог, вряд ли)

(48) Вопросы найдутся, не стоит беспокоиться.

(48) Посмотрю твои ветки на Мисте))

(53) смотри

как правило на мои вопросе на мисте ответить не могут :(

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

(46) Любое из спеца по используемой конфе...

Кстати, я тоже бы для проверки посмотрела бы...

и я

(46) Просто сформулировать словами 2-3 существующих реальных задач и выложить сюда с просьбой отвечать кодом или словами в личку, дабы в форуме не устраивать дискуссии.
Предложение хорошее, соответственно и требования должны быть соответствующие.

Вот упрощенная задача.

Необходимо разработать приложение, которое позволяет фиксировать в режиме он-лайн текущее состояние на конвейере с выбором текущего сырья и количеством выхода - сотрудник производственной линии вручную указывает количество выпуска. Выпускаться продукция может в разной упаковке: по 72, 80, 96, 108 штук. Таких линий, предположим, 10.
В УПП находится рабочее место диспетчера производства, где он видит общее выполнение плана как по каждой линии, так и по всем линиям вместе.

Информация по заданиям на выпуск задается в УПП накануне смены с указанием сырья, выпускаемой продукции и количества выпускаемой продукции.

(61) отлично!

(20)
http://www.fontanka.ru/2013/05/24/046/

(63) http://www.online812.ru/2013/05/24/005/

Это было землетрясение.

Если правильно понял, то для (61) нужно мобильное(?) приложение, которое будет дергать веб-сервисы бэка для отправки туда данных-циферок, а в бэке - диаграмму какую-нибудь с прогресс-барами. Или не то?
Что конкретно оценивается при выполнении - проектирование интерфейса (юзабилити), логика (механика) обмена или все вместе?
Разработать за сколько-то времени или только концепцию рассказать?

(65) >>Что конкретно оценивается при выполнении
Способность понимать задачу с полуслова.
Вот Fragster похоже все слету уловил :)

(61) мы такое реализовывали,только у нас кол-во не сотрудник вносит а автоматом сделали

(61)мое решение - при наличии wi-fi.

Планшет + подключение к RDP + упрощенное РМ диспетчера

у меня кладовщики по такой схеме расходники делают

+ (66) Наверно имелось ввиду, что нужно разработать что-то вроде обработки, которая позволяет указывать какой продукции сколько сделали для каждого вида сырья. Ну то есть допустим есть план сделать из некоторого сырья  100 штук по 72, 50 штук по 80 и т.д.
По мере выполнения плана циферки заносятся в обработку, а она в свою очередь пишет в какой-нить регистр, а диспетчер его читает периодически. Наверно как-то так...

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

и даже предложенные варианты концепций

пока видится веб/хттп сервис на каждое арм с большими кнопками под сенсорный экран (возможно + ТСД или СШК в режиме потокового сканирования или весы для определения количества из веса) + слив данных в РС. Арм также может быть реализовано в 1с. Отображение текущих данных в АРМ старшего. По окончании смены перекачивание данных из РС в отчет по смене и обнуление РС.

(61) Решение такой задачки в работоспособном, хоть и упрощённом виде, который готов в продакшен, тянет на тыщ 70

т.е. по текущей ставке - 28 часов франя

или 3-4 дня

из них 1-2 - согласование "физических" процессов

(77) не из них, а кроме них.

Сразу видим, что Денис неплохо оценивает сроки.

(0) Опять? Вы их там едите?

(80) да ладно, на волне "антисанкций" агрокомплекс неплохо растет

(80) ->> (16)

(68) Я отказался от RDP по причине того, что не гарантируется 100% бесперебойность связи с головной базой. А производство нельзя останавливать.

Поэтому, рассматриваю вариант решения с выходом в офф-лайн на планах обмена. Что касается мобильная или десктоп версия - приоритет в сторону десктоп, так как сейчас развернуть приложение можно на планшете под управлением Win 10, а мне в дальнейшем нужны будут возможности платформы десктопной ОС - в частности, планируется подключение АРМ к АСУ конвейера для полностью автоматического фиксирования состояния работы в 1С.

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

(84) а за что деньгу взять?

(84) Потому что это колхоз, а не производство по ISO.

(84) чтобы этот листик и не отправлять голубиной почтой из Новосибирска в СПб

вертикальная масштабируемость технологий:
листик
АРМ с ручным вводом количества
АРМ с СШК и ручным сканированием каждой пачки
Арм с автоматическим подсчетом (весы, потоковый сканер, система машинного зрения, смотрящая на конвейер)

(86) по поводу ИСО спорно...Осбенно если рабочий будет ставить автограф на  этом  литке...

Если  делатьэтот софт по исо,то его надо бекапить, иметьеще одну железку в  резерве и т.д. и  п.т...

А задачка-то не такая уж и простенькая оказалась...

Хорошо, что хоть кто то(Fragster) тестовое сделает.

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

"Если падает канал и УПП становится недоступна, диспетчер ничего не сможет контролировать." // Зато линецщик продолжит бить данные и при восстановлении канала данные подгрузятся в бэк.
А ты предлагаешь линейщика засунуть в базу онлайн? Тогда он не сможет бить данные при падении канала до бэка.

Сорри, а зачем вам знание ООП? Будете свои классы делать?

(91) вот интересно, если я так сделаю тестовое задание, так, что все обоссутся от восторга, готовы ли (0) ждать меня 6+ месяцев + немного подкорректировать предложение по ЗП?

что-то много "так". ну да все поняли, наверное.

Я думаю тут вообще будет какой-то ШК с памятью на рабочую смену, а потом передача разом в БАЗУ

(96) прочитай условие еще раз + важное дополнение в (83)

Сканер К не справится с хранением таблицы с 5-8 колонками. Если нужно посмотреть, тогда данные можно подкачивать онлайн/оффлайн.

К - *ШК

(92) Диспетчера выпилить из УПП.
В УПП "Отчеты производства за смену" грузить обменами.
И "Отчеты производства за смену" мне кажется нужно тоже выносить в ту базу, что бы они не были обезличенными и начальник смены мог так же создать этот документ при упавшем канале.

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

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

(93) Говорит о разностороннем развитии специалиста. Кроме того, не исключаю необходимость написания прикладных dll хоть на плюсах, хоть на решетке. Вообще, полезное качество.

(102) А какой интерфейс имеет АСУ? Голый обмен по RS232, TCP/IP, HTTP или придается библиотека с неким API и под что?

Дурацкие требования в (0). Говорит о том, что возьмут кого-то, кто не удовлетворяет этим требованиям.

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

А с другой стороны заменить необходимость "знание ЗУП 3" и "понимание ООП" на "приветствуется" и вуаля, нормальная вакансия.

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

(106) Мне кажется, понимание != знание. Понимание - это синоним приветствуется. А вот знание ЗУП нужно. Нужно перевести с ЗУП 2.5 на ЗУП 3.0 и вытащить все кадры из УПП.

(102) и жнец, и швец, и на дуде игрец...

(108) хороший спец по ЗУП, это уже от 120 в Питере. без всяких УПП и прочих дээлелек...

(108) Да про ООП — это вообще левая хрень, из серии фары на лбу.
Я вот, например, имею очень отдаленное понимание, как работает ООП, меня любой спец засмеет, я даже не рискну говорить про понимание. А уж как написано в (102), что не исключено написание dll, так я и говорю, фара во лбу.

Про перенос с ЗУП 2.5 на ЗУП 3.0 и перенос кадров из УПП вообще смешно.
Делайте отдельный проект, ищите во франче грамотного спеца по ЗУП, в первую очередь 3.0.
Недавно поработал на крупном проекте рядом с человеком, занимающимся ЗУП в ERP, так вот, ЗУП 3.0 и ЗУП 2.5 как небо и земля.
Спецов по ЗУП 3.0 днем с огнем не сыщешь.
А предлагать ему еще и dll'ки пописать между делом — даже не смешно уже, грустно.
Сколько сотрудников, 120, я так понял?

(110) +1
Соглашусь, что уже даже УПП в этом случае лишнее.
Нужно брать на проект отдельно зарплатчика, делать проект и потом брать эникейщика на подайпринесипошелнахрен.
И на УПП серьезного спеца, который будет эникейщика гонять в том числе.

(111) 2000.

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

(113) 2000 человек?!
Вы издеваетесь? :))

+(115) Вы еще скажите, что перелезть на тройку хотите до конца года с переносом всех исторических данных :))

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

(115) 2000 на предприятии.

(116) Я вообще много чего хочу. Хочу на ЕРП перейти, например. Но пока холоден к этому процессу.

(116) Я готов ради вашего любопытства еще подержать ветку, ибо уже набралось достаточное число кандидатов и вся следующая неделя будет распланирована. А вы говорите.

(118) Хм, у нас как-то завязалась беседа, из которой складывается впечатление, что вы представитель клиента из (0)?
Это так?

(120) Я руководитель отдела.

(121) Понятно. Спасибо за ответ.

(119) Скажем так, я довольно пессимистично настроен насчет удовлетворения кандидатов всем озвученным в (0) требованиям :))

(123) что-то одно из требований в (0), найдется точно...

(123) Если золотой сотрудник с искрой в глазах, я, как адекватный человек, могу пойти на уступки. И думаю, если человек хороший спец, ему не заставит труда подтянуться в определенных областях. Я на курсы отправляю периодически сотрудников.

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

(124) Думаю, что даже не одно.
Но уже УПП и ЗУП внушает сомнение.
А уж ЗУП 2.5 и ЗУП 3.0 одновременно...

(126) Хорошо, будем иметь ввиду. Спасибо за предложение.

(125) А с какой целью, если не секрет, переходите на ЗУП 3.0?
Типа 2.5 все одно скоро умрет?

(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) еще один Тестовое задание