В апреле 2012 завершился сложный проект комплексной автоматизации в компании «Световые технологии». Проект начался в конце мая 2011, с 10 января все уже работали в новой базе, полностью отказавшись от старых систем. Функциональные требования у клиента были очень высокие, что не сочеталась со сроками начала эксплуатации, которые планировались по проекту. До нас заказчик уже начинал сотрудничать с двумя компаниями, которые после экспресс- обследования отказались от проекта. Для нашей команды (http://делаемпроекты.рф/) это был профессиональный вызов.
В результате проекта типовая конфигурация, взятая за основу, была переработана процентов на 40. Все реализовано в 1С:УПП на РАУЗе и интегрированной в нее конфигурации БИТ:Финанс. Конструкторская и технологическая документация ведется в 1С:PDM, между которой настроен автоматический обмен с 1С:УПП. В базе одновременно работает около 650 пользователей. Около 300 внутренних, остальные ключевые клиенты. Клиенты физически работают в базе через web- интерфейс, реализованный на управляемых формах.
Максимальное количество одновременно работающих специалистов с нашей стороны на проекте 23, количество сотрудников, принявших участие в проекте 32.
Описание того, что сделано http://делаемпроекты.рф/project/6/
Пресс релиз по проекту http://v8.1c.ru/news/newsAbout.jsp?id=8273
В текущей статье я рассмотрю наиболее интересные (самый минимум) на мой взгляд функциональные решения по участкам учета:
- Управление заказами
- Управление оперативным производством
- Учет затрат (РАУЗ)
- Сервисные функции
Блок «Управление заказами»
В блоке переработаны основные документы корректировок. В отличие от типовых, все корректировки производятся в одной строке, что значительно удобнее и нагляднее. Нет необходимости вводить две строки, одну сторно, вторую — с тем, что должно получиться.
В корректировках все старые реквизиты начинаются со слова «Старое/ый» или буквы «(С)». Если значение в старой колонке не равно значению в новой, то при проведении документа выполняются корректирующие движения. Сторно старых значений и приход новых.
Блок «Производство»
Блок был значительно переработан, добавлено много новых документов, обработок и отчетов. Из наиболее ключевых объектов в блоке можно выделить:
1. Документ «План производства» (типовой).
Добавлены сервисные функции автоматического заполнения табличной части по правилам MRP II (новый реализованный механизм).
2. Документ «Корректировка планов производства» (новый).
Используется для актуализации планов производства.
3. Документ «План производства по дням недели» (новый).
Используется для распределения плана производства по участкам в разрезе дней недели и автоматического формирования заказов на производство (сменно суточные задания) на каждый день для каждого участка. При формировании заказов на производство система автоматически «разузловывает» продукцию до сырья сверху вниз (от продукции до сырья) и проверяет наличие свободных остатков материалов и полуфабрикатов на складах, кратностью партии, датой запуска и прочей информацией для производства продукции. Сменно суточные задания формируются на полуфабрикаты только в том случае, если их нет на складах или это явно указано в документе. Из документа есть возможность скорректировать сменно суточные задания. Корректировка выпуска при полуфабрикатном методе очень сложная задача, т.к. при изменении на любом уровне передела, нужно откорректировать все связанные данные (как сверху, так и снизу).
4. Документ «Заказ на производство» (типовой).
Добавлена возможность указывать технологию производства, которая контролируется на этапе корректировок и выпуска продукции. Такой же контроль ведется по дате выпуска и спецификациям. Если изменяется дата выпуска продукции, то необходимо делать корректировку, чтобы перенести срок выпуска на новую дату. Такой подход позволяет оперативно получать информацию, к какому сроку сколько будет выпущено продукции.
5. Документ «Корректировка заказа на производства» (типовой).
В документе добавлены сервисные функции и возможность корректировать заказы на производство с учетом технологии производства.
6. Документ «Разрешенная замена».
Используется конструкторским и технологическим отделами для определения в рамках выпускаемой продукции возможных вариантов замен комплектующих ее аналогами. Эта информация используется в дальнейшем, чтобы, не вовлекая в процесс конструкторский и технологический отдел, запускать продукцию в производство. Если продукцию невозможно выпустить по заявленной спецификации в связи с отсутствием комплектующих, но в наличии есть их аналоги.
7. Документ «Карта замены».
Используется, когда продукцию нельзя выпустить по заказу на производство согласно указанной технологии и спецификации. Документом отражается заявка на выпуск продукции в необходимом количестве по альтернативной спецификации и технологии. Новые позиции (аналоги) отображаются красным фоном.
8. Документ «Отчет производства за смену» (типовой).
Добавлена возможность контроля выпуска продукции с учетом технологии производства, указанной в заказе на производство.
Когда по заказу на производство невозможно отразить выпуск по заявленной технологии (сломался станок) или спецификации (нет основного сырья), данные берутся из «Карт замен», сформированных ранее. Таким образом, исключается пересортица, когда выпуск проходит по спецификации, материалов по которой не хватает.
Нередко возникает ситуация, когда материалы, распределенные на выпуск продукции по спецификации, не соответствует тому, что позже списывается по факту. Именно для этих целей в документе реализована закладка «Отклонения (СТ)». На ней указывается номенклатура, которая была ошибочно распределена на выпуск продукции и правильная номенклатура с количеством. При проведении документа информация на закладке «Распределение материалов на выпуск» заменяется на информацию с закладки «Отклонения». В результате на закладке «Материалы» содержится информация по спецификациям, а на закладке «Распределение материалов» информация по факту. При необходимости эту информацию можно использовать для формирования отчетов по план-факту.
Блок «Учет затрат (РАУЗ)»
Блок был значительно переработан в части управленческого учета. В большинство типовых документов системы были добавлены счета управленческого учета с их аналитиками по аналогии с бухгалтерским учетом. Для управленческого учета используется собственный справочник по статьям затрат (статьи оборотов). В типовом решении этот справочник общий для управленческого и регламентированного учета, что нередко вызывает вопросы, когда управляющий персонал хочет видеть отличную структуру себестоимости от регламентированного учета. Нескольким статьям затрат в регламентированном учете (отдельная статья по каждому характеру затрат) соответствует одна статья затрат в управленческом учете, характер статьи оборотов регулируется счетом управленческого учета.
Доработаны механизмы расчета себестоимости и распределения затрат. Добавлены собственные документы по определению финансовых результатов.
В механизмы расчета себестоимости в дополнение к типовым аналитикам были добавлены:
- Организация,
- Счет управленческого учета,
- Статья оборотов (взамен справочника «Статьи затрат»),
- Аналитика 3-го уровня (произвольная аналитика для учета затрат).
Регистры по учету затрат, которые были модифицированы:
Пример документа с добавленной аналитикой по управленческому учету, используемой при отражении по регистрам затрат:
В документе «Поступление товаров и услуг» добавлена возможность относить стоимость услуг на себестоимость товаров без ввода дополнительного документа «Поступление доп. расходов», что требуется в типовом функционале:
В документе «Получение услуг по переработке» добавлена возможность распределять стоимость услуги на выпущенную продукцию переработчиком сразу при проведении документа. В типовом функционале для этих целей используется отдельный документ «Распределение прочих затрат».
Реализованы механизмы по расчету плановой себестоимости продукции с «разузлованием»:
Блок «Сервисные функции»
Реализован механизм запрета редактирования документов по видам. В отличие от типового механизма, где дата запрета действует на все, в текущем механизме для каждого вида документа перечисляются пользователи, которым разрешено изменять данный вид документа, начиная с указанной даты. Всем остальным данный вид документа изменять запрещено.
Закрыть период теперь можно одной кнопкой. Для этого достаточно запустить обработку, которая за указанный период по каждой отмеченной организации создаст все регламентированные документы в нужной последовательности и выполнит все необходимые процедуры (к примеру, восстановление последовательности расчетов и прочие).
Следующая обработка за указанный период меняет во всех документах по выбранному виду номенклатуры или номенклатуре счета учета УУ, БУ, НУ.
В текущей статье я изложил очень малую функциональную часть от всего что было реализовано на проекте. За кадром остаются многие вопросы, потому как техническая сторона на проекте не самая большая. На мой взгляд, одна из интересных тем «Управление проектом». После нового года планирую посвятить этому отдельную статью, в которой опишу практический опыт по данному проекту. Теорию писать не вижу смысла, ее и так много, а вот как на реальном большом проекте собирали команду, по какой технологии запускали проект (использовали элементы Agile), как организовывали команду внутри, взаимодействовали с командой Заказчика и с какими сложностями сталкивались, вот это должно быть интересно.
Готов рассмотреть Ваши вопросы по тому что изложено, может на чем-то нужно остановиться более подробно.
Жду Ваших предложений, чтобы определить круг интересов аудитории.
—————————————-
С уважением, Антон Щекачев
Технический руководитель проекта
Офис «м. Савеловская» (Москва) — http://делаемпроекты.рф/
Компания «Первый БИТ» (1С:Бухучет и Торговля)
От себя добавлю частично новую информацию, что:
Проект вошел в ТОП-30 крупнейших проектов на 1С:Предприятии (
Проект номинирован на премию «Проект года» сообщества Global CIO.
Вступить в сообщество можно здесь (.
Проголосовать за наш проект можно здесь (
(2) Alraune, да можно, причем режим работы конфигурации РАУЗ или партионный учет (ПУ) значения не имеет.
Для того, чтобы рассчитать себестоимость по заказам на производство, нужно во всех документах по отражению затрат явно указывать к какому заказу на производство относится затрата.
К примеру, Вы хотите посчитать себестоимость в разрезе заказов на производство и отражаете затраты через документы:
1. Поступление товаров и услуг
2. Прочие затраты
3. Требование накладная
4. и т.д.
В этом случае во всех этих документах нужно явно указывать заказ на производство к которому относится затрата.
Если к примеру, сумму в 1 000 руб нужно разделить между заказами №1 и №2, то нужно заносить две строки, одну на 150 руб. по заказу №1, другую на 850 руб. по заказу №2 или в другой пропорции.
Если Вы хотите сумму затрат распределить между всеми заказами на производство в разрезе которых отражали выпуск в течение месяца, то заказ на производство можно не указывать в документах при отражении затрат.
Далее, если у Вас был выпуск продукции по заказам на производство и затраты были собраны в разрезе этих заказов, то документ расчет себестоимости выпуска (РСВ) распределит по заданной базе распределения эти затраты в разрезе заказов, если затраты были собраны без заказов, то РСВ распределит их на все выпуски по всем заказам на производство.
Тут простое правило, если заказ на производство указан, то все затраты распределяются в рамках указанных заказов, если заказ при регистрации затрат не указан, то все затраты распределяются на выпуски которые отражались с использованием заказа на производство в качестве аналитики затрат.
Аналитика затрат при выпуске продукции документом «Отчет производства за смену» (ОПЗС) указывается на закладке «Продукция» в колонке «Заказ затраты». Для того, чтобы эта колонка появилась нужно в ОПЗС по кнопке «Настройка» установить флажок «Использовать заказы».
по первому глазу плюса
но таки не видно 20 человек 12 месяцев…
что оставили за кадром?
Вопрос по формированию заказов через веб-приложение. У вас как я предполагаю реализовано через https есть ли подвисания при работе стольких пользователей в защищенном режиме?
(4) Alraune, то что я описал это как раз про косвенные. Вы правильно подметили в типовой в документе отражения з/п в регл. учете нельзя указать заказ на производство. Им можно только отразить затраты без заказа. Но это легко лечится доработкой.
В Вашем случае вижу два варианта.
Первый.
Вручную базу распределения рассчитывать не нужно. Если Вы не будете отражать косвенные затраты с указанием заказа и Вас устроит, что эти затраты пойдут на все заказы по указанной Вами базе распределения.
Второй.
К примеру, у Вас есть N заказов и одна затрата по Электроэнергии, но эту затрату нужно распределить пропорционально базе распределения не на все N заказы, а только на избранные. В этом случае при отражении такой затраты придется разделить суммы, которые пойдут на каждый из заказов. При РСВ уже затраты в рамках заказа будут распределены по заданной базе распределения по другим аналитикам (номенклатурные группы, спецификации, продукция)
Типовыми механизмами эта задача решается, но не сильно удобно. Тут как правило разрабатывают различные сервисные процедуры по распределению сумм, указанных в таб. части по нужным аналитикам и нужным правилам.
(5) tango, за кадром осталось 11397 человеко-часов большого командного труда.
Сложно написать все в рамках одной статьи, да и не нужно скорее всего.
Поэтому и выложили небольшую часть материала, чтобы понять интересующие большинство аудитории участки.
Если интерес обозначится к конкретным темам, то готовы ответить на вопросы в развернутом виде, возможно с приложением отдельных документов с проекта.
(8) интересно очень. но, тьфу-тьфу, интерес «академический». хочется, чтобы кроме обновления практически типовых бухгалтерий не интересовало ничего как можно дольше.
вообще, реально рад за вас. приятно, что работа где-то делается уже
удачи 🙂
для снабженцев сильно настраивали?
(это функционал мне лично приходилось разбирать и собирать на крупном машиностроительном)
Да, про управление процессом, организацию работы специалистов, agile было очень очень интересно почитать. Каким софтом пользовались — СУПы, баг-трекеры всякие.. Частота итераций. Была ли рабочая группа со стороны заказчика, чем она занималась?
Что с поддержкой, обновлениями, обучением?
Интересно, в общем, всё 🙂
А если по технической части, то можно было бы вот что спросить:
Какой объем базы? Количества строк в справочниках, регистрах.. Сервера? Дедлоки? Как организован процесс бэкапа?
По PDM-ной части: насколько большие сборки — сколько уровней вложенности, количество номенклатуры? Быстро ли обсчитывается на самых крупных сборках полный «состав изделия» с разузловкой — себестоимость, материальные ведомости, технологические ведомости?
Внедрялся ли какой-то поцеховой оперативный учет, маршрутные карты и пр.? Расчеты загрузки цехов?
Ну т.е., если одним словом — насколько крупное производство и быстро ли ворочается PDM с ним? 🙂
А вообще, 650 человек на PDM + УПП — да, это круто, поздравляю (знаю, что ацкий труд)!
Завидую по-хорошему немного.. ))
Что происходит при необходимости обновления бухгалтерского, зарплатного блока до следующей версии?
Почему нельзя было разделить на две базы управленческую (переписанную вдоль и поперек) и регламентную,в качестве которой использовать стандартную УПП? Объем работ упал бы в разы.
Жду статью по управлению проектом. Было бы интересно.
Alraune, bagaev, tango, romansun, milkers, serega_sun спасибо за участие и Ваши вопросы.
Я и мои коллеги с проекта обязательно ответим на все поступившие и поступающие вопросы, может не так оперативно как хотелось (текущая работа).
Сейчас согласовываю с Заказчиком возможность выкладывания отдельных документов/инструкций с проекта по блокам. Предварительная договоренность уже достигнута, поэтому часть ответов на вопросы будет в виде документов/инструкций с проекта.
romansun, serega_sun, про управление текущим проектом и организацию процесс обязательно напишу отдельную статью в середине января 2013.
Сегодня планирую отвечать на вопросы примерно с 15:00.
Интересное внедрение программы.
По поводу «адского труда» согласен на все 100%.
1) Из описания совсем не понятно чем могли 20 человек год заниматься :). Можно было бу уже всё УПП на УФ переписать :). Самое интересное что можно рассказать о проекте как раз ИХМО в этом.
2) а в чём «МЕГА» для проекта? 300 док-тов в день это весьма средненький проект… Сколько одновременно работающих пользователей, сколько блоков и т.п….
Если заказчик согласует ещё очень хотелось бы модель БП посмотреть…
На сколько я знаю у Световых технологий несколько заводов в разных городах, сейчас они все работают в единой базе? Или внедрение было только на московском предприятии?
(17) comol,
вообще в (8) ответили как бы
**
281 заказ в день
**
(0):
(18) comol, а чё БП? с ТЗР потёрлись, агентские услуги подпилили, и от РАУЗа в шоке, а так БП как БП 🙂
(19) Sybr,
в общем, господа коллеги, рекомендую прогуляться по указанным ссылам — интересно, познавательно, и, как указал коллега в (11), немножко завидно
В настоящее время мы заканчиваем полугодовой проект по внедрению УПП + БитФинанс на предприятии, которое оказывает услуги металлообработки. От РАУЗа отказались поскольку опасаемся набивания некорректных данных людьми с невысокой квалификацией. Скажите, возникали ли у вас какие-нибудь проблемы после внедрения, связанные с человеческим фактором? Или мы зря РАУЗа боимся?
(24)Напротив, РАУЗ куда устойчивее к человеческому фактору, зря вы его боитесь.
(25) mymyka, А можете порекомендовать хорошую литературу или статью или видеокурсы и т.п. по РАУЗу?
(26) Oleg_nsk, на текущий момент (то что знаю я) есть:
1. Курсы у Фарита Насипова —
2. Книжка от 1С — Е.Абрашина, И.Емельянов «Использование механизма расширенной аналитики в «1С:Управление производственным предприятием»
(26) Oleg_nsk,
(26)Да нет особо литературы по РАУЗу, в принципе он прозрачен и прост, один раз настроить способы распределения затрат и все. Для этого и желтых книжек достаточно, плюс есть немного инфы у Гилева и Насипова на сайте.
(32) mymyka, он прозрачен и прост с т.з. программера 1сь
(пока он не увидел запросы 🙂 )
а юзер не может с карандашиком/счетами/екселем повторить расчет, вот и дергается, поскольку приходится верить программе, не имея возможности ее проверить
ну, и «партионность в пределах месяца» — не для каждой задачи комильфо. например — для расчета вознаграждения от маржи по конкретной поставке
где-то тут по соседству мелькнула — кто-нибудь может развернуть тезис?
(20) tango, Ага… спс… такое чувство что просто клиентов пустили заказы самостоятельно бить :). а 300 юзеров — вполне средняя компания…
(35) comol, для московской мамы — неплохая цифра
другой вопрос — чем они там занимаются ?!? (эх, АлексО нам бы рассказал :))
(34)говоря прозрачен и прост, я имел ввиду, естественно, анализ «незакрывающегося» месяца, а не алгоритм расчета )насчет МСФО хз, но главный минус РАУЗА — несовместимость с директ-костингом, многие руководители хотят видеть текущее состояние дел, а не итоги в конце месяца )
(37) mymyka,
ага, об этом я все время упускаю почему-то 🙁
(37) mymyka, Можно же пустить расчет себестоимости с некоторой переодичностью — раз в 2 часа например. фононовым заданием. А вот отчет по Валовой прибыли многих не устраивает, особенно если учитывать нужно по ФИФО.
(6) bagaev, Здравствуйте! Меня зовут Ерзиков Андрей. На данном проекте я выполнял роль технического руководителя по блоку оперативного учета. По вопросу о вэб доступе: доступ организован по http, проблем с зависаниями при работе web ползователей нет. Единственное были жалуобы от тех пользователй, у кого очень низкая скорость соединения, и долгий пинг до москвы.
(47) AErzikov, снабжение считается оперативным учетом?
(48) tango, Да, считается, готов ответить на вопросы.
(69) AErzikov, спасибо
как понял — исходно это было ексельная табличка, в которую что-то кем-то вносилось
для начала хотелось бы уточнить обстановку:
вы работали с московской головой или снабжение конкретного производства?
насколько в холдинге централизован закуп?
(71) tango, мы работали с отделом закупки, который обеспечивает производство в России, закупка в рамках всего холдинга не централизована.
(73) AErzikov, все интересней и интересней:
vs
есть несколько предприятий по РФ, объединены собственником
у собственника с Москве есть управляющая структура, с которой вы и работали
на предприятиях, каждом из них, есть свои маленькие королевства в королевстве — отдел снабжения
и есть подразделение московской структуры, которая обеспечивает…
может быть, мы по-разному понимаем термин «централизация»?
(77) tango, в общий холдинг входят предприятия не только в РФ, в РФ есть один завод в Рязани + управляющая структура в москве. Основная закупка ведется из Москвы, но часть закупается из Рязани. И московские и рязанские пользователи работаю в одной базе. При данной структуре я бы не назвал закупку совсем централизованной.
(80) AErzikov, понял. просто я сталкивался с другой схемой: звезда, несколько лучей-предприятий. до 80% (номенклатуры) закупок — только через московского поставщика (отсюда забавная фишка — синхронизация справочников…).
у вас — фактически одна служба снабжения. у этой службы есть единоначальник, или москва с рязанью управляются параллельно?
**
ок. следующий вопрос — план производства есть? снабженцы его используют как руководство к действию?
и еще, от туда ж: при отпуске материала в цех виза снабжения требуется?
(82) tango, есть единоначальник.
(83) AErzikov, извините, я дописал (82)
(82) tango, да есть план производства и это руководство к действию для снабженцев. От плана производства до заказов поставщикам процесс организован следующим образом:
Есть специалный «интерактивный» отчет «План закупок», он берет данные из планов производства, текущие остатки, и из созданного регистра сведений «План закупок».
Почему он интерактивный: он позволяет непосредственно из отчета на основании остатков на складе, планов производства, методов пополнения запасов (варианты на тему MRP) произвести расчет колличетва, которое необходимо закупить с периодичностью неделя. Далее менеджер вносит корректировки в рассчитанно количество, по каждой позиции после проверки количества фиксирует, что это плановой количество утверждено им. После того как план сформирован, непосредственно из отчета можно создать заказы поставщикам на выбраный период, с отборами по номенклатуре и поставщикам. Прикрепил изображение, как это выглядит в жизни.
(12) milkers,
Полноценное обновление ставим только перед сдачей отчетности. Не чаще чем раз в квартал иногда пол года.
Зарплата в этой базе не ведется, для этих целей используется отдельная база на конфигурации ЗиУП.
Потому что задача была работать всем в единой базе, управленцы ежедневно формируют оперативную отчетность по упр. учету, изменяют аналитику упр. учета (статьи оборотов, счета учета УУ и прочую инф.). При такой активной работе с упр. частью обмен между базами тормозил бы процесс и накладывал определенные функции по контролю этого процесса. Обновление здесь лучше, чем мониторинг обменов и задержка в информации.
Если бы можно было решить вопрос внедрением двух баз, то мы только ЗА. Нам знаете тоже, чем проще, тем лучше.
(95) AErzikov, спасибо.
таки есть
что (как вычисляется количество), чем, кем туда пишется, с какой регулярностью?
**
да, и почему РС? у меня (был когда-то) накопления, оборотный
(17) comol,
Согласен, что за год разработки можно было переписать много, но реально в годовом проекте разработка занимает даже не половину. Все свои новые разработки делали на управляемых формах, если требовалось добавляли упр. формы к типовым документам или развивали их (пример Заказ покупателя в типовой УПП без таб. части). Этапы проекта и сроки в укрупненном виде есть на нашем сайте, ссылки приводил в статье, дублирую ниже.
Уникальность этого проекта в его очень разнообразной функциональности, ведением всего учета в одной базе, большом количестве пользователей и в очень сжатых срока проекта от момента старта проекта (конец мая 2011) до начала работы всех пользователей в новой базе с полным отказом от старых систем (10 января 2012). После 10 января это уже была промышленная эксплуатация и сопровождение.
По тому что было сделано не стали писать в текущей статье очень подробно (главный критерий время), чтобы не переписывать, то что уже есть. Из имеющихся материалов можно понять что было сделано. Смысл этой статьи обсудить функциональные детали и поделиться опытом, с теми у кого будут предметные вопросы.
Описание того, что сделано http://делаемпроекты.рф/project/6/
Пресс релиз по проекту
(11) romansun,
В данный моент база занимает около 70 Гб, Но процентов 30-40 от объема, это прикрепленный файлы (используется стандарный механизм прикрепления файлов).
Количество элементов в справочниках:
Номенклатура — около 23000
Контрагенты — около 3000
Количество записей в регистре бухгалтерии 2500000
Сервера:
Сервер приложения:
Процессоры: 2 x Intel Xeon E5630
Опративна память: 32 Гб
Дисковая подситема: Два RAID 1, каждый из двух SAS дисков
Сервер СУБД:
Процессоры: 2 x Intel Xeon E5645
Опративна память: 96 Гб
Дисковая подситема: Система — RAID 1 из 2ух дисков, базы данных + логи — RAID 10 из 4ех дисков, tempdb — RAID 0 из 2ух дисков. Диски везде SAS.
Бэкапы делаются средвтвами СУБД один раз в сутки.
(19) Sybr,
У Световых технологий в России завод один в Рязани. Автоматизация проходила на двух площадках Москва (Торговая компания) и Рязань (Производство). Все они работают в единой базе.
— тут можно подробнее прочитать историю развития данной компании.
С января 2013 года запуск завода в Украине (старт работ был в июле 2012) на УПП для Украины, аналогичный проект России, только уже много чего взяли с России, сильные изменения только в их регл. учете.
(95) AErzikov, +(97) по ходу вы в этот отчет и регистр тупо загнали ексельную табличку.
у меня регистр складские и заказы поставщикам двигали
(98)
Так вот и написали бы, как проектировали, какие подходы использовали, как коллективную работу организовали, какие модели строили, насколько получилось спроектировать в соответствии и т.п. ИХМО было бы куда интереснее чем описание проведенных доработок, которые, как отметил Артур (28) несут достаточно мало полезной информации.
Другое дело что подходами к проектированию и организации работ не каждый наверное готов делиться… 🙂
(102) comol, ага, и еще исполнение бюджета по-статейно 🙂
(28) artbear,
Ответил, см (93). По производству отвечу завтра.
(97) tango,
сведений «План закупок»
что (как вычисляется количество), чем, кем туда пишется, с какой регулярностью?
**
да, и почему РС? у меня (был когда-то) накопления, оборотный
Данные в регистр сведений пишутся непосредственно из отчета.
При двойном клике на ячейке с планируемым количеством открывается форма редактирования кличества(95) после редактирования в ней данных и нажатия на кнопку «Заверить редактирование» данные пишутся в регистр.
Регистр сведений периодический, периодичность секунда.
Регистр сведений, т.к. если делать регистр накопления, необходимо к нему делать документ.
Документ «План закупок» пользователи не приняли бы, а делать все создания документов программно кажется не очень красивым варианом, а так каждое изменение — новая запись в регистре, хранится вся история редактирования, а актуальное состояние плана — срез последних.
(106) AErzikov, ну как бы да, см. (101)
(99)(93)
ребят, спасибо за ответы
(11) romansun,
Краткое описание действующей схемы:
1. Пользователь инициирует заполнение «Плана производства по дням недели» данными о недельном объеме выпуска (из регистра «Планы производства» по подтвержденным документам). Самостоятельно распределяет количество между днями недели. При необходимости меняет тех.карту (участок) и/или спецификацию.
2. Из «Плана производства по дням недели» (график выпуска готовой продукции по участкам) запускается формирование заказов на производство. По продукции точно по данным документа. Далее по полуфабрикатам всех уровней вложенности исходя из:
— потребностей заказов на продукцию и всех полуфабрикатов предыдущих уровней
— текущих остатков на складах
— ожидаемых выпусков (по уже ранее сформированным и еще не исполненным заказам на производство)
— параметров пополнения (страховой запас, мин.партия, кратность, опережение, консолидация потребностей)
Полученный массив заказов на производство по сути является производственной программой на ближайшие дни (рабочая неделя + 2-3 дня до).
3. Под потребности заказов на производство формируются заявки на перемещение материалов с центрального склада на склады производственных площадок (участков) — документы «Внутренний заказ». На основании которых затем выполняются собственно перемещения.
4. Остатки заказов на производство выводятся в печатную форму в виде заданий на участки.
5. По итогам дня каждым участком вводится «Отчет производства за смену». Используется обработка заполнения табличной части с формой в виде таблицы остатков по заказам на производство данного участка. Для фактически изготовленных позиций пользователь в отдельной колонке этой таблицы указывает выпущенный объем.
Текущее состояние производственной программы просматривается универсальным отчетом по регистру заказы на производство (строки: участки, номенклатура; колонки: даты выпуска).
(11) romansun,
При формировании заказов на производство (как продукции, так и полуфабрикатов) никакой контроль ограничений производственных мощностей не осуществляется.
Есть возможность использовать добавленные специализированные отчеты «Проверка достаточности рабочих центров» и «… персонала».
Потребности времени работы рабочих центров и персонала на даты рассчитываются по технологическим картам и заказам на производство. В технологическую карту добавлены реквизиты по трудоемкости.
Доступное на эти даты время использования ресурсов определяется по графикам работы рабочих центров и добавленному регистру сведений (численность персонала и количество часов рабочей недели для каждого участка).
При выявлении превышений потребностей времени ресурсов над их доступностью либо корректируется план производства по дням недели (уменьшается), либо увеличивается доступность (вводятся сверхурочные часы или дополнительный персонал).
(116) MiklBreg, не возникала ли необходимость в таком функционале:
материал передан в цех (то бишь в производство, д20-к10) и постепенно переносится на продукцию
но перенос занимает достаточно долгое время, при этом продукция не выпускается, но может возникнуть желание знать, сколько материала еще лежит в кладовке цеха, а сколько уже реально вложено в единицу изделия (эта единица еще не изготовлена)
(118) tango, в дополнение (119). В номенклатуре на закладке «Настройка учета» есть флажок «Вести оперативный учет остатков незавершенного производства», им можно контролировать остаток в НЗП. Но этим флажком лучше не злоупотреблять и устанавливать его только у той номенклатуры по которой действительно важно понимать текущий остаток в НЗП. К примеру, очень дорогие материалы, очень редки и т.д.
(118) а еще бывает такое что этот материал уже попал в полуфабрикат который не передан на склад (промежуточное производство например) и материала нет на складе и иногда не выяснить на что он потрачен (нет выпуска).
Мы использовали виртуальные склады передачи в конце смены (сдал работу/наработку/полуфабрикат/недоделку — принял) Но это уже учет на поставленном производстве. На «диких» производствах только жесткий контроль (внос -вынос материалов — продукции).
(99) AErzikov, Странный проект. А вот почему:
1. Для подбора серверов использовалось нагрузочные тесты? Можно же обойтись более слабыми серверами для нагрузки — 300 документов в день и 350 пользователей.
2. От чего у Вас база раздутая такая при 300 документов в день? Даже если 50% это прикрепленные файлы получается довольно много 35Гб.
Для сравнения:
у нас в месяц вводится около 100.000 документов — база всего 22ГБ и это почти за 2 года.
Количество элементов в справочниках:
Номенклатура — около 70000
Контрагенты — около 35000
Есть несколько тяжеловесных регистров с 50,000,000 и более записей.
Оперативные показатели можно получить мгновенно.
Блокировки очень нереально редкое явление, интенсивно работает от 100-150 пользователей.
Да и чем там занимались 20-32 человека не понятно. Одна мысль нам бы такие ресурсы мы б космический корабль построили.
(214) Baza,
эта мысль возникает у всех, кто представляет себе внедрение как «взял и накодил»
(214) Baza,
Для подбора серверов не использовались нагрузочные тесты, запуск просход на том, что есть. В дальнейшем север СУБД был заменен на тот, описание которого я приводил. Решение по конфигурации серверов принимали IT специалисты заказчика. Единственное, что мы испльзовали перед запуском что бы понять возможности оборудования это был СНТ(Стандартный нагрузочный тест из состава КИПа).
Это связвно с наличием довольно больших таблиц и с тем, что используется много разных видов документов.
+ Приложил табличку с данными по объемам для базы без вложеных файлов.
(214) Baza,
хоть и говорят, что 9 женщин не родит за 1 месяц, но как раз на проектной стадии «разработка» такое возможно. Другими словами за счет большого количества разработчиков удалось сильно распараллелиться и выиграть время
(226) tango, да, накодить — это приблизительно 20%..тестирование прим. 60%…Если по другому — пускается сырой участок прямо в рабочую конфигурацию — и перекодинг 60%..
(229) barelpro, как было организовано взаимодействие связанных задач при параллельном кодинге?
Были ли codereview от заказчика, анализ изменений и согласование где будут производится доработки?
Был ли у заказчика штатный программист или же приходящий для проверки?
(231)
обещают отдельную статью — самое, да, вкусное 🙂
Меня тоже весьма интересуют организационные моменты.
(231) pumbaE, не хотелось забегать в перед, т.к. Антон Щекачев обещал эту тему раскрыть в отдельной статье. Скажу только, что после этого проекта мы приглашали к себе Agile-тренера, и мы с удивлением констатировали, что интуитивно уже давно разделяем agile-манифест и принципы Scrum
(233) barelpro, разделять можно сколько угодно, но засада — это
если нет, то нет 🙂
**
а если есть, то такой чувак может сделать себе автоматизацию, просто раздавая задания на ИС
**
ну, как бы вряд ли. предполагается, что у него и своей основной работы должно быть
т.е. или это 1с-фикси заказчика
или это чисто заказчик. тогда ему нужен кто-то отсюда же, с ИС, чтобы в тандеме «руководить проектом»
не присутствуя на биеналле Доржи, судя только по отзывам учаснегов, мне подумалось, что именно это схему реализовал Белов.
оказалось — нет, у Белова схема все того же 1с-франчайзинга/консалтенга, только виртуальная
фигня в том, что если посадить всех в виртуальную комнату, то среди независимых исполнителей начнется всякая фигня
собственно, схема Белова на то и направлена, чтобы исполнителя изолировать от заказчега, а менеджеры, соответственно, об 1с только чтоб как бы слышали, что такая есть
**
в общем, для возникновения и-команды необходима прозрачность условий и согласие учаснегов
(214) Baza,
Роли на проекте разные. Программированием занимались далеко не все. Понятно, что с первого дня проекта не могло быть сразу такого количества специалистов. Команда достигала указанных значений только в период, когда нужно было ускоряться и это было возможно.
За все время в проекте приняли участие:
— 51,85% — разработчики
— 29,63% — консультанты, методологи
— 18,52% — ТРП (технические руководители проекта)
(231) pumbaE, все вопросы не относящиеся к функциональной части проекта мы собираем и к концу января ответим на них в рамках отдельной статьи посвященной управлению на проекте.
(235) меня очень интересует как проверяли качество выполненых работ? Производительность при стремительных ростах объемов? Считали ли APDEX и как?
Критика за то, что за Вашей статьей масштабов не видно. Меня всегда в таких проектах интересует техническая сторона, а интерфейсы это не столько важно. Вот бы описывали нюансы бизнеса и как решали эту и другую проблему. Что, например, изменили по сравнению с типовым решением и почему. А потом в двух словах написать как собираетесь поддерживать конфигурацию и обновлять.
P.S. По поводу нюансов бизнеса, вот у нас очень актуально высокая скорость получения данных. Розница, крупный опт, даже задержки при поиске товара (среди 70.000) более 2 секунд это уже много. Блокировок не должно быть вовсе или очень редко. Постоянный парсинг конкурентов в режиме онлайн. Логистика с точностью выезда со склада до 5 минут и прибытия с разбросом до 1 часа.
(237) Baza,
имхо — отнюдь не есть
(236) бюджет проекта по-статейно представите?
(238) tango, не обещаем, но все возможно.
(238) tango, а вот с этим можно поспорить, время сильно регламентировано и даже за 5 минутное отсутствие на рабочем месте — нужно указать причину этого самого отсутствия. За такие нормы у нас и зарплата на 40-200% выше чем в среднем в регионе.
(237) Baza, о качестве работ в статье по управлению напишем.
Об этом напишет Андрей Ерзиков, он все эти вопросы решал с Фирмой 1С в рамках ЦКТП.
В дополнение к ответу (116) на вопросы (11). Прилагаю схему того, что было реализовано по производству в УПП.
(242) в схеме нет снабжения вообще: ни заказов покупателей, ни даже складских запасов
**
отклонения на производстве — тоже со снабженцами связано
(243) tango, все верно — это схема оперативного производства без связки со снабжением. В схеме только определение потребностей материалов и получение их через внутренние заказы из кладовых.
(237) Baza,
Некоторое проблемы с производительностью были, они решались в рамках проекта ЦКТП совместно с фирмой 1С.
Они были в основном связаны с тем, что многие документы при доработках обросли дополнитлельными достаточно тяжелыми алгоритмами, и соответственно проводились достаточно долго. Проблем с блокировками не было. Самы тяжелой операцией было проведение ОПЗС, т.к. при проведении производится полное разузлование для заполнение табличной части «Распределение материалов», а так же при проведении ОПЗС автоматически формируется требование накладная для списания матеиалов. Основным выходом для ускорения проведения было писать часть движений ОПЗС (РАУЗ + Бух регистры) фоновым заданием.
APDEX считали встрайвая в нужные места замеры времени.
Для замеров времени использовали соответствующие куски из БСП.
(243)Фирма, которая может убить 1-2 миллиона евро на автоматизацию может себе позволить морозить оборотные средства в страховых запасах материалов. В таких условиях снабжение может работать подходами — с утра сформировали потребности, заказали, успокоились до следующего дня. Совершенно бессмысленно активно включать их в бизнес-процесс как отделбную веху, отчетиком по потребностям на скд обойдутся )
(247) mymyka, на заменах однако без их согласования может не взлететь
согласен, что таком коротком плече заказа покупателя формировать потребность в материалах можно только статистически, но можно ведь
и оценку замороженного (хоть и не наша, 1снегов, пичалька) провести таки следует — валюта автоматизации тут ни при чем
и ведь сували же им этот ексельный файлик. только сказать не смогли, чего хотели. а БиТ культурненько промолчал
(247) mymyka,
Странные выводы. Как раз данная компания себе такого позволить не может. У них очень длинный цикл поставок сырья до полу года, поэтому планировать все нужно четко и без ошибок.
У них очень хорошо организована служба снабжения. Главное как организован процесс без компьютера. Автоматизация — это инструмент помощи. Если процесс не продуманный, то как бы хорошо он не был автоматизирован, хорошо не будет.
Как мы любим говорить: Если на предприятии бардак и никто ничего не хочет менять в первую очередь в умах сотрудников и организационно, то после внедрения системы будет автоматизированный бардак.
Эффект ухода от экселевских файлов в первую очередь позволил всем работать в едином пространстве и оперативно получать информацию. Новым заинтересованным в информации сотрудникам достаточно взять инструкцию и им не нужно искать владельцев файлов эксель.
Сам организационный процесс при внедрении изменен не был.
(122) iov, зачем использовать виртуальные склады? Можно же делать выпуск с направлением выпуска «на затраты»?
(242) как я понимаю функционал посменного планирования не используется. По какой причине?
(242) заказчик не ставил задачу использования маршрутных листов (сопроводительных карт, которые сопровождают партию продукции от момента запуска до выпуска)? Не приходилось ли вам сталкиваться с такой задачей и если да, то как вы ее решали?
(259)Не всегда и не все уходило в итоге на затраты. Да и передачи в конце смены позволяли контролировать … А выпуск на затраты полуфабрикатов?
(263) iov, выпуск полуфабрикатов как раз удобно делать с направлением выпуска «на затраты». А если для каждого промежуточного состояния продукции нецелесообразно создавать полуфабрикат в справочнике «Номенклатура», то нужно использовать вид выпуска «наработка».
(260) Рамзес, да функционал посменного планирования не использовали.
Заказчик привлекал бизнес-тренера для проработки модели MRP II. Предложенная схема, учитывающая бизнес и потребности Заказчика не сочеталась с типовыми инструментами посменного планирования. Поэтому было принято решение не дорабатывать существующую модель, а разработать полностью новые механизмы.
(261) Рамзес, на Ваш вопрос ответит Михаил Брегадзе, он был ТРП по блоку оперативное производство.
(261)
В случае, когда продукция с какого-то уровня передела приобретает какие-либо уникальные признаки, сохраняющиеся до конечного выпуска, можно порекомендовать в качестве входов и выходов спецификаций использовать одну номенклатуру с характеристиками, одним из свойств которых будет «стадия обработки». В некоторых конфигурациях (например, от ИТРП) такая сущность выделена в отельный (самостоятельный) разрез аналитики — «заход» — в учетных регистрах и НСИ (Спецификациях, Техкартах).
Для документального сопровождения такого технологического процесса можно предложить некий «чек-лист» с отметками о выполнении очередной тех.операции (на партию или, как частный случай, единицу продукции). При желании (необходимости) можно реализовать его электронный вариант в базе (штрих-код партии, операции, исполнителя, плюс дата, время и т.п.).
На предприятиях наверняка существуют свои формы такого рода сопроводительных документов (маршрутные листы и т.п.) и при необходимости «нарисовать» их в базе не проблема.
Возможны, конечно, различные нюансы формирования именно текущего варианта маршрута при решении задач оптимизации загрузки оборудования и т.п. Но это уже другая история…
(270) MiklBreg,
Именно этот момент мне интересен. Лично я попытался сделать так. При запуске партии в производство создается серия номенклатуры. Эта серия завязана на позицию в заказе на производство. Электронный вариант маршрутной карты это отчет, собирающий в себе информацию об этой партии: нормативный материал, фактически выданный материал, технологические операции, какие комплектующие должны быть поданы на технологическую операцию, в какие сборочные единицы войдут детали из данной партии и т.д. Такой подход имеет ряд минусов. Какой вариант выбрали вы? Создавали в конфигурации новый Документ «Маршрутная карта»?
(272) Рамзес,
увы, на практике до реализации решения таких задач не доходило. Соответственно, никакой вариант выбирать не приходилось. Как правило, в каждой конкретной ситуации оказывается свой более оптимальный вариант решения (с учетом действующих допущений, ограничений и т.п.).
(226) tango,
шкодил»🙂