v8: Как в запросе пересчитать валюту на даты документов? #119564

Как в запросе пересчитать сумму из валюты документа в выбранную валюту?

up

up

По уму в выбранной валюте итоге нужно хранить готовые.

Посмотри такой запрос. Он, правда, писался на T-SQL и для наших специфических нужд:SELECT nom.DESCR AS NomDescr, rnhead.SP1583 AS ContrahID, j.SP798 AS ProjectID,FROM _1SJOURN j INNER JOIN  DH1611 rnhead ON j.IDDOC = rnhead.IDDOC INNER JOIN  DT1611 rntabl ON rnhead.IDDOC = rntabl.IDDOC INNER JOIN  SC84 nom ON rntabl.SP1599 = nom.ID INNER JOIN  _1SCONST exrt ON CAST(LEFT(j.DATE_TIME_IDDOC, 8) AS datetime) = exrt.DATE  (j.SP798 = ' 1 ' OR j.SP798 = ' 2 ' OR j.SP798 = ' 6 ' OR j.SP798 = ' 7 ') AND  (rntabl.IDDOC NOT IN    (SELECT RIGHT(DH6661.SP6662, 9) AS BASISIDDOC    FROM _1SJOURN INNER JOIN      DH6661 ON _1SJOURN.IDDOC = DH6661.IDDOCGROUP BY nom.DESCR, rnhead.SP1583, j.SP798Обрати внимание на строчку:>>INNER JOIN _1SCONST exrt ON CAST(LEFT(j.DATE_TIME_IDDOC, 8) AS datetime) = exrt.DATE,где описывается связь таблиц _1SCONST с таблицей _1SJOURN.Чего будет не понятно, пиши. Здесь мы получаем курс доллара на дату документа.

Блин, тормознул. Этот запрос писан для 7.7.А структура таблиц документов в 8-ке схожа с 7.7? И где там хранятся курсы валют?

в сиквеле конечно можно посмотреть структуру таблиц, вот только прямые запросы к SQl не нужны в v8, они и так выполняются на серваке, в отличие от 7.7 :-)

в 8-ке курсы валют лежат в регистре сведений, т.е. таблице, где поля:Кратность -...Работать, как с sql. Есть метод срез последних. Дает срез последних записей. Проблема в том, что срез получается на конкоетную дату, на надо на каждый документ.Вопрос, как получить записть на дату 01,01,05, если последняя запись 01,01,04?

2 Прочитай ... так как-то проще... что ваяешь?

(8 +All)Задача:Торговля+Склад. Нужно вести учет товара на складах в валюте учета.Реализация: В номенклатуре товара реквизит "Валюта учета". При формировании партий производится пересчет в эту валюту и запись готовой цифирии в регистр.Нужно посчитать наценку на товар.

+9 Желательно максимально "загрузить" запрос, чтобы потом в модуле не делать пересчетов и тд

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

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

:) Делал, не выходит из-за того, что на дату документа не сужествует записи в регистре сведений купса валют. Последняя запись раньше, и результат получается пустым. пересмотри . последняя строка ;)

не помню кто предлагал такВЫБРАТЬПродажи.Номенклатура КАК Номенклатура,Продажи.СуммаПродажи * Курсы.Курс КАК СуммаРуб,Продажи.Количество КАК Количество                     ГДЕ Курсы.Валюта = &ВалютаУпрУчета И Продажи.Период МЕЖДУ &ПериодОт И &ПериодПоПО Продажи.Период = ДатаКурсаНаПериодПроведения.ДатаПродажиГДЕ Продажи.Период МЕЖДУ &ПериодОт И &ПериодПоИ Курсы.Валюта = &ВалютаУпрУчета

так в запросе там где пишешь условия соединения, пиши не = а <=

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

2 "Собственно на эту тему я говорил неоднократно." - читал :)Согласен, фпринципе... гимора не оберешься потом, если все так делать

(14-15) попробую - думаю, если "еще один ресурс в регистр " - это валюта учета - ситуацию не спасет

