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

[Kosmos]

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

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

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

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

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

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

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

 

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

[бывший прапорщик]

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

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

 

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

[Леха]

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

[Rexther]

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

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

[Леха]

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

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

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

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

[Rexther]

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

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

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

Почему?

[Леха]

Потому что:

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

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

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

 

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

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

[бывший прапорщик]

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

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

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

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

 

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

[Леха]

Когда сможете решить вопрос с разной стоимостью заказов - поделитесь, плиз... Очень интересно.

[алех slk]

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

[Kosmos]

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

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

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

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

 

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

 

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

 

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

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

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

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

[Rexther]

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

.....

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

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

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

...

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

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

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

 

.....

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

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

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

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

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

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

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

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

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

[бывший прапорщик]

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

[бывший прапорщик]

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

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

 

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

 

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

[Kosmos]

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

 

 

 

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

 

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

 

 

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

 

 

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

 

 

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

 

 

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

[Kosmos]

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

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

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

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

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

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

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

[А.Х.]

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

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

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

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

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

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

 

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

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

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

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

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

[бывший прапорщик]

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

[morfeus]

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

[Леха]

Оно есть.

[Rexther]

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

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

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

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

[Kosmos]

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

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

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

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

[Kosmos]

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

 

 

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

 

 

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

 

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

 

 

 

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

[PavelM]

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

[Rexther]

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

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

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

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