gifts2017

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

Опубликовал Олег Молочников (milkers) в раздел Управление - Практика учета

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

 

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

 

 

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

 

  После публикации http://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

 

 

 

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

А) Продажи

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

 

 

 Рис. 24

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

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

 

 

Рис. 25

 

 

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

 

Рис. 26

 

 

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

 

 

Рис. 27

 

 

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

 

 

Рис. 2

 

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

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

 

 

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

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

 

 

 

 

 

 

 

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Олег Сорокин (Oleg_nsk) 09.01.13 11:38
Проекты сравнивать некорректно, поскольку не знаем всех нюансов. Внедрить предприятие с огромным количеством пользователей + бюджетирование + web клиенты это уже 1 программист вряд ли потянет. Плюс горячая линия консультаций в течении всего проекта + обучение пользователей + скорее всего там стояла задача скоростного внедрения + уверенность клиента в результате в связи с тем что первый бит это не программист фрилансер, способный потеряться. К тому же все эти программисты думаю работали на нескольких проектах одновременно и потому стоимость проекта там ниже, чем результат перемножения КолвоПрограммистов*КолвоМесяцев.
2. Олег Молочников (milkers) 09.01.13 12:44
(1) Согласен, я просто пытался показать, что серьезные вещи можно делать и в эконом сегменте. Да и один программист очень мало и рискованно на большой проект, и связанно, по большей части, со скупостью заказчика. Но как бы некорректно было сравнение проектов, оно наводит на некоторые размышления.
3. Андрей (AKV77) 09.01.13 14:42
Уважаемые коллеги, в каждом из вышеизложенных постов есть своя правда. Несколько лет назад являлся техническим руководителем проекта со стороны компании про внедрению УПП на производственном предприятии занимающимся производством продукции из рулонной стали. Проект разрабатывался и внедрялся совместно с 1С Рарус НН. Фаза предпроекта заняла 3 месяца, фаза тестовой эксплуатации - 3 месяца, итого через 6 месяцев мы полностью отказались от старой учетной системы на 7-ке (в которой уже был внедрен полноценный производственный учет, включающий автоматизированный раскрой сырья в том числе). Еще через месяц мы отказались от услуг фирмы-франчайзи. В итоге через 7 месяцев от начала мы получили полностью рабочую и адаптированную к предприятию конфигурацию УПП. Теперь "ложка дегтя": ребята из франча - грамотные и профессиональные, однако тех.задание, контроль написания кода и тестирование на всех этапах внедрения осуществлялось сотрудниками нашей компании. И имея опыт внедрения еще двух подобных проектов могу с уверенностью сказать - только при наличии у компании собственных "умных голов" возможно внедрение УПП с минимальными временными и финансовыми затратами. Справедливости ради замечу, что работа над проектом очень хороший повод поднять зарплату своему (своим) штатному программисту - что и было сделано в нашем случае.
sergio199; iTony73; dicwork; Drozd80; Andy.Shel; kaa79; shurik_shurik; KroVladS; VasMart; sanfoto; myrowka; vasiliy_b; krein; fomix; babys; +15 Ответить 1
4. qweasd qweasdzc (serega3333) 09.01.13 17:17
В управленческом учете детализация учета – рулон (на складе рулонных материалов) и стандартные единицы измерения на других складах. При выгрузке в базу регламентного учет происходит уменьшение детализации учета до килограммов (на складе рулонных материалов). Также, из-за того, что у материалов с разной шириной могут быть разные закупочные цены и, соответственно, разные цены списания, а бухгалтерский учет ведется без учета характеристик номенклатуры, то происходит трансформация номенклатуры+ширины в новую позицию номенклатуры с кодом, состоящим из кода номенклатуры и ширины. После выгрузки периода существуют специальные отчеты, позволяющие найти исправить расхождения в учетах, если они возникнут.

а можно про это поподробней. столкнулся с такой же ситуацией - есть листы железа, из них делают блоки для ворот въездных. как построить учет чтобы видеть поступление в штуках, а списывать в м2. Просто на примере рулонов можете показать как грамотно увязать цены, метры, штуки...
5. Олег Молочников (milkers) 09.01.13 17:29
(4) Самый простой вариант, если листы железа имеют несколько типовых форматов (а так чаще всего и происходит), то переделывать ничего не надо, используем стандартный функционал.
Вар. 1. Приходуем Лист железа формата ФЛ18(6 кв. метров) как 1 штуку. Создаем дополнительную еденицу измерения м2 c коэффициентом = 1/6. Теперь при продаже 1 м2 позиции ФЛ18 будет списываться 1/6 от единицы хранения. Единицей отчетов лучше сделать м2.
Если этот вариант не подойдет, объясните подумаем еще.
6. krein (krein) 09.01.13 23:04
На чем велся учет до внедрения? Проект как-то делился на этапы?
Сроки, планируемые на этапе экспресс-обследования примерно совпали с фактическими?
Почему пришлось формы списка переделать на управляемые (на этом акцентировано внимание), с ними работают из браузеров?

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

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

В (2) правильный комментарий, действительно есть совсем разный подход к проектам, это зависит большей частью от заказчиков...
Есть в таких случаях "одиночного внедрения" и проекты, брошенные на полпути, все зависит от конкретных людей конечно..
7. Александр Жебряков (GPL) 09.01.13 23:18
(1) Oleg_nsk, Вы там работали на фикси или это чисто аутсорсинг?
если фикси - то сравнивать некорректно. девелопер на фикси за два года может конфетку сделать
8. Александр Жебряков (GPL) 09.01.13 23:22
(3) AKV77, как вариант, если спецы франча имели опыт внедрения на аналогичном предприятии и менеджер проекта может убедить руководство проломить коллектив на "как надо", а не "как хочется Марье Васильевне" )))
помню Апрель в Белом Парусе чего-то внедрял, до организации дошло, что своих спецов нужно иметь
9. Андрей (AKV77) 10.01.13 09:54
(8) GPL, полностью согласен с тем что при внедрении любого серьезного проекта требуется собственный специалист (или команда). Хотя бы для того, чтобы отвечать на различные "глупые" вопросы пользователей, которые наверняка у них будут появляться в процессе работы как минимум в первые несколько месяцев после запуска проекта в рабочую эксплуатацию. Неговоря уже о сложностях при закрытии месяца, года, расчета себестоимости и т.д. Необходимо также отметить тот факт, что любой руководитель хочет видет четко отлаженную систему учета, но "подводные камни" и дополнительные "хотелки" при ее эксплуатации возникают зачастую уже после завершения тестовой эксплуатации проекта. И как следствие директор не хочет привлекать к работе сторонних специалистов, дабы не увеличивать и так не малые финансовые затраты.
10. Андрей (AKV77) 10.01.13 10:03
И еще не маловажный фактор. Своих спецов необходимо обучать !!! Желательно в Москве (если есть такая возможность), т.к. при всем уважении, уровень курсов читаемых во франчах в регионах значительно ниже чем в УЦ 1С в Москве. Это мое субъективное мнение. Сам обучался и в Москве и в Нижнем Новгороде, поэтому и сравниваю.
11. Олег Молочников (milkers) 10.01.13 11:34
(6) krein,
а чем велся учет до внедрения?

Управленческий учет шел в экселе. Существовало n-e количество файлов в экселе, примерно соответствующих по назначению регистрам УПП. Были определенные принципы, по которым куски страницы экселя копировались между файлами с помощью буфера обмена при совершении учетных операций. Вы не поверите, но эта система работала!! Единственной осознанной проблемой на тот момент были блокировки файлов при работе многих пользователей.
Были также регламентная база на бухгалтерии 2.0, управленческая база (тоже бух2.0) , в которой местный программист пытался дописать производственные документы. Реально там работало лишь оформление продаж, импортируемых из экселя. Материалы списывались методом подгонки бухгалтерией.
Огромное количество изобретенных заново велосипедов, к которым уже привыкли пользователи, например дикая система работы с договорами пользователей, когда вместо ведения договоров по счетам, каждый раз генерируется новый договор. Пожалуй, переломить сознание пользователей было самым трудным.


Проект как-то делился на этапы?

Да, первичное обследование и черновой проект для демонстрации концепции - 2- месяца.
Первичная разработка 6 месяцев, до начала работы в параллельном режиме. 4 месяца параллельной эксплуатации, устранения недостатков и разработки экспорта в бухгалтерию 2.0. На этом этапе мы избавились от их торговой базы. Полный отказ от экселя и перевод бухгалтерской базы на УПП.
В итоге через год мы имеем вместо зоопарка две УПП базы. А дальше доработка напильником.

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

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

Почему пришлось формы списка переделать на управляемые (на этом акцентировано внимание), с ними работают из браузеров?
Быстрее и удобнее сделать цветовое выделение по данным регистра сведений. К тому же никто не даст гарантии, что этот документ не потребуется в дальнейшем сделать доступным через ВЕБ.

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

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

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


Так-то отлично, что последнее время много описаний крупных, концептуально разных, внедрений
И читать интересно, и авторам хорошая реклама!
Ну в моем случае все просто. Этот проект подходит к концу, и я активно ищу новых заказчиков.
12. Олег Молочников (milkers) 10.01.13 11:39
(7) GPL,
Вы там работали на фикси или это чисто аутсорсинг?
если фикси - то сравнивать некорректно. девелопер на фикси за два года может конфетку сделать

Да, я обычно устраиваюсь к заказчику на срок выполнения проекта. Потом ищу другой проект. Нельзя сказать что это фикси в чистом виде.
13. Игорь Исхаков (Ish_2) 11.01.13 19:10
Насколько всё было хорошо сделано,
корректно ли вообще сравнение двух обозначенных автором проектов
- все эти вопросы правомерны и кто там разберет..., но жанр "Знай наших !!" мне настолько нравится ,
что скажу только одно : Олег , так и надо ! Молодца.
14. Алексей 1 (all_i_ance) 12.01.13 00:21
(13) Ish_2, полностью согласен :)
15. Матти Нюкянен (Nykyanen) 14.01.13 16:39
Толковые программисты есть среди фрилансеров и среди франчайзи.
Из тех с кем сталкивался примерно 1.7 из 10 толковые и готовые работать, а не на форумах сидеть или заниматься чем угодно, кроме работы [нужное дописать :-)].

Итого если в БИТ было 23-32 среднее количество получается 27,5 - землекопа.
Получаем 27,5 / 10 * 1.7 = 4,675 землекопа, что были толковые и в это время работали.
Итого получаем 4,675 чел * 6 месяцев = 28 человеко-месяцев.

Так что как то так.
16. Алексей Рябцев (okref) 15.01.13 13:16
Отличная статья. Понравилась и по существу, и по подаче материала.
1. В рис. 11 не затерт ответственный пользователь.
2. Что значит буква "П" в комментариях многих документов?
17. Олег Молочников (milkers) 15.01.13 14:35
(16) okref, П - это означает, что все документы распечатаны и переданы клиенту. Бухгалтерии так удобно.
18. Алексей Рябцев (okref) 15.01.13 16:34
Просто у нас так же. Я удивился что в хорошо переработанной базе живет и здравствует такой простой механизм.
19. Олег Молочников (milkers) 15.01.13 17:00
(18) okref, Просто принцип : "Не спорь по мелочам с бухгалтерий - целее нервы будут" мне кажется основополагающим для отрасли. :)
20. Dmitriy Kuklin (amadeus2011) 16.01.13 15:10
наша компания прошла такой же путь как у автора. Была самописная база на оракл, листы ексель для учета поступления заказов.Потом решили перейти на УПП, за 2 года работу делали 2 франча, в итого руководство наняло 2 программистов, которые дописывали за франчами и выполняли разные хотелки пользователей на что ушло еще 8 месяцев.В результате на сегодняшний день имеем полноценную систему на базе УПП 1.2. Планируем обновить до 1.3
так что ситуация частично знакома и на небольшой фирме с количеством пользователей 1С до 100, 2-3 программиста могут автоматизировать процесс
21. Виталий (nafa) 17.01.13 10:40
При сравнении стоимости необходимо учесть, что больший в 4 раза срок реализации означает, что предприятие 18 месяцев несло много дополнительных затрат. Отсутствие автоматизации - это излишки одинк материалов и недостаток других, а значит простои производства, транспорта и т.п. С учетом этих факторов нередко бывает дешевле заплатить дороже, но получить результат быстрее. Вообще по моему пониманию в при ИТ сфере как раз экономический эффект и является определяющим, собственно прямые затраты вообще мало что значат (если конечно речь не идет про супердорогой софт типа САПа)
22. Олег Молочников (milkers) 17.01.13 17:00
(21) nafa,
При сравнении стоимости необходимо учесть, что больший в 4 раза срок реализации означает, что предприятие 18 месяцев несло много дополнительных затрат. Отсутствие автоматизации - это излишки одинк материалов и недостаток других, а значит простои производства, транспорта и т.п. С учетом этих факторов нередко бывает дешевле заплатить дороже, но получить результат быстрее. Вообще по моему пониманию в при ИТ сфере как раз экономический эффект и является определяющим, собственно прямые затраты вообще мало что значат (если конечно речь не идет про супердорогой софт типа САПа)

Следует учитывать еще и такое экономическое понятие как "стоимость денег". Выведенная из оборота оплата за весь проект обойдется гораздо дороже клиенту, чем та же сумма помесячно. А тут еще и разница в оплате на порядок отличается. Есть еще очень много факторов и в минус и в плюс для каждого варианта, и не только экономического характера. Выбор любого варианта требует очень тщательного анализа, здесь нет идеальной стратегии для всех случаев.
Drozd80; krein; +2 Ответить
23. sergey03 (Sergey03) 30.01.13 10:29
Классная статья, много интересного, но и много вопросов появилось:

-Используются ли для занесения данных сканера штрих кодов? в какой части?
-если каждый раз формировать новое наименование на каждый рулон, справочник может вырости очень сильно. я правильно понял? Можно пример названия в справочнике, используется ли в названии штрих код?
- как учитываются остатки (обрезки) материалов которые можно еще раз использовать. Например: полотно стекла разрезали, нужное взяли, остались большие куски. Как эти куски отразить в программе что бы по ним был учет?
что бы не резали каждый раз новый лист а знали что есть куски подходящего размера.
24. Сергей Сергеев (Рамзес) 12.04.13 09:39
При соединении исходного давальческого рулона и не давальческого, готовая продукция может быть только не давальческой.

Как это? Получается, что давальческий материал используется для собственных нужд?
25. Олег Молочников (milkers) 12.04.13 10:37
(24) Нет. Выбранна модель учета сырья в БУ, когда учитывается только недавальческое сырье.
Отрицательное значение флага давальческое сырье означает что в материале нет нашего сырья и операции с этим сырьем в БУ отображать не не нужно. Перегружаются в БУ только те позиции в документах, которые содержат наше сырье.
26. Штаб Главный (таксяк) 16.09.13 09:36
А почему у вас ЭНЕРГОМАШБАНК где-то затерт, а где-то нет? Спалили контрагента? Или терли все подряд?
27. Дмитрий (Senator_I) 09.10.13 07:06
А можно вопрос, как рассчитывается себестоимость, по ФИФО или средневзвешенному.
29. Олег Молочников (milkers) 09.10.13 10:21
(27) Senator_I, Себестоимость рассчитывается по ФИФО, но учитывая, что единица детализации один рулон материала с уникальными параметрами(серия номенклатуры), это не играет значения.
30. Дмитрий (Senator_I) 09.10.13 12:32
Понятно! Большое спасибо за ответ!
31. Елена К (Ele1234567) 23.12.13 10:10
Познавательная статья, спасибо!
32. Елена Ситникова (lesenoklenok) 14.02.14 11:44
Очень интересная и познавательная статья, спасибо что поделились опытом.
33. Евгений Климентьев (kudlach) 07.04.14 14:36
Олег, учет в дополнительных единицах (рулоны - основная, вес, метраж) регистры допиливал или отчеты переписал с пересчетом по параметрам серий? Что проще и лучше?
34. Олег Молочников (milkers) 07.04.14 14:52
(33) kudlach, Проведение по регистрам не трогал, а вот отчеты переписаны.
Может быть не очень понятен вопрос. Сложности чего вы хотите сравнить?
35. Евгений Климентьев (kudlach) 19.05.14 17:17
Прото у клиента похожая чем-то задача. Ювелиры. Изделия в штуках и в граммах. Плюсом учет состава изделия на этапе производства и реализации.
Две единицы параллельно запилил в регистрах - первые рабочие результаты уже есть. А вот сложнй состав изделия придется, видимо, аналогично как у Вас реализовывать, через серии (хотя, тут умельцы пошли путем характеристик, но это не так важно - таблицы есть аблицы, а механизмы похожие)
Интересовался, чтобы удостовериться каким путем надежнее идти.
36. Тарас Жидков (tori131313) 02.12.14 13:07
да, побольше бы таких статей было: часто проблема не в том, как написать в 1С, а что.
37. Константин Куликов (Светлый ум) 01.09.15 12:12
Как и во всех аналогичных статьях не описывается поведение документа "Расчет себестоимости".
- Доработки повлияли на его работу?
- Дописки какие-то делали по нему?