Вообще периодические реквизиты можно еще выбирать, напр., так:select Товары.*, valСтавкаНДС.value as СтавкаНДСfrom sc1171 as Товарыleft join(select objid, max(date) as maxdatefrom _1sconstwhere id = 1272 and date <= @dataformgroup by objidon Товары.id = mdСтавкаНДС.objidleft join _1sconst as valСтавкаНДСon valСтавкаНДС.id = 1272 and Товары.id = valСтавкаНДС.objid and mdСтавкаНДС.maxdate = valСтавкаНДС.date

а что такое периодический реквизит? :-)

select objid, max(date) as maxdatefrom _1sconstwhere id = 1272 and date <= @dataformgroup by objid это и получается срез последних на дату dataform, а как получить на дату документа?

"Смешалтсь в кучу кони, люди..." ;)

То 18. Именно спасает!

Поясни, вкраце, в чем спасение?

То 24. В том, что кроме ресурса Стоимость будет нужный тебе ресурс СтоимостьВВалютеУчетаТвоейХрени. Куда при приходе и расходе будет писать сумма ВВалютеУчетаТвоейХрени. Которую потом замечально можно получить отчетом - быстро и без пересчетов.

Конечно вы меня сильно будите материть, но я пошел по наименьшему соротивлению.В Себестоимость я пишу уже пересчитанную сумму в валюте учета МоейХрени. И в любой момент я могу посмотреть, по какой цене МояХрень продана в валюте учета моейХрени. Меня не интересует, сколько стоит моя хрент в валюте упр учета.Вопрос в том, что мне нужно перечситать, на сколько наценили МоюХрень, если документ в валюте рубли, а валютаУчеиа МоейХрени - бакс.

То All Не сочтите за грубость, сказанное в .

То 26. Т.е. ты вообще разрушил товарный учет. С чем тебя и поздравляю. Действительно - на фига нам какая-то там лажовая себестоимость.Лучше поменяй профессию. Это мой тебе хороший и безплатный совет.

Если использовать user defined function (пользовательскую функцию) типа как в , то для каждой строки, возвращаемой запросом можно получить курс на дату документа. Если претит использование пользовательской функции можно попробовать как в этом примере (тут в запросе участвуют только две таблицы), далее можно усложнять по потребности. Попробуй, так сработает?SELECT j.IDDOC, CAST(LEFT(j.DATE_TIME_IDDOC, 8) AS datetime) AS docdate, c.VALUEFROM _1SJOURN j, _1SCONST cWHERE (c.DATE =    (SELECT TOP 1 DATE  (c.ID = 17)Этот запрос возвращает ID документа и курс доллара на дату документа.

+29 Еще возвращает и дату документа, конечно.

Неужели ВСЕ так плохо, как написал всеми нами уважаемый "Джинн"?У кого какие еще мнения по этому поводу? попробую

Вот аналог на 8-ке запросуВЫБРАТЬ  ПродажиСебестоимостьОбороты.Регистратор КАК Регистратор,  ПродажиСебестоимостьОбороты.Номенклатура,      (ВЫБРАТЬ ПЕРВЫЕ 1        РегистрСведенийКурсыВалют.Период      ИЗ  И ПродажиСебестоимостьОбороты.Номенклатура.ВалютаУчета = КурсыВалют.ВалютаРаботает, но медленновато. Заменил "КурсыВалют.Период =" на "КурсыВалют.Период В". "=" не работаетЕсть возможность оптимизировать?

up

У меня запрос на 9 500 документах запрос срабатывает за 1 сек. Ты пробовал выполнить запрос не из 1С, а, скажем из Query Analyzer или из SQL Server Enterprise Manager?Если я убираю из подзапроса в предложении WHERE строки>> (_1SCONST.OBJID = ' 2 ') AND      (_1SCONST.ID = 17), запрос выполняется значительно(!) медленнее.Все тормоза от того, что подзапрос, вычисляющий курс на дату документа, выполняется для каждой строки основного запроса (а как иначе?).Дляч меня прозиводительность не очень актуальна, т.к. запрос запускается несколько раз в месяц (корпоративная отчетность).Как варианты:- прямые запросы к SQL на языке T-SQL (а не на внутреннем языке 8.0);- создание и последующее использование хранимых процедур и/или пользовательских функций;- возможно имеет смысл рассмотреть использование индексированных представлений (index views);

+34. Хм... Фигню спорол. Без этих строк в подзапросе запрос ьбудет выдавать вообще непредсказуемые результаты.

То 31. Именно все так плохо. В УТ реализована простая, понятная, логичная и общепринятая методология учета. При которой все сводится к одной валюте. Потому что это позволяет получить сопоставимые цифры, независимо от товара или какой-то мифической валюты учета для каждого товара в отдельности. Разрушать ее ради решения какой-то мелкой и в принципе никому не нужной задачи - очень плохое решение. Естественно по моему скромному мнению, которое не является мнение Всевышнего, переданным на скрижалях Моисею. Но с валютным учетом я работаю примерно десять лет - срок, за который и обезъяна бы научилась не наступать на грабли.

в 8-ке просто так прямой запрос не напишешь к базе, итруктура не изветна (если не использовать вн. обработок). Все тормоза из-за перебора курса валют. ;)

>> в 8-ке просто так прямой запрос не напишешь к базеТы в этом точно уверен? Что нельзя создать и сохранить в базе хранимую процедуру, а затем вызывать ее с помощью ADO, как в 7-ке? Если это действительно так, то ценность 8-ки в моих глазах просто обрушилась.:(.>> Все тормоза из-за перебора курса валютПробуй уменьшить выборку для которой пересчитываются курсы, либо храни промежуточные итоги в index views, если это позволяют условия задачи.

В том-то и дело, что схема общая. Не все-что общее для всех приемлимо.Как реализовать след. схему:У нас куча товара от разных поставщиков. У каждого из них "своя валюта" и "свой курс". Мы закупаем у них товар по их курсу.Допустим ...День 1.ВалютаУпрУчета $ - курс на 01.01.01 сост. 29.00Товар группы Марс Валюта $Марс - курс на 01.01.01 сост. 25.0001.01.01 закупаем 100 шт товар группы Марс по 1 $Марс за шт. = 100 $МарсДень 2.ВалютаУпрУчета $ - курс на 02.01.01 сост. 30.00Товар группы Марс Валюта $Марс - курс на 02.01.01 сост. 25.0002.01.01 продаем 100 шт товар группы Марс по 27 руб. за шт. = 2700 руб.День 3.Считаем наценку и получаем, что если мы вели учет товара в $, то 02.01.01 мы просто потеряли бабки на росте курса $, хотя $Марс остался на прежнем уровне.Что скажешь?

в 8-ке все данные храняться в двоичном виде. так просто, как в 7-ке к ним не подберешься (правда это мое мнение). В 7.7 проще. Но ты не спеши разочаровываться :)....Вобщем я покапался в конфе и пошел немножко другим путем (да простит меня Джинн). Вкраце. Себестоимость в валюте учета у меня хранится в партиях товара. При продаже я пересчитываю себестоимость полученную себестоимрсть из валюты учета товара в валюту Упр. учета на дату документа. Дальше все срастается и отпадает нужда делать пересчеты в запросе ;).

это редкий маразм, вы не умеете работать с импортом, и придумываете себе какие-то бредовые сложные схемы.

8-ку смотрел давно, года 1.5 назад мельком. Что-то мне подсказывает, что не все данные там хранятся в двоичном формате. Лишь метаданные. Хотя, может, я и запамятовал или чего-то путаю.

Подскажите, как это делаеися?

Да, ты прав

Мне сложно подсказывать не зная специфики.Мы разрабатывали конфигурацию для импортера, очень вкратце: Отчет анализ себестоимости товаров происходит постфактум после прибытия трака и распределения косвенных затрат (доставка, услуги ТЛС, лаборат контроль, доп услуги, бой, штрафы) там кроме валют головняка хватает.Склад ведется только в управленческой валюте (евро), а не в каких-то разных валютах контрактных обязательств.

Наверное я чушь сегодня целый день несу.>>(доставка, услуги ТЛС, лаборат контроль, доп услуги, бой, штрафы)+ всякая лабуда - себестоимость. Это точно. Одна цифра напротив товара. Какая разница как мы ее получили.А далее >>Склад ведется только в... то же самое, и как это решает мою задачу?...Я ни в коем случае не спорю, мне просто хотелось бы понять логику ситуации и ее решение.Кто-то скажет что мне этого не дано.

Я не понимаю, почему сравниваются цены в разных единицах измерения. В $ и в $Марс...$Сникерс?Если интересно помнить какой "свой" курс $ у разных контрагентов, то это нужно хранить имхо в отдельном регистре сведений. А в учете, если упр валюта $, то зачитываем товар так: 100 штук на сумму 100*25/29 $. Как-бы проводим нормализацию, приводим всё к одной единице измерения, к $ по ЦБ.

То есть по даже нельзя ответить на вопрос "Сколько стоит?" ... Как-бы 100, но не совсем $, а $Марс... а если это просуммировалось с $Сникерс (которое например 34) то вообще жуть...Учетная система призвана помочь принять управленческие решения итп, а с такой методологией только воровать удобно... Может всё дело в этом?

(47,48) ... не знаю... Мне кажется, что можно было объяснить по ситуации - я объяснил.Опять-же, "приводим всё к одной единице измерения, к $ по ЦБ" + "нужно хранить имхо в отдельном регистре сведений". А если мне нужно посчитать на каюи сумму наценки (допустим рубли) продали сегодня товара марса, я должен буду сначала пересчитать партию из $ в $Марс на курс поступления, затем на дату продажи пересчитать по курсу $Марс в рубли? Не много ли пересчетов?"воровать удобно... Может всё дело в этом?" Не знаю, Может и так. Начальство мне не докладывает.А по ситуации с скачками курсов, имхо, мне еще никто не дал внятной схемы...Гиблое это дело :(

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

Вот и я об том-же. У каждого свои заморочки ;). Стаоая конфа (7.7) у нас тоже 2 года пропахала

ИМХО, если нужно посчитать наценку, то формула у Вас (!!!) примерно такая: Наценка = Цена - Стоимость.(или (Цена-Стоимость)/Стоимость*100% )Причём Стоимость желательно иметь НА ДЕНЬ ПРОДАЖИ... Так ведь? Так вот это имхо проблема ТЕОРЕТИЧЕСКАЯ... Не даром всякие фифо-лифо придумали... Валюты с разными курсами в данном случае только маскируют вопрос.Ну, например то же самое: Сколько стоит например конкретная квартира?Возможные ответы: За сколько купили; За сколько можно купить такую сегодня; За сколько можно продать такую сегодня; Как независимый оценщик решит. Во сколько её оценят при выдаче кредита, если она будет залогом, Мы её купили за столько-то, но это нам повезло а вообще она стоит столько-то... А если рядом семья цыган поселится, то сколько?То же самое и с марсами. При таком подходе даже и с рублями-то можно запутаться... Пусть все расчеты идут в рублях например... В день1 купили 100 шт марсов по 25 руб, и продали в день2 их по 27 руб. Но! В день2 у поставщика этого цена уже была по 28 руб. И как считать в этом случае наценку? По вашей логике нужно так (27-28) за штуку в рублях. Отрицательное число однако!Выводы... нужно на день продажи пересчитать по курсу $ ЦБ... вот и всё!Стоимость для предприятия это то, сколько потрачено реально... даже если потратили больше, чем следовало-бы...Цену поставщика анализировать пересчитывая в $, т.е. в признанный эталон.Тогда в День1 Стоимость100штВ$=100*1*25/29=86.21$не День2 продали 100 шт за 2700 руб. НаценкаЗа100штВРуб= 2700 - 86.21*30 = 113.70 руб или 3.79 $ или3.79/86.21*100=4.40 % ... не жирно однако...А по рублям будет так (если бы учет был в рублях): (2700-2500)/2500*100= 8 % - это для налоговой.