|
v7: Отбор в журнале | ☑ | ||
---|---|---|---|---|
0
Масянька
26.10.11
✎
17:23
|
День добрый!
Ногами не бить... Есть ли возможность сделать отбор в ОБЫЧНОМ журнале? |
|||
1
xazrad
26.10.11
✎
17:24
|
(0) В обычном нет. нет как мне помнится
|
|||
2
NS
26.10.11
✎
17:25
|
Чем общий насолил?
|
|||
3
Масянька
26.10.11
✎
17:26
|
(2) Ну, что вы... Ни чем.
Просто хочется в журнале счетов - фактур сделать отбор: обычные, на аванс. |
|||
4
ДенисЧ
26.10.11
✎
17:26
|
ТОлько по виду документа...
|
|||
5
Масянька
26.10.11
✎
17:26
|
(4) А нету вида дока... Только признак.
|
|||
6
FN
26.10.11
✎
17:27
|
(0) есть метода по перехвату/замене стандартных запросов 1С к скулю. Вот с ее помощью можно даже вместо документов справочники в журнал выводить, не говоря уж про отбор.
:) |
|||
7
Масянька
26.10.11
✎
17:28
|
(6) Очень сложно. Наверное.
|
|||
8
DJ Anthon
26.10.11
✎
17:28
|
тебе - да...
|
|||
9
FN
26.10.11
✎
17:28
|
(6) ага
|
|||
10
GreyK
26.10.11
✎
17:29
|
(3) А чем отчет не подходит?
|
|||
11
Mikeware
26.10.11
✎
17:44
|
(6) вместо перехвата и замены лучше использовать http://www.1cpp.ru/forum/YaBB.pl?num=1285520767/0
|
|||
12
NS
26.10.11
✎
17:53
|
(3) Так и сделайте графу отбора типсчетафактуры, и используйте её в общем журнале.
|
|||
13
Largo
26.10.11
✎
18:09
|
Взять отчет. Бросить на форму видимую ТаблицуЗначений.
Реализовать в нее загрузку данных по документам с обновлением только изменений, чтобы этот "журнал" не тормозил каждый раз перегружая в себя весь список документов заново. Поможет в этом невидимая ТЗ в памяти. По видимой таблице значений хоть зафильтруйся. Летать будет и летает, что на сиквельной, что на ДБФ-базе. И без всяких изменений конфиугурации, танцов с бубнов вокруг внешних компонент, и другой муеты. |
|||
14
NS
26.10.11
✎
18:16
|
У меня такое впечатление, что я попал в сумасшедший дом. Графа отбора чем не устраивает?
|
|||
15
viktor_vv
26.10.11
✎
18:19
|
Осталось еще только посоветовать на восьмерку перейти :).
|
|||
16
Mikeware
26.10.11
✎
18:20
|
(15)Это уже тяжелая артиллерия.
Хотя (11) изрядно напоминает снеговика... Особенно разновидностями отборов... |
|||
17
Classic
26.10.11
✎
18:34
|
(0)
Делаешь общий журнал, делаешь графу отбора, куда заносишь признак твоего СФ в форме журнала рисуешь закладки и обработку переключения закладки как отбор по графе отбора. И все становится резко красиво :) Без 8рок и сипп |
|||
18
NS
26.10.11
✎
19:51
|
Вообще-то проще - берешь журнал выданных СФ, и либо копируешь, либо вообще делаешь общим, и делаешь три варианта отбора - первый по виду документа - это журнал как был раньше, второй на аванс, третий не аванс.
|
|||
19
Злопчинский
26.10.11
✎
20:25
|
(13) а ну-ка, такой грамотный, вот отсюда "с обновлением только изменений," - поподробнее.. как будешь отлавливать изменения в другом сеансе 1С - как обычно, обработкой ожидания..?
|
|||
20
FN
26.10.11
✎
20:29
|
(19) пока (13) думает - предложу свой вариант - http://infostart.ru/public/90224/
|
|||
21
КонецЦикла
26.10.11
✎
22:30
|
Есть класс удобный с интерфейсом, все придумано до нас
Искать на 1cpp.ru |
|||
22
Largo
27.10.11
✎
01:27
|
(19) ах уели, ах уели, ах уели вы меня! В вашем то возрасте меряться стручками с такими щеглами, как я...
Но раз пошла такая пьянка, пожалуйста, не сочтите за труд, еще раз и вдумчиво прочтите последнее предложение, так задевшего вас, поста (13). Вдумчиво в части "И без всяких изменений конфигурации". Потому что это тоже самое, как в том анекдоте, когда на киоске написано "Пива нет!", и чуть ниже приписано "Пива ВООБЩЕ НЕТ!", а еще ниже - "ПИВА ТОЧНО НЕТ!!!" Без всяких изменений - это значит, что вообще без всяких, и даже без добавления в конфигурацию кода функции для использования ее в обработке ожидания. По большей части логика решения предложена мудрым человеком в посте (20) по ссылке. Конретно для нашего случая: Так как нам не нужен весь лог-файл, вдумчиво анализируем его лишь с момента времени, когда произошло открытие нашего "журнала-отчета" после первичного заполнения таблиц. Анализируем на тот случай случай, если за те секунды, пока мы грузили данные в память, произошло изменение в документах. Как в первый раз при открытии, так и далее, мониторим только свежие изменения в журнале на предмет появления там объектов-документов, используемых нашим журналом. Обнаружив их, прямо в журнале проверяем имела ли место запись (значит будем сравнивать реквизиты этого документа с загруженными в таблицы реквизитами и обновлять соостветсвующую строку в таблице при различиях), или не имела - документ просто открывался для "посмотреть". Таким образом (если немного "поколдовать" с анализом метаданных) реализуется универсальный журнал-отчет, для любых видом документов. Как в виде обычного журнала для одного вида документов, так и в виде Общего журнала для всех видов. А можно и комбинировать виды документов в одном журнале. Например, счета с актами. Или платежки с выписками. Количество возможных вариантов и фильтров будет ограничиваться лишь вашей фантазией. Поэтому повторюсь - "без всяких изменений конфиугурации, танцов с бубнов вокруг внешних компонент, и другой муеты". Достаточно просто. При работе 30+ пользователей в терминале замедления работы с базой не обнаружил. Сами пользователи отметили, что заметно на глаз, как база стала работать быстрее. И журналы стали удобнее с появлением нормальной фильтрации. А счетчик производительности показал более чем 20%-ное снижение нагрузки на диски по сравнени с замерами при использовании обычных журналов. А ну-ка, такой грамотный, вот отсюда поподробнее сможешь сразуметь по какой причине при таком решении высвобождается ресурсы дисковой подсистемы при работе с базой в терминале, но еще существеннее снижается сетевой трафик при работе с базой по сети? |
|||
23
КонецЦикла
27.10.11
✎
03:22
|
(22) Для этого придется городить неизвестно что, чтобы корректно и быстро отслеживать все изменения
Неизвестно что более затратно - обновлять видимую часть журнала (а это могут быть документы и позавчерашние) или заниматься мутотенью типа "мониторим только свежие изменения в журнале" и "будем сравнивать реквизиты этого документа с загруженными в таблицы реквизитами". Ты подумай чего нашкорябал... если свежие документы - это, например, 200-300 документов... а если 1000? Штатно уже ответили как Другое работающее решение с возможностью расширения - в (21) |
|||
24
КонецЦикла
27.10.11
✎
03:25
|
+(23) Есть еще программное изменение документов
|
|||
25
Largo
27.10.11
✎
07:37
|
(23) "Родится же такая ягодка..." (с)
"Для этого придется городить неизвестно что, чтобы корректно и быстро отслеживать все изменения" - с объектом ФС и строковыми функциями работать умеешь? Это неизвестно "что"? Моих 30+ пользователей как раз и вводят до 200-300 документов в день. В целом. Документов одного вида - 50-60. Про 1000 документов и более не скажу - не проверял. "Неизвестно что более затратно" - не можешь, или не умеешь сам - попроси приятеля-админа - он замеряет, что более затратно. И, как говорится, почувствуйте с ним вместе разницу. А то, мля, как всегда - "книгу не читал, но гамно редкостное!" :) +(24) Есть еще не зажравшиеся программисты, которые "программные" изменения тоже пишут в журнал. Просто так. По доброе душевной. Ну и для порядку, естественно. |
|||
26
Масянька
27.10.11
✎
14:46
|
NS- спасибо! Но все-таки - гемморойно....
|
|||
27
NS
27.10.11
✎
14:49
|
(26) А чего гемморного? Повесить выбор из списка на форму, прописать использоватьграфуотбора, и переключить журнал на общий.
работы на 5 минут. |
|||
28
filh
27.10.11
✎
14:51
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |