Jump to content
forum-okna.ru

Kosmos

Участник
  • Posts

    42
  • Joined

  • Last visited

Старые поля

  • Регион/город
    Иркутск

Информация

  • Пол
    Мужчина

Kosmos's Achievements

Участник

Участник (1/8)

0

Reputation

  1. С третьего Профстроя на четвёртый перешли с 1 ноября. Изучал, как же этот модуль работает (в тройке его не было), писал отчёты - наряды для вспомогательных подразделений (москитки, откосы, отливы,...), а заодно и бумажные наряды для основных (в алюминии всё равно будем жить без автоматизации) таким образом, чтобы одним кликом сделать наряды на все изделия пула и мелочёвку. А при попытке запуска наткнулись на некорректный раскрой профиля - в некоторых пулах всё ОК, а в других бардак. Разгрести его вручную практически нереально. Соответственно, пилить в автоматическом режиме нельзя.
  2. Всем добрый день! Вопрос к пользователям четвёртого Профстроя. Кто-то уже внедрил производственный модуль с полноценными раскроями и передачей заданий на автоматические станки? А то у нас этот процесс как-то буксует. Может быть, чего-то недопонимаем или что-то делаем не так?
  3. У меня будет ответ в стиле Rexther' а: Какая у Вас программа? Я сталкивался с подобной проблемой года 3 назад и Профсегментовцы нашли ошибку в коде программы и всё исправили. Если у Вас какая-то древняя версия, работающая без ключа защиты - помочь сможет только Всевышний.
  4. Сегал - система Слайдинг-45 или Татпроф - ЭК-640 - любая комбинация глухарей, поворотных и раздвижных створок в одной конструкции.
  5. Такой вопрос (немного в другом виде) я поднимал ещё в феврале в теме по функционалу ПС-3, и Константин в ответе обещал подумать.
  6. Чтобы в расчёт попала стоимость хлыстов нужно установить расчёт по целым хлыстам, а не с оценкой остатков.
  7. В отчёте "Спецификация проекта (профиль хлыстами)" выводится не коммерческая стоимость проекта, а себестоимость материалов (из тарифа МЦ) и она должна получаться не больше, а меньше стоимости проекта. Почему у Вас наоборот? Скорее всего, так: При расчёте по такому методу программа раскладывает заготовки на хлысты, вычисляет длину остатков и включает эти остатки в стоимость только в том случае, если они короче "делового остатка". Если у Вас длина делового остатка небольшая, или вообще нулевая - ничего не добавляется. А в отчет идёт стоимость целого хлыста. Например, тариф профиля 100 руб./метр, длина хлыста 6500мм, на проект требуется 1000мм (импост на одно окно), деловой остаток 500мм, коэффициент наценки 2. В расчёте: 100 руб. х 1метр х 2 = 200 руб. В отчёте: 100 руб. х 6,5м = 650 руб.
  8. Давайте при "подъёме" автоматически удалять файл архива. А нужно заархивировать ещё раз (после изменений или без таковых) - создаётся новый файл. Более того: у пользователей не должно быть доступа к списку заархивированных файлов. Тогда его и не получиться разархивировать второй раз - если нажмём кнопку "Извлечь" при выделении в списке активного проекта, программа просто объяснит, что мы не правы. (Значит, можно файл архива и не удалять, но правильнее, наверное, удалить). А путь к папке, в которую будут сохраняться архивные файлы, нужно прописывать в глобальных настройках, доступных только администратору базы данных. А при действиях пользователей никаких путей программа запрашивать не будет.
  9. Предлагаю изменить процедуру архивирования проектов. Источник проблемы: Когда количество проектов в базе переваливает за 10 тысяч, программа начинает ощутимо притормаживать, хотя железо на нашем сервере весьма недешевое. Что делать? Вычищаем проекты, провисевшие больше месяца без заключения договора. Но совсем удалять их не стоит - клиент может созреть и через полгода. А попробуем их заархивировать, а затем при необходимости - распаковать. И то же самое проделаем с уже завершенными проектами - программа будет просто летать! Новая проблема: А как же теперь найти тот проект, который нам нужно разархивировать - предлагается только список из тысяч файлов с номерами заказов. Как по номеру найти тот самый заказ, который нам нужен? Предлагаемое решение: После архивирования проекта нужно проводить его "частичное удаление" с сохранением информации для его идентификации. Конкретно: 1. Сохранить строку в ListPrj. 2. Возможно, сохранить данные в ListOrd, совершенно точно - сохранить эскизы изделий. 3. Также сохранить все данные по проекту в StatPrj (это "история" проекта) и MonePrj (очистив оплаты, нарушим финансовый баланс контрагента). Спрашиваете, облегчится ли при этом база? Отвечаю: я насчитал 13 таблиц, которые можно очистить от информации по проекту - и в каждой будет не по 1-2 строки, а десятки и сотни. Это спецификация, трудозатраты и кучка таблиц, сохраняющих весь конструктив изделий проекта. Я оцениваю объём удаляемой таким образом информации как минимум в 95%. После такого "частичного удаления" должна появиться специальная иконка, поясняющая пользователю, что проект заархивирован и любое его редактирование (в том числе, изменение статусов, отметок, оплат) должно быть невозможным. Но! Пользователь по-прежнему видит проект в программе, видит контрагента, дату создания, входящие в проект изделия, рассчитанную когда-то стоимость, историю присвоения статусов, внесённые оплаты, проект участвует в сортировке по контрагентам, менеджерам и всем другим фильтрам списка проектов. При возвращении проекта в базу из архива кнопкой "Извлечь" не нужно открывать список файлов - должен разархивироваться выделенный в списке проект. В итоге в базе данных в "активном" состоянии могут находиться лишь проекты за пару месяцев, а видны в списке будут абсолютно все. Какие будут мнения?
  10. Действительно, вытащить трудозатраты каждого отдельного комплекта трудно, если не невозможно. Я у себя решил проблему (в отчете) следующим образом. На примере водоотливов. Водоотливы прописаны как комплекты, включающие оцинкованный лист и трудозатраты участка гибки, а если сами красим, то ещё порошковая краска и трудозатраты участка покраски. У отливщика трудозатраты рассчитываются по длине, а у покрасчика по площади. Беру из таблицы трудозатрат суммарные трудозатраты на каждый артикул комплекта (HourOrd.hIndK=KompLst.kUnic=SpecPAU.clkK при условии SpecPAU.clkC=10) по каждому участку. Из спецификации вычисляю общую длину отливов и общую площадь листа для выбранного артикула комплекта. Вычисляю значения трудозатрат на погонный метр для отливщика и на квадратный метр для покрасчика. В итоге стоимость комплекта = стоимость материалов комплекта + длина * трудозатраты на пог/м * стоимость чел/час + площадь * трудозатраты на кв/м * стоимость чел/час.
  11. Очень здорово. А теперь ещё одно предложение. При работе со строительными компаниями и корпоративными заказчиками часто возникает такая ситуация: Проводится расчёт по проектной документации, коммерческая служба обрабатывает заказчика с учётом всех особенностей Российского ценообразования и заключается договор. А на объекте ещё никто не был, реальные размеры будущих изделий не замерял. Значит тот проект, по которому заключен договор, уйти в производство не может - как правило, создаются поэтапные отдельные проекты после замеров и всех уточнений. То есть, деньги заказчик платит на основании "большого" проекта, а в работу заходит кучка "маленьких" со своей стоимостью. Их сумма, как правило, не совпадает со стоимостью "большого" проекта и бухгалтерия постоянно ничего не может понять. Вывод: нужно как-то связать между собой "большой" и "маленькие" проекты для корректного отслеживания реальной стоимости и оплаты. Предложение заключается в следующем: Вводим новый признак классификации проектов по способу реализации: 1) Обычный - то, что имеем сейчас; 2) Договор - это наш "большой" проект; 3) Часть (стадия, этап) договора - это "маленький" внутри "большого". Особенности "Договора": 1) Он не может быть запущен в производство; 2) По нему ведётся расчёт баланса так же, как по обычному проекту - возможно прямое внесение оплат или списание с предоплат, занесённых на счёт заказчика. Особенности "Части договора": 1) При создании проекта программа спрашивает, к какому проекту - "Договору" привязать эту "часть" и выводит в список для выбора все "Договоры" этого заказчика; 2) Проект запускается в производство так же, как обычный; 3) Проект не участвует в расчете баланса и на него нельзя внести платёж или сделать списание с предоплат заказчика; 4) На этот проект могут быть отнесены деньги, поступившие в качестве оплаты на основной проект-"Договор", у "Договора" же ведётся учет перенесённых на зависимые проекты денег и остатка, доступного к переносу. Любые переносы туда - обратно никак не влияют на финансовый баланс; 5) Для визуального выделения таких проектов в общем списке нужны какие-то отметки или цвет фона в полях "Стоимость" и "Оплата" списка проектов. При такой системе сразу будет видно, что деньги на основном "Договоре" уже закончились, и мы уходим в минус, или же наоборот легко определяем дополнительную маржу, которую получили на этом объекте. Если ушли в минус, показываем заказчику реальные затраты и стараемся получить дополнительную оплату, увеличиваем сумму основного "Договора" и у нас появляются деньги для финансового покрытия всех частей.
  12. Прошёл месяц, но никакого обсуждения этой идеи не состоялось - неужели, такой вопрос стоит только перед нами? А вот Профсегмент вчера анонсировал новый модуль, в котором эта идея реализуется. Возможно, пригодятся мысли и про расчёты стоимости. 1. Скидки на профили / аксесуары / погонаж / заполнения сейчас задаются по умолчанию в справочнике контрагентов, но пользователь программы никак не ограничен в установке любых (вплоть до 100%) значений внутри проекта. Нужно либо ограничить максимальные значения всех этих скидок, либо (ещё лучше), вообще, убрать возможность их изменения в каждом конкретном проекте. Тогда эти скидки станут инструментом "индивидуальной настройки" цены, по которой головная компания продаёт свою продукцию тому или иному дилеру, помимо общей дилерской скидки - и вводить эти значения должен только пользователь со специальным полномочием. 2. Наценки дилера на конструкции / комплектацию / работы, тоже, нужно задавать не внутри проекта, а где-то в "кабинете дилера" - опять-таки, по специальному полномочию ответственным работником дилера или, по его просьбе, ответственным работником головной компании. У каждого дилера такие наценки могут быть свои, но постоянные от проекта к проекту. 3. Скидки дилера (на конструкции, комплектацию, работы, общая и дополнительная), устанавливаемые пользователем - менеджером дилера, также, должны ограничиваться в "кабинете дилера" отдельно для каждого дилера (группы пользователей). 4. В стоимость проекта на уровне "Производитель - Дилер" должны включаться только те комплекты и работы, которые определены для основной компании (любой дилер может, при желании, воспользоваться полным спектром услуг головной компании). 5. Стоимость на уровне "Дилер - Покупатель" - это стоимость "Производитель - Дилер" с учетом скидок проекта и наценок дилера плюс стоимость комплектов и работ, определенных для группы пользователей конкретного дилера. И ещё. Настройки в "кабинете дилера", наверное, должен проводить уполномоченный пользователь типа "дилер" (из своей группы пользователей), но, также, все они должны быть доступны уполномоченному работнику головной фирмы - многим дилерам нужно будет помогать.
  13. Мысли по разделению заказчиков между дилерами и головной компанией. 1. В списке контрагентов добавляем новую категорию «Покупатели» - это будут конечные потребители наших дилеров; к полномочию пользователя «Контрагенты, источники заказов» добавляем ещё одно – «Клиенты (покупатели) дилера». Менеджерам дилера открывается это новое полномочие (старое – нет) и, они получают доступ к справочнику контрагентов со следующими ограничениями: 1) Они видят только категорию «Покупатели», при введении нового контрагента он автоматически получает эту категорию, изменение категории запрещено. При установленном в настройках интерфейса флаге «Автозаполнение группы пользователя при вводе контрагента» менеджеры дилера будут видеть в справочнике только своих покупателей и смогут свободно редактировать их данные. Сейчас они лишены такой возможности – им запрещён доступ в справочник, а если разрешить, то они смогут подредактировать, а то и удалить ЛЮБЫХ контрагентов. 2) В реквизитах контрагентов категории «Покупатели» отсутствуют опции «Прайс-лист», «Источник заказов», «Сальдо», «Кредитная линия», возможность регулирования скидок и вкладка «Платежи». Для пользователей с открытым «старым» полномочием, но закрытым новым, категория «Покупатели» должна быть недоступна. Оба полномочия открываются администратору программы, чтобы он мог помочь дилерам в случае необходимости. 2. В таблице проектов добавляем новое поле – Покупатель. 3. Работа с проектами пользователей с открытым полномочием «Клиенты дилера». При создании нового проекта должно автоматически заполниться поле «Контрагент» - туда попадает субъект, имеющий в справочнике категорию «Дилер» и соответствующую группу пользователей. Вносит такого субъекта в базу ответственный работник головного предприятия при заключении дилерского договора. На главной странице проекта выбираются не «контрагенты», а «покупатели», естественно в списке открываются только «свои» и возможно создание нового «покупателя». Фильтр списка проектов также принимает вид «покупатели», а не «контрагенты». 4. При работе с проектами менеджеров головной компании они по-прежнему выбирают «Контрагентов», а поле «Покупатель» либо должно оставаться пустым, либо туда копируется значение поля «Контрагент». В фильтре списка проектов присутствуют именно «Контрагенты», т.е. дилеры плюс частные и корпоративные заказчики головного предприятия. Менеджер головного предприятия может увидеть конечного покупателя дилерского заказа в общем списке проектов, но как-то поменять его не в состоянии. Сложно? Описывал долго, т.к. пытался учесть нюансы, а доработок, думается, не так много и в работе каждого конкретного пользователя не вижу особых усложнений, наоборот – всё как надо. Про вычисление двух стоимостей – в следующий раз.
  14. Если такое изменение в функционал проще для разработчиков, очень хорошо. Важно только, чтобы к проекту "приклеивалась" информация не просто о том, что изготовление задерживается, но и на какой, конкретно, срок.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.