PavelM Опубликовано: 11 апреля, 2013 Опубликовано: 11 апреля, 2013 Для Откосов трудозатраты - это, фактически, Работа типа "монтаж откосов" ... Не совсем так, для Откосов - это фактически Работа типа "монтаж откосов", т.е за нее получают работу монтажники. К цеху это отношения не имеет. Понятие Трудозатрат в ПС4 сводится к зарплате цеха - я об этом и говорю, а рабочий, который пилит материал для установки откосов, как быть с ним? P.S. Для комплектов, чтобы учитывались ТЗ в цене, еще нужно переписать отчет. А то, есть цена комплекта, но в ней не учитываются ТЗ.
Rexther Опубликовано: 11 апреля, 2013 Автор Опубликовано: 11 апреля, 2013 Для Откосов трудозатраты - это, фактически, Работа типа "монтаж откосов" ... Не совсем так, для Откосов - это фактически Работатипа "монтаж откосов", т.е за нее получают работу монтажники. К цеху это отношения не имеет. Понятие Трудозатрат в ПС4 сводится к зарплате цеха - я об этом и говорю, а рабочий, который пилит материал для установки откосов, как быть с ним? Ну м.б. ... P.S. Для комплектов, чтобы учитывались ТЗ в цене, еще нужно переписать отчет. А то, есть цена комплекта, но в ней не учитываются ТЗ. Какой отчет? В Т.П. писали?
PavelM Опубликовано: 11 апреля, 2013 Опубликовано: 11 апреля, 2013 Какой отчет? В Т.П. писали? Коммерческое, (Смета, смета ценовая и т.п. - в этих отчетах комплект разбивается на составляющие, но это поправимо). В Т.П. не писал.
Kosmos Опубликовано: 16 апреля, 2013 Опубликовано: 16 апреля, 2013 Мысли по разделению заказчиков между дилерами и головной компанией. .................. Про вычисление двух стоимостей – в следующий раз. Прошёл месяц, но никакого обсуждения этой идеи не состоялось - неужели, такой вопрос стоит только перед нами? А вот Профсегмент вчера анонсировал новый модуль, в котором эта идея реализуется. Возможно, пригодятся мысли и про расчёты стоимости. 1. Скидки на профили / аксесуары / погонаж / заполнения сейчас задаются по умолчанию в справочнике контрагентов, но пользователь программы никак не ограничен в установке любых (вплоть до 100%) значений внутри проекта. Нужно либо ограничить максимальные значения всех этих скидок, либо (ещё лучше), вообще, убрать возможность их изменения в каждом конкретном проекте. Тогда эти скидки станут инструментом "индивидуальной настройки" цены, по которой головная компания продаёт свою продукцию тому или иному дилеру, помимо общей дилерской скидки - и вводить эти значения должен только пользователь со специальным полномочием. 2. Наценки дилера на конструкции / комплектацию / работы, тоже, нужно задавать не внутри проекта, а где-то в "кабинете дилера" - опять-таки, по специальному полномочию ответственным работником дилера или, по его просьбе, ответственным работником головной компании. У каждого дилера такие наценки могут быть свои, но постоянные от проекта к проекту. 3. Скидки дилера (на конструкции, комплектацию, работы, общая и дополнительная), устанавливаемые пользователем - менеджером дилера, также, должны ограничиваться в "кабинете дилера" отдельно для каждого дилера (группы пользователей). 4. В стоимость проекта на уровне "Производитель - Дилер" должны включаться только те комплекты и работы, которые определены для основной компании (любой дилер может, при желании, воспользоваться полным спектром услуг головной компании). 5. Стоимость на уровне "Дилер - Покупатель" - это стоимость "Производитель - Дилер" с учетом скидок проекта и наценок дилера плюс стоимость комплектов и работ, определенных для группы пользователей конкретного дилера. И ещё. Настройки в "кабинете дилера", наверное, должен проводить уполномоченный пользователь типа "дилер" (из своей группы пользователей), но, также, все они должны быть доступны уполномоченному работнику головной фирмы - многим дилерам нужно будет помогать.
Rexther Опубликовано: 17 апреля, 2013 Автор Опубликовано: 17 апреля, 2013 Прошёл месяц, .... 1. Скидки на профили ..... 2. Наценки дилера ..... 3. Скидки дилера.... 4. В стоимость проекта на уровне .... 5. Стоимость на уровне ..... И ещё. .... Все это и кое-что другое, как раз, и есть в новом модуле.
Kosmos Опубликовано: 23 апреля, 2013 Опубликовано: 23 апреля, 2013 Все это и кое-что другое, как раз, и есть в новом модуле. Очень здорово. А теперь ещё одно предложение. При работе со строительными компаниями и корпоративными заказчиками часто возникает такая ситуация: Проводится расчёт по проектной документации, коммерческая служба обрабатывает заказчика с учётом всех особенностей Российского ценообразования и заключается договор. А на объекте ещё никто не был, реальные размеры будущих изделий не замерял. Значит тот проект, по которому заключен договор, уйти в производство не может - как правило, создаются поэтапные отдельные проекты после замеров и всех уточнений. То есть, деньги заказчик платит на основании "большого" проекта, а в работу заходит кучка "маленьких" со своей стоимостью. Их сумма, как правило, не совпадает со стоимостью "большого" проекта и бухгалтерия постоянно ничего не может понять. Вывод: нужно как-то связать между собой "большой" и "маленькие" проекты для корректного отслеживания реальной стоимости и оплаты. Предложение заключается в следующем: Вводим новый признак классификации проектов по способу реализации: 1) Обычный - то, что имеем сейчас; 2) Договор - это наш "большой" проект; 3) Часть (стадия, этап) договора - это "маленький" внутри "большого". Особенности "Договора": 1) Он не может быть запущен в производство; 2) По нему ведётся расчёт баланса так же, как по обычному проекту - возможно прямое внесение оплат или списание с предоплат, занесённых на счёт заказчика. Особенности "Части договора": 1) При создании проекта программа спрашивает, к какому проекту - "Договору" привязать эту "часть" и выводит в список для выбора все "Договоры" этого заказчика; 2) Проект запускается в производство так же, как обычный; 3) Проект не участвует в расчете баланса и на него нельзя внести платёж или сделать списание с предоплат заказчика; 4) На этот проект могут быть отнесены деньги, поступившие в качестве оплаты на основной проект-"Договор", у "Договора" же ведётся учет перенесённых на зависимые проекты денег и остатка, доступного к переносу. Любые переносы туда - обратно никак не влияют на финансовый баланс; 5) Для визуального выделения таких проектов в общем списке нужны какие-то отметки или цвет фона в полях "Стоимость" и "Оплата" списка проектов. При такой системе сразу будет видно, что деньги на основном "Договоре" уже закончились, и мы уходим в минус, или же наоборот легко определяем дополнительную маржу, которую получили на этом объекте. Если ушли в минус, показываем заказчику реальные затраты и стараемся получить дополнительную оплату, увеличиваем сумму основного "Договора" и у нас появляются деньги для финансового покрытия всех частей.
Леха Опубликовано: 23 апреля, 2013 Опубликовано: 23 апреля, 2013 Не надо это. Все решается проще - есть договор бухгалтерский - его сумма отражается в бухгалтерии, а есть исполнение заказов на производстве. И не надо путать бухгалтерию и производственные задания! Профстрой - не бухгалтерская программа. Никаких "больших и малых" договоров вводить категорически нельзя - база станет нестабильной и пойдет большая путаница. Бюджет проекта можно написать в графе "примечания" - есть даже конфиденциальные примечания. И оформить как лимит по кредиту. Ну, в общем, что-то имеющимися средствами придумать всегда можно.
А.Х. Опубликовано: 23 апреля, 2013 Опубликовано: 23 апреля, 2013 Очень здорово. А теперь ещё одно предложение. Так делать сложно (обрабатывать один документ совсем по разным правилам в зависимости от "типа"). Проще сделать отдельный документ "Договор" и для Заказа (Проекта) опциональную ссылку на Договор. А деньги (дебиторка) - "дэ юре" они вообще по Контрагенту. Вести учет взаиморасчетов в разрезе Договоров - возможно, но у бухгалтерии будут (могут быть) сложности с отнесением денег на конкретный договор.
А.Х. Опубликовано: 23 апреля, 2013 Опубликовано: 23 апреля, 2013 все решается проще - есть договор бухгалтерский - его сумма отражается в бухгалтерии, а есть исполнение заказов на производстве. ...Ну, в общем, что-то имеющимися средствами придумать всегда можно. Последствия такого подхода выше уже указаны: То есть, деньги заказчик платит на основании "большого" проекта, а в работу заходит кучка "маленьких" со своими стоимостями. Их сумма, как правило, не совпадает со стоимостью "большого" проекта и бухгалтерия постоянно ничего не может понять. Всегда можно "придумать" правила работы, которые в какой-то степени сгладят/нивелируют негативные эффекты. Но речь-то о дополнительных удобствах от автоматизации с помощью ПО. Плюс, чем больше правил, тем большая зависимость организации от людей, которые эти правила знают.
Rexther Опубликовано: 23 апреля, 2013 Автор Опубликовано: 23 апреля, 2013 Очень здорово. А теперь ещё одно предложение. ..... Сугубо ИМХО. Все что выше описано, решается в существующем функционале. Поясню, как я это вижу: 1. У каждого номера проекта м.б. суффикс. Ну, вот и можно рассматривать "обычный" проект - это проект, в номере которого нет суффикса. А "ДОГОВОР" – тот, у которого есть части с суффиксом. 2. Далее все решается отчетами и макросами, чтобы пользователи не ошибались, пишется макрос, который не дает вводить платежи в проектах с суффиксами. И пишутся отчеты, которые проводят нужную аналитику для расчетов - оплаты ведутся в проекте с суффиксом =0, его же стоимость можно зафиксировать как изначально оговоренный объем и цену, а реальная работа в проектах с суффиксом. Т.е. пусть есть ДОГОВОР и проект № 358 - это начальные условия и объем. Реальные объемы и цены этого ОБЪЕКТА в проектах 358.1, 358.2 и т.д. Там же и стоимости - отчет просто сравнивает нужные цифры. И никакой путаницы. Если есть "обычные" проекты, у которых м.б. части с суффиксом (ну например переделка брака) можно вводить разветвление Категориями, Типами Проектов ... Категория, на мой взгляд, предпочтительнее в данном случае - на нее назначается %% оплаты для запуска в пр-во.
Форточник Опубликовано: 24 апреля, 2013 Опубликовано: 24 апреля, 2013 А вот если оплата труда в цехе считается по м2 и на разные изделия своя цена, можно ли привязать стоимость сборки м2 конструкций к каждому типу подсистем, чтобы сборка автоматом учитывалась в себестоимости и не надо было вбивать работы?
Леха Опубликовано: 24 апреля, 2013 Опубликовано: 24 апреля, 2013 Лучше поменяйте систему оплаты. Такую разработку профстрой бесплатно делать не будет. У нас прошлым летом перешли с оплаты за кв.м. на оплату по углам.
Rexther Опубликовано: 24 апреля, 2013 Автор Опубликовано: 24 апреля, 2013 А вот если оплата труда в цехе считается по м2 и на разные изделия своя цена, можно ли привязать стоимость сборки м2 конструкций к каждому типу подсистем, чтобы сборка автоматом учитывалась в себестоимости и не надо было вбивать работы? Сейчас это возможно путем написания макроса. В принципе в планах есть создание модуля расчета зарплаты. Не только для цеха, но и для менеджеров, для монтажников, доставщиков и т.д. Но пока только в планах. А макрос можно писать, прям сейчас - если не можете сами, то обращайтесь в техподдержку. Речь конечно о ПС4, хотя в ПС3 тоже есть возможность создавать макросы и использовать их.
Форточник Опубликовано: 24 апреля, 2013 Опубликовано: 24 апреля, 2013 А вот ещё вопрос, почему, когда в мат. ценностях прописываешь % отхода, после выхода цифра обнуляется и чтобы установить его нужно выйти и ещё раз зайти?
Rexther Опубликовано: 24 апреля, 2013 Автор Опубликовано: 24 апреля, 2013 А вот ещё вопрос, почему, когда в мат. ценностях прописываешь % отхода, после выхода цифра обнуляется и чтобы установить его нужно выйти и ещё раз зайти? У меня такого нет ... Какая версия?
Форточник Опубликовано: 24 апреля, 2013 Опубликовано: 24 апреля, 2013 У меня такого нет ... Какая версия? 4.03.87 В общем, чтобы поставить % отхода в новом вводимом профиле нужно сначала выйти, потом зайти, тогда значение сохраняется.
Форточник Опубликовано: 24 апреля, 2013 Опубликовано: 24 апреля, 2013 И ещё, насколько я помню в ПС-3 во вкладке "спецификация фурнитуры" можно было прописать разные комплекты по размерным диапазонам (т.е. например от 500 мм до 1000 мм две петли, а от 1001 мм до 1500 мм три петли), а в ПС-4 на этом месте только ограничение сторон.
Rexther Опубликовано: 24 апреля, 2013 Автор Опубликовано: 24 апреля, 2013 4.03.87 В общем, чтобы поставить % отхода в новом вводимом профиле нужно сначала выйти, потом зайти, тогда значение сохраняется. У меня та же версия ... Обратитесь в техподдержку. И ещё, насколько я помню в ПС-3 во вкладке "спецификация фурнитуры" можно было прописать разные комплекты по размерным диапазонам (т.е. например от 500 мм до 1000 мм две петли, а от 1001 мм до 1500 мм три петли), а в ПС-4 на этом месте только ограничение сторон. Комплекты фурнитуры есть и сейчас. Они, правда, теперь Фурнитурные Наборы и их функционал расширен. В частности можно не указывать конкретную сторону в Наборе, а указать переменную, значение которой присваивается в той фурнитуре, в которую этот Набор вставляется. Все настройки диапазонов на месте, ограничения сторон задаются, так же как и в ПС3.
Леха Опубликовано: 24 апреля, 2013 Опубликовано: 24 апреля, 2013 Надо будет переделать средние запоры по технологии П4.
Форточник Опубликовано: 29 апреля, 2013 Опубликовано: 29 апреля, 2013 Столкнулся с такими ситуациями: 1. При прописании штапика в заполнениях нужно усечь и горизонтальные и вертикальные штапики, делаю поправку на ... мм, но в этом случае углы реза даются 45/45, а нужно 90/90 и нет параметра выбора угла реза. 2. Создаю параметр выбор штапика "полукруглый или прямоугольный", но для некоторых толщин заполнения полукруглого штапика не существует, а девушки-менеджеры об этом не знают или забывают и получается, что при выборе параметра "полукруглый" штапик, вообще, не считается. Как бы сделать ограничения по использованию параметра? 3. Происходит только в поворотных створках на горизонтальный штапик выдаются углы реза -90/90 и 90/-90. В глухих конструкциях всё нормально, когда режешь по биссектрисе тоже нормально без минусов.
Rexther Опубликовано: 29 апреля, 2013 Автор Опубликовано: 29 апреля, 2013 Столкнулся с такими ситуациями: 1. При прописании штапика в заполнениях нужно усечь и горизонтальные и вертикальные штапики, делаю поправку на ... мм, но в этом случае углы реза даются 45/45, а нужно 90/90 и нет параметра выбора угла реза. 2. Создаю параметр выбор штапика "полукруглый или прямоугольный", но для некоторых толщин заполнения полукруглого штапика не существует, а девушки-менеджеры об этом не знают или забывают и получается, что при выборе параметра "полукруглый" штапик, вообще, не считается. Как бы сделать ограничения по использованию параметра? 3. Происходит только в поворотных створках на горизонтальный штапик выдаются углы реза -90/90 и 90/-90. В глухих конструкциях всё нормально, когда режешь по биссектрисе тоже нормально без минусов. Все Ваши вопросы относятся к зоне ответственности ТП разработчика. Адресуйте их туда, пожалуйста ...
Форточник Опубликовано: 29 апреля, 2013 Опубликовано: 29 апреля, 2013 Все Ваши вопросы относятся к зоне ответственности ТП разработчика. Адресуйте их туда, пожалуйста ... В ТП мы обратимся. У меня вопрос: "Решаемо ли это всё в данной версии программы?"
Форточник Опубликовано: 30 апреля, 2013 Опубликовано: 30 апреля, 2013 Вот было бы хорошо, если бы один артикул профиля мог выступать в роли и коробки, и створки, и импоста!
Rexther Опубликовано: 30 апреля, 2013 Автор Опубликовано: 30 апреля, 2013 Вот было бы хорошо, если бы один артикул профиля мог выступать в роли и коробки, и створки, и импоста! Может ... Еще со времен ПС3 ...
Форточник Опубликовано: 30 апреля, 2013 Опубликовано: 30 апреля, 2013 Может ... Еще со времен ПС3 ... Понял, обратиться в ТП!
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВойти
Уже зарегистрированы? Войдите здесь.
Войти сейчас