Мультивалютная БСм9

Коллеги, хочется обсудить и понять необходимость хранения цен материалов в Базе материалов в нескольких валютах. Ну и соответственно, чтобы Базис-Смета при расчете стоимости рассчитывала стоимость материалов и работ исходя из валютной цены изделия и текущего курса, установленного в Смете.

Чем продиктована такая необходимость в моем случае?
Дело в том, что курсы национальных валют не всегда стабильны. А работать приходится с большим количеством прайс-листов поставщиков (у которых, как правило, прайс-листы в их программах учета зарегистрированы в EUR или USD и не меняются годами, как у того же BLUM). У каждого из поставщиков свой формат таблиц прайс-листов. И для того, чтобы обновить цены стандартным инструментом "Обновление цен" приходится так плясать с бубном и экспортом-импортом для приведения их прайсов в удобоваримый Базис-Сметой вид, что совсем неудобно.

А в случае много валютного учета данные телодвижения с прайс-листами поставщиков можно было бы провести один раз при загрузке номенклатуры и цен. Назначить данным ценам валюту. И все! Можно тоже не касаться вопроса изменения цен годами. Только устанавливай актуальные курсы валют при изменении их курса.

Так вот вопрос- есть ли необходимость в таком расширении функционала Базис Сметы с вашей точки зрения?

[Uncle]

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

[Uncle]

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

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

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

[DTioutiou]

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

Это не полноценная возможность. Она , если можно так выразиться, очень узконаправлена.

Она решает поставленную задачу. Понимаете? Просто решает - и все тут. Тут вопрос цели:
1. Цель - реализовать некий конкретный интерфейс?
2. Или цель - быстро изменить цены на материалы при изменении курса валют?

Вторая цель достигнута. Через какой интерфейс - вопрос можно обсуждать. Но достигнута.

[Uncle]

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

Она решает поставленную задачу.

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

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

Вторая цель достигнута. Через какой интерфейс - вопрос можно обсуждать. Но достигнута.

Она достигнута только в простейшей ситуации - изменить стоимость в зависимости от курса. А если на этот же материал или группу материалов ещё и наценку надо ввести? Например, стоимость поставили 10. Согласно курса , например 60,46, ставим такой же коэффициент . Но ещё надо наценку сделать 22 процента. Как считать? Брать калькулятор в руки и производить математические действия. Кроме того это действие надо где то зафиксировать, что мол,такого то числа был установлен определённый коэффициент, состоящий из курса на эту дату 60,46 и наценки 22 процента. Иначе, если это не зафиксировать, то при следующем обновлении курса или наценки или обоих сразу очччень тяжело будет припомнить чего и сколько к чему прибавлялось.. Так ? Или я не правильно рассуждаю...
А к стати, почему не ввести оба этих варианта - и существующую сейчас наценку и мультивалютный учет в том примерно варианте , наверняка с какими то доработками по ходу, о котором я говорю. И все будет в лучшем виде - и полноценная самодостаточная наценка и учет курса валют, друг другу не мешающие..

[FIDEL]

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

Брать калькулятор в руки и производить математические действия. Кроме того это действие надо где то зафиксировать, что мол,такого то числа был установлен определённый коэффициент, состоящий из курса на эту дату 60,46 и наценки 22 процента. Иначе, если это не зафиксировать, то при следующем обновлении курса или наценки или обоих сразу очччень тяжело будет припомнить чего и сколько к чему прибавлялось.. Так ? Или я не правильно рассуждаю...

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

[yavsochi]

Ох да, обсуждения горячие, а итог каков?
Всё это о чём идет обсуждение уже давно реализовано в 1С и очень прекрасно работает. Может сложности в реализации этого функционала в Смете, вот и была пренита функция "Установить наценку"

Скрытый текст

[свернуть]

[Uncle]

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

Может сложности в реализации этого функционала в Смете

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

[yavsochi]

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

[Am0ralist]

Вот честно, табличка в экселе и копипаст в DBF решает все проблемы.
При этом еще и версионность можно сохранять для истории (то есть каждый файл для обновления цен - сохранять под датой обновления. Или табличку)
И не надо ждать, что БазисЦентр что-то там напишет.
Ибо после того, как напишет - еще год будет исправлять...

Это самый простой вариант, есть и сложнее, в духе держать отдельную полноценную БД под это, но тому, кому надо - и так это делает, я думаю. Правда этот вариант позволяет еще и другие вещи делать по упрощению сложных расчетов.

[Kudesnick]

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

- результат достижим уже здесь и сейчас;
- в точно такое же (десятки секунд) время.

Все верно, задача решается. Но, как это часто бывает в Базисе, решается "через коленку".
Ваше решение будет верно, только при соблюдении следующих условий:

• обязательное выделение всех товаров определённого класса,
• необходимо фиксировать (где-то) дату и величину последнего изменения.

Фиксация даты нужна по той, причине, что в базе не хранится реальная цена в валюте.

А вот чего не может решить предложенный способ и что-таки решает мультивалютность:

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

По последнему пункту: поставщики зачастую ставят курс как ЦБ+%. Причём проценты у всех разные. Это как раз можно решить созданием "зависимой валюты", в поле которой можно было бы ввести формулу типа "EUR+2%", где EUR - название уже вбитой прежде валюты.