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

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

Опубликовано:

Для Откосов трудозатраты - это, фактически, Работа типа "монтаж откосов" ... Не совсем так, для Откосов - это фактически Работа типа "монтаж откосов", т.е за нее получают работу монтажники. К цеху это отношения не имеет.

 

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

 

P.S. Для комплектов, чтобы учитывались ТЗ в цене, еще нужно переписать отчет. А то, есть цена комплекта, но в ней не учитываются ТЗ.


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



Опубликовано:

Для Откосов трудозатраты - это, фактически, Работа типа "монтаж откосов" ... Не совсем так, для Откосов - это фактически Работатипа "монтаж откосов", т.е за нее получают работу монтажники. К цеху это отношения не имеет.

 

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

 

 

Ну м.б. ...

 

P.S. Для комплектов, чтобы учитывались ТЗ в цене, еще нужно переписать отчет. А то, есть цена комплекта, но в ней не учитываются ТЗ.

Какой отчет? В Т.П. писали?

Опубликовано:

Какой отчет? В Т.П. писали?

 

 

Коммерческое, (Смета, смета ценовая и т.п. - в этих отчетах комплект разбивается на составляющие, но это поправимо).

В Т.П. не писал.

Опубликовано:

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

..................

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

Прошёл месяц, но никакого обсуждения этой идеи не состоялось - неужели, такой вопрос стоит только перед нами?

А вот Профсегмент вчера анонсировал новый модуль, в котором эта идея реализуется.

Возможно, пригодятся мысли и про расчёты стоимости.

 

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

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

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

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

5. Стоимость на уровне "Дилер - Покупатель" - это стоимость "Производитель - Дилер" с учетом скидок проекта и наценок дилера плюс стоимость комплектов и работ, определенных для группы пользователей конкретного дилера.

 

И ещё. Настройки в "кабинете дилера", наверное, должен проводить уполномоченный пользователь типа "дилер" (из своей группы пользователей), но, также, все они должны быть доступны уполномоченному работнику головной фирмы - многим дилерам нужно будет помогать.

Опубликовано:

Прошёл месяц, ....

 

1. Скидки на профили .....

2. Наценки дилера .....

3. Скидки дилера....

4. В стоимость проекта на уровне ....

5. Стоимость на уровне .....

 

И ещё. ....

 

Все это и кое-что другое, как раз, и есть в новом модуле.

Опубликовано:

 

Все это и кое-что другое, как раз, и есть в новом модуле.

Очень здорово.

 

А теперь ещё одно предложение.

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

Проводится расчёт по проектной документации, коммерческая служба обрабатывает заказчика с учётом всех особенностей Российского ценообразования и заключается договор. А на объекте ещё никто не был, реальные размеры будущих изделий не замерял. Значит тот проект, по которому заключен договор, уйти в производство не может - как правило, создаются поэтапные отдельные проекты после замеров и всех уточнений. То есть, деньги заказчик платит на основании "большого" проекта, а в работу заходит кучка "маленьких" со своей стоимостью. Их сумма, как правило, не совпадает со стоимостью "большого" проекта и бухгалтерия постоянно ничего не может понять. Вывод: нужно как-то связать между собой "большой" и "маленькие" проекты для корректного отслеживания реальной стоимости и оплаты.

Предложение заключается в следующем:

Вводим новый признак классификации проектов по способу реализации:

1) Обычный - то, что имеем сейчас;

2) Договор - это наш "большой" проект;

3) Часть (стадия, этап) договора - это "маленький" внутри "большого".

 

Особенности "Договора":

1) Он не может быть запущен в производство;

2) По нему ведётся расчёт баланса так же, как по обычному проекту - возможно прямое внесение оплат или списание с предоплат, занесённых на счёт заказчика.

 

Особенности "Части договора":

1) При создании проекта программа спрашивает, к какому проекту - "Договору" привязать эту "часть" и выводит в список для выбора все "Договоры" этого заказчика;

2) Проект запускается в производство так же, как обычный;

3) Проект не участвует в расчете баланса и на него нельзя внести платёж или сделать списание с предоплат заказчика;

4) На этот проект могут быть отнесены деньги, поступившие в качестве оплаты на основной проект-"Договор", у "Договора" же ведётся учет перенесённых на зависимые проекты денег и остатка, доступного к переносу. Любые переносы туда - обратно никак не влияют на финансовый баланс;

5) Для визуального выделения таких проектов в общем списке нужны какие-то отметки или цвет фона в полях "Стоимость" и "Оплата" списка проектов.

 

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

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

Опубликовано:

Не надо это. Все решается проще - есть договор бухгалтерский - его сумма отражается в бухгалтерии, а есть исполнение заказов на производстве.

 

И не надо путать бухгалтерию и производственные задания! Профстрой - не бухгалтерская программа.

 

Никаких "больших и малых" договоров вводить категорически нельзя - база станет нестабильной и пойдет большая путаница.

 

Бюджет проекта можно написать в графе "примечания" - есть даже конфиденциальные примечания.

И оформить как лимит по кредиту.

Ну, в общем, что-то имеющимися средствами придумать всегда можно.

Опубликовано:
Очень здорово. А теперь ещё одно предложение.

Так делать сложно (обрабатывать один документ совсем по разным правилам в зависимости от "типа").

Проще сделать отдельный документ "Договор" и для Заказа (Проекта) опциональную ссылку на Договор.

 

А деньги (дебиторка) - "дэ юре" они вообще по Контрагенту.

Вести учет взаиморасчетов в разрезе Договоров - возможно, но у бухгалтерии будут (могут быть) сложности с отнесением денег на конкретный договор.

Опубликовано:

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

...Ну, в общем, что-то имеющимися средствами придумать всегда можно.

Последствия такого подхода выше уже указаны:

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

Всегда можно "придумать" правила работы, которые в какой-то степени сгладят/нивелируют негативные эффекты.

Но речь-то о дополнительных удобствах от автоматизации с помощью ПО.

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

Опубликовано:

Очень здорово.

 

А теперь ещё одно предложение.

.....

 

 

Сугубо ИМХО.

Все что выше описано, решается в существующем функционале.

 

Поясню, как я это вижу:

1. У каждого номера проекта м.б. суффикс. Ну, вот и можно рассматривать "обычный" проект - это проект, в номере которого нет суффикса. А "ДОГОВОР" – тот, у которого есть части с суффиксом.

2. Далее все решается отчетами и макросами, чтобы пользователи не ошибались, пишется макрос, который не дает вводить платежи в проектах с суффиксами. И пишутся отчеты, которые проводят нужную аналитику для расчетов - оплаты ведутся в проекте с суффиксом =0, его же стоимость можно зафиксировать как изначально оговоренный объем и цену, а реальная работа в проектах с суффиксом.

Т.е. пусть есть ДОГОВОР и проект № 358 - это начальные условия и объем. Реальные объемы и цены этого ОБЪЕКТА в проектах 358.1, 358.2 и т.д. Там же и стоимости - отчет просто сравнивает нужные цифры.

 

И никакой путаницы.

Если есть "обычные" проекты, у которых м.б. части с суффиксом (ну например переделка брака) можно вводить разветвление Категориями, Типами Проектов ... Категория, на мой взгляд, предпочтительнее в данном случае - на нее назначается %% оплаты для запуска в пр-во.

Опубликовано:

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

Опубликовано:

Лучше поменяйте систему оплаты.

Такую разработку профстрой бесплатно делать не будет.

У нас прошлым летом перешли с оплаты за кв.м. на оплату по углам.

Опубликовано:

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

Сейчас это возможно путем написания макроса.

В принципе в планах есть создание модуля расчета зарплаты. Не только для цеха, но и для менеджеров, для монтажников, доставщиков и т.д.

Но пока только в планах.

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

Речь конечно о ПС4, хотя в ПС3 тоже есть возможность создавать макросы и использовать их.

Опубликовано:

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

Опубликовано:

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

У меня такого нет ... Какая версия?

Опубликовано:

У меня такого нет ... Какая версия?

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

Опубликовано:

И ещё, насколько я помню в ПС-3 во вкладке "спецификация фурнитуры" можно было прописать разные комплекты по размерным диапазонам (т.е. например от 500 мм до 1000 мм две петли, а от 1001 мм до 1500 мм три петли), а в ПС-4 на этом месте только ограничение сторон.

Опубликовано:

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

 

У меня та же версия ... Обратитесь в техподдержку.

 

И ещё, насколько я помню в ПС-3 во вкладке "спецификация фурнитуры" можно было прописать разные комплекты по размерным диапазонам (т.е. например от 500 мм до 1000 мм две петли, а от 1001 мм до 1500 мм три петли), а в ПС-4 на этом месте только ограничение сторон.

Комплекты фурнитуры есть и сейчас. Они, правда, теперь Фурнитурные Наборы и их функционал расширен. В частности можно не указывать конкретную сторону в Наборе, а указать переменную, значение которой присваивается в той фурнитуре, в которую этот Набор вставляется.

Все настройки диапазонов на месте, ограничения сторон задаются, так же как и в ПС3.

Опубликовано:

Столкнулся с такими ситуациями:

1. При прописании штапика в заполнениях нужно усечь и горизонтальные и вертикальные штапики, делаю поправку на ... мм, но в этом случае углы реза даются 45/45, а нужно 90/90 и нет параметра выбора угла реза.

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

3. Происходит только в поворотных створках на горизонтальный штапик выдаются углы реза -90/90 и 90/-90. В глухих конструкциях всё нормально, когда режешь по биссектрисе тоже нормально без минусов.

Опубликовано:

 

Столкнулся с такими ситуациями:

1. При прописании штапика в заполнениях нужно усечь и горизонтальные и вертикальные штапики, делаю поправку на ... мм, но в этом случае углы реза даются 45/45, а нужно 90/90 и нет параметра выбора угла реза.

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

3. Происходит только в поворотных створках на горизонтальный штапик выдаются углы реза -90/90 и 90/-90. В глухих конструкциях всё нормально, когда режешь по биссектрисе тоже нормально без минусов.

Все Ваши вопросы относятся к зоне ответственности ТП разработчика. Адресуйте их туда, пожалуйста ...

Опубликовано:

Все Ваши вопросы относятся к зоне ответственности ТП разработчика. Адресуйте их туда, пожалуйста ...

В ТП мы обратимся. У меня вопрос: "Решаемо ли это всё в данной версии программы?"

Опубликовано:

Вот было бы хорошо, если бы один артикул профиля мог выступать в роли и коробки, и створки, и импоста!

Может ... Еще со времен ПС3 ...

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

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

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



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

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

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