Сегодня я хочу поговорить об оптимизации 1С, о том, как можно решить проблему ожиданий на блокировках при работе системы. Я буду рассказывать достаточно простые вещи, но они, возможно, позволят кому-то сэкономить время, силы и деньги.
Когда я стал работать в компании-пользователе, для меня наиболее критично стало не то, насколько красиво и правильно сделано мое решение с точки зрения рефакторинга, а то, как быстро я смогу решить проблему бизнеса, и какой эффект это принесет. Как написан мой код – бизнесу зачастую неважно.
Я расскажу о нашем опыте, как мы у себя оптимизировали 1С на тех участках, где она «тупила» и «тормозила», и как мы сделали это без оптимизации запросов, алгоритмов и т.д.
Оптимизация «по учебнику»
Напомню классический подход к оптимизации.
Допустим, у нас «тупит» и «тормозит» 1С. Мы это видим по системам мониторинга, либо нам говорят об этом пользователи. Что мы, как специалисты 1С, должны делать «по учебнику»?
- Мы находим узкие места, где «болит» больше всего – например, система начинает «висеть», когда идет массовый расчет себестоимости, или начисление зарплаты, или массовый ввод реализации, как это было у нас.
- Когда найдены узкие места, мы должны посмотреть, что можно оптимизировать, чтобы ускорить работу системы.
- Возможно, нужно оптимизировать запросы, чтобы они захватывали меньше данных,
- Или переписать алгоритмы с транзакциями, чтобы они чаще отдавали данные, либо обрабатывали более короткий промежуток времени.
- Если это не помогает, мы пробуем нарастить серверное оборудование.
Иногда все это приводит к положительным результатам. Но я сейчас хочу привести примеры того, как мы ускорили систему, не используя классические подходы.
Мы у себя в компании столкнулись с тем, что 1С в некоторые моменты времени «зависала» и «тормозила». Руководство потребовало решить эту проблему, но:
- У нас в команде не было серьезных специалистов, которые профессионально, на ежедневной основе занимались бы вопросами оптимизации.
- Для нас было трудоемко решать проблему с учетом классических подходов;
- Требовалась определенная квалификация, которой у нас не было, либо было необходимо привлекать других специалистов;
- При этом мы не могли гарантировать, что наши усилия дадут какой-либо эффект. Например, если мы оптимизируем алгоритмы проведения реализации, из-за которых у нас очень много ожиданий на блокировках, то, может быть, мы получим какое-то ускорение в разы, а может, это даст лишь небольшой прирост.
Несколько слов о компании
Пару слов о нашей компании.
Компания «Ароса» – мы поставляем продукты питания в HoReCa, (в кафе, бары, рестораны), в государственные учреждения, в ритейл. Работаем в Москве, Питере, Сочи.
Отгружаем:
- Порядка 100 тонн товаров в сутки, сейчас даже больше.
- В день обрабатываем порядка 800 и более заказов – суммарно во всех заказах примерно 4000 строк.
- В основном это штучная отгрузка.
Я в нашей компании отвечаю за автоматизацию складов, т. е. непосредственно за нашу WMS-систему.
Основная учетная система у нас – это «Управление торговлей». А на складе мы используем WMS «Кортес». В мире 1С в качестве WMS-системы наибольшее распространение получило решение от компании Axelot, но кроме него есть и другие WMS-решения на 1С, одно из них используем и мы.
Кейс 1. Обработка заказов
Первое узкое место, про которое я расскажу – это процесс обработки заказов на складе.
У нас процессы на складе выстроены следующим образом:
- целый день склад работает «на вход» – принимаются товары от поставщиков;
- потом в систему вносятся заказы, принятые в течение рабочего дня;
- ночью осуществляется их сборка;
- утром машины развозят заказы по клиентам.
И каждый день в 18:00-19:00 при достижении определенных значений количества заказов в сутки мы стали сталкиваться с «зависаниями» системы – в те один-два часа, когда шла основная обработка заказов операторами, работать в системе было практически невозможно.
Все заказы у нас группируются в рейсы по машинам, в которых поедут к клиентам. При подготовке рейса надо обработать «пачку» заказов, которые в него входят (их может быть 30-40) и зарезервировать по ним товар. Все рейсы (а их может быть несколько десятков) операторы обрабатывают параллельно.
И из-за того, что большому количеству заказов требовался доступ примерно к одним и тем же данным, возникала проблема – шла конкуренция за данные.
Например, какой-то товар (допустим, говядина), лежит в ячейке X в качестве свободного остатка, а эта говядина нужна в каждом четвертом заказе. И, поскольку большое количество заказов проводилось параллельно, то несколько сеансов пытались конкурировать за одни и те же данные – возникало ожидание на блокировках.
Операторы вынуждены были играть в игру «Я зарезервирую этот рейс с пятой попытки», потому что реализовано все это было не идеально. Когда оператор нажимал кнопку «Зарезервировать товар по рейсу», у него появлялись песочные часы – система начинала обрабатывать первый, второй, третий заказ, и, допустим, на четвертом заказе возникало ожидание на блокировке – пользователю выдавалась ошибка, что произошел таймаут. Попытка номер два, пробуем еще раз и т.д.
Мы внимательно посмотрели на эту ситуацию и увидели, что если бы резервирование производилось не параллельно, если бы все одновременно не пытались пройти в одну дверь, то и проблемы бы не было. Если бы наши пользователи обрабатывали заказы последовательно, они бы все успевали в отведенное время. А так основное время уходило на ожидания на блокировках и на попытки повторных обработок.
Это скриншот одной из систем мониторинга, которые мы используем. Здесь показывается суммарное время ожидания по блокировкам в течение суток. Видно два ярких пика.
- Первый пик – это 17:00-19:00 часов, когда операторы обрабатывают первую порцию заказов.
- И второй пик ночью, когда они массово начинают обрабатывать вторую порцию заказов.
Что мы сделали? Мы немного поменяли бизнес-логику системы, чтобы заказы перестали обрабатываться и резервироваться параллельно. Я допускаю мысль, что в алгоритмах можно было что-то оптимизировать, но мы решили этим не заниматься, мы просто сделали так, что все заказы стали обрабатываться последовательно одним фоновым заданием.
Как это выглядит технически?
- Когда оператор нажимает кнопку «Зарезервировать рейс», его сеанс никакого резервирования не выполняет – просто делается запись в служебный регистр сведений, что по этому рейсу необходимо сделать резервы.
- Стартует фоновое задание, которое начинает выполнять все необходимые действия.
- Когда другой оператор параллельно в это же время делает те же действия по своим рейсам, его рейс также встает в очередь.
- И потом, когда фоновое задание закончит работу с первым рейсом, оно переходит к обработке второго рейса. Когда закончит второй, перейдет к третьему, если он есть в регистре. Если третьего нет, то оно завершается.
Таким образом, заказы перестали обрабатываться параллельно.
На скриншоте показано, как все это выглядит интерфейсно в используемом у нас решении «Кортес» на толстых формах. Сейчас все это происходит примерно следующим образом:
- Когда пользователь нажимает кнопку «Зарезервировать товар», у него напротив определенного рейса появляется значок часиков. Это означает, что данный рейс отправлен в работу.
- При этом интерфейс у пользователя не «замерзает», он может дальше строить какие-то отчеты, отправить в работу еще какой-то рейс, но его сеанс больше не занимается этой работой.
- Когда рейс будет отработан, эти часики уйдут.
Если в процессе работы фоновое задание получит какие-то ошибки, допустим, по определенному заказу не хватает товара, или в документе неправильно заполнены реквизиты, и надо выдать какую-то диагностику пользователю, то в отдельном регистре сведений, где мы ведем протокол отправки рейсов, будут сделаны записи. Любые пользователи смогут посмотреть, были проблемы по рейсу или нет.
Технически мы эту задачу решили достаточно быстро, не занимаясь при этом оптимизацией алгоритмов. В результате:
- Ожидания в пиковые периоды практически ушли;
- Нервозность склада снизилась;
- Скорость обработки рейсов существенно выросла;
- И что самое важное для нас и бизнеса – все это было сделано просто и быстро.
Кейс 2. Отгрузка рейсов
Второе узкое место, которое мы оптимизировали – это отгрузка заказов, которые в течение ночи собирали кладовщики. С тем бизнес-процессом, который происходит до сборки, мы уже разобрались, но после завершения сборки там есть операция, когда кладовщики начинали с терминала сбора данных регистрировать факт отгрузки рейсов. С точки зрения пользователя ничего критичного в этот момент не происходило – сканировались штрих-коды, в 1С фиксировалось, что такой-то рейс можно отгружать, укладчики загружали паллеты в машину, и она уезжала.
С точки зрения 1С в это время по каждому рейсу запускалось массовое перепроведение заказов, потому что надо сделать соответствующие движения по документам, списать этот товар по регистру остатков с ячеек отгрузки, сделать какие-то движения по резервам и т.д. И из-за того, что несколько кладовщиков делали это одновременно, опять происходило ожидание.
Возможно, у нас все было плохо в запросах, и их нужно было оптимизировать, но сильно вникать в это нам не хотелось, может быть, потому, что мы ленивые.
В итоге мы реализовали отложенное проведение.
- С точки зрения бизнес-логики для нас было не принципиально, чтобы в 7:00-8:00 утра, когда идет погрузка машин, товар был правильно списан по регистрам. Для нас было главное, чтобы у документов был статус «Отгружен», и пользователи в своих формах видели, что они такие-то документы обработали. Поэтому, когда кладовщики отгружают рейсы, документы заказов не перепроводятся, у них просто меняется реквизит статуса на «Отгружен».
- При этом делается запись в регистр сведений «Документы к проведению», что такие-то рейсы, такие-то заказы надо потом допровести.
- И потом, спустя несколько часов, когда нагрузки на систему нет, стартует фоновое задание, которое пробегает этот регистр, смотрит эти рейсы, эти заказы, которые надо обработать, и допроводит их.
По сути, мы реализовали отложенное проведение. Ничего нового здесь нет, эта идея уже много лет работает и в УТ 10-ой редакции, и в УПП.
Иногда внедренцы забывают, что подобные проблемы можно решить таким нехитрым приемом. Но мы в очередной раз решили проблемы с ожиданиями и с тем, что 1С «тупит» и «тормозит», и сделали это достаточно быстро.
Кейс 3. Создание и проведение реализаций
Третья проблема, которую мы решали у себя подобным подходом – это проблема непосредственно в нашей офисной базе УТ.
Пока мы работали на складе, делали жизнь складских работников прекрасной и удивительной, в нашей офисной УТ тоже возникли проблемы, и наши 1С-специалисты в офисе, которые отвечают за УТ, попросили нас разобраться, что же происходит у них.
Мы увидели, что в офисе тоже почему-то возникает своя суточная сезонность – определенное временное окно в начале смены (порядка двух-трех часов), когда продажники регистрируют основную массу заказов.
Телемаркетологи, продажники, менеджеры по продажам звонят клиентам, общаются с ними и вносят заказы. Система в это время начинает жутко «тормозить», вплоть до того, что не формируются отчеты.
Процесс оформления заказов у нас достаточно несложный, его можно увидеть на слайде.
- В УТ продажник оформляет документ «Заказ», с помощью подбора подбирает свободные остатки, и проводит документ.
- При проведении заказа система проверяет, хватает ли свободных остатков, нет ли долгов по дебиторке, все ли условия по оплате выполнены. И, если все хорошо, заказ проводится. Если заказ проведен, то значит, товара клиенту хватит.
- Далее продажник переводит в статус «К отгрузке», вводит на его основании:
- реализацию;
- счет-фактуру;
- наш служебный документ «Распоряжение на склад», который с помощью обменов потом летит к нам в WMS.
Все эти операции, особенно оформление реализации, самому продажнику не нужны. Он уже сделал все, что нужно, чтобы принять заказ – если заказ провелся, то реализация не провестись не может. Она может не провестись только по каким-то техническим проблемам, которые не касаются этого заказа.
Поэтому все эти действия для продажника были, с одной стороны, лишними, просто их кто-то должен был делать. Но, с другой стороны, все проблемы возникали как раз при проведении реализации. Точнее, проблемы были из-за того, что несколько продажников одновременно параллельно проводили реализации, и из-за этого возникали блокировки.
Мы посмотрели на эту проблему и решили сделать так, чтобы реализации создавались и проводились в отдельном потоке фоновым заданием.
Работа продажника сейчас выглядит следующим образом:
- Он оформляет заказ, и если тот проводится, он переводит его в статус «К отгрузке». На этом работа продажника заканчивается. Он переходит к следующему клиенту. Никакие документы он больше не регистрирует.
- При этом, в системе в соответствующий регистр сведений пишется, что появился заказ, по которому надо бы создать реализацию.
- И раз в несколько минут регламентное задание проверяет, есть ли что-то в этом регистре, и если есть, то оно начинает по этим заказам создавать реализации и делает это «в один поток».
Никакой конкуренции за ресурсы между несколькими сеансами не происходит. Реализация создается немного с запозданием, но это не критично. Пользователи оформили заказ и стали работать со следующим клиентом. Реализация все равно через несколько минут будет создана, и все другие задачи будут выполнены.
Результат в данном случае тоже был похожий:
- Мы решили проблему ожидания на блокировках.
- Пропускная способность УТ в этот период увеличилась.
- Пользователи сменили «гнев на милость».
Главное, что с того момента, как у них все «накипело», и они по управленческой структуре дошли до верха, сказали нам: «Сделайте что-нибудь, вы же 1С-ники, вы же программисты», прошло достаточно мало времени до того, как мы поняли, в чем проблема, и решили ее – проверили, протестировали.
Итоги
Подведу небольшой итог.
Если у вас возникают подобные проблемы, но нет возможности делать оптимизацию, а результат хочется получить быстрее и меньшей кровью, посмотрите:
- Возможно, вы сможете перенести эти операции на другое время, чтобы они выполнялись, когда система не будет сильно нагружена;
- Может вам удастся организовать для этих операций один поток, чтобы исключить причину блокировок.
- Конечно, купить железо за 1000 долларов – это более правильно, но нам надо получить результат быстрее и с максимальным эффектом. Если логика при этом не пострадает, то почему бы и нет.
*******************
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 COMMUNITY. Больше статей можно прочитать здесь.
В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
по учебнику нужно сначала избегать иррациональной «работы», результат которой не востребован полностью или частично, а не пытаться все подряд ускорить
как бы вы хорошо не ускорили ненужную работу, она все равно зря..
(1) Как раз подобное вчера у Лукьяненко прочитал))
— Позиция лентяя, — восхищённо сказал я. — Уважаю!
— Это чистая логика! — возмутился Михаил. — Приступив к ненужной работе, очень трудно понять её ненужность. В итоге больше времени тратится на выполнение излишних действий, чем на выработку правильного регламента работ.
— Логичная лень! — Я всплеснул руками, вскочил из-за стола. — Михаил, ты придал моей жизни новый смысл. Давай думать.
Хорошие кейсы оптимизации, использующие фоновые (отложенные) процессы. И да, это, всё таки, оптимизация алгоритмов 😉
Нужно не брать типовую УТ 11 и героически оптимизировать неоптимизируемое 🙂 А написать конфу под себя. Вы просто не будете знать про эти проблемы никогда. 4000 строк в день — да это детсад просто.
(4) И сколько месяцев Вы будете писать такую конфу, оптимизированный под себя аналог УТ 11?
(5)
Годика два точно )
Вы, конечно, молодцы, спору нет. Но проблема не в 1С, а в несоответствующей вашим объемам WMS системе.
(6) Ага, а компания все это время будет сидеть и ждать релиза 😉
Отличная статья!
Раньше думал, что отложенное проведение — это перенос нагрузки на железо на другое время, например, ночью мощности простаивают.
Очень важная мысль, что при отложенном проведении решается проблема с блокировками таблиц.
(2)Что за книга? не узнаю фрагмент))
(10) Кваzи
2005 год. Известный ритейл. Те же действия на SAP.
Ежедневно 10000 заказов, в пике(праздники) 15000 заказов. 8 веб серверов для приема заказов, 200 магазинов. Всего строк в день 80000-130000.
Задача похожая на описанные в статье выполнялась в 23.00. Система закрывалась для приема заказов и начинала формировать задачи для комплектовщиков (400 комплектовщиков в смене).
Полное закрытие заказов и формирование всех задач занимало 20-30 минут. Никаких конфликтов блокировок.
Оборудование 2005 года, даже с учетом, что этот ритейл покрупнее, схожее или может даже слабее чем у автора.
Это информация — не в укор автору, а чтобы оценить способности SAP в сравнении с 1с.
(12) Я такое на 1С (не в типовой конфе, конечно) видел, тоже никаких блокировок. И что?
(12) вы бы ещё сравнили с Amazon или Alibaba, интересно сколько там стоит информационная система
(14) Для полноты картины. Заурядная группа разработки Sap из 3 аваперов и двух системных администраторов. Никаких привлеченных специалистов. И обратите внимание на год оборудования.
(15) Стоимость лицензий и стоимость годового обслуживания приведите, для полноты картины.
(16) Это любимый аргумент. Чуть выше в третьем пункте есть Сергей Носков. Спросите у него, что для бизнеса важнее: Оценка стоимости лицензии или работоспособность 5000 человек? Конечно мы говорим не о ларьках или маленьких магазинах.
(12) Видимо там код оптимальный.
Если в те же функции вложить те же деньги и на 1С будет быстро и красиво
Стандартный подход в системах реального времени размазывать пиковую нагрузку во времени.
(17) Так почему вы программист 1С, а не авапер?
(17) Надо считать общую стоимость достижения результата. В платформе 1С нет технологических ограничений, не позволяющих достичь (и превысить) производительность SAP.
(20) Серьезное возражение в сравнении двух систем. :)) Нечем крыть. :))
(1) практические рекомендации или примеры из жизни можете написать? для полноты картины 🙂
(0) молодцы! и спасибо за статью!
(4)
Героически написать свою конфу. Пытаться догнать по функциональности обновления типовой. Клепать костыли на костыль. Устать от всего этого. Набраться опыта и свалить с конторы, отставив их на поиски дорогого сумасшедшего кто это все будет поддерживать и допиливать.
(5) Сколько писать, это только один из вопросов. Сколько они будут отлаживать уже введённую в эксплуатацию конфигу?
(12) как оценивать-то?
в 1с переход на отложенное проведение происходит собственными силами, а не силами вендора, некоторые оптимизаторы даже осторожно делятся опытом, что это «хороший способ»… но это капля в море в мире 1с — каждая группа разработчиков так и будет придумывать велосипед…
Ох, я такое лет 8 назад делал в УПП еще 1.2. Сейчас рулят очереди типа Kafka и прочий DevOps. Но уже хорошо, что кто-то снова додумался в фон скидывать обработку данных. И если в отгрузке были ошибки, то часики нужно менять на красный восклицательный знак, чтобы пользователь не нервничал на тему того, ушел у него заказ или нет — путь сразу видит, если есть проблемы.
(19) стандартный подход — подходит для стандартных процессов. остатки нужно видеть оперативно — списание остатков необходимо проводить в момент проведения реализации. списание по фифо — не обязательно в момент — можно отложить. я так думаю.
(28) Очереди для обмена сообщениями внутри одной базы 1С? Зачем?
(25) Расскажите об этом Деловым Линиям :))
(31) Списание каких остатков? Свободных, в резерве? Если в резерве, то почему бы и не отложено?
Мне кажется или на инвентаризации наступит капец?
(36) Деловые Линии это здоровая корпорация, которая может себе позволить содержать большой штат разработчиков и вкладывать в разработку нового ПО немалые средства, совсем другое дело это малый и средний бизнес, не совсем корректное сравнение.
О, то был фееричный доклад. Мы не умеем оптимизировать, поэтому делаем костыли. Делайте как, мы, делайте лучше нас )))
(39) Если мы сравниваем 1С и SAP, то почему некорректное?
(40) Причём, в первую очередь, надо оптимизировать бизнес-процессы…
(12)
еще бы, с данными в это время никто не работал, откуда взяться блокировкам?
и что там делалось если поступал заказ в 23:05?
да и конечно неплохо бы сравнить железо, на котором это все крутилось у автора и у вас.
(41) Я написал про сравнение разработки ПО на 1С в средней компании и в большой корпорации типа «Деловые линии», речь выше шла о разработке конкретно на 1С (про написание компанией своей конфы с нуля), а не про сравнение двух платформ.
(37) А разве резерв не влияет на свободный (доступный) остаток на складе?
(45) Если при проведении реализации товар уже поставлен в резерв (заказом, например), то совсем не обязательно списывать остатки со склада в реальном времени.
(44) Если взять среднюю компанию, как у ТС, то с нуля писать скорее всего не стоит. Но, если заниматься оптимизацией, по итогу скорее всего всё равно получится вусмерть препаханная типовая.
(40) Почему Вы считаете что использование отложенного проведения и фоновых заданий является костылем?
(49) Тут больше о том, что все эти способы широко известны, и статья ничего нового не открывает. С чем можно отчасти согласиться, конечно.
(42) В статье же речь идет о технических средствах оптимизации за счет использования фоновых заданий, а не за счет оптимизации бизнес-процессов (на что возможно у айтишника нет возможности повлиять)
(50) То что не нова понятно, но это же не означает что это костыль, разве не так?
(52) Костыль в том смысле, что проблема на самом деле не решена, а просто скрыта чуть глубже.
(51) Ну да, сделали, что могли, молодцы.
(51) Я просто был на докладе, и автор очень зажигательно говорил, мол, ну да, мы не умеем оптимизировать, но жить-то надо. Почти прямые цитаты. Именно это и было весело.
(12) А я могу контр-аргумент привести, когда нам заменятели 1С на САП говорили, что загрузят нашу номенклатуру в САП за месяц. Чтобы вы понимали: они поставят нам сервера, для наращения мощности и тогда, точно-точно успеют загрузить нашу номенклатуру в САП за месяц работы всех серверов 24/7. Одна номенклатура заводится в САП примерно 10 секунд. Одна запись товарной карточки. В среднем 5 карточек в минуту. Оборудование 2016 года, жрущие электричество числодробильные монстры. Историй САП vs 1С — сотни. И далеко не все в пользу САП.
Это информация, как раз в укор автору. «способности сап по сравнению с 1С» — ничтожны. САП не быстрее 1С. Если не говнокодить, то 1С технологически не медленнее сапа. Может для крупных заводов тяжелой промышленности САП лучше, не знаю. Но для сетевой торговли то, что предлагается консультантами САП и выдается за конфетку — ну… оно действительно по цвету похоже на шоколад, да. А вот если принюхаться…
По юзабилити — САП не стоял даже рядом. Посмотрите доклад Олега Филиппова двухлетней давности. Там далеко не все, но понять общую картину можно. Убогий синенький интерфейс, который продается как панацея для бизнеса. Как только не стыдно сие впаривать с честными лицами, даже не пойму.
(53) Ускорить процесс в том месте, где он тормозит, это не решение проблемы, пускай и частично (только определенными техническими инструментами)?
(57) Решение, почему нет. В рамках своих возможностей. Но, для тех, кто занимается реальной оптимизацией, это может выглядеть как костыль :))
Если товара всегда много, конкуренции и дефицита нет, имеет место замораживание оборотных средств. При первом же появлении дефицита первые заказчики забирают весь остаток. Фоновое задание не умеет урезать заказы и перераспределять при создании реализаций объемы пропорционально потребностям или заказам. Я за то, чтобы вместо фонового задания был один человек.
(59) А вот это уже совсем другая история, про бизнес-процессы.
(56)Андрей, я уважаю тебя как специалиста, но чувствуется, что ты никогда не работал с SAP. Увы как и Олег. Это как оценивать машину по цвету коврика. По производительности на больших объемах SAP превосходит 1с. Сколько потребовалось усилий деловым линиям чтобы запустить свою систему с нормальной производительностью? При этом пришлось подключать еще и 1с. Думаешь при каждом внедрении SAP все зовут немцев на помощь? 🙂
Обычные формы. Фии…
Надо бы в типовой на замке, с расширением и в облаке.
(61) Спасибо за уважение. Я видел несколько неуспешных внедрений САП изнутри. Внедрений, на которых бабло и ложь побеждали здравый смысл. Однако, я допускаю, что успешные внедрения есть и люди счастливы. Мой персональный опыт общения с САП — негативный, о нем и пишу. Кроме того, подрядчики и клиенты, которые используют САП, при настройке интеграции всегда просят обменятся Excel-файлами, т.к. настроить API — дороже на их стороне. Почему и отчего дороже — это не ко мне вопрос, но заинтегрироваться с САП часто сложнее. Опять же — это личный опыт, я допускаю, что так не везде.
Все это насколько знакомо, настолько и уныло. =) И пользователи, и те кто их обслуживает становятся заложниками принятых когда-то решений: выбранные основная учетная система и WMS, и механизмы их взаимодействия. Некоторые решения даже знакомы, сами через это прошли. Но, если по честному, то:
— На адекватном оборудовании такого быть не должно. Это скорее похоже на поведение файловой УТ-ки. У вас же не файловая УТ-ка? ) Далее, вы пишите про конкуренцию при создании рейсов. Бог мой, да у вас от силы 20 рейсов в сутки в сезон, какая конкуренция? Видимо, есть какие-то нюансы, завязанные на wms. Временное окно в 1 час на обработку рейсов и передачу их складу, на мой взгляд, слишком мало. Ну да ладно, решили проблему и заработало, значит все сделано правильно.
(33) база одна — процессов много.
(36)
А вот не надо тут поминать в суе))) ДЛ начал конфу писать еще на 7.7 и никаких типовых по бизнес процессу перевозки грузов не было.
И ДЛ использует и БП и ЗУП, с доработками конечно, но никто их с нуля не писал.
(49)
Масштабировать не получится. Временное окно не резиновое.
Разнесли бы резервирование и запись/проведение. Резервирование вне транзакции и отдельно по каждому товару, а уж потом док проводить с тяжелыми движениями. Задним числом перепровели док? Ну, партионный учет по резервам и его восстановление.
В соседнем топике где-то менеджер потоков есть — прекрасная штука, даж думать ненадо, только массив ресурсов правильно сформировать 🙂
(61)
На момент подключения 1С всё отлично работало. Все проекты ДЛ с 1С были связаны с переходом на новую платформу (сначала на 8.2, потом на 8.3) и абсолютное большинство ошибок было в плоскости работы платформы. Ну и думаю Вы в курсе, что речь не про 10’000 заказов в сутки, а в 100 раз больше. Поэтому сравнение с ДЛ не корректно.
Все разговоры SAP vs 1С достаточно бессмысленны. У SAP сильная сторона — стабильность платформы, изначальная ориентированность на масштабируемость. Скудность интерфейса, контроль над выполняемыми запросами ему как раз и помогают. Основной принцип «главное работа, а не рюшечки». К тому же SAP очень любят «внедрять» для повышения капитализации, и тут принцип «чем дороже тем лучше» явно не в пользу 1С.
1С идет по пути «дадим пользователям максимальную свободу» (собственно и конфигуратор изначально задумывался именно для пользователя), поэтому «из коробки» тонкий и web клиент, динамические списки, поиск, сортировка и отборы в формах списков по любой колонке, отчеты с гибкими настройками. Из минусов — у 1С много вопросов к самой платформе.
(66) И? Какие преимущества у внешних очередей для взаимодействия процессов внутри одной базы?
А можно было вызвать специалиста тыщ за 20.
Это меньше зарплаты помошника кладовщика
(67) Про БП и ЗУП понятно, но вот сейчас, какую бы вы типовую взяли под перевозку грузов?
(69) А как вы думаете, будет 1С ещё сильнее разделять платформы Проф и Корп?
(72) честно говоря не изучал
C wms у них там явно не то. Возможно с архитектурой Кортеса. Одна из самых нагрузочных задач это планирование отборов (резервирование товаров по ячейкам под заказ). Делать это в онлайн—режиме оператором это вообще полный беспредел, допустимый для мелкого склада с невысокой нагрузкой.
Ну и планировать что-то целиком подокументно — тоже бяка тотальная. Потому возможно и напарывались на блокировки.
В том то и дело аналог не нужен! А нужно заточенное под ваш бизнес процесс программное средство. Иногда конечно можно взять некоторые наработки из стандартных конфигураций.
Напишите ваше сообщение
(6)
У нас заняло 4 месяца создания и 2 месяца тестовой эксплуатации. (Оптово-розничный магазин-филиал с негарантированной связью GPRS).
Напишите ваше сообщение
(8)Почему ждать? Компания уже работает и в процессе работы для себя решает куда и как направить ресурсы на создание новых/исправление старых бизнес процессов… иногда переделка стандартной конфигурацией может стать дороже чем написание своей конфигурации с нуля.
Есть и плюсы и минусы в собственной кофигурации.
Плюсов много.
+ Вносить изменения в собственную конфигурацию и проще, да и приходится это делать ГОРАЗДО реже.
+ Она не имеет, как стандартная конфигурация, кучи лишних данных/возможностей, которые вы никогда не используете в силу специфики ваших бизнес процессов. Например: учет себестоимости у вас всегда ведется по среднескользящей стоимости и необходимости в партийных регистрах отсутствует.
+Она может быть остро заточена под ваш бизнес процесс, где квалификация сотрудников, работающих на ней может быть сильно снижена. Например: мы, создавая конфигурацию для курительного клуба, смогли полностью отказаться от такого понятия ка «последовательность», все документы специализированные под нужды компании, потому что в клубе запрещено говорить слова «продажа», а все продажи товаров в клубе клиентам, должна была отражаться не как продажа, а как затраты на нужды клуба с учетом того кто, сколько потратил.
+ Кто-то говорил «вы никогда не догоните типовую», смею утверждать, если у вас сильные методисты, вы не только догоните, но и быстро обгоните стандартные возможности 1С. Например, заполнение/проверка контрагентов по ИНН, у нас было написано в 1С 7.7, когда 1С еще маялась с бухгалтерией 2.5. Некоторые вещи, которые реализовывала команда, в которой я работал, 1С только еще только «раскуриват». Я пишу про это статьи кстати ;).
+ И при выходе очередного обновления 1С у вас не летит все к чертям, а очередное обновление превращается в перенаписание ваших изменений конфигурации заново.
Все эти преимущества можно получить при сильной команде 1С программистов и МЕТОДИСТОВ компании.
Минусов тоже не мало:
— Если вдруг увольняются ведущие специалисты по вашей самописной конфигурации, она «превращается в отраслевую типовую» для вновь пришедших программистов 1С, пока не въедут.
— Сложные задачи, как ведение зарплаты или регламентная отчетность с выгрузками в налоговую пока решаются только типовыми решениями, поскольку наше законодательство слишком часто меняется.
(12)Это проблема не платформы в организации данных.
На 1С 7.7+SQL7.0(3GB) решали задачу по снижению времени на проведение документов по конкурентному резервированию и выписки документов реализации не более 1 сек.
На 8.3 ЕРП к таким скоростям даже приблизится не можем, несмотря на севера с памятью, многократно превышающей размеры баз.
Просто в современных продуктах 1С слишком много вспомогательных/не нужных регистров.
Напишите ваше сообщение
(70)
Поскольку взаимодействие процессов в типовой конфигурации не самое эффективное, самый оптимальный способ не править все, а прикрутить сверху собственных процесс, которые делает работу более оптимальным.
Даже стандартное решение от 1С «отложенное проведение» постоянно компенсирует мозги отделу ИТ.
Почитайте книгу Голдратт «Цель».
В ней суть повышения производительности производства (без замены оборудования) сводилось как раз в аналогичный «фоновый процесс»-очередь на самом медленном участке. Там так же, как у автора статьи, общую производительность производства увеличили за счет заполнения работай самого медленного участка производства по времени.
Только согласно этой книге, автору статьи, делая очередь из заказов, нужно давать им метку по приоритету, и выполнять очередь согласно этих меток. Если скорость разбора в фоновой задаче заказов не велика, и образуется достаточно длинная очередь (буфер), необходимо иногда пропускать на выполнение заявки с более низким приоритетом, как это делает процессор intel с приоритетами потоков.
(78) На чем первоначально будет работать только что открытая компания? Кроме как взять за относительно небольшие деньги типовую конфу и допиливать ее под свои процессы альтернативных вариантов особо не вижу.
В том то и дело, что иногда, купить типовую конфу куда менее рискованнее и менее трудозатратно, чем писать с нуля, подумайте еще о том, кто в дальнейшем будет ее поддерживать (и не кривые ли руки у создателя самописки).
Согласен. Если вы начинаете путь в бизнесе, ваш путь через типовые конфигурации. Легче ваши бизнес процессы привести к стандартам 1С, чем наоборот.
Но если вы большая компания со штатом методистов и «1с-ников», то создавая новый бизнес проект у вас есть выбор, исправлять стандартную конфигурацию или писать свою.
Немного отвлекусь от 1С с конкретным личным примером.
В этом году, запуская сеть табачных магазинов, пришли к выводу, что POS система АТОЛ не решает некоторые, жизненно важные задачи. Было принято решение разработать свою POS систему, работающая автономно под linux с real-time ретрансляцией событий в WEB + масштабный обмен 1С (вплоть до создание табелей на продавцов) и встроенными элементами EDI. Это позволяет решать наши задачи так, как надо нашему бизнесу, а не так, как задумала компания, производящая POS системы для широкого круга лиц.
Еще одно отступление:
Стандартная конфигурация ERP2.1 как показала практика не пригодна к эксплуатации из «коробки», да она и не продается без услуг по внедрению.
(81) Я имел в виду другие бизнес-процессы — например, переход на EDI вместо ручного вколачивания заказов операторами…
Система явно не для высокооборачиваемых складов.
Для быстрого выхода из ситуации описанный вариант неплохой.
(79)
Вы забыли про регламентированную отчетность. Все что вы напишите сами — это сугубо заточенное решение под ваш конкретный бизнес, но нужно потом все это еще стыковать хотя бы со стандартной БП для ведения Бух. учета.
(9)
(9) Очень помогает отложенное проведение в производстве, например , что бы списывать материалы не в режиме реального времени.
(73) предполагаю, что будут сильнее делать упор на корпоративную поддержку и стараться больше её продавать. Будут ли делить платформу — сказать сложно, использовать возможности, даваемые КОРП лицензией, до сих пор доступны всем. Если их заблокировать сейчас — уже будет негатив, а если продолжать тянуть с блокировкой — негатива будет еще больше.
(89) Да, было бы интересно посмотреть статистику, сколько и каких предприятий используют КОРП лицензии. Но, я думаю, в открытом доступе такого не найти…
(87)
Вы правы. Только, я не забыл написать об этом в последнем абзаце (79). 😉
В отпуске бронировал номер в одном пансионате .
Они там еще в 10 раз ускорили :
1. Только одна секретарша занимается только резервированием, к слову в другом городе
2. Если кому то из менеджеров нужно зарезервировать — звонят этой секретарше.
И никаких блокировок
(25)ага, приходит новый сумасшедший(дорогой или нет это зависит от финансовых возможностей компании), клепает новые костыли, плюёт, уходит… Приходит новый… В результате получается нечто монструозно — накостыленое, вечно ждущее доработок, с пользователями, которые привыкли делать как есть, вместо того, чтобы делать как надо…
(84)
Интересно, а на чем писали POS систему под linux?
(92) Ещё прикольный вариант, разрешить проведение только одного документа одновременно,
Придумать глобальный семафор какой нибудь, и проводить документ если никто не проводит сейчас,
иначе пользователю сообщение «Подождите 5сек, идет проведение другого документа».
Если без блокировок документ проводится быстро, то же может помочь, и даже не сильно тормозить работу 🙂
(83) у боле менее динамичной компании через какое то количество лет типовая конфигурация превращается в «самописку».
Получается в пределе нет разницы «типовая» или «самописка», важна квалификация тех кто дорабатывает/разрабатывает конфигурацию.
p.s.
Гипотетически, если бы 1с поддерживала и продавала функциональный аналог 1С 7.7 ТиС но на 8 платформе, у которой по нынешним меркам простая конфигурация без наворотов,
легко дописываемая под нужды бизнеса, был бы не неё спрос?
Не от 1С конфигурация то есть () , но ктож рискнет её использовать как бы без поддержки 🙂
(95)
Так весь 1С на этом базируется. Если помножь «почти монопольное» проведение документа на время проведения (в последних релизах тут отрицательная тенденция наблюдается) … и вот, у тебя блокировки из за очереди проведения.
Автор предлагает решать задачу «кто пролезет в очередь» не самому пользователю (тыкая кнопку «провести» и ждать удачную попытку), а автоматической фоновой системе.
(92)Ну это вообще колхоз, давайте ещё на бумажку записывать ))
Отложенное проведение отличная идея, вот только если остатков кому-то не хватит, то узнает он об этом не сразу
(4) уже три года работаю на самописной конфе. И все три года упорно из нее получается ут 10.3
(23) могу, в компании значительная текучка кадров
при увольнении каждого отдельного сотрудника выполнялось действие заполнить документ начислений (по зарплате)
и в документ попадали все сотрудники компании с расчетом
затем все записи сотрудников удалились и оставалась только одна запись по увольняемому
компания жалуется на долгое заполнение
пример понятен?
(5) в вашем примере надо использовать УТ 11 как базовый набор таблиц. Далее создать свои интерфейсы и меню, свои регистры накопления и свои алгоритмы заполнения и их использования, свои отчеты. При этом справочники, документы, большинство регистров остаются типовыми. Добавьте свою функциональность, к примеру напишите свой расчет себестоимости или резервирования по заказам. Не нужно с нуля писать конфу, если можно уже использовать то , что есть. Это и называется написать конфу под себя. В некоторых случаях можно и с нуля. Зачем ставить минус комменту (4), который действительно подсказывает в каком направлении двигаться.
(101) понятен
(102) Чтобы компании запустить новый бизнес необходимо уже готовое решение, которым можно начать пользоваться как можно быстрее и постепенно допиливать под себя в процессе развития компании (в том числе и оптимизировать уже имеющиеся алгоритмы приобретенного решения), в комменте (4), на сколько я понял, было предложено не брать УТ 11 и «пилить» ее, а написать что-то свое с нуля (УТ 11 в любом случае рано или поздно будет допилена).