УПП: Переработка рулонных материалов, или сколько нужно программистов на крупный проект

После публикации http://infostart.ru/public/166856/ (УПП: Хроники МЕГАпроекта) я решил поделиться альтернативным опытом реализации крупных проектов.
Итак, некоторые данные: Размер проекта, по моей оценке, примерно в 3 с лишним раза меньше, чем проект, внедренный командой «Первый БИТ». Внедрение проекта заняло 24 месяца против 6. На всех этапах внедрения проект внедрял 1 человек против 23-32. И самое главное, проект обошелся заказчику в 24*80 т.р., т.е. приблизительно в 2 миллиона рублей.

Молочников Олег Spb. 2013.

УПП: Переработка рулонных материалов, или сколько нужно программистов на крупный  проект.

  После публикации //infostart.ru/public/166856/ (УПП: Хроники МЕГАпроекта) я решил поделиться альтернативным опытом реализации крупных проектов.

Итак, некоторые данные:  Размер проекта, по моей оценке, примерно в  3 с лишним раза меньше, чем проект, внедренный командой «Первый БИТ». Внедрение проекта заняло 24 месяца против 6. На всех этапах внедрения проект внедрял 1 человек против 23-32. И самое главное, проект обошелся заказчику в 24*80 т.р.,  т.е. приблизительно в 2 миллиона рублей.

О корректности подходов  и методик, использованных в проекте.  Проект уже успешно эксплуатируется в течении года, за это время не было выявлено существенных недостатков. Дополнительно он проходил внешнюю экспертизу в Санкт-Петербургском филиале БИТ.

Обновляемость: Проект разделен на 2 базы, между которыми происходит обмен: базу управленческого учета (УУ) и базу регламентированного учета (РУ). База РУ – абсолютно стандартное УПП, благодаря чему ее обновление происходит примерно за  час, против сложного процесса обновления занимающего неделю.

Конечно, масштабы проектов и затраченные силы очень отличаются. Проект, сделанный «Первый БИТ», по-своему красив и заслуживает каждого потраченного цента. В случае крупного холдинга выбор однозначно оправданный, но очень дорогой.  Что делать, если у Вас нет ресурсов холдинга, но есть потребность в автоматизации учета?

Особенности ведения учета:

  1. На предприятии ведется порулонный учет. Это значит, что каждому рулону присваивается уникальный серийный номер.  Дополнительно рулон имеет  много других характеристик, таких длина, вес, площадь, толщина материала, ширина и много других. Все эти характеристики распределены между тремя стандартными уровнями иерархии 1С:

Номенклатура, характеристика номенклатуры и серия номенклатуры.  

 

Рис  1. Номенклатура.

 

Рис  2. Характеристика номенклатуры.

 

Рис  3. Серия номенклатуры.

  1. На предприятии ведется многопередельный учет. На каждом этапе переработки создается новый элемент серии номенклатуры с новым серийным номером  и другим набором характеристик рулона.
  2. На предприятии принимаются товары в переработку и передаются в давальческую переработку. Часто материалы, переданные в переработку, смешиваются в готовом изделии с собственными материалами. С учетом требований к учету по серийным номерам рулонов и правильному отражению на счетах бухгалтерского учета при выгрузке в базу РУ, была разработана сложная подсистема учета давальческих материалов, визуальная подсистема  поиска ошибок и автоматическая проверка на правильность перед выгрузкой в базу РУ.
  3. В управленческом учете детализация учета – рулон (на складе рулонных материалов) и стандартные единицы измерения на других складах.  При выгрузке в базу регламентного учет происходит уменьшение детализации учета до килограммов (на складе рулонных материалов). Также, из-за  того, что у материалов с разной шириной  могут быть разные закупочные цены и, соответственно, разные цены списания, а бухгалтерский учет ведется без учета характеристик номенклатуры, то происходит трансформация номенклатуры+ширины в новую позицию номенклатуры с  кодом, состоящим из кода номенклатуры и ширины. После выгрузки периода существуют специальные отчеты, позволяющие найти исправить расхождения в учетах, если они возникнут.

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

Изменения в учете:

Поступления товаров и услуг

 

  1. Форма списка изменена на управляемую, с цветовым выделением документов, которые проверил менеджер.
  2. На доп. закладке выбирается вариант расчета цены. По умолчанию это килограммы, но возможен вариант за метр квадратный и за метр погонный. Для рулонных материалов количество в строке т.ч. всегда должно быть  равно 1. Сумма строки рассчитывается из соответствующего показателя в серии номенклатуры. Этот пункт обязателен для всех документов, имеющих суммовой учет.

 

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

 

