Kosmos

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

Всем добрый день! Вопрос к пользователям четвёртого Профстроя. Кто-то уже внедрил производственный модуль с полноценными раскроями и передачей заданий на автоматические станки? А то у нас этот процесс как-то буксует. Может быть, чего-то недопонимаем или что-то делаем не так?

У меня будет ответ в стиле Rexther' а: Какая у Вас программа? Я сталкивался с подобной проблемой года 3 назад и Профсегментовцы нашли ошибку в коде программы и всё исправили. Если у Вас какая-то древняя версия, работающая без ключа защиты - помочь сможет только Всевышний.

Сегал - система Слайдинг-45 или Татпроф - ЭК-640 - любая комбинация глухарей, поворотных и раздвижных створок в одной конструкции.

Такой вопрос (немного в другом виде) я поднимал ещё в феврале в теме по функционалу ПС-3, и Константин в ответе обещал подумать.

Чтобы в расчёт попала стоимость хлыстов нужно установить расчёт по целым хлыстам, а не с оценкой остатков.

В отчёте "Спецификация проекта (профиль хлыстами)" выводится не коммерческая стоимость проекта, а себестоимость материалов (из тарифа МЦ) и она должна получаться не больше, а меньше стоимости проекта. Почему у Вас наоборот? Скорее всего, так: При расчёте по такому методу программа раскладывает заготовки на хлысты, вычисляет длину остатков и включает эти остатки в стоимость только в том случае, если они короче "делового остатка". Если у Вас длина делового остатка небольшая, или вообще нулевая - ничего не добавляется. А в отчет идёт стоимость целого хлыста. Например, тариф профиля 100 руб./метр, длина хлыста 6500мм, на проект требуется 1000мм (импост на одно окно), деловой остаток 500мм, коэффициент наценки 2. В расчёте: 100 руб. х 1метр х 2 = 200 руб. В отчёте: 100 руб. х 6,5м = 650 руб.

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

Предлагаю изменить процедуру архивирования проектов. Источник проблемы: Когда количество проектов в базе переваливает за 10 тысяч, программа начинает ощутимо притормаживать, хотя железо на нашем сервере весьма недешевое. Что делать? Вычищаем проекты, провисевшие больше месяца без заключения договора. Но совсем удалять их не стоит - клиент может созреть и через полгода. А попробуем их заархивировать, а затем при необходимости - распаковать. И то же самое проделаем с уже завершенными проектами - программа будет просто летать! Новая проблема: А как же теперь найти тот проект, который нам нужно разархивировать - предлагается только список из тысяч файлов с номерами заказов. Как по номеру найти тот самый заказ, который нам нужен? Предлагаемое решение: После архивирования проекта нужно проводить его "частичное удаление" с сохранением информации для его идентификации. Конкретно: 1. Сохранить строку в ListPrj. 2. Возможно, сохранить данные в ListOrd, совершенно точно - сохранить эскизы изделий. 3. Также сохранить все данные по проекту в StatPrj (это "история" проекта) и MonePrj (очистив оплаты, нарушим финансовый баланс контрагента). Спрашиваете, облегчится ли при этом база? Отвечаю: я насчитал 13 таблиц, которые можно очистить от информации по проекту - и в каждой будет не по 1-2 строки, а десятки и сотни. Это спецификация, трудозатраты и кучка таблиц, сохраняющих весь конструктив изделий проекта. Я оцениваю объём удаляемой таким образом информации как минимум в 95%. После такого "частичного удаления" должна появиться специальная иконка, поясняющая пользователю, что проект заархивирован и любое его редактирование (в том числе, изменение статусов, отметок, оплат) должно быть невозможным. Но! Пользователь по-прежнему видит проект в программе, видит контрагента, дату создания, входящие в проект изделия, рассчитанную когда-то стоимость, историю присвоения статусов, внесённые оплаты, проект участвует в сортировке по контрагентам, менеджерам и всем другим фильтрам списка проектов. При возвращении проекта в базу из архива кнопкой "Извлечь" не нужно открывать список файлов - должен разархивироваться выделенный в списке проект. В итоге в базе данных в "активном" состоянии могут находиться лишь проекты за пару месяцев, а видны в списке будут абсолютно все. Какие будут мнения?

Ответил в новой теме.

Действительно, вытащить трудозатраты каждого отдельного комплекта трудно, если не невозможно. Я у себя решил проблему (в отчете) следующим образом. На примере водоотливов. Водоотливы прописаны как комплекты, включающие оцинкованный лист и трудозатраты участка гибки, а если сами красим, то ещё порошковая краска и трудозатраты участка покраски. У отливщика трудозатраты рассчитываются по длине, а у покрасчика по площади. Беру из таблицы трудозатрат суммарные трудозатраты на каждый артикул комплекта (HourOrd.hIndK=KompLst.kUnic=SpecPAU.clkK при условии SpecPAU.clkC=10) по каждому участку. Из спецификации вычисляю общую длину отливов и общую площадь листа для выбранного артикула комплекта. Вычисляю значения трудозатрат на погонный метр для отливщика и на квадратный метр для покрасчика. В итоге стоимость комплекта = стоимость материалов комплекта + длина * трудозатраты на пог/м * стоимость чел/час + площадь * трудозатраты на кв/м * стоимость чел/час.

Очень здорово. А теперь ещё одно предложение. При работе со строительными компаниями и корпоративными заказчиками часто возникает такая ситуация: Проводится расчёт по проектной документации, коммерческая служба обрабатывает заказчика с учётом всех особенностей Российского ценообразования и заключается договор. А на объекте ещё никто не был, реальные размеры будущих изделий не замерял. Значит тот проект, по которому заключен договор, уйти в производство не может - как правило, создаются поэтапные отдельные проекты после замеров и всех уточнений. То есть, деньги заказчик платит на основании "большого" проекта, а в работу заходит кучка "маленьких" со своей стоимостью. Их сумма, как правило, не совпадает со стоимостью "большого" проекта и бухгалтерия постоянно ничего не может понять. Вывод: нужно как-то связать между собой "большой" и "маленькие" проекты для корректного отслеживания реальной стоимости и оплаты. Предложение заключается в следующем: Вводим новый признак классификации проектов по способу реализации: 1) Обычный - то, что имеем сейчас; 2) Договор - это наш "большой" проект; 3) Часть (стадия, этап) договора - это "маленький" внутри "большого". Особенности "Договора": 1) Он не может быть запущен в производство; 2) По нему ведётся расчёт баланса так же, как по обычному проекту - возможно прямое внесение оплат или списание с предоплат, занесённых на счёт заказчика. Особенности "Части договора": 1) При создании проекта программа спрашивает, к какому проекту - "Договору" привязать эту "часть" и выводит в список для выбора все "Договоры" этого заказчика; 2) Проект запускается в производство так же, как обычный; 3) Проект не участвует в расчете баланса и на него нельзя внести платёж или сделать списание с предоплат заказчика; 4) На этот проект могут быть отнесены деньги, поступившие в качестве оплаты на основной проект-"Договор", у "Договора" же ведётся учет перенесённых на зависимые проекты денег и остатка, доступного к переносу. Любые переносы туда - обратно никак не влияют на финансовый баланс; 5) Для визуального выделения таких проектов в общем списке нужны какие-то отметки или цвет фона в полях "Стоимость" и "Оплата" списка проектов. При такой системе сразу будет видно, что деньги на основном "Договоре" уже закончились, и мы уходим в минус, или же наоборот легко определяем дополнительную маржу, которую получили на этом объекте. Если ушли в минус, показываем заказчику реальные затраты и стараемся получить дополнительную оплату, увеличиваем сумму основного "Договора" и у нас появляются деньги для финансового покрытия всех частей.

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

Мысли по разделению заказчиков между дилерами и головной компанией. 1. В списке контрагентов добавляем новую категорию «Покупатели» - это будут конечные потребители наших дилеров; к полномочию пользователя «Контрагенты, источники заказов» добавляем ещё одно – «Клиенты (покупатели) дилера». Менеджерам дилера открывается это новое полномочие (старое – нет) и, они получают доступ к справочнику контрагентов со следующими ограничениями: 1) Они видят только категорию «Покупатели», при введении нового контрагента он автоматически получает эту категорию, изменение категории запрещено. При установленном в настройках интерфейса флаге «Автозаполнение группы пользователя при вводе контрагента» менеджеры дилера будут видеть в справочнике только своих покупателей и смогут свободно редактировать их данные. Сейчас они лишены такой возможности – им запрещён доступ в справочник, а если разрешить, то они смогут подредактировать, а то и удалить ЛЮБЫХ контрагентов. 2) В реквизитах контрагентов категории «Покупатели» отсутствуют опции «Прайс-лист», «Источник заказов», «Сальдо», «Кредитная линия», возможность регулирования скидок и вкладка «Платежи». Для пользователей с открытым «старым» полномочием, но закрытым новым, категория «Покупатели» должна быть недоступна. Оба полномочия открываются администратору программы, чтобы он мог помочь дилерам в случае необходимости. 2. В таблице проектов добавляем новое поле – Покупатель. 3. Работа с проектами пользователей с открытым полномочием «Клиенты дилера». При создании нового проекта должно автоматически заполниться поле «Контрагент» - туда попадает субъект, имеющий в справочнике категорию «Дилер» и соответствующую группу пользователей. Вносит такого субъекта в базу ответственный работник головного предприятия при заключении дилерского договора. На главной странице проекта выбираются не «контрагенты», а «покупатели», естественно в списке открываются только «свои» и возможно создание нового «покупателя». Фильтр списка проектов также принимает вид «покупатели», а не «контрагенты». 4. При работе с проектами менеджеров головной компании они по-прежнему выбирают «Контрагентов», а поле «Покупатель» либо должно оставаться пустым, либо туда копируется значение поля «Контрагент». В фильтре списка проектов присутствуют именно «Контрагенты», т.е. дилеры плюс частные и корпоративные заказчики головного предприятия. Менеджер головного предприятия может увидеть конечного покупателя дилерского заказа в общем списке проектов, но как-то поменять его не в состоянии. Сложно? Описывал долго, т.к. пытался учесть нюансы, а доработок, думается, не так много и в работе каждого конкретного пользователя не вижу особых усложнений, наоборот – всё как надо. Про вычисление двух стоимостей – в следующий раз.

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

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

Понятно, что высказываемые здесь идеи – это не руководство к действию, а приглашение к обсуждению заинтересованных лиц. Одна голова – хорошо, а куча голов гораздо лучше. Бесспорно, Ваша идея может оказаться и лучше моей. Может, поделитесь тем, что предлагаете Вы? Но и свою хочу попытаться защитить. В спецификацию каждого элемента добавляется одно поле – сейчас их 36, станет 37 – сильно ли «потяжелеет»? В тарифе МЦ сейчас 14 полей, а в Списке проектов 79! Настраивать спецификации каких-либо конструктивов не нужно – поле заполняется так же, как тип и подтип МЦ. А настройка в МЦ нужна не для всех, а именно для «экзотических» случаев – по умолчанию ставим 0, как цену по умолчанию ставим 100. Когда-то от ФОРМЫ и ТЕКСТУР профиля и заполнений, а когда-то просто от АРТИКУЛА, независимо от формы и текстур. А так, все приходящие на ум случаи, Вы перечислили. Хорошо бы иметь какую-то отметочку у такого проекта и какую-то процедуру, чтобы понять, из-за чего, конкретно, эта отметочка появилась, иначе пойди докажи нерадивому пользователю, что предупреждение было.

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

Ещё одна идея. У любой оконной компании существут "стандартная" продукция и какие-то дополнительные штучки. Все материалы для изготовления стандартной продукции постоянно есть на складе в нужном количестве (иначе увольняем логистов), а некоторые дополнительные позиции поставляются только под заказ, причем не все они имеются даже у регионального поставщика - нужна поставка из Москвы или, вообще, из Германии. Идея в том, чтобы программа подсказывала менеджеру ещё на этапе расчёта проекта, что срок изготовления будет больше стандартного из-за ожидания поставки отдельных материалов (технологический цикл изготовления при этом не увеличится, просто придётся реальный запуск в производство откладывать до поступления материалов на склад). Как это можно реализовать. 1. В таблице "Тариф МЦ" нужно ввести дополнительное поле "Срок поставки" (тип AsInt), в которое по умолчанию при создании новой строки будет вводиться значение "0", а настройщик базы может заменить его на реальное количество дней, необходимых для поставки этого материала в этом цвете - эту информацию ему дадут логисты предприятия на основании договоров с поставщиками. Почему вводить такое поле нужно именно в тариф? Например, оконные ручки белого и коричневого цвета всегда поддерживаются на складе, а 5-10, а то и больше "экзотических" цветов поставляются под заказ. 2. Такое же дополнительное поле вводим в таблицу Спецификации - при расчете спецификации в каждую строку подставляется значение, соответствующее артикулу и текстуре примененного материала. Это позволит легко создать отчет, показывающий какие конкретно материалы "задерживают" готовность заказа. 3. Аналогичное поле нужно и в таблице Проекты, а попадать туда, в процессе ценового расчёта проекта, должно максимальное значение из всех имеющихся в спецификации проекта. И в том случае, если это значение оказалось больше нуля, должно появиться окно с подсказкой типа "Срок поставки материалов по проекту составляет N рабочих дней". Дальше возможны какие-то варианты - установка на проект какой-либо отметки, или введение в список проектов ещё одного доступного поля. Кстати, установку отметки может выполнить и настройщик базы через макрос. Жду критики либо поддержки.

Может быть. И, наверное, при выстраивании такого приоритета (раздаче "номеров"), можно предусмотреть вариант "не отображать" - пусть это относится только к началу проектирования изделия.

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

Насколько я понимаю, внутрь команды ~IF:.... нельзя подставлять такое выражение, как Вы написали - нужно ввести параметр и затем проверять его, например: ~AsString:ТипОрганизации='0'~ ~Проект:Контрагент.Тип_организации:AsString:ТипОрганизации~ ~IFS:ТипОрганизации=0:THEN~ ......... ~ENDIF~

Профсегменту респект. В сегодняшнем обновлении появилось.

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

Удобнее всего будет такой вариант: Внутри типов работ (выезд, замер,...) настройщик делит работы на категории, которым сам даёт название (как в Комплектах внутри ПРОДАЖИ, СКАТКИ,...), а пользователь при выборе работ в проект имеет фильтр по этим категориям.