v7: Перебрать запросом документы и получить цены номенклатуры из справочника цен. #719289

Надо перебрать документы по номенклатуре и получать цену не из документа, а из справочника цен на дату документа. Кто делал, подкиньте кусок кода . Пожалуйста.

Блин ... ТиС, файловая, черный запрос.

Обязательно запросом? Нередко выборка работает быстрее в 7.7.

Не обязательно, но надо таблицу строить потом, а итоги по группировкам и вообще, группировки проще в запросе.

В функции чёрного запроса можно использовать функцию из модуля. Может медленно работать, но логику упрощает.

+ Можно и к глПолучитЦену обратиться сразу

Ну да, пробовал уже. Как то тоже криво. Вот об ней то и речь. Сейчас вот вернулся к этому ...

но если есть аргументы не только из запроса, то к ф-и глоб. модуля придется обращаться через промежуточную ф-ю из модуля

Все из запроса. Вот что передаю в глобальную глПолучитьЦену(Номенклатура,СпрПоРекв("ТипыЦен","Код",Строка(Контрагент.ОсновноеСвойство.ЗначениеСвойства)),ДатаДок,Единица,Валюта,"1","1");

Не надо в запросе - будет жутко Смотри как получается цена в подборе, например

Блин, совсем разучился подглядывать. Верно ведь.

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

Мало того, что как то по владельцу надо синхронизировать выборку и группировку, так еще хз, как на дату документа цену получить.

какая нахрен сумма? где группировка по строке документа? у тебя же задача получить цену для каждой номенклатуры в каждой строке? понятно что у 1с крыша едет... сделай перебором если не прет

С выборкой все понятно - но блевать охота от подсчета итогов и построения группировок.

... или сортировать ТЗ и извращаться... но тут противно действительно

Мне надо не из строки документа цену, а из справочника цен. Так что строка тут не при чем. Было бы из документа - не изгалялся бы

Так надо отделить строки чтобы не было каши У тебя 1с суммирует цены по номенклатуре... но номенклатура повторяется в одном/разных документах и т.п.

И выборка только строк документов - без Справочник...

Так у меня и нет группироввки по документу, что бы заморачиваться, что она сукка тупо не просуммирует цены по контрагенту ? Номенклатура то одна в пределах группирговки, функция суммирует по группировке, по логике. Куррва ...

Для этого надо выбрать различную номенклатуру и потом уже что-то там лепить и суммировать А вообще иди проспись, а то забанюнахрен

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

За баней решение есть ? о_О

Сам то че не спишь ... Или белорусы не спят ?

Настало время главного вопроса: зачем перебирать "документы по номенклатуре" если она и так известна и цена хранится не в документе?

>И выборка только строк документов - без Справочник... О ... На четверты день Зоркий Сокол увидел, что у сарая нет четвертой стены ... Попробую

)) Таки да ? Зачем ))

Если не известна - выборка номенклатуры из документов, свертка тз по номенклатуре и вперед, получать цены

А зачем цену суммировать просто так? Какой нужен итог?

от же сцуко

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

да он просто нагло троллирует

К стати да, нахера. Да ладно ... Не до этого. Туплю уже просто

значит нужно цену множить на количество

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

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

Ну некоторые значения по номенклатуре просуммировать ...

Блят ... полпятого

Клянусь - завяжу с одинесом в течении полугода.

Блевать уже от нее охота .

Пошло оно все кобыле в трещину .... Пошол спать. Спасибо, за посильную помощь. Утро вечера, как говорится ...

Примерно так тогда: ....... в ПолучитьСуммуСкидки описать вычисление скидки а запрос все просуммирует

От враги ... Сами не спят и другим не дают. Щас попробую. Уже есть похожие конструкции

точнее так: |Функция СуммаСкидки = Сумма(Количество*ПолучитьСуммуСкидкиНаЕдиницу(Номенклатура, Реализация, Цена))