Поля ввода наверху формы являются одновременно и фильтром и шаблоном для заполнения при нажатии на кнопку “создать”,  если нет подходящего варианта.

Затем при нажатии на лупу в серии номенклатуры открывается новая форма рулона, в котором заполняются остальные характеристики.   См. Рис 3. Эти характеристики динамически отображаются в строке документа, но доступны для редактирования только в серии номенклатуры.

4. Все печатные формы документа переделаны. Все позиции сворачиваются до номенклатуры и ширины. Количественные показатели выводятся в зависимости от варианта расчета цены.

Изменения  в  других документах.

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

 

Выбранные позиции автоматически исчезают из формы подбора и переносятся в документ. Позиции уже имеющиеся в документе в подборе не отображаются. В документе “Поступление товаров из переработки” подбор осуществляется не из остатков на складе рулонных материалов, а из остатков переданных рулонов.

Описание подсистемы  целостности давальческой последовательности.

Назначение

               Подсистемы  целостности давальческой последовательности (ПЦДП) это программное расширение конфигурации “Управление производственным предприятием”, предназначенная для правильного отражения в бухгалтерском учете и формирования требуемых печатных форм при реализации товаров и услуг для давальческих материалов (материалов, принятых в переработку от клиента).  Давальческая последовательность (ДП)– правильное отражение, является ли материал давальческим на каждом этапе производственной цепочки. Производственная цепочка (ПЦ) – последовательность учетных документов от принятия на склад до выпуска готовой продукции для каждого конкретного материала.

Основные отличия от стандартной подсистемы:

  1. Не требует предварительного формирования документа заказ покупателя.
  2. Не требует формирования резервов по материалам на каждом этапе производственной цепочки.
  3. Имеет дополнительные средства контроля давальческой последовательности (ДП)  на каждом этапе производственной цепочки и перед выгрузкой в бухгалтерию.
  4. Имеет дополнительные средства визуализации и контроля.   
  5. Имеет средства автоматизированного исправления ошибок ДП.

Хранение информации в системе.

Информация о том, является ли каждый конкретный материал (рулон) давальческим  хранится в справочнике “Серии номенклатуры”, в реквизите “Давальческое сырье”.

 

Информация о том, какие материалы являются исходными для других материалов, находится в табличной части “Исходные рулоны” в справочнике “Серии номенклатуры”, на соответствующей закладке:

 

Эта информация формируется в процессе  переработки материла,  при вводе  документов “Отчет производства за смену” и ”Поступление материалов из переработки”. Наличие этой информации позволяет контролировать давальческую последовательность на всех этапах от поступления до реализации.

Описание изменений в пользовательском интерфейсе и действий пользователей.

Документ “Поступление товаров и услуг”

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

Это связано с тем, что давальческие материалы не учитываются в бухгалтерском учете и документ ПТУ с видом операции в переработку не будет выгружен.

 

 Рис. 10

Документ “ Отчет производства за смену ”

Рис. 11

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

 

Рис. 12

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

  1. Для давальческого готового рулона исходными рулонами могут только давальческие рулоны.
  2. При соединении исходного давальческого рулона и не давальческого, готовая продукция может быть только не давальческой.

Документ выгружается в бухгалтерию как два документа: » Отчет производства за смену” и “Требование-накладная”. Строки с давальческими материалами не  выгружаются.

Документ “ Поступление товаров из переработки ”

Работа с документом происходит в точности, как с документом “Отчет производства за смену”, описанным выше.

   

   Рис. 13

Документ “ Реализация товаров и услуг ”

 

 Рис. 14

На закладке “Специал.” добавлен флаг “давальческое сырье”. При установке этого флага появляются дополнительные закладки.

  1. Закладка “Материалы заказчика”.  Из меню  “Заполнить” заполняется автоматически на основании данных об исходных материалах в сериях номенклатуры в табличной части “Товары”.

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

Рис. 15

     2. Закладка М15 –заполняется бухгалтером  и содержит данные для печатной формы.

 

Рис. 16

В случае если флаг “давальческое сырье” не установлен, то документ выгружается в бухгалтерию как документ “Реализация товаров и услуг”, за исключением строк с давальческими материалами.

В случае если флаг “давальческое сырье” установлен, то документ выгружается в бухгалтерию как документ “Акт об оказании производственных услуг”,  и “Требование-накладная”, если есть наши материалы.

Визуальный контроль и исправление ошибок

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

Для всех документов, за исключением “Реализация товаров и услуг” этот контроль осуществляется перед проведением документа, в “Реализация товаров и услуг” этот контроль осуществляется перед установкой пометки “Проверено менеджером”.

Для визуализации цепочки переработки и исправления ошибок в давальческой последовательности существует внешняя печатная форма “Отчет по последовательности переработки”, доступная из документов из кнопки “Печать”.

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

Зеленым отражены недавальческие документы.

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

Красным цветом отмечены те документы, где нарушается давальческая последовательность.

Для исправления последовательности необходимо:

  1. Выполнить из печатной формы “Действия -> Сделать недавальческими”. Во всех сериях номенклатуры цепочки сбросится флаг “Давальческое сырье”.
  2. Правильно исправить тип операции, цену поступления, НДС  в документах поступления.

Если нет давальческого сырья, то этого достаточно.

  1. Если есть давальческое сырье, то выполняем “Действия -> Автоматическая установка давальческой цепочки”. В этом случае компьютер проанализирует цепочку и сам решит, к какому типу сырья должен относиться тот или иной материал.

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

Рис. 17

Проверка периода

Перед выгрузкой в бухгалтерию обязательно осуществлять контроль давальческой последовательности для выгружаемого периода. Это осуществляется через меню “Документы->Специал->Тестирование периода перед выгрузкой в бухгалтерию”.

 

Рис. 18

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

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

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

 Описание механизма:

А) Хранение информации о давальческих услугах:

Новый регистр сведений:  ЦеныДавальческихУслуг и новый документ регистратор для этого регистра:

Рис.19

Новый механизм расчета себестоимости и рентабельности в заказе покупателя:

 

Рис. 20

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

 

Рис. 21

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

Механизм закрытия заказов

Переписан код модулей проведения по регистру Заказы покупателей для документов ЗаказПокупателя, РеализацияТоваров и услуг. Суть изменений сводится к подмене количественных значений из серий номенклатуры численными показателями Вес, Площадь, Длина в зависимости от вида единиц, в которых оформлен заказ покупателя. Для давальческих услуг  контролируется только цена заказа и количественные показатели,  с номенклатурой заказа – услугой по переработке. В связи с возможным различим номенклатуры заказа и номенклатуры реализации предусмотрены дополнительные поля: номенклатура заказа и характеристика заказа, а также мастер из упрощенного заполнения.

 

Рис. 22

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

Дополнительно создана роль “МенеджерПоПланированию” для тех пользователей, которым будет доступен этот механизм.

 

Рис. 23

Расчет технологического отхода при многопередельном производстве

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

Технологический  отход =Приход -Реализации-Возвраты-Списания- Текущий остаток, по данным регистра товары на складах с отбором по рулонам по заказу. То есть  тех. отход равен разнице между произведенной продукцией и пошедшей на производство. Данные дальше легко могут предоставлены клиентам  в виде отчета:

Отчет о переработке материалов заказчика при выполнении работ

г.Санкт-Петербург

по заказу покупателя №            от 

Мы, нижеподписавшиеся, представитель Заказчика с одной стороны и Исполнителя, с другой стороны, составили настоящий отчет о том, что по состоянию на 01.01.0001 0:00:00 года материалы, переданные Заказчиком Исполнителю за период с по переработаны. Остаток, числящийся за Исполнителем, будет переработан по указанию Заказчика для изготовления будущих заказов.

Материал

Нач. ост. сырья, кг

Остаток готовой продукции, кг

Приход сырья, кг

Номер накладной, дата

Брак по сырью, кг

Итого сырья, кг в(в т.ч. Брак)

Переработано сырья в пр-ве, кг

В т.ч тех. Отходы, кг

Выпущено гот.прод., кг

Итого готовой продукции, кг

Отгружено поставщику гот.прод., кг

Номер накладной, дата

Расход сырья, кг

Номер накладной, дата

Кон. Ост. сырья , кг.

Остаток гот.прод., кг

Итого:

Примеры отчетов.

А) Продажи

Добавлены колонки Вес,Площадь.

 Рис. 24

Б) Стоимостная оценка складав ценах номенклатуры

Добавлены колонки Вес,Площадь,Цена (кг),Цена (кв.м)

 

Рис. 25

Г) Новый отчет ведомость по первичным списаниям материалов производство

 

Рис. 26

Д) Новый отчет ведомость по закупкам материалов на склад

 

Рис. 27

Е) Отчет по сравнению регламентированного учета и управленческого.

 

Рис. 2

PS: Надеюсь вам понравится эта и другие мои статьи и разработки на //infostart.ru/profile/48714/.

Также надеюсь, что материалы по этому проекту могут значительно сократить время и затраты на разработку проектов аналогичной тематики. В случае возникновения проблем всегда буду рад выступить консультантом. 

Очень жду ваших комментариев  и пожеланий.

Молочников Олег Spb. 2013. 

39 Comments

  1. Oleg_nsk

    Проекты сравнивать некорректно, поскольку не знаем всех нюансов. Внедрить предприятие с огромным количеством пользователей + бюджетирование + web клиенты это уже 1 программист вряд ли потянет. Плюс горячая линия консультаций в течении всего проекта + обучение пользователей + скорее всего там стояла задача скоростного внедрения + уверенность клиента в результате в связи с тем что первый бит это не программист фрилансер, способный потеряться. К тому же все эти программисты думаю работали на нескольких проектах одновременно и потому стоимость проекта там ниже, чем результат перемножения КолвоПрограммистов*КолвоМесяцев.

    Reply
  2. milkers

    (1) Согласен, я просто пытался показать, что серьезные вещи можно делать и в эконом сегменте. Да и один программист очень мало и рискованно на большой проект, и связанно, по большей части, со скупостью заказчика. Но как бы некорректно было сравнение проектов, оно наводит на некоторые размышления.

    Reply
  3. AKV77

    Уважаемые коллеги, в каждом из вышеизложенных постов есть своя правда. Несколько лет назад являлся техническим руководителем проекта со стороны компании про внедрению УПП на производственном предприятии занимающимся производством продукции из рулонной стали. Проект разрабатывался и внедрялся совместно с 1С Рарус НН. Фаза предпроекта заняла 3 месяца, фаза тестовой эксплуатации — 3 месяца, итого через 6 месяцев мы полностью отказались от старой учетной системы на 7-ке (в которой уже был внедрен полноценный производственный учет, включающий автоматизированный раскрой сырья в том числе). Еще через месяц мы отказались от услуг фирмы-франчайзи. В итоге через 7 месяцев от начала мы получили полностью рабочую и адаптированную к предприятию конфигурацию УПП. Теперь «ложка дегтя»: ребята из франча — грамотные и профессиональные, однако тех.задание, контроль написания кода и тестирование на всех этапах внедрения осуществлялось сотрудниками нашей компании. И имея опыт внедрения еще двух подобных проектов могу с уверенностью сказать — только при наличии у компании собственных «умных голов» возможно внедрение УПП с минимальными временными и финансовыми затратами. Справедливости ради замечу, что работа над проектом очень хороший повод поднять зарплату своему (своим) штатному программисту — что и было сделано в нашем случае.

    Reply
  4. serega3333

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

    а можно про это поподробней. столкнулся с такой же ситуацией — есть листы железа, из них делают блоки для ворот въездных. как построить учет чтобы видеть поступление в штуках, а списывать в м2. Просто на примере рулонов можете показать как грамотно увязать цены, метры, штуки…

    Reply
  5. milkers

    (4) Самый простой вариант, если листы железа имеют несколько типовых форматов (а так чаще всего и происходит), то переделывать ничего не надо, используем стандартный функционал.

    Вар. 1. Приходуем Лист железа формата ФЛ18(6 кв. метров) как 1 штуку. Создаем дополнительную еденицу измерения м2 c коэффициентом = 1/6. Теперь при продаже 1 м2 позиции ФЛ18 будет списываться 1/6 от единицы хранения. Единицей отчетов лучше сделать м2.

    Если этот вариант не подойдет, объясните подумаем еще.

    Reply
  6. krein

    На чем велся учет до внедрения? Проект как-то делился на этапы?

    Сроки, планируемые на этапе экспресс-обследования примерно совпали с фактическими?

    Почему пришлось формы списка переделать на управляемые (на этом акцентировано внимание), с ними работают из браузеров?

    По разделению базы на две, если есть время, напишите более подробно момент,

    как решалась ситуация, например, при исправлениях, изменении данных «задним числом», изменении наименований характеристик в базе УУ при указанных транформациях при переносе в базу РУ…

    Так-то отлично, что последнее время много описаний крупных, концептуально разных, внедрений

    И читать интересно, и авторам хорошая реклама!

    В (2) правильный комментарий, действительно есть совсем разный подход к проектам, это зависит большей частью от заказчиков…

    Есть в таких случаях «одиночного внедрения» и проекты, брошенные на полпути, все зависит от конкретных людей конечно..

    Reply
  7. GPL

    (1) Oleg_nsk, Вы там работали на фикси или это чисто аутсорсинг?

    если фикси — то сравнивать некорректно. девелопер на фикси за два года может конфетку сделать

    Reply
  8. GPL

    (3) AKV77, как вариант, если спецы франча имели опыт внедрения на аналогичном предприятии и менеджер проекта может убедить руководство проломить коллектив на «как надо», а не «как хочется Марье Васильевне» )))

    помню Апрель в Белом Парусе чего-то внедрял, до организации дошло, что своих спецов нужно иметь

    Reply
  9. AKV77

    (8) GPL, полностью согласен с тем что при внедрении любого серьезного проекта требуется собственный специалист (или команда). Хотя бы для того, чтобы отвечать на различные «глупые» вопросы пользователей, которые наверняка у них будут появляться в процессе работы как минимум в первые несколько месяцев после запуска проекта в рабочую эксплуатацию. Неговоря уже о сложностях при закрытии месяца, года, расчета себестоимости и т.д. Необходимо также отметить тот факт, что любой руководитель хочет видет четко отлаженную систему учета, но «подводные камни» и дополнительные «хотелки» при ее эксплуатации возникают зачастую уже после завершения тестовой эксплуатации проекта. И как следствие директор не хочет привлекать к работе сторонних специалистов, дабы не увеличивать и так не малые финансовые затраты.

    Reply
  10. AKV77

    И еще не маловажный фактор. Своих спецов необходимо обучать !!! Желательно в Москве (если есть такая возможность), т.к. при всем уважении, уровень курсов читаемых во франчах в регионах значительно ниже чем в УЦ 1С в Москве. Это мое субъективное мнение. Сам обучался и в Москве и в Нижнем Новгороде, поэтому и сравниваю.

    Reply
  11. milkers
    Reply
  12. milkers

    (7) GPL,

    Вы там работали на фикси или это чисто аутсорсинг?

    если фикси — то сравнивать некорректно. девелопер на фикси за два года может конфетку сделать

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

    Reply
  13. Ish_2

    Насколько всё было хорошо сделано,

    корректно ли вообще сравнение двух обозначенных автором проектов

    — все эти вопросы правомерны и кто там разберет…, но жанр «Знай наших !!» мне настолько нравится ,

    что скажу только одно : Олег , так и надо ! Молодца.

    Reply
  14. all_i_ance

    (13) Ish_2, полностью согласен 🙂

    Reply
  15. Nykyanen

    Толковые программисты есть среди фрилансеров и среди франчайзи.

    Из тех с кем сталкивался примерно 1.7 из 10 толковые и готовые работать, а не на форумах сидеть или заниматься чем угодно, кроме работы [нужное дописать :-)].

    Итого если в БИТ было 23-32 среднее количество получается 27,5 — землекопа.

    Получаем 27,5 / 10 * 1.7 = 4,675 землекопа, что были толковые и в это время работали.

    Итого получаем 4,675 чел * 6 месяцев = 28 человеко-месяцев.

    Так что как то так.

    Reply
  16. okref

    Отличная статья. Понравилась и по существу, и по подаче материала.

    1. В рис. 11 не затерт ответственный пользователь.

    2. Что значит буква «П» в комментариях многих документов?

    Reply
  17. milkers

    (16) okref, П — это означает, что все документы распечатаны и переданы клиенту. Бухгалтерии так удобно.

    Reply
  18. okref

    Просто у нас так же. Я удивился что в хорошо переработанной базе живет и здравствует такой простой механизм.

    Reply
  19. milkers

    (18) okref, Просто принцип : «Не спорь по мелочам с бухгалтерий — целее нервы будут» мне кажется основополагающим для отрасли. 🙂

    Reply
  20. amadeus2011

    наша компания прошла такой же путь как у автора. Была самописная база на оракл, листы ексель для учета поступления заказов.Потом решили перейти на УПП, за 2 года работу делали 2 франча, в итого руководство наняло 2 программистов, которые дописывали за франчами и выполняли разные хотелки пользователей на что ушло еще 8 месяцев.В результате на сегодняшний день имеем полноценную систему на базе УПП 1.2. Планируем обновить до 1.3

    так что ситуация частично знакома и на небольшой фирме с количеством пользователей 1С до 100, 2-3 программиста могут автоматизировать процесс

    Reply
  21. nafa

    При сравнении стоимости необходимо учесть, что больший в 4 раза срок реализации означает, что предприятие 18 месяцев несло много дополнительных затрат. Отсутствие автоматизации — это излишки одинк материалов и недостаток других, а значит простои производства, транспорта и т.п. С учетом этих факторов нередко бывает дешевле заплатить дороже, но получить результат быстрее. Вообще по моему пониманию в при ИТ сфере как раз экономический эффект и является определяющим, собственно прямые затраты вообще мало что значат (если конечно речь не идет про супердорогой софт типа САПа)

    Reply
  22. milkers

    (21) nafa,

    При сравнении стоимости необходимо учесть, что больший в 4 раза срок реализации означает, что предприятие 18 месяцев несло много дополнительных затрат. Отсутствие автоматизации — это излишки одинк материалов и недостаток других, а значит простои производства, транспорта и т.п. С учетом этих факторов нередко бывает дешевле заплатить дороже, но получить результат быстрее. Вообще по моему пониманию в при ИТ сфере как раз экономический эффект и является определяющим, собственно прямые затраты вообще мало что значат (если конечно речь не идет про супердорогой софт типа САПа)

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

    Reply
  23. Sergey03

    Классная статья, много интересного, но и много вопросов появилось:

    -Используются ли для занесения данных сканера штрих кодов? в какой части?

    -если каждый раз формировать новое наименование на каждый рулон, справочник может вырости очень сильно. я правильно понял? Можно пример названия в справочнике, используется ли в названии штрих код?

    — как учитываются остатки (обрезки) материалов которые можно еще раз использовать. Например: полотно стекла разрезали, нужное взяли, остались большие куски. Как эти куски отразить в программе что бы по ним был учет?

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

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

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

    Reply
  25. milkers

    (24) Нет. Выбранна модель учета сырья в БУ, когда учитывается только недавальческое сырье.

    Отрицательное значение флага давальческое сырье означает что в материале нет нашего сырья и операции с этим сырьем в БУ отображать не не нужно. Перегружаются в БУ только те позиции в документах, которые содержат наше сырье.

    Reply
  26. таксяк

    А почему у вас ЭНЕРГОМАШБАНК где-то затерт, а где-то нет? Спалили контрагента? Или терли все подряд?

    Reply
  27. Senator_I

    А можно вопрос, как рассчитывается себестоимость, по ФИФО или средневзвешенному.

    Reply
  28. Senator_I

    ?

    Reply
  29. milkers

    (27) Senator_I, Себестоимость рассчитывается по ФИФО, но учитывая, что единица детализации один рулон материала с уникальными параметрами(серия номенклатуры), это не играет значения.

    Reply
  30. Senator_I

    Понятно! Большое спасибо за ответ!

    Reply
  31. Ele1234567

    Познавательная статья, спасибо!

    Reply
  32. lesenoklenok

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

    Reply
  33. kudlach

    Олег, учет в дополнительных единицах (рулоны — основная, вес, метраж) регистры допиливал или отчеты переписал с пересчетом по параметрам серий? Что проще и лучше?

    Reply
  34. milkers

    (33) kudlach, Проведение по регистрам не трогал, а вот отчеты переписаны.

    Может быть не очень понятен вопрос. Сложности чего вы хотите сравнить?

    Reply
  35. kudlach

    Прото у клиента похожая чем-то задача. Ювелиры. Изделия в штуках и в граммах. Плюсом учет состава изделия на этапе производства и реализации.

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

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

    Reply
  36. tori131313

    да, побольше бы таких статей было: часто проблема не в том, как написать в 1С, а что.

    Reply
  37. Светлый ум

    Как и во всех аналогичных статьях не описывается поведение документа «Расчет себестоимости».

    — Доработки повлияли на его работу?

    — Дописки какие-то делали по нему?

    Reply
  38. milkers

    (0) Добавил решение проблемы расчета технологического отчета при многопередельной переработке.

    Reply
  39. milkers

    (37) Никак не повлияло.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *