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

Управление - Практика учета

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

См. также

Комментарии
1. Олег Сорокин (Oleg_nsk) 141 09.01.13 11:38 Сейчас в теме
Проекты сравнивать некорректно, поскольку не знаем всех нюансов. Внедрить предприятие с огромным количеством пользователей + бюджетирование + web клиенты это уже 1 программист вряд ли потянет. Плюс горячая линия консультаций в течении всего проекта + обучение пользователей + скорее всего там стояла задача скоростного внедрения + уверенность клиента в результате в связи с тем что первый бит это не программист фрилансер, способный потеряться. К тому же все эти программисты думаю работали на нескольких проектах одновременно и потому стоимость проекта там ниже, чем результат перемножения КолвоПрограммистов*КолвоМесяцев.
2. Олег Молочников (milkers) 1667 09.01.13 12:44 Сейчас в теме
(1) Согласен, я просто пытался показать, что серьезные вещи можно делать и в эконом сегменте. Да и один программист очень мало и рискованно на большой проект, и связанно, по большей части, со скупостью заказчика. Но как бы некорректно было сравнение проектов, оно наводит на некоторые размышления.
6. krein (krein) 61 09.01.13 23:04 Сейчас в теме
На чем велся учет до внедрения? Проект как-то делился на этапы?
Сроки, планируемые на этапе экспресс-обследования примерно совпали с фактическими?
Почему пришлось формы списка переделать на управляемые (на этом акцентировано внимание), с ними работают из браузеров?

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

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

В (2) правильный комментарий, действительно есть совсем разный подход к проектам, это зависит большей частью от заказчиков...
Есть в таких случаях "одиночного внедрения" и проекты, брошенные на полпути, все зависит от конкретных людей конечно..
11. Олег Молочников (milkers) 1667 10.01.13 11:34 Сейчас в теме
(6) krein,
а чем велся учет до внедрения?

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


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

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

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

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

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

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

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

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


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

Да, я обычно устраиваюсь к заказчику на срок выполнения проекта. Потом ищу другой проект. Нельзя сказать что это фикси в чистом виде.
3. Андрей (AKV77) 222 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 Ответить
8. Александр Жебряков (GPL) 09.01.13 23:22 Сейчас в теме
(3) AKV77, как вариант, если спецы франча имели опыт внедрения на аналогичном предприятии и менеджер проекта может убедить руководство проломить коллектив на "как надо", а не "как хочется Марье Васильевне" )))
помню Апрель в Белом Парусе чего-то внедрял, до организации дошло, что своих спецов нужно иметь
9. Андрей (AKV77) 222 10.01.13 09:54 Сейчас в теме
(8) GPL, полностью согласен с тем что при внедрении любого серьезного проекта требуется собственный специалист (или команда). Хотя бы для того, чтобы отвечать на различные "глупые" вопросы пользователей, которые наверняка у них будут появляться в процессе работы как минимум в первые несколько месяцев после запуска проекта в рабочую эксплуатацию. Неговоря уже о сложностях при закрытии месяца, года, расчета себестоимости и т.д. Необходимо также отметить тот факт, что любой руководитель хочет видет четко отлаженную систему учета, но "подводные камни" и дополнительные "хотелки" при ее эксплуатации возникают зачастую уже после завершения тестовой эксплуатации проекта. И как следствие директор не хочет привлекать к работе сторонних специалистов, дабы не увеличивать и так не малые финансовые затраты.
4. qweasd qweasdzc (serega3333) 09.01.13 17:17 Сейчас в теме
В управленческом учете детализация учета – рулон (на складе рулонных материалов) и стандартные единицы измерения на других складах. При выгрузке в базу регламентного учет происходит уменьшение детализации учета до килограммов (на складе рулонных материалов). Также, из-за того, что у материалов с разной шириной могут быть разные закупочные цены и, соответственно, разные цены списания, а бухгалтерский учет ведется без учета характеристик номенклатуры, то происходит трансформация номенклатуры+ширины в новую позицию номенклатуры с кодом, состоящим из кода номенклатуры и ширины. После выгрузки периода существуют специальные отчеты, позволяющие найти исправить расхождения в учетах, если они возникнут.