ага, вам тоже спать пора ... В Цена то, что будем передавать ? Значение то по владельцу да и периодический еще ...

Цена из документа, если нужна конечно

Не нужна, нужна из справочника

Потому и сыр бор весь

А из справочника цена берётся через вызов глполучитцену из нашей функции получитьсуммускидкинаединицу

Номенклатура и реквизиты шапки реализации все в ней есть

В получитьсуммускидкинаединицу можно передать из запроса еще единицу и валюту, если не брать дефолтные

Посмотри как формируется скидка в печатной форме счета со скидками. Скомпилируй для своей задачи. Может быть, и прозреешь.

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

Так вся инф-я из строк документа извлекается в запросе. Передаётся в функцию для расчёта. Да - будет тормозить на больших объёмах, но работать будет

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

Делал подобный отчет по регистрам, сравнивал с ценами заданного пользователем типа цен.

Это же пестец ... Лучше б я и не углублялся в 1с. Так бы и думал, что зачетный софт. Вопрос то в том, что в запросе к справочнику нельзя получить значения периодического подчиненного реквизита ... Что тут ненужного в языке запросов по мнению разработчиков ?? Епланы ...

При чем тут "зачетный софт"? На любом языке, чтоб что-нибудь написать - надо уметь писать.

Убираешь цену из запроса. И получаешь её естественно при обходе группировок запроса.

Ну ... это я думаю справедливо отнести и к разработчикам ... Что такого необычного в моем пожелании к функционалу языка запросов ? Стандартное обращение к стандартному справочнику в стандартной конфигурации ... За каким хером ламеру надо выписывать какие то кренделя запросом, что бы добыть какие то значения из этой ситуации ? ... опять за рыбу деньги ... А итоги ? Опять счетчиком считать ??? Гамнописцы 1совские ... Так то я и сам своими кривымируками могу, но нахера такие качели то ?

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

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

Ну так понимаю в принципе то ... Покажи мне функционал языка запросов для работы с периодическими реквизитами ?

А он должен быть? Язык - встроенный язык 1С, и в нем есть полный функционал для работы с периодикой. Естественно не надо при этом пользоваться запросами.

А язык запросов - это встроенный в китайца язык ? > Естественно не надо при этом пользоваться запросами. С какого перепугу то такая нелогичная предопределенность то ??

Язык запросов - это всего-лишь часть встроенного языка 1С. И в семерке, и в восьмерке, и в Аccess и т.д. - у языка запросов куча ограничений. И предназначен он для решения узкого класса задач и подзадач. Для решения любой задачи принято использовать те средства, которые для этого предназначены, и в любом случае программист должен использовать те средства при помощи которых задачу можно эффективно решить. Ничего нелогичного я вообще-то не вижу.

О каком китайце идет речь?

Кстати, для получения цены даже есть готовая функция у тебя в конфигурации. Если ты не умеешь использовать в запросе внешние функции - это опять-таки никак не проблема 1С.

Ну ... Это уже вопрос религии, по типу - почему винда все делает сама, а Линупс надо кодить выпучив глаза ... Линуксоиды - за эксюзабельность, а виндоводы - за френдабельность ... В итоге - это не логика которую подсказывает практика, а логика диктуемая разработчиком. А уж результатом чего она является - возможностями синтаксиса или представлениями разработчика о том, что ДОСТАТОЧНО программисту в тех или иных ситуациях - вопрос филосовский. Мое убеждение такое, что в моей ситуации неумение запроса работать с периодикой, в частности, ставит меня в затруднительное положение при выводе результатов в таблицы, так как выборки сложно группировать и суммировать, а так же адаптировать под макет печати. Т.е. разработчики решили свои проблеммы за мой счет. Казлы. Поскольку речь таки идет о работе с набором стандартных реквизитов. И о НЕСПОСОБНОСТИ механизма платформы получать из них значения. Не знаю, о любом. Это я к тому, что язык запросов - неотемлемая часть языка 1С. А не сторонняя приблуда. Знаю. Она работает только в функции запроса и таки отрабатывает криво, перемножает результат на количество вхождений в группировку. Причем по хер знает по какому то кривому алгоритму. Начинается как бе не с 1 го вхождения, а со второго и далее. Сижу вот сейчас разгадываю ... Опять надо или счетчик прикручивать и делить на него или по условию прекращать суммирование при значении счетчика более 1. Мы тут в дворницкой то тоже не пальцем деланы ...

Ни у кого проблем нет, проблемы только у тебя, а виноват естественно язык :) Код, который ты выкладываешь, ни имеет ни малейших признаков логики, и аналогичный код не будет работать ни на одном языке. Проблема то не в языке, а в том что не всем дано писать. Не лучше ли найти вид деятельности к которому у тебя есть способности, и заниматься им?

Не имел логики. Счас вот выложу, что допилил и там с логикой порядок. Но и с ограничениями функционала - тоже все очевидно.

По кругу идем. В любом языке функционал ограничен. И в любом языке со временем функционал развивается. Ты бы видел какие ограничения были в конструкторе запросов в Access на момент появления семерки.

Не ... Это ты по кругу. Я на старте - разрабы - ленивые казлы ...

Вот эта пидерсия отрабатывает правильно. Запрос = СоздатьОбъект("Запрос"); И скажите мне после этого, что я ленивый тупой ламер ...

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

Конечно ламер. нафига ты складываешь ЦЕНУ??? |Функция СуммаБезСкидки=Сумма(глПолучитьЦену(Номенклатура,ТипЦены,ДатаДок,Единица,Валюта,Курс,Кратность)*КОЛИЧЕСТВО); Естественно решало все твои проблемы.

Зачем цену суммировать без перемножения на количество??!

+1

1.>Конечно ламер. нафига ты складываешь ЦЕНУ??? Это не я складываю, а функция запроса, потому как обращение к фнешней функции возможно только изФУНКЦИИ ЗАПРОСА и именно ИЗ СУММЫ. 2. Потому что СуммаБезСкидки суммируется не по КОЛИЧЕСТВУ товара, а по количеству ВХОЖДЕНИЙ в группировку. При чем тут вообще, количество товара ... Сам ты ... плохо меня понял. :D

Можно взять функцию запроса Среднее, чем делить на вхождения

Ну да, можно. Только я об этом не знал и тут никто не подсказал. Щас попробую.

"2. Потому что СуммаБезСкидки суммируется не по КОЛИЧЕСТВУ товара, а по количеству ВХОЖДЕНИЙ в группировку. При чем тут вообще, количество товара ..." Это всё происходит на живой базе работающей фирмы?!

на копии. а что не так в моем утверждении ???

Цену-то итожить по номенклатуре для чего нужно?

Да где ты видишь, что я ее по номенклатуре то итожу ? Я цену перемноженную на количество итожить, так как надо все суммировать по этой номенклатуре и по контрику. Я пока только ДОБЫВАЮ ЦЕНУ !!!

Для цены функция запроса вовсе не нужна

епать  вы заколдованные что ли ? Из чего такой вывод  то ?? Мне цена нужна ИЗ СПРАВОЧНИКА

+а ее только через внешнюю функцию добыть можно (для NS об использовании ВСЕХ возможностей этого ушлепского языка), а доступ к ВНЕШНЕЙ функции - только из ФУНКЦИИ ЗАПРОСА ...

Так как она не нужна то ?

Да, еще раз спасибо. Среднее отрабатывает как надо. Ну так и быть ... Не криворукие разрабы ... Только одна рука у них кривая :D

цену итожить не надо, а значит и посчитать её можно уже на этапе обхода результата запроса перед выводом

пля ... А группировки как суммировать ? Счетчиком ??

Ты не мудри, ты код покажи какой получился

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

А просто функцию запроса "СуммаСоСкидкой" поделить на функцию запроса "Сумма(Количество)"?

Без разницы - главное,что этим не загромождать запрос