|
v7: Два последних прихода | ☑ | ||
---|---|---|---|---|
0
AAA
05.06.23
✎
07:53
|
Всем доброго дня!
Коллеги, не могу сообразить, нужно для каждой позиции номенклатуры найти последние 2 документа прихода. Прямым запросом один последний документ нахожу без проблем, а вот как найти второй, предыдущий ) Ничего путного в голову не приходит ) Видимо надо писать второй похожий запрос с такой же выборкой, но кроме данных из первого запроса |
|||
1
Bigbro
05.06.23
✎
08:19
|
да ничего тут особо не придумаешь.
по одной позиции приходы могут быть вчера и позавчера а по другой - через столетие в будущем и до рождества христова в прошлом. вижу только брать все и уже затем перебирать. два цикла по группировкам. |
|||
2
AAA
05.06.23
✎
08:22
|
(1)ну весь период я ограничу, например двумя годами. Сложность выбрать для каждой позиции именно 2 прихода, а не один последний
|
|||
3
arsik
05.06.23
✎
08:54
|
Вот самое простое в 8ке. Но будет проблема если по одной номенклатуре в одну и ту же дату будет 2 документа
|
|||
4
skafandr
05.06.23
✎
09:17
|
(0) Наступите песне на горло - сделайте стандартным запросом
Группировка Номенклатура; Группировка Приход; При обходе группировки (не забудьте обратное направление указать) Приход после второй записи Прервать ;-) |
|||
5
Андрей_Андреич
naïve
05.06.23
✎
09:23
|
(4) угу - если номенклатура сотни тысяч и приходов столько же - из горла вместо песни предсмертный хрип
|
|||
6
skafandr
05.06.23
✎
09:25
|
(5) А может номенклатура 100 и 10 приходов :-) Автор темы все условия не озвучил
|
|||
7
Андрей_Андреич
naïve
05.06.23
✎
09:28
|
(6) В первой строке звучит "прямой запрос" - явно номенклатура > 100
|
|||
8
kalleka
05.06.23
✎
09:40
|
(0) Можно же SQL функцией сделать, в которую передавать ИД номенклатуры. И там уже не так важен размер запроса.
Если получаешь SQL функцией, то можно добавить реквизит для исключения ИдДокумента что-то вроде function [dbo].[ПолучитьДокументПоследнийПриходТовараКромеДокумента] (@Товар char(9), notiddoc char(9)) .. where dt.SP195 = @Товар and j.closed = 1 and dh.iddoc <> @notiddoc .. Тогда уже в основном запросе в 1с dbo.ПолучитьДокументПоследнийПриходТовараКромеДокумента(@Товар,'') - будет первый приход dbo.ПолучитьДокументПоследнийПриходТовараКромеДокумента(@Товар,dbo.ПолучитьДокументПоследнийПриходТовараКромеДокумента(@Товар,'') ) - будет второй приход |
|||
9
ADirks
05.06.23
✎
10:01
|
(0) Что-то мне подсказывает, что если ты находишь один последний документ, то найти любое количество последних не составит труда.
Приведи текст твоего запроса, и я покажу тебе, куда там TOP 2 вставить :)) |
|||
10
AAA
05.06.23
✎
10:14
|
(9)
ТекстПодЗапроса = " |SELECT | MAX(Ном.Id + " + ИдВремени + ") AS НомДатаВремяIddoc, | Ном.Id AS [Номенклатура] |FROM |" + Журнал + " AS Jr, | $Документ.ПоступлениеТоваров AS Док, | $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ, | $Справочник.Материалы AS Ном, | $Справочник.Контрагенты AS Контр |WHERE | (Jr.IdDoc = Док.IdDoc) AND | (Док.IdDoc = ДокТЧ.IdDoc) AND | ($Док.Служебный = 0) AND | ($Док.ТипДокумента = 0) AND | ($Док.Контрагент = Контр.Id) AND | (RIGHT($ДокТЧ.Товар,9) = Ном.Id) AND | ($ДокТЧ.Цена > 0.00) AND | ($Контр.ТипПоставщика <> 1) AND |" + УсловиеDate + " AND " + УсловиеClosed + УсловиеТовар + ТекстМФФильтра + " |GROUP BY | Ном.Id"; ТекстЗапроса = " |SELECT Посл.Номенклатура AS [Номенклатура $Справочник.Материалы], | CAST(($ДокТЧ.Цена) AS Numeric(15,2)) AS ЦенаПрихода, | $Док.Контрагент AS [Контрагент $Справочник.Контрагенты], | Jr.IdDoc AS [ДокументПрихода $Документ], | Jr.IdDocDef AS ДокументПрихода_вид, | Посл.НомДатаВремяIddoc |FROM " + Журнал + " AS Jr |INNER JOIN | $Документ.ПоступлениеТоваров AS Док ON (Jr.IdDoc = Док.IdDoc) |INNER JOIN | $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ ON (Jr.IdDoc = ДокТЧ.IdDoc) |INNER JOIN (" + ТекстПодЗапроса + ") Посл | ON (Jr.IdDoc = RIGHT(Посл.НомДатаВремяIddoc,9)) AND | (RIGH($ДокТЧ.Товар,9) = Посл.Номенклатура) |ORDER BY Посл.Номенклатура |"; |
|||
11
AAA
05.06.23
✎
10:16
|
Ном.Id из MAX() можно убрать, это я сейчас пытался свести первый запрос к одному параметру выборки
|
|||
12
Гена
05.06.23
✎
10:22
|
В идеале, для одного обхода достаточно двухмерной нумерации вместо одномерного идентификатора: i - номенклатура, j - док
Тогда после только одного обхода сразу можно получить для каждой i номенклатуры известные уже N-й и (N-1)-й доки. |
|||
13
uno-group
05.06.23
✎
10:24
|
А для чего это нужно. Может тебе надо совсем другое? Не разу не сталкивался с задачей поиска нескольких приходов для кучи номенклатуры.
Приходные цены при приходе в историю цены закупки не пишутся? может проще по периодике запрос сделать, или по справочнику партии товаров, чем по документу. |
|||
14
AAA
05.06.23
✎
10:24
|
(12)Что такое обходы ? Обходы чего ?
|
|||
15
Андрей_Андреич
naïve
05.06.23
✎
10:25
|
А вообще-то менеджерам лучше свою работу делать, а не придумывать работу для программиста. Один дворник может загрузить работой по оптимизации взмахов метлы десяток НИИ
|
|||
16
AAA
05.06.23
✎
10:27
|
(13)Если бы писались, то было бы все иначе. Это цены материалов для цеха. И озадачили именно тем, что нужны две последние цены прихода, чтобы их сравнить
(15)Это типа для снабжения. Хотя в целом я не очень уверен в полезности этой информации |
|||
17
AAA
05.06.23
✎
10:28
|
Может просто тупо все выбрать, да отсортировать )) а там уже бери хоть 2, хоть 10 приходов
|
|||
18
ADirks
05.06.23
✎
10:31
|
(10) как-то излишне сложно
Проще надо быть. Примерно так ТекстЗапроса = " |SELECT TOP 2 | Посл.Номенклатура AS [Номенклатура $Справочник.Материалы], | CAST(($ДокТЧ.Цена) AS Numeric(15,2)) AS ЦенаПрихода, | $Док.Контрагент AS [Контрагент $Справочник.Контрагенты], | Jr.IdDoc AS [ДокументПрихода $Документ], | Jr.IdDocDef AS ДокументПрихода_вид, | Посл.НомДатаВремяIddoc |FROM | "+Журнал+" AS Jr | INNER JOIN $Документ.ПоступлениеТоваров AS Док ON (Jr.IdDoc = Док.IdDoc) | INNER JOIN $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ ON (Jr.IdDoc = ДокТЧ.IdDoc) | INNER JOIN (" + ТекстПодЗапроса + ") Посл ON | (Jr.IdDoc = RIGHT(Посл.НомДатаВремяIddoc,9)) AND | (RIGH($ДокТЧ.Товар,9) = Посл.Номенклатура) | | LEFT JOIN $Справочник.Материалы AS Ном ON Ном.Id = RIGHT($ДокТЧ.Товар,9) AND Left($ДокТЧ.Товар, 4) = $ВидСправочника36.Материалы | LEFT JOIN $Справочник.Контрагенты AS Контр ON Контр.Id = $Док.Контрагент | | |WHERE | (Jr.IdDoc = Док.IdDoc) AND | (Док.IdDoc = ДокТЧ.IdDoc) AND | ($Док.Служебный = 0) AND | ($Док.ТипДокумента = 0) AND | ($ДокТЧ.Цена > 0.00) AND | ($Контр.ТипПоставщика <> 1) AND | "+УсловиеDate + " AND " + УсловиеClosed + УсловиеТовар + ТекстМФФильтра+" | |ORDER BY | Jr.Date_Time_IDDoc Desc |"; |
|||
19
ADirks
05.06.23
✎
10:35
|
Только надо учитывать тот факт, что выборка с такими условиями будет читать всю табличку $ДокументСтроки.ПоступлениеТоваров, и если там строк много, то может получиться неприятно.
|
|||
20
Гена
05.06.23
✎
10:35
|
(14) Не помню, мы в 7-ке же табличные части доков поступления обходим, не регистры?
А коли так, то матрица нумерации сложится так: (уникальный код номенклатуры, просто номер позиции по времени дока) Для первого дока по времени (***, 1), для второго (***, 2) и т.д до конца периода выборки. |
|||
21
ADirks
05.06.23
✎
10:37
|
(18) + ошибочка... подзапрос "INNER JOIN (" + ТекстПодЗапроса + ") ..." надо убрать, он не нужен
|
|||
22
AAA
05.06.23
✎
10:38
|
(18)а в чем проще то ?)) ТекстПодзапроса остался прежним? а он же выбирает один приход для каждого материала
|
|||
23
AAA
05.06.23
✎
10:39
|
я пробовал с TOP 2 и ORDER BY, но у меня ничего не вышло. Отбирались всего две позиции для всей номенклатуры.
|
|||
24
ADirks
05.06.23
✎
10:40
|
(22) Проще для понимания. Так то принципиально ничего не изменилось.
Ну и подзапрос там не нужен, я его удалить забыл. |
|||
25
AAA
05.06.23
✎
10:42
|
(24)так у меня вернется всего 2 прихода, а мне надо 2 прихода для каждого материала
|
|||
26
uno-group
05.06.23
✎
11:07
|
(16) В том то и дело что тут нужно сравнивать цены этих приходов и сравнивать их будут с учетом каких то факторов. Цена прихода которая вчера и 2 года назад это 2 разных цены. Цена прихода за партию 10 кг и 20 тн тоже будут отличаться. Опять же если перебираешь документы то Документ поступления товаров может быть с признаком возврат и там будут стоять цена по который ты продавал, хотя для материалов это обычно не критично. К документу поступления может быть привязан документ затраты на поступления где пописаны транспортные и прочие затраты которые для дешевых материалов могут превышать цену самих материалов.
Очень часто что если последняя цена закупки равна текущей цене закупки то искать еще одну цену закупки просто не надо, что значительно сокращает список товаров по которым нужно искать 2 цену. |
|||
27
ADirks
05.06.23
✎
11:25
|
(25) что-то я не внимательно задачу прочитал.
В такой постановке запросом получить нужную выборку врядли получится. Только постобработкой. |
|||
28
AAA
05.06.23
✎
11:37
|
(28)Потому то у меня и был подзапрос. Можно результаты выборки последних цен выкинуть во временную таблицу или временный справочник сделать и затем выбрать снова последние цены, но исключая сохраненные. Но возиться неохота ради этой задачи. Итак день почти убил. Я лучше выберу все, а затем смогу показать хоть 2 прихода, хоть 22. Думаю, что это будет малополезным. Типа хотят видеть динамику последних цен закупа, чтобы цены снижались )
|
|||
29
ADirks
05.06.23
✎
11:46
|
Таки можно и запросом. С использованием OVER
схема такая: select * from ( select ROW_NUMBER() over (PARTITION BY ТЧ.Номенклатура ORDER BY жДок.Date_Time_IDDoc) нДок, ТЧ.Номенклатура, жДок.Date_Time_IDDoc from докТЧРеализация ТЧ left join ЖурналДокументов жДок ON жДок.идДок9 = ТЧ.идДок9 ) ТЧ2 where ТЧ2.нДок <= 2 |
|||
30
ADirks
05.06.23
✎
11:47
|
результат примерно такой
1 9 201610038T6W8W DOD6 2 9 201610055E03GW DP3L 1 4A 2016100367B9KW DO50 2 4A 201610038T6W8W DOD6 1 5X 201610059HRO3K DPI9 2 5X 20161007AO2374 DQIU 1 60 2016100367B9KW DO50 2 60 20161003729T1C DO7N 1 66 20161021A54PVK DVF8 2 66 201610246TASY8 DVNF 1 8Q 20161005A284G0 DPJK 2 8Q 201610277W4WQO DX93 1 HP 201610035SGI1C DO36 2 HP 20161003729T1C DO7N 1 IL 2016100450R79C DONO 2 IL 201610128K2BJK DRYY 1 IM 2016100450R79C DONO 2 IM 2016100476BZDS DOSV 1 IN 2016100450R79C DONO 2 IN 2016100476BZDS DOSV |
|||
31
AAA
05.06.23
✎
11:54
|
(29)возьму на заметку, спасибо огромное
|
|||
32
Злопчинский
05.06.23
✎
11:56
|
а еслитупо?
Регистр ОбратныйПорядок УстановитьФильтр ВыбратьДвижения ? |
|||
33
AAA
05.06.23
✎
12:04
|
(32)я уже доделываю с полной выборкой, осталось печатную форму сделать )) там дел то. Пошел по ложному пути
Стереотип мышления. Недавно выезжаю со стоянки утром. Надо выехать направо на дорогу Д1, потом через 200 м снова направо на дорогу Д2. На выезде направо авария, проехать никак. Поэтому еду закоулками, выезжаю сразу на Д2. И какие то мгновения размышляю, где лучше развернуться, чтобы вернуться назад и снова выехать на дорогу Д2, на которой уже нахожусь. Это пипец. Стало даже страшно ))) Но помутнение было кратковременным и поехал прямо )) |
|||
34
AAA
05.06.23
✎
13:11
|
Всем спасибо! все отлично получилось )) Надо просто правильно ходить, не всегда прямо ))
|
|||
35
Bigbro
06.06.23
✎
05:55
|
а вообще если задача в (16) стоит то можно не удалять общепринятым в среде 1с образом гланды
а именно при поступлении второго прихода делать необходимую проверку и сохранять нужный результат проверки. чтобы получать его мгновенно а не перелопачивая полбазы каждый раз когда подобное потребуется. |
|||
36
AAA
06.06.23
✎
06:17
|
(135)Что значит при поступлении второго прихода? Приходов по каждой позиции много. В отчете нужны 2 последних. А завтра может 3 или более попросят. На 11 ГБ файловой база работает вполне шустро.
|
|||
37
Bigbro
06.06.23
✎
06:26
|
имеется в виду при оформлении поступления у вас уже есть последний документ - вы его формируете в этот момент.
предпоследний получается по щелчку пальцев мгновенно - потому что последний еще не проведен. вот в этот момент и делайте проверку и записывайте куда то в свой регистр, откуда будете так же мгновенно получать я вот о чем. |
|||
38
AAA
06.06.23
✎
07:18
|
(37)Там тоже будет геморрой, надо как то определять, что приход последний, бывший последний делать предпоследним. Я не вижу профита. Задача решилась, прямым запросом все выбираю, загрузка. в индексированную таблицу и все чудесно. И могу показать хоть 2 прихода, хоть все, выделяя цветом приходы, которые дороже предыдущего.
В принципе я согласен, что бывает полезно использовать Ваш подход - готовить данные заранее, а потом только доставать готовое |
|||
39
Гена
06.06.23
✎
07:27
|
(37) Поступления вводит девочка низшего звена бухгалтерии, не будет она ждать, пока финансовый аналитик рассмотрит цены.
(38) Только так и будет эргономично: один запрос, а далее работа с готовой таблицей номенклатура - поступление. Выбирай хоть предпоследнее, хоть все нечётные, хоть десятое снизу, хоть по заданной группе номенклатуры. |
|||
40
АгентБезопасной Нацио
07.06.23
✎
15:00
|
(27) почему "вряд ли получится"?
что-то вроде этого: SELECT ДваПрихода.Номенклатура [Номенклатура $Справочник.Номенклатура], ДваПрихода.Позиция [Позиция], Журнал.iddoc [ДокументПоступление $Документ.ПоступлениеТоваров], $ДокТЧ.Цена [ЦенаПоступления], $Док.Контрагент [Поставщик $Справочник.Контрагенты] ( SELECT $Док.Номенклатура [Номенклатура], MAX(Журн.DateTimeIddoc) [Позиция] FROM _1journ AS Журнал INNER JOIN $Документ.ПоступлениеТоваров AS Док ON Журнал.IdDoc = Док.IdDoc INNER JOIN $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ ON Док.IdDoc = ДокТЧ.IdDoc INNER JOIN $ДокументСтроки.ПоступлениеТоваров AS ВыбранныйДок ON $ВыбранныйДок.Номенклатура = $ДокТЧ.Номенклатура WHERE Журн.DateTimeIddoc > :НачДата and ВыбранныйДок.iddoc = :ВыбранныйДок and ВыбранныйДок.iddoc <> Док.iddoc GROUP BY $Док.Номенклатура UNION ALL SELECT $Док.Номенклатура [Номенклатура], MAX(Журн.DateTimeIddoc) [Позиция] FROM _1journ AS Журнал INNER JOIN $Документ.ПоступлениеТоваров AS Док ON Журнал.IdDoc = Док.IdDoc INNER JOIN $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ ON Док.IdDoc = ДокТЧ.IdDoc INNER JOIN $ДокументСтроки.ПоступлениеТоваров AS ВыбранныйДок ON $ВыбранныйДок.Номенклатура = $ДокТЧ.Номенклатура LEFT JOIN ( SELECT $Док.Номенклатура [Номенклатура], MAX(Журн.DateTimeIddoc) [Позиция] FROM _1journ AS Журнал INNER JOIN $Документ.ПоступлениеТоваров AS Док ON Журнал.IdDoc = Док.IdDoc INNER JOIN $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ ON Док.IdDoc = ДокТЧ.IdDoc INNER JOIN $ДокументСтроки.ПоступлениеТоваров AS ВыбранныйДок ON $ВыбранныйДок.Номенклатура = $ДокТЧ.Номенклатура WHERE Журн.DateTimeIddoc > :НачДата and ВыбранныйДок.iddoc = :ВыбранныйДок and ВыбранныйДок.iddoc <> Док.iddoc GROUP BY $Док.Номенклатура ) AS ПервыеДокументы ON ПервыеДокументы.Номенклатура = $ДокТЧ.Номенклатура and ПервыеДокументы.Позиция = Журн.DateTimeIddoc WHERE Журн.DateTimeIddoc > :НачДата and ВыбранныйДок.iddoc = :ВыбранныйДок and ВыбранныйДок.iddoc <> Док.iddoc and ПервыеДокументы.Номенклатура is NULL GROUP BY $Док.Номенклатура ) AS ДваПрихода INNER JOIN _1journ AS Журнал ON Журнал.datetimeiddoc = ДваПрихода.Позиция INNER JOIN $Документ.ПоступлениеТоваров AS Док ON Журнал.IdDoc = Док.IdDoc INNER JOIN $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ ON Док.IdDoc = ДокТЧ.IdDoc |
|||
41
Харлампий Дымба
07.06.23
✎
18:09
|
(39) Тогда это проще будет сделать через периодический реквизит "ЦенаПоступления" в справочнике "Номенклатура" и в модуле проведения приходной накладной делать УстановитьРеквизитСправочника(). Все последние цены товара можно оперативно получить вместе с документами.
Если есть предубеждение к периодическим реквизитам - то можно через подчиненный номенклатуре справочник с реквизитами "цена" и "документ", а в наименование, например, пихать позицию документа, чтобы выборку можно было сделать в порядке/обратном порядке документов. Создавать/изменять элементы справочника при проведении, удалять в ОбработкаУдаленияПроведения(). Правда, для УРБД, если есть, не будет работать нормально. Но думаю, что если решение запросом уже найдено и оно довольно быстрое - то оно лучшее. |
|||
42
Bigbro
08.06.23
✎
06:09
|
(41) не надо злоупотреблять периодичкой в 7.7
рассчитывать каждый раз тоже не надо - это архитектурно неверное решение. все что может быть рассчитано один раз и далее повторно использовано - должно быть именно так и реализовано. поэтому Гена в (39) извини но ты неправ в данном случае. девочка на приходе не знает ничего и знать не должна. но в момент когда она нажимает на кнопку "провести" в приходе выполняется запрос по остаткам на последний документ - мы имеем все предыдущие цены. в текущем документе у нас все текущие цены. сравниваем и сохраняем результаты - в отдельный регистр например. из которого можно выдернуть что угодно в любой момент. не получая все документы от начала времен. |
|||
43
АгентБезопасной Нацио
08.06.23
✎
06:37
|
(42) если доставать не из документов, а из регистра движений ТМЦ, который проиндексирован и по номенклатуре, и по докам - то запрос получится весьма быстрый. Насколько необходимо разменивать "расчет" на "запись и хранение" - зависит от частоты операций "анализа приходов".
Что касается "девочки на приходе" - Гена говорил о другом. Первичку вводит [дешевая] девочка-оператор, которая вообще не должна думать. ее задача обработать документы как есть (и без ошибок и в срок). а анализ цен, и принятие каких-то решений - задача для [более дорогого] финаналитика, финконтролера, или какого-то другого стража бюджета. И уже он должен получать информацию о девиации цен, и принимать какие-то решения. |
|||
44
Bigbro
08.06.23
✎
06:40
|
(43) так я о том и говорю - что переписанная логика работы документа и системы в целом вообще никак не касается девочки на приходе.
она вводит ровно те же данные ровно те же кнопки жмет. и понятия не имеет какие запросы к каким регистрам производятся и какие движения куда пишутся. |
|||
45
Гена
08.06.23
✎
06:40
|
(42) Зачем тогда вообще нужны запросы по документам? Давайте тогда по любому чиху заведём свои регистры.
Видел как-то 90-й счёт, куда ГБ упросила впендюрить кучу субконто: и контрагентов, и номенклатуру и ещё что-то. |
|||
46
Bigbro
08.06.23
✎
06:42
|
(45) это "дешевый" с точки зрения ресурсов системы вариант выполнить хотелку с 2 последними приходами.
когда мы получаем результат не дергая все данные из всей базы. а крохотным запросом при каждом приходе получаем нужное и пишем в готовом к использованию виде. откуда при необходимости опять же будет мгновенное получение по нужным отборам не перелопачивая всю базу. |
|||
47
Гена
08.06.23
✎
06:48
|
(46) Да это понятно. Просто стоит ли игра свеч. Сегодня им цены подавай, завтра почасовой учёт прибыли/убытка от каждой продажи.
Как показывает практика, если финдира вовремя не тормозить - программа распухнет от его хотелок ) |
|||
48
АгентБезопасной Нацио
08.06.23
✎
06:49
|
(46) но увеличивает скорость записи, т.е. время блокировки. а читать можно без блокировки.
кроме того, "регистр приходов" - это подмножество правильно индексированного регистра движений. (это я намекаю на то, что если понадобится получать "две последних цены расходов" - ты тоже будешь делать отдельный регистр?) ну и ко всему этому вопрос - нужно ли "мгновенное получение", как часто оно нужно, и какова его реальная стоимость |
|||
49
AAA
08.06.23
✎
07:18
|
Мне кажется, что здесь не тот случай, когда надо писать при провендении в специальный "регистр". При полной выборке движений постобработка данных минимальная и быстрая. Гена абсолютно прав, что завтра может понадобиться 3.5 прихода разных оттенков серого или еще что-нибудь подобное. Сейчас могут смотреть произвольное число приходов. Бывают случаи, когда выборка сложная, тогда можно "агрегат" куда-то писать, но это редко. А здесь пихать сложность в проведение ради отчета, который может еще и не очень нужен - сомнительное занятие
|
|||
50
Гена
08.06.23
✎
07:44
|
Кстати, вы никогда не замечали, что при начале работы с новой средней фирмой - сразу начинает нарезать круги финдир со своими эксель-табличками и ласково так просить их реализовать в программе 1с? )
Стоит дать слабину, и брюки превращаются... тьфу! Конфа превращается... превращается конфа... |
|||
51
Гена
08.06.23
✎
07:56
|
Помню войну на одной фирме между ГБ и финдиром, как раз на 7-ке. Финик пробил у программиста на 90-х свои статьи доходов и расходов под свой анализ. Девчата из бухгалтерии понятия не имели какой элемент выбирать нового справочник и заводили каждый раз новый, вроде "оплата за гостиницу Пупкину". Финаналитикам потом приходилось всё перебивать, а это перепроведение доков задним числом, отчего съезжал напрочь БУ. Вот ГБ и материла финика, а тот кричал в ответ, что все её бабы дуры )
Ну я и предложил в его справочнике создать группы точно под свой анализ. Какие бы новые элементы потом девчата ни заводили, финаналитики легко их перебрасывали в нужные им группы, а сам финик анализировал свою хрень не по элементам, а по группам. |
|||
52
АгентБезопасной Нацио
08.06.23
✎
09:48
|
(49) попробуй, плз, (40) по времени по сравнению с постобработкой. Интересно на реальных данных (на выборке из регистра (40) будет, кстати, быстрее, чем по документам)
и да, база файловая, временные таблицы низзя? и еще, на "произвольное количество" запрос нужен? Если да, то дай структуру регистра движения остатков (можно прямо из dds, с индексами) (3) не работает. для 10 номенклатур выбирает 526 строк. |
|||
53
Aleksey
08.06.23
✎
09:51
|
(41) лучше через регистр накопления
|
|||
54
Харлампий Дымба
08.06.23
✎
11:13
|
(53) Я, к стыду своему, не силён в восьмерочных терминах, в семерке - регистр остатков и регистр оборотов. И оба не совсем удобны для хранения/получения сведений о последних ценах прихода. Плюс при добавлении каких-то измерений/ресурсов/реквизитов надо или лезть напрямую в таблицы или шаманить с технологическим перепроведением, что очень неудобно.
Периодические реквизиты хранятся в одной таблице, поэтому сильно её задействовать не комильфо. Поэтому как вариант (аналог регистра сведений в 8, да?) можно использовать отдельный или подчиненный справочник - реализовать быстро, первоначально заполнить просто, информацию можно записать/получить быстро, места много не займёт. |
|||
55
ADirks
08.06.23
✎
11:37
|
(52) Мне такой запрос на практике не нужен, но тем не менее интересно было бы взглянуть.
Предположим, что регистр простой (Номенклатура, Документ; Количество). И проиндексирован так, как тебе надо, невзирая на правила 1С. Идея в (40) понятна (собственно, была высказана ещё в (8)), но как-то очень уж по-китайски. |
|||
56
AAA
08.06.23
✎
11:45
|
(52)время будет, я попробую. База у меня файловая, 11 гигов. А временные таблицы есть - INTO DBF <имя файла>, редко но пользуюсь. Но здесь неохота, потому что базу собираюсь в SQL затащить, а там еще и другие перемены маячат ) По скорости не измерял, но визуально быстрее, чем просто последние цены. Выборка же очень простая. Индексированная таблица тоже шустро работает
|
|||
57
arsik
08.06.23
✎
12:09
|
(52) Сорян. Не проверял. Лишнее поле было.
Вот правильное:
|
|||
58
АгентБезопасной Нацио
08.06.23
✎
12:27
|
(55) 1.Ну, по-китайски потому, что без временных таблиц. с временными слегка короче.
2. клюшек сейчас под рукой нет, вот на снеговике по документам. По регистру, в принципе, ровно то же самое - там в зависимости от быстройобработкиДвижений либо привязываешься к datetimeiddoc, либо сам его делаешь ВЫБРАТЬ ПриобретениеТоваровУслугТовары.Ссылка КАК Ссылка, ПриобретениеТоваровУслугТовары.Номенклатура КАК Номенклатура, ПриобретениеТоваровУслуг.Дата КАК Дата, 1 КАК сч ПОМЕСТИТЬ ВТ_сч ИЗ Документ.ПриобретениеТоваровУслуг.Товары КАК ПриобретениеТоваровУслугТовары ЛЕВОЕ СОЕДИНЕНИЕ Документ.ПриобретениеТоваровУслуг КАК ПриобретениеТоваровУслуг ПО (ПриобретениеТоваровУслугТовары.Ссылка = ПриобретениеТоваровУслуг.Ссылка) ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ПриобретениеТоваровУслуг.Товары КАК ПриобретениеТоваровТекущийДокумент ПО (ПриобретениеТоваровУслугТовары.Номенклатура = ПриобретениеТоваровТекущийДокумент.Номенклатура) ГДЕ ПриобретениеТоваровУслуг.Дата > &НачДата И ПриобретениеТоваровУслуг.Ссылка <> ПриобретениеТоваровТекущийДокумент.Ссылка И ПриобретениеТоваровТекущийДокумент.Ссылка = &Ссылка ; //////////////////////////////////////////////////////////////////////////////// ВЫБРАТЬ ВТ_сч.Ссылка КАК Ссылка, ВТ_сч.Номенклатура КАК Номенклатура, ВТ_сч.Дата КАК Дата, СУММА(ВТ_сч.сч) КАК сч ИЗ ВТ_сч КАК ВТ_сч ЛЕВОЕ СОЕДИНЕНИЕ ВТ_сч КАК ВТ_сч1 ПО ВТ_сч.Дата <= ВТ_сч1.Дата И ВТ_сч.Номенклатура = ВТ_сч1.Номенклатура СГРУППИРОВАТЬ ПО ВТ_сч.Ссылка, ВТ_сч.Номенклатура, ВТ_сч.Дата ИМЕЮЩИЕ СУММА(ВТ_сч.сч) <= &КоличествоПоследних УПОРЯДОЧИТЬ ПО Номенклатура, Дата УБЫВ |
|||
59
ADirks
08.06.23
✎
12:39
|
(58) ага, понятно. Почему-то я про такой манёвр забываю всё время.
|
|||
60
АгентБезопасной Нацио
08.06.23
✎
12:43
|
(59) блин, даже короче получилось. что-то вчера думал, что будет две временных.
|
|||
61
АгентБезопасной Нацио
08.06.23
✎
13:18
|
(54) ну, в снеговике - это понятие, объединяющее (и разделяющееся на) остатки и обороты.
хранить а оборотном регистре удобнее, чем в справочнике, потому, что имеешь автоматичексое удаление при распроведении/пометке удаления. а значение получать выборкой движений |
|||
62
Злопчинский
08.06.23
✎
15:04
|
(54) регистр сведений в 77 можно реализовать типа регистр без измерений, только с реквизитами
|
|||
63
Харлампий Дымба
08.06.23
✎
15:44
|
(61) Понятно. Хотя и работу со справочником можно спокойно запихнуть в ОбработкаПроведения() и ОбработкуУдаленияПроведения(), при этом не будет особых заморочек с первоначальным заполнением за предыдущие года. Но будут заморочки с УРБД.
Так что если прямые запросы, как в (58) у ТС заработает, то это будет лучшим решением. Хотя и (32) неплохо, если строк в документе в среднем немного, а то дёргать 100 раз рег.выбратьдвижения с наложеннным фильтром по товару и перебирать документы обратным порядком довольно тормозно может оказаться. (62) Как много нам открытий чудных... С другой стороны - у меня компонента "БУ", там регистры недоступны вообще. Так что приходится искать другие способы реализации регистра сведений. |
|||
64
АгентБезопасной Нацио
08.06.23
✎
15:58
|
(63) а почему будут заморочки с УРБД? не вижу ни одной причины.
выборка движений в обратном порядке - не фильтруется по iddocdef, не фильтруется по виду движения (не в индексе), поэтому выбирается в dbf по тем полям, по которым может, дбф тянется на клиента, там доиндексируется, и уже по нему выборка ходит.... Ну а РС - это в любом случае табличка. И справочник ты можешь по нужным полям проиндексировать, и регистр п онужным реквизитам. Просто справочник - это "независимый РС", а регистр с толькореквизитами - "РС подчиненный регистратору" |
|||
65
Aleksey
08.06.23
✎
17:25
|
(62) поправочка - без ресурсов
В измерении Номенклатура и вид цен Ресурсы - пусто Реквизиты цена А далее Прайс.УстановитьФильтр(Номенклатура,ТипЦен); Прайс.ОбратныйПорядок(1); Прайс.ВыбратьДвижения(,ДатаПрайса); Если Прайс.ПолучитьДвижение()=1 Тогда Результат=Прайс.Цена; //ДокументДвижения=Прайс.ТекущийДокумент(); Иначе Результат=0; КонецЕсли; |
|||
66
Харлампий Дымба
08.06.23
✎
19:06
|
(64) Заморочки с УРБД - это про реализацию задачи через справочник (дубли про одновременном проведении в двух разных базах). При реализации через регистр - такой заморочки, конечно, нет. Ну в общем выбор по решению задачи есть и зависит от умений, вкуса, конкретных параметров базы.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |