Перейти к публикации
forum-okna.ru

Давайте поговорим о ПС4 и его функционале


Rexther

Рекомендованные сообщения

Ещё одна идея.

У любой оконной компании существут "стандартная" продукция и какие-то дополнительные штучки. Все материалы для изготовления стандартной продукции постоянно есть на складе в нужном количестве (иначе увольняем логистов), а некоторые дополнительные позиции поставляются только под заказ, причем не все они имеются даже у регионального поставщика - нужна поставка из Москвы или, вообще, из Германии. Идея в том, чтобы программа подсказывала менеджеру ещё на этапе расчёта проекта, что срок изготовления будет больше стандартного из-за ожидания поставки отдельных материалов (технологический цикл изготовления при этом не увеличится, просто придётся реальный запуск в производство откладывать до поступления материалов на склад).

Как это можно реализовать.

1. В таблице "Тариф МЦ" нужно ввести дополнительное поле "Срок поставки" (тип AsInt), в которое по умолчанию при создании новой строки будет вводиться значение "0", а настройщик базы может заменить его на реальное количество дней, необходимых для поставки этого материала в этом цвете - эту информацию ему дадут логисты предприятия на основании договоров с поставщиками. Почему вводить такое поле нужно именно в тариф? Например, оконные ручки белого и коричневого цвета всегда поддерживаются на складе, а 5-10, а то и больше "экзотических" цветов поставляются под заказ.

2. Такое же дополнительное поле вводим в таблицу Спецификации - при расчете спецификации в каждую строку подставляется значение, соответствующее артикулу и текстуре примененного материала. Это позволит легко создать отчет, показывающий какие конкретно материалы "задерживают" готовность заказа.

3. Аналогичное поле нужно и в таблице Проекты, а попадать туда, в процессе ценового расчёта проекта, должно максимальное значение из всех имеющихся в спецификации проекта. И в том случае, если это значение оказалось больше нуля, должно появиться окно с подсказкой типа "Срок поставки материалов по проекту составляет N рабочих дней".

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

 

Жду критики либо поддержки.

Ссылка на комментарий
Поделиться на других сайтах


Оконный портал tybet.ru | Подписка на новости | Бесплатные объявления | Наша телега | База оконных знаний | ОНЛАЙН-ВЫСТАВКА



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

Идея может и не плохая, но очень специфичная.

 

Мы вот с чем сталкнулись. Терминальная версия, модуль корпоративного ценообразования. Есть закладка расчёта проекта для дилера. Но все работы, которые считает дилер, кем бы они небыли созданы, отражаются в нашем расчёте проекта. Тоже самое и с комплектацией, если дилер её у нас не берёт, а предоставить полноценный расчёт заказчику хочется. Нет возможности, чтобы цена фигурировала за работы или за комплектацию только в расчёте дилера. А т.к. она проявляется и у нас, как нам вести учёт стоимости проекта с дилером. Вот это уже проблема. Может кто-то уже нашёл выход. Мы пока не знаем, что делать.. :huh:

Ссылка на комментарий
Поделиться на других сайтах

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

Ссылка на комментарий
Поделиться на других сайтах

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

У них терминалка. Хотят работать в одной БД с дилерами.

Ссылка на комментарий
Поделиться на других сайтах

У них терминалка. Хотят работать в одной БД с дилерами.

Не получится.

Да и бред это - запускать заказы в производство из той же базы, что и дилеры.

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

Ссылка на комментарий
Поделиться на других сайтах

Не получится.

Да и бред это - запускать заказы в производство из той же базы, что и дилеры.

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

Почему?

Ссылка на комментарий
Поделиться на других сайтах

Потому что:

Мы вот с чем столкнулись. Терминальная версия, модуль корпоративного ценообразования. Есть закладка расчёта проекта для дилера. Но все работы, которые считает дилер, кем бы они небыли созданы, отражаются в нашем расчёте проекта. Тоже самое и с комплектацией, если дилер её у нас не берёт, а предоставить полноценный расчёт заказчику хочется. Нет возможности, чтобы цена фигурировала за работы или за комплектацию только в расчёте дилера. А т.к. она проявляется и у нас, как нам вести учёт стоимости проекта с дилером. Вот это уже проблема. Может кто-то уже нашёл выход. Мы пока не знаем, что делать.. :huh:

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

Все это мешает.

 

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

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

Ссылка на комментарий
Поделиться на других сайтах

Не получится.

Да и бред это - запускать заказы в производство из той же базы, что и дилеры.

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

Всё ок, временные проекты будем чистить периодически, чтобы не раздувать базу, а делить производство от расчётов при том кол-ве фильтров, что есть не составит труда. Сейчас разработчики взялись за некоторые доработки, связанные с взаимоотношениями с дилерами. Отчёты, тоже, напишем. Мы для этого на терминалку и ушли, чтобы задача наших менеджеров заключалась в проверке правильности конструкций, приём оплат и запуск в производство, а дублирование проектов ещё больше увеличит вес базы, что и приведёт к тормозам.

 

У нас сейчас один человек занимается, заносит в 1с проекты (себестоимость, стоимость работы и т.п), это нужно кучу операций сделать, а, ну да, ещё и оплаты. А зачем, когда всё есть в пс. Правильно настроить полномочия, создать нужные отчёты - всем этим хозяйством, вместо пятерых, может, вообще, один человек управлять. Сегодня показал менеджеру, которая занимается заявками на стеклопакеты (раньше делали из проекта), групповой доработанный под нас отчёт-заявка на стеклопакеты унифицированная, групповые накладные на отгрузку, групповой расчёт зар/платы цеха за месяц, хотим сделать отчёт спецификация изделия для запила, тоже, групповой. Она меня спросила, а что мне потом на работе делать? Т.е. экономия по времени раз в 20.

Ссылка на комментарий
Поделиться на других сайтах

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

Ссылка на комментарий
Поделиться на других сайтах

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

Идея может и не плохая, но очень специфичная.

Конечно, сейчас всё работает и без этого, персонал время от времени приходится взбадривать, основная проблема - с дилерами, работающими в терминале.

Они совершенно не заморачиваются такими вопросами, подписывают со своим клиентом договор со стандартными сроками изготовления, а мы ни сном, ни духом. И ситуация выплывает наружу, в лучшем случае, при запуске в производство, а до готовности уже, лишь, 2 - 3 дня. Причем, многие дилеры наступают на эти грабли неограниченное количество раз. А вот если, уже на стадии расчёта, программа заставит его остепениться - вот это будет здорово.

 

Мы вот с чем сталкнулись. Терминальная версия, модуль корпоративного ценообразования. Есть закладка расчёта проекта для дилера. Но все работы, которые считает дилер, кем бы они небыли созданы, отражаются в нашем расчёте проекта. Тоже самое и с комплектацией, если дилер её у нас не берёт, а предоставить полноценный расчёт заказчику хочется. Нет возможности, чтобы цена фигурировала за работы или за комплектацию только в расчёте дилера. А т.к. она проявляется и у нас, как нам вести учёт стоимости проекта с дилером. Вот, это уже проблема. Может кто-то уже нашёл выход. Мы пока не знаем, что делать..

 

Потому что: Выход один - дилер своему заказчику считает свой заказ, а на завод отправляет копию без работ, без комплектации и с дилерской скидкой - иначе как проводить взаиморасчеты по бухгалтерии?

 

Тема действительно актуальная, и никакими настройками базы, при существующем функционале, её не решить.

Нужно разделить все работы на "Работы производителя" и "Работы дилера" (какой-то флаг при настройке), и вторые приплюсовывать только к цене дилера.

Если дилер берёт комплектацию "на стороне", это никак не может относиться к нашим комплектующим с нашими ценами и т.д. и т.п. - пусть дилер рассчитывает её в сторонней программе или на калькуляторе (объёмы, как правило, позволяют), а для внесения в ПрофСтрой нужен механизм, схожий с работами, м.б. третий кроме 2-х вышеуказанных типов работ - "Комплектация производителя", также попадающая только в цену дилера.

И ещё - в таком заказе существуют не только контрагент и продавец, а ещё и третье юр. или физ.лицо. Предложение: Контрагентом проекта должен быть именно дилер (с ним мы имеем финансовые взаимоотношения), плюс необходимо дополнительное поле ("Клиент"?), в которое дилер будет вносить своего заказчика. При заведении дилером новых заказчиков, они должны автоматически получать некую специальную категорию в общей таблице контрагентов и не предлагаться к выбору в поле проекта "Контрагент", но предлагаться в поле "Клиент". А менеджеры головной фирмы наоборот, не могут заводить "Клиентов", но могут "Контрагентов". Таким образом, мы чётко разделим всех, вносимых в программу заказчиков, на тех, кто имеет финансовые взаимоотношения с головной фирмой и тех, кто не имеет. А наличие 3-х юр/физ лиц в одном заказе позволит легко создать отчёты для взаимоотношений "Производитель - Дилер" и "Дилер - Клиент".

Ссылка на комментарий
Поделиться на других сайтах

Ещё одна идея.

.....

Идея жизненная (это поддержка была :thumbsup: )

Только шибко громоздкая ...

В спецификацию, для КАЖДОГО элемента что-то писать ... Да еще в МЦ это для каждого артикула настраивать ...

...

Идея, как это решить у меня есть. Хотелось бы послушать, от чего зависит увеличение срока поставки...

Понятно, что от формы профиля и заполнений (арки, например), понятно, что от определенных текстур профиля и заполнений. НУ, наверно, и от фурнитуры и от резинки (ну, хочет клиент синюю (условно) резину - бывает????). От чего еще?

Достаточно ли будет вывода предупреждения?

 

.....

И ещё - в таком заказе существуют не только контрагент и продавец, а ещё и третье юр. или физ.лицо. Предложение: Контрагентом проекта должен быть именно дилер (с ним мы имеем финансовые взаимоотношения), плюс необходимо дополнительное поле ("Клиент"?), в которое дилер будет вносить своего заказчика. При заведении дилером новых заказчиков, они должны автоматически получать некую специальную категорию в общей таблице контрагентов и не предлагаться к выбору в поле проекта "Контрагент", но предлагаться в поле "Клиент". А менеджеры головной фирмы наоборот, не могут заводить "Клиентов", но могут "Контрагентов". Таким образом, мы чётко разделим всех, вносимых в программу заказчиков, на тех, кто имеет финансовые взаимоотношения с головной фирмой и тех, кто не имеет. А наличие 3-х юр/физ лиц в одном заказе позволит легко создать отчёты для взаимоотношений "Производитель - Дилер" и "Дилер - Клиент".

Не вполне согласен.

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

Дилер - группа пользователей.

Контрагенту может сразу, при создании присваиваться номер группы пользователя.

В Проекте Контрагент - Заказчик дилера, дилер - менеджер. А с кем работает дилер - поставщик конструкций, переработчик - и так ясно.

А дальше уже исключительно вопрос создания отчетов.

И, кстати, Контриков при обмене данными по проектам, тоже, можно передавать. Т.е. ничего не разрушается даже при перегрузке из одной БД в другую...

Как-то так думаю.

Ссылка на комментарий
Поделиться на других сайтах

Тоже уже по этой теме думал, при создании проекта дилером, в поле "контрагент" должно автоматом ставится его название, Самое неудобное ещё то, что при выборе контрагента, там в куче и дилеры и розница, и поставщики, это список может быть на несколько тысяч. Как искать? Категория клиент необходима, чтобы отделить основных покупателей от временных (клиент). В списке проектов, тоже, как сортировать по основным покупателям, на контрагенте может быть несколько менеджеров и отделов, соответственно, через эти фильтры отпадает, а фильтр контрагент засорён временными данными. Конечно, можно на клаве набрать, но как-то неудобно. А ещё лучше, чтобы у дилеров были свои списки клиентов, и к чужим не попадали (не знаю, может это уже и так, не проверял).

Ссылка на комментарий
Поделиться на других сайтах

Конечно, сейчас всё работает и без этого, персонал время от времени приходится взбадривать, основная проблема - с дилерами, работающими в терминале.

Они совершенно не заморачиваются такими вопросами, подписывают со своим клиентом договор со стандартными сроками изготовления, а мы ни сном, ни духом. И ситуация выплывает наружу, в лучшем случае, при запуске в производство, а до готовности уже, лишь, 2 - 3 дня. Причем, многие дилеры наступают на эти грабли неограниченное количество раз. А вот если, уже на стадии расчёта, программа заставит его остепениться - вот это будет здорово.

 

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

 

Можно через параметр, если разработчикам сложно возиться с мат. ценностями, или приведёт к тормозам. Если вы зададите параметр доп. фурнитуре 30 дней, или стеклопакет или профиль, разработчикам дать задание и, у вас выскакивает окно: срок изготовления столько-то дней, как с ограничением фурнитуры и стеклопакета по размерам. Только нужно найти место для этого параметра, куда приделать, думаю так проще, (разработчики, идея достаточно проста :) )

Ссылка на комментарий
Поделиться на других сайтах

Идея жизненная (это поддержка была :thumbsup: ) Только шибко громоздкая ... В спецификацию, для КАЖДОГО элемента что-то писать ... Да еще в МЦ это для каждого артикула настраивать ... ... Идея, как это решить у меня есть.

 

 

 

Понятно, что высказываемые здесь идеи – это не руководство к действию, а приглашение к обсуждению заинтересованных лиц. Одна голова – хорошо, а куча голов гораздо лучше. Бесспорно, Ваша идея может оказаться и лучше моей. Может, поделитесь тем, что предлагаете Вы? Но и свою хочу попытаться защитить.

 

В спецификацию каждого элемента добавляется одно поле – сейчас их 36, станет 37 – сильно ли «потяжелеет»? В тарифе МЦ сейчас 14 полей, а в Списке проектов 79! Настраивать спецификации каких-либо конструктивов не нужно – поле заполняется так же, как тип и подтип МЦ. А настройка в МЦ нужна не для всех, а именно для «экзотических» случаев – по умолчанию ставим 0, как цену по умолчанию ставим 100.

 

 

Хотелось бы послушать, от чего зависит увеличение срока поставки...

 

 

Когда-то от ФОРМЫ и ТЕКСТУР профиля и заполнений, а когда-то просто от АРТИКУЛА, независимо от формы и текстур. А так, все приходящие на ум случаи, Вы перечислили.

 

 

Достаточно ли будет вывода предупреждения?

 

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

Попробую возразить.

Дилер - группа пользователей.

Контрагенту может сразу, при создании присваиваться номер группы пользователя.

В Проекте Контрагент - Заказчик дилера, дилер - менеджер.

И вот дилер создал проект с контрагентом - своим заказчиком. На проект вносится оплата и попадает не на счёт дилера (как её отнести на менеджера?), а на счет его заказчика, с которым Производитель никаких договоров не подписывал, и как и где посмотреть финансовый баланс дилера, с учётом ВСЕХ его заказов по ВСЕМ его заказчикам? То есть, нужно именно два проекта: в одном контрагент - это заказчик дилера, этот проект просто висит в базе и в работу не заходит, а во втором контрагент - уже сам дилер и цена та, по которой мы продаём заказ дилеру.

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

Ссылка на комментарий
Поделиться на других сайтах

То есть, нужно, именно, два проекта: в одном контрагент - это заказчик дилера, этот проект просто висит в базе и в работу не заходит, а во втором контрагент - уже сам дилер и цена та, по которой мы продаём заказ дилеру.

А еще лучше три:

- Заказ, с помощью которого дилер оформил продажу конечному покупателю, с услугами и доп. товарами дилера и продажными ценами дилера.

- Заказ, в котором остались только те позиции, которые дилер заказывает у производителя, с ценами производителя для дилера.

- Заказ, который менеджеры дилерского отдела производителя обрабатывают и в работу отправляют

Средний (второй) документ нужен дилеру для сверки "что я хотел" и "что я получил".

 

Про сроки поставки материалов:

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

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

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

- если "максимальный срок поставки материалов под заказ" указывать в заказе, то что делать при пересчете заказа (перечень материалов со "сроки под заказ" может измениться)?

Ссылка на комментарий
Поделиться на других сайтах

Да, правильна была изначальная мысль, не должен быть обычный заказчик контрагентом, вообще, заказчик это временный объект, который итак уже награждён номером проекта, он нужен только чтобы в списке проектов упростить поиск по фамилии, а все финансовые отношения с большим кол-вом проектов должны связываться через контрагентов. Если мне нужно узнать, сколько нам должна мадам Сидорава за один заказ, я её найду по списку проектов, благо там ещё реализована функция настройки окон и всё прекрасно видно. А вот с ИП или ООО нужен более подробный анализ оплат отгрузок, и не важно кому они там, что продают. Главное, чтобы между нами взаимоотношения были более прозрачны и просты.

Ссылка на комментарий
Поделиться на других сайтах

Все мысли идут к CRM :). Я думаю, эти функции в ПС4 надо развивать, потому как интерес к нему у конечных пользователей приличный.

Ссылка на комментарий
Поделиться на других сайтах

.... Может, поделитесь тем, что предлагаете Вы? ...

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

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

Примерно, так думается.

Ссылка на комментарий
Поделиться на других сайтах

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

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

Примерно, так думается.

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

 

Мысли по разделению заказчиков между дилерами и головной компанией.

 

 

 

1. В списке контрагентов добавляем новую категорию «Покупатели» - это будут конечные потребители наших дилеров; к полномочию пользователя «Контрагенты, источники заказов» добавляем ещё одно – «Клиенты (покупатели) дилера».

 

Менеджерам дилера открывается это новое полномочие (старое – нет) и, они получают доступ к справочнику контрагентов со следующими ограничениями:

 

1) Они видят только категорию «Покупатели», при введении нового контрагента он автоматически получает эту категорию, изменение категории запрещено. При установленном в настройках интерфейса флаге «Автозаполнение группы пользователя при вводе контрагента» менеджеры дилера будут видеть в справочнике только своих покупателей и смогут свободно редактировать их данные. Сейчас они лишены такой возможности – им запрещён доступ в справочник, а если разрешить, то они смогут подредактировать, а то и удалить ЛЮБЫХ контрагентов.

 

2) В реквизитах контрагентов категории «Покупатели» отсутствуют опции «Прайс-лист», «Источник заказов», «Сальдо», «Кредитная линия», возможность регулирования скидок и вкладка «Платежи».

Для пользователей с открытым «старым» полномочием, но закрытым новым, категория «Покупатели» должна быть недоступна.

 

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

 

2. В таблице проектов добавляем новое поле – Покупатель.

 

3. Работа с проектами пользователей с открытым полномочием «Клиенты дилера».

 

При создании нового проекта должно автоматически заполниться поле «Контрагент» - туда попадает субъект, имеющий в справочнике категорию «Дилер» и соответствующую группу пользователей. Вносит такого субъекта в базу ответственный работник головного предприятия при заключении дилерского договора.

 

На главной странице проекта выбираются не «контрагенты», а «покупатели», естественно в списке открываются только «свои» и возможно создание нового «покупателя».

 

Фильтр списка проектов также принимает вид «покупатели», а не «контрагенты».

 

4. При работе с проектами менеджеров головной компании они по-прежнему выбирают «Контрагентов», а поле «Покупатель» либо должно оставаться пустым, либо туда копируется значение поля «Контрагент».

 

В фильтре списка проектов присутствуют именно «Контрагенты», т.е. дилеры плюс частные и корпоративные заказчики головного предприятия.

 

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

 

 

 

Сложно? Описывал долго, т.к. пытался учесть нюансы, а доработок, думается, не так много и в работе каждого конкретного пользователя не вижу особых усложнений, наоборот – всё как надо.

 

 

 

Про вычисление двух стоимостей – в следующий раз.

Ссылка на комментарий
Поделиться на других сайтах

  • 3 weeks later...

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

Ссылка на комментарий
Поделиться на других сайтах

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

Для Комплектов трудозатраты есть. Уже давно.

Для Откосов трудозатраты это фактически Работа типа "монтаж откосов" ...

Вообще, понятие Трудозатрат в ПС4 сводится к зарплате цеха.

Ссылка на комментарий
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    • Нет пользователей, просматривающих эту страницу.



×
×
  • Создать...

Важная информация

Условия и правила использования форума Правила.