а можно про это поподробней. столкнулся с такой же ситуацией - есть листы железа, из них делают блоки для ворот въездных. как построить учет чтобы видеть поступление в штуках, а списывать в м2. Просто на примере рулонов можете показать как грамотно увязать цены, метры, штуки...
5. Олег Молочников (milkers) 1667 09.01.13 17:29 Сейчас в теме
(4) Самый простой вариант, если листы железа имеют несколько типовых форматов (а так чаще всего и происходит), то переделывать ничего не надо, используем стандартный функционал.
Вар. 1. Приходуем Лист железа формата ФЛ18(6 кв. метров) как 1 штуку. Создаем дополнительную еденицу измерения м2 c коэффициентом = 1/6. Теперь при продаже 1 м2 позиции ФЛ18 будет списываться 1/6 от единицы хранения. Единицей отчетов лучше сделать м2.
Если этот вариант не подойдет, объясните подумаем еще.
10. Андрей (AKV77) 222 10.01.13 10:03 Сейчас в теме
И еще не маловажный фактор. Своих спецов необходимо обучать !!! Желательно в Москве (если есть такая возможность), т.к. при всем уважении, уровень курсов читаемых во франчах в регионах значительно ниже чем в УЦ 1С в Москве. Это мое субъективное мнение. Сам обучался и в Москве и в Нижнем Новгороде, поэтому и сравниваю.
13. Игорь Исхаков (Ish_2) 985 11.01.13 19:10 Сейчас в теме
Насколько всё было хорошо сделано,
корректно ли вообще сравнение двух обозначенных автором проектов
- все эти вопросы правомерны и кто там разберет..., но жанр "Знай наших !!" мне настолько нравится ,
что скажу только одно : Олег , так и надо ! Молодца.
14. Алексей 1 (all_i_ance) 12.01.13 00:21 Сейчас в теме
(13) Ish_2, полностью согласен :)
15. Матти Нюкянен (Nykyanen) 215 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) 1667 15.01.13 14:35 Сейчас в теме
(16) okref, П - это означает, что все документы распечатаны и переданы клиенту. Бухгалтерии так удобно.
18. Алексей Рябцев (okref) 15.01.13 16:34 Сейчас в теме
Просто у нас так же. Я удивился что в хорошо переработанной базе живет и здравствует такой простой механизм.
19. Олег Молочников (milkers) 1667 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) 630 17.01.13 10:40 Сейчас в теме
При сравнении стоимости необходимо учесть, что больший в 4 раза срок реализации означает, что предприятие 18 месяцев несло много дополнительных затрат. Отсутствие автоматизации - это излишки одинк материалов и недостаток других, а значит простои производства, транспорта и т.п. С учетом этих факторов нередко бывает дешевле заплатить дороже, но получить результат быстрее. Вообще по моему пониманию в при ИТ сфере как раз экономический эффект и является определяющим, собственно прямые затраты вообще мало что значат (если конечно речь не идет про супердорогой софт типа САПа)
22. Олег Молочников (milkers) 1667 17.01.13 17:00 Сейчас в теме
(21) nafa,
При сравнении стоимости необходимо учесть, что больший в 4 раза срок реализации означает, что предприятие 18 месяцев несло много дополнительных затрат. Отсутствие автоматизации - это излишки одинк материалов и недостаток других, а значит простои производства, транспорта и т.п. С учетом этих факторов нередко бывает дешевле заплатить дороже, но получить результат быстрее. Вообще по моему пониманию в при ИТ сфере как раз экономический эффект и является определяющим, собственно прямые затраты вообще мало что значат (если конечно речь не идет про супердорогой софт типа САПа)

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

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

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