БАЗИС-Смета 7.0

Есть ли возможность данные из листа спецификации экспортировать в exel?

[DTioutiou]

Сообщение от Kudesnick

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

Можете. Для этого нужно еще произвести дробление классов. Классов станет больше - да, но результат Вы получите искомый. Если я Вас правильно понял, каждый Ваш класс сейчас связан с определенным коэффициентом. Как-то так:
М1 - материалы с К=1,0
М2 - материалы с К=1,1
М3 - материалы с К=1,2
и т.д. Я правильно Вас понял? Если да, то что Вам мешает сделать так:
М1 - фурнитура с К=1,0
М2 - фурнитура с К=1,1
М3 - фурнитура с К=1,2
...
М11 - листовые с К=1,0
М12 - листовые с К=1,1
М13 - листовые с К=1,2
...
М21 - кромочные с К=1,0
М22 - кромочные с К=1,1
М23 - кромочные с К=1,2
...
В результате Вы получите и расчет по Вашим коэффициентам, и таблицы выходных форм по типам материалов. Разве не так?

[KOHKyPEHT]

Сообщение от Kudesnick

У меня все классы сейчас используются для просчёта цены, т.е. каждый класс в формуле связан с коэффициентом. Т.к. каждый материал уже ассоциирован с каким-либо классом для рассчёта, то я не могу в смете сделать отдельную таблицу для фурнитуры, комплектующих и т.д.
Лично мне нужно именно это!

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

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

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

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

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

Как итог. Возможность присвоения материалам, дополнительного класса, (как вариант - подкласса или "особой метки") было бы полезно. Хоть для построения отдельных таблиц, хоть для реализации "бредовых" идей)))

Ну впрочем, это ИМХО. Настаивать я не буду. И требовать справедливости)))
Нет так нет)

Сообщение от DTioutiou

В результате Вы получите и расчет по Вашим коэффициентам, и таблицы выходных форм по типам материалов. Разве не так?

Так, да. Только путаницы будет больше. И выходных форм. Такая система не будет массовой. То есть "разобраться в ней сможет только тот, кто ее создавал". )))

[DTioutiou]

Сообщение от KOHKyPEHT

Ну впрочем, это ИМХО. Настаивать я не буду. И требовать справедливости)))

Дело не в справедливости. И даже не в трудоемкости. Дело в реальной потребности. Пока мне не очень понятно - чего же именно не может обеспечить нынешняя смета?

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

Сообщение от KOHKyPEHT

Так, да. Только путаницы будет больше. И выходных форм. Такая система не будет массовой. То есть "разобраться в ней сможет только тот, кто ее создавал". )))

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

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

[KOHKyPEHT]

Сообщение от Kudesnick

Смысл в том, что каждой отдельной ветке пользователь может отвести конкретную задачу. Например:
для ветки М - коэффициенты домножения для итоговой стоимости,
для ветки Л - это разбиение на принадлежность к тем или иным материалам (крепеж, ЛДСП, комплектующие, вспомогательные и т.д.),
для ветки К - разбиение по поставщикам (если это важно кому-то при конструировании),
для ветки И - другие коэффициенты на материалы, которые просто перепродаются

На самом деле я себе представил, как много классов придется создать))) Чтобы вот ЭТО реализовать. Но слюни то текут))
Хотя прекрасно понимаю уважаемых разработчиков, синтаксис (как жесткие правила и ограничения) позволяет избегать огромного количества ошибок )))

[Kudesnick]

Сообщение от DTioutiou

Как-то так:
М1 - материалы с К=1,0
М2 - материалы с К=1,1
М3 - материалы с К=1,2
и т.д. Я правильно Вас понял? Если да, то что Вам мешает сделать так:
М1 - фурнитура с К=1,0
М2 - фурнитура с К=1,1
М3 - фурнитура с К=1,2
...
М11 - листовые с К=1,0
М12 - листовые с К=1,1
М13 - листовые с К=1,2
...
М21 - кромочные с К=1,0
М22 - кромочные с К=1,1
М23 - кромочные с К=1,2
...
В результате Вы получите и расчет по Вашим коэффициентам, и таблицы выходных форм по типам материалов. Разве не так?

Всё так!

А теперь давайте посчитаем, у меня 15 классов, еще нужно для вывода таблиц где-то 7 (как минимум). 7*15=105. Итого 105 (!) классов мне нужно!! И я их должен запомнить, а потом из этого списка выбирать, пока все эти классы разнесу по материалам (1500-2000 шт.)... сколько времени пройдет (выкидной список-то не маленький получится)?! Да проще вообще ничего не делать, Дмитрий!

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

Сообщение от KOHKyPEHT

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

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

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

Сообщение от DTioutiou

Дело не в справедливости. И даже не в трудоемкости. Дело в реальной потребности. Пока мне не очень понятно - чего же именно не может обеспечить нынешняя смета?

Всё дело в эргономике и экономии времени (и на бумажке можно всё посчитать, но есть же Смета!). Время - деньги!

[DTioutiou]

Итак, мы таки ответили на вопрос №2 (общий): нынешняя Смета позволяет(!!!) реализовать все задуманное. Получается много классов? Что ж, так и изначальная задумка (давать разные накрутки на разные материалы) - тоже, скажем прямо, не блещет стройностью.

Несомненно, уменьшить количество классов позволит теоретическая возможность относить один материал к нескольким классам (дальше начнет работать их матричная комбинация). Пусть так. На этот случай прошу расписать, что делать программе во всех случаях, включая конфликтных. Например, отнесли материал к классам М1, М2 и М3. А потом создали таблицу из классов М1, М2 и М3. Чего и сколько должно быть в этой таблице?

[Kudesnick]

Сообщение от DTioutiou

На этот случай прошу расписать, что делать программе во всех случаях, включая конфликтных. Например, отнесли материал к классам М1, М2 и М3. А потом создали таблицу из классов М1, М2 и М3. Чего и сколько должно быть в этой таблице?

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

[Kudesnick]

Сообщение от DTioutiou

Получаем абсурд, так ведь? Мне тоже так кажется.

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

Сообщение от DTioutiou

Именно поэтому я просил обдумать и расписать возможное взаимодействие(!!!) предлагаемой схемы со всеми остальными частями Базис-Сметы - сметой операций и сметой статей калькуляции цены.

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

[DTioutiou]

Сообщение от Kudesnick

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

Так и подскажите! Вопрос не в программном отслеживании. Вопрос в том, что делать программе в той или иной ситуации. Я привел только одну. Вопрос - в продуманности(!) предложения.

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

[Kudesnick]

Сообщение от DTioutiou

Так и подскажите!

Без проблем! Подскажем!

Сообщение от DTioutiou

Вопрос не в программном отслеживании. Вопрос в том, что делать программе в той или иной ситуации.

Второе предложение исключает первое.

Сообщение от DTioutiou

Вопрос - в продуманности(!) предложения.

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

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

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