| 0
- 18.10.2012 - 16:49
|
довить то добавил всё что нужно чтобы выбрать по двум критериям, а не пойму как в установить отбор вписать условие к примеру вибрать в первом поле котрагента а во втором поле выбрать по виду документа -только реализации. подскажите как сделать чтобы отбор в журнале отработал по двум критериям??
    | | |
| 1
- 18.10.2012 - 16:50
| *добавить | | |
| 2
- 18.10.2012 - 17:05
| Эта тема очень стара и много раз подробно обсуждалась. Одно из решений - составной реквизит отбора | | |
| 3
- 18.10.2012 - 17:35
| 2/ спсибо за ответ - теперь я знаю что тема стара и много раз обсуждали и поробую составной реквизит- но я немного в растрянности - это будет много составных реквизитов? а нельзя как то передать к методу установке отбора передать условие типа "контрагент =то то И виддок = то то" | | |
| 4
- 18.10.2012 - 17:40
|
Не влетит. В "семерке" возможен отбор токмо по одному полю. И это поле должно быть в ветке конфигурации "графы отбора". Примечание: "вид документа" всегда является полем отбора. Т.о., для того, чтобы "объединить" два критерия, надо сделать некое общее составное поле (в сабже: вид документа + контрагент), затем заполнить его для всех документов в базе, озаботиться, чтоб вновь создаваемые документы при записи заполняли (перезаполняли) это поле, затем в конфигураторе это поле включить в графы отбора, и только потом можно будет наслаждаться. Обеспечив для юзера интерактивное формирование значения отборв ;) Токмо не надо этого: формируй список документов по хотелкам юзера, и выводи этот список для выборки. Универсально. Недорого. | | |
| 5
- 18.10.2012 - 17:42
|
(2): по контрагенту и виду документа - никаких составных. графа отбора, в которую сунуть контрагента только из нужного вида документа. (3): составных много не надо. практика показывает, что именно необходимых комбинаций - немного. нет, нельзя. отбор - строго по равенству строго заданного реквизита. не парь людям мозг - используй обработку с ТЗ на морде, в которую отбирай как хочешь и что хочешь, показывай как надо и обрабатывай как заблагорассудится. | | |
| 6
- 18.10.2012 - 17:44
| (4): "перезаполняли" как раз нетрудно. в типовых. где во все "призаписи" воткнут, как правило, вызов какой-нибудь проверочной экспорт-процедуры/функции глобальника (или даже в модкле проведения - типа глСообщить) с передачей контекста - в неё запихнуть установку значений композитных реквизитов отбора и всё. | | |
| 7
- 18.10.2012 - 18:02
|
6-Cthulhu > Я не сказал, что это "трудно" ;) Проблема в том, что подобные "хотелки" будут портить конфигурацию, и накапливаться. И со временем (меньшим, чем оптимистично ожидается) осложнит жизнь (больше, чем оптимистично представляется)... Так что лучше сделать универсальный отчет (по типу бухгалтеских "анализ счета по субконто", или вроде того), формировать список интересующих юзера документов, и нехай расшифровкой разглядывает заинтересовавший его докУмент ;) | | |
| 8
- 18.10.2012 - 18:04
| 4/ 5/ 6/ ой сложно как то- и что плохо здесь- это раздувание базы :-(( эх... хорошо бы если отбор в общем журнале был двухпроходным, второй раз по результату первого отбора... | | |
| 9
- 18.10.2012 - 18:06
| 7. дело не в отчете а в желании пользователя ограничить необходимое количество документов в окне общего журналы, чтобы с этой выборокй работать дальше... | | |
| 10
- 18.10.2012 - 18:08
| 9-7d5x > Дадада... Юзер желает легкий велосипед, но чтоб на нем бетон можно было возить... Облом-с :D | | |
| 11
- 18.10.2012 - 18:09
|
8-7d5x > нету такого в 7.7. забудь. выводи в отчет с любыми отборами, допколонками, любые доки. значения отбора кстати также нельзя никак получить из вычисляемых реквизитов (точнее, нельзя стандартными способами, без ВК). то есть только по графам можно отбор. доваявываю как раз такой отчет. | | |
| 12
- 18.10.2012 - 18:18
|
9-7d5x > Юзеру чуть-чуть станет легче, а о несчастном SQL-сервере ты подумал? Он (SQL) и так, бедолага, корячится, каждый раз когда юзер листает в журнале (хорошо, если курсором, а то ведь PgUp, PgDown норовят ведь...). Ему нужно СРОЧНО сделать запросом выборку актуальных на экране строк (+-30% некий кэш - запас на листание...) и показать результат выборки юзеру на экране быстренько... А теперь давай мы на этот запрос ещё составных условий навесим (НА КАЖДУЮ СТРОКУ выборки)... | | |
| 13
- 18.10.2012 - 18:23
| А что мешает завести ЧАСТНЫЙ журнал документов: РЕАЛИЗАЦИИ? | | |
| 14
- 18.10.2012 - 18:29
| \всем кого интересует этот вопрос- я простой случай только и говорю . в идеале хотелось два поля быстрого отбора к ним две кнопки получить значение- а результат мог бы лбой комбинацией из значений этих двух отборов - частный случай о котором писал по первому выставить контрагента а по второму виддок. контрагента и автора контрагента и склада отгрузки итд- вариантов уйма и в принципе очень много можно было бы- увы уперлась всё в метод Установить Отбор который работатет только по одному полю... жаль что не получается | | |
| 15
- 18.10.2012 - 18:33
| 14-7d5x >Юзай 1с++, там это не слжно сделать. | | |
| 16
- 18.10.2012 - 18:40
| 15. намекаете про восмёрку? :-)) меня интересует а автори 1cv77 вообще живы? | | |
| 17
- 18.10.2012 - 18:41
|
15-Billi >Причём сдесь восьмерка? 1С++ это ВК для семёрки. | | |
| 18
- 18.10.2012 - 18:43
| 16-7d5x >База СКЛ или ДБФ? | | |
| 19
- 18.10.2012 - 18:47
|
Короче, читай последовательно (2,7,11). Попутно так между делом, медитируй на (12,13). | | |
| 20
- 18.10.2012 - 18:50
|
14-7d5x > Отчёт. Однозначно. И ваяй там ЛЮБЫЕ условия отбора. "Так что лучше сделать универсальный отчет (по типу бухгалтеских "анализ счета по субконто", или вроде того), формировать список интересующих юзера документов, и нехай расшифровкой разглядывает заинтересовавший его докУмент ;)" ©VZ | | |
| 21
- 18.10.2012 - 19:15
| "Оперативный" журнал со многими отборами вряд ли уж сильно нужен. А для целей отбора и поиска пользуюсь много лет отчетом с таблицей значений. Отбор по любым реквизитам - общим, шапки, табличной части, графам. Хватает этого до пупа ) | | |
| 22
- 18.10.2012 - 19:54
| 21-USSR > нужен, как оказалось. очень именно отборов не хватает в 7ке (и про ТЧ документов с более чем 50 строками и/или более чем 15 колонками в частности). | | |
| 23
- 18.10.2012 - 20:25
|
А жалоба пользователя для нас закон 20/ 21/ 22/ не отчет нужен!!! а состряпать выборку которая уменшшила бы количество строк в общем журнале оставив только необходимые документы- в одной базе держат родственные но разные фирмы, говорят что путаются в них, и действиельно если бы можно было в общем журнале отбирать по двум критериям путаниц было бы гораздо меньше | | |
| 24
- 18.10.2012 - 21:13
|
23-7d5x >Тебя спасёт 1С++ в связке с FormEx и класс ПоставщикДанных. Если дбф то прибавь к набору ещё и 1sqlite. | | |
| 25
- 18.10.2012 - 21:27
|
23-7d5x > " не отчет нужен!!!" - Это кто это такое сказал? Директор? ПОШЁЛ В ЖОПУ, ДИРЕКТОР!!!!!! "а состряпать выборку которая уменшшила бы количество строк в общем журнале" - Готовьте стотыщмиллиардов на аппаратную модернизацию SQL-сервера. " говорят что путаются в них, и действиельно если бы можно было в общем журнале отбирать по двум критериям путаниц было бы гораздо меньше" - Дай ты им отчёт и назови его "Общий Журнал". Один фиг - не вкурят разницы, в отчёте или в журнале они работают... | | |
| 26
- 18.10.2012 - 21:30
|
1С++ в связке с FormEx и класс ПоставщикДанных - это ЗЛО. 1) Представь, что завтра ты увольняешься/уходишь в декрет/уходишь в запой. Кто будет разбираться во всей этой кне после тебя? 2) Представь, завтра вы переходите на Win2008 64x и SQL64x R2... Адаптируй 1С++ под SQL2008, угу... | | |
| 27
- 18.10.2012 - 21:44
|
26-DeiMos > Цитата:
Спасибо, поржал :))))))) У меня, если что, семёрошные клиенты только на СКЛ 2008 R2 и остались. | | |
| 28
- 18.10.2012 - 21:46
| 26-DeiMos >Заметь, даже режим совместимости с СКЛ 2000 не использую. Всё в родном, 2008 режиме. ;) | | |
| 29
- 18.10.2012 - 21:51
|
23-7d5x > А не надо все валить в одну кучу... Не надо. Хоть родственная "фирма", хоть не родственная - по каждому предприятию надо вести обособленный учет. Есть такой механизм: разделитель учета называется. Вначале оне помойку устраивают, потом удобства требуют... Базу надо правильно конструировать. А не фокусничать. | | |
| 30
- 18.10.2012 - 21:55
|
26-DeiMos >А по поводу Цитата:
К тому же к Поставщику очень вменяемая документация. | | |
| 31
- 18.10.2012 - 21:56
|
(27, 28): И при этом юзаешь "1С++ в связке с FormEx и класс ПоставщикДанных."? Кросавчег, что я могу тебе на это сказать... Если я пойду на ТАКОЙ риск на своей базе - то мне Героя России надо будет вручать в Георгиевском зале Кремля. Если случится какой-то фейл из-за глюка несовместимости 1С++ с SQL 2008 - я буду мгновенно без суда расстрелян, господин Путин - мгновенно перестанет быть Президентом, в РФ наступит общий хаос и армагеддец. Да, да. Такие серьёзные базы. (Десятки терабайт, если чо) А ты что думал, в сазку попал, играться тут с внешними несовместимыми компонентами? | | |
| 32
- 18.10.2012 - 22:00
|
31-DeiMos >Слышали мы про твои базы :) У меня клиенты уже три года на таких связках работают, и ничего, ни одного вылета по причине совместимости или ещё по какой-нибудь другой причине. Админить и программить надо с умом, тогда всё работать будет ;) А лучше, как VZ говорит, жесткий порядок надо наводить. Правда не все клиенты это хотят/могут :) | | |
| 33
- 18.10.2012 - 22:01
|
(23): "в одной базе держат родственные но разные фирмы" - Коллеги, ИМХО, это НАГЛЫЙ троллинг. На 7.7 они в одной базе держат фирмы без разделителя учёта, угу... Предлагаю ветку закрыть, автора забанить по IP. Навсегда. | | |
| 34
- 18.10.2012 - 22:04
|
32-Billi > "Слышали мы про твои базы :)" - Что вы там такого слышали? Гоу, напиши в личку, плиз. | | |
| 35
- 18.10.2012 - 22:05
|
33-DeiMos >Насколько я понял, у ТС проблема не в разделителе учета, а как раз наоборот. Разделитель есть, только вот его нельзя использовать в купе с другими реквизитами при отборе документов в журнале, а это реально неудобная штука. Именно поэтому я подбных клиентов перевёл на вышеуказаную связку, и они довольны, как слоны. | | |
| 36
- 18.10.2012 - 22:08
| Цитата:
| | |
| 37
- 18.10.2012 - 22:10
| Не ссорьтесь мальчики умоляю | | |
| 38
- 18.10.2012 - 22:26
|
36-Billi > А, ну тогда ладно. Это всё правда... Кстати, хинт!!! Совет: На триллионы пользователей - нужно покупать триллион лицензий на SQL. А это ОЧЕНЬ дорого. Поэтому - у Майкрософт еспешиалли для таких страдальцев как я - имеется специальный продукт SQL WEB Edition. Купляешь его и не паришься ваще. На него CAL-ы клиентские ваще не нужны. Пусть хоть триллиарды юзеров работают. Пофиг. Управление "К" МВД РФ - идёт в жопу. Аборты да... Это проблема... Они больше всех мировых запасов денег... И запасов калькулятора не хватает, это да... Ну, как-то выкручиваюсь потихоньку... Если будут идеи и предложения как выкрутить аборты в отчётах выше - пишите в личку, буду рад советам. 37-Синегурочка > Кто тут ссорится? Ты сначала фото топлесс мне в личку пришли, а потом я подумаю, ссориться из-за тебю или не нуно? | | |
| 39
- 18.10.2012 - 22:41
| 33. я четто не понял что тебя смущает... глава семьи жена и дочь открыли три фирмы и ведут работу внутри одной базы- это 1с тис позволяет и самим это устраивает. номенклатура клиентская база у них общая. неудоство в том что документы в одной куче и это источник путаниц- требуется внимательность при работы а при наличии двойного отбора можно было бы существенно облегчить работу . я не пойму при чём тут разделители учета.... | |
Интернет-форум Краснодарского края и Краснодара |
