Имя: Пароль:
1C
 
Бух 7.7 SQL Медленная работа 20-30 пользователей и ошибки
0 Drac0
 
11.05.11
15:29
День добрый!
Стали что-то бухи жаловаться на медленную работу 1С. Опишу структуру работы:
есть два офиса, в одном сидят все бухи, а во втором терминальный сервер и сервер, где крутится SQL. Между ними канал на 10 Мбит, но нагрузка на него не критичная. Терминальный сервер периодически нагружается до 100%, но штатно 20-40%. На нем стоит Xeon 4 ядра и 4 гига оперативки. про сервер, где крутится SQL посмотреть нет возможности (разные офисы курируют разные айтишники, прямого доступа у нас туда нет).

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

Попробовал ТИС на выгружнной и получил тьму ошибок вроде:
Файл DT12027.dbf. Запись 459340. Поле SP12025. Неверное содержимое текстового поля - "                                                                                                  "
Файл DH12070.dbf. Запись 12319. Поле SP40382. Неверное содержимое текстового поля - "        "
Файл 1SBLOB.dbf. Запись 7600. Поле BLOCK. Неверное содержимое текстового поля - "1e       Денисов Д митрий Александрович                                         "

Первая таблица - это "Документ (Мн.ч.) ОперацияПоРасчСчету" и строка Значение; вторая - "Документ ПлатежноеПоручение" и строка КППполучателя. Ну с третьими все ясно - случайно нажатые комбинации клавиш.

Посему вопрос, могут ли приведенные мной ошибки в большом количестве замедлять работу базы. И что еще стоит проверить, где искать узкие места.
1 Mikeware
 
11.05.11
15:46
1. реиндексация и обновление статистики на сиквеле
2. сиквел очень нехорошо работает с бухподсистемой
2 serg_m_v
 
11.05.11
15:46
Если куча ошибок, попробуй сделать тестирование своей скульной базы, только про бекап не забудь, и реиндексацию таблиц тоже, может ускорить. А еще журнал транзакций почистить.
3 Mikeware
 
11.05.11
15:48
кстати, на терминальнике может помочь приблуда от ромикса..
4 Mikeware
 
11.05.11
15:50
а поиск узких мест - скрипт от vde69, либо старая древняя статья "семь главных счетчиков производительности SQL-сервера"(или типа того, точное название не помню) - лежит на sql.ru
5 Guk
 
11.05.11
15:55
(1) нормально он работает с бухподсистемой...
6 Mikeware
 
11.05.11
16:00
(5) хуже, чем с оперативным, гораздо...
7 vde69
 
11.05.11
16:00
infostart.ru/public/16681/
8 vde69
 
11.05.11
16:02
а вообщето для 20 терминальных сесий 4 гига оперативки - это мало, ОЧЕНЬ мало!!! посмотри может память уходит в своп
9 FN
 
11.05.11
16:07
(8) Для 7.7 нормально
Если конечно не грузить в сессиях Експлорер, офис, мониторчики от принтера и тп
10 Serg_XX
 
11.05.11
16:45
Я смотрел на dbf-ной базе: 1-пользователь в обычном режиме отъедает около 50Мб оперативки терминального сервера, но при формировании тяжелых отчетов (весь отчет тоже сидит в ОП)доходило до 200 (отчет был ~ на 70 тыс. строк)
11 ptiz
 
11.05.11
16:55
(8) Для 7.7 - это мегамного!
12 val
 
11.05.11
17:03
(0) В (1) тебе уже все сказали: реиндексация каждую ночь и обновление статистики каждый час.

(1) "сиквел очень нехорошо работает с бухподсистемой" - Вы не любите собак? (с)
13 val
 
11.05.11
17:06
(0) Да, неверное содержимое текстового поля никак не влияет на скорость выполнения отчета.
14 Mikeware
 
11.05.11
17:09
(12) может, я не сильно умею их готовить, но тем не менее - при использовании штатных бухзапросов - медленнее. Штатная ОСВ за большой период (года два-три) клала сервер напрочь.
а работатать с бухией напрямую - мне не понравилось. регистры логичнее, роднее и ближе :-)
15 Drac0
 
11.05.11
17:10
(8) Памяти отъедают максимум гига 2-3, даже в период большой загрузки.
(12) Что ж будем разговаривать с админами, курирующими SQL сервер. Спасибо за советы :)
16 Drac0
 
11.05.11
17:38
Что ж, админы курирующие SQL сервер на вопрос какогда было произведена последняя реиндексация и как происходит обновление статистики, сказали: "Мы не знаем, подключись посмотри". А вот теперь не пинайте, пожалуйста, но подключиться-то я подключился через Enterprise Manager, стоящий на другом компе в другом домене, а вот как узнать когда эти процедуры были проделаны с этой базой, да и как их сделать не смог слету разобраться. Если есть возможность, то ткните носом в статью или подскажите примерно. Буду премного благодарен!
17 Drac0
 
11.05.11
17:48
+(16) как сделать нашел, а вот как посмотреть ,когда в последний раз было - нет ...
18 Drac0
 
11.05.11
18:03
+(17) в логах только запуск и бэкапы постоянные
19 vde69
 
11.05.11
18:15
(18) смотри в job-ах, скорее всего вообще не настроено
20 Z1
 
12.05.11
08:20
(0) Переделай канал между серверами на 1гигобит
21 Drac0
 
12.05.11
08:57
(20) кошерный вариант, учитывая, что нагрузка на канал далека от 100% :) Боюсь себе представить счет от провайдера ...

(19) Да, как вы и предполагали в джобах только бэкапы (и то слава богу!). Будем настраивать. Еще раз спасибо!
22 mishaPH
 
12.05.11
09:00
(0) Отчеты если гоняют стандартные типа обороток и проч. поставь комплект на прямых запросах. у меня уже 2 последние конторы в бух на одних и тех же граблях. после вопросов не возникает. а то как развернут карточку 41 счета за год. вот надо им и все. так 30-40 минут лопатит. а тут 1-5 минуты.
23 mishaPH
 
12.05.11
09:00
а то и быстрее.
24 Z1
 
12.05.11
09:27
(21) Бред какой-то. Кто же sql сервер и терминал сервер держат в разных сетках да еще внешних речь именно об 1с sql.
Обычно Все в одной сети локальной ( даже для твоих 30 пользователей можно совмещать оба сервера в один но это требует более тщательной настройки.) и терминал и sql а извне лезут именно на терминал.
25 Z1
 
12.05.11
09:41
"Между ними канал на 10 Мбит" можно прочитать двояко
1. между офисами канал 10 мб
2. между серверами канал 10 мб.
когда читал 0 то прочел как вариант 2
но если действует 1 все равно должно быть верно и  20
т.е между серверами должен быть 1 гбит
26 Drac0
 
12.05.11
10:06
(24) Терминал и SQl находятся в одной сети конечно же. Так что это все нормально.
(22) Я думал, чтобы перевести на прямые, но есть достаточно много самописных отчетов, так придется многое перелопачивать, а учитывая, что очень хочется перейти на 8-ку (мне и бухам/кадрам, но не начальству), то смысл в этом будет чуть. Проверим, как будет работать после запуска периодической переиндексации и обновления статистики.
27 chief accountant
 
12.05.11
10:10
(26) Бухзапросы оборотные будут работать также медленно
28 Delorn
 
12.05.11
10:30
(0) То есть файлы базы 1сной лежат у тебя на терминальном сервере? А до sqlя 10 мегабит? Проведи эксперимент все на сервер SQL. И посмотри скорость формирования отчетов. А то чует мое сердце что эти 10 мегабит тебе и дают пол часа формирования отчетов...
SQL какой версии? Какие сервис паки?
Длина содержания операции какая? Количество субконто на счетах 3? или вы добавили еще 5?
Прямые запросы не помогут. Хотя, зависит от отчетов... Но чтобы получить остатки на начало месяца голову себе поломаешь.
29 Drac0
 
12.05.11
10:36
(28) Я уже в (26) писал, что терминал и SQl  в одной сети и там, скорее всего, честный гбит. 10 Мбит от офиса с бухами до терминала. SQL - 2000. Субконто - 3.
30 Delorn
 
12.05.11
10:52
(29) А что за отчеты? Типовые или самописные?
Сервис пак на SQLе какой? длину содержания операции не увеличивали? Размер базы какой?
31 val
 
12.05.11
11:08
(16) _1sp_DBReindex - реиндексация
sp_updatestats - обновление статистики.
Все - без параметров.
Имей в виду, что при реиндексации ощутимо вырастает лог. Это нормально, резать его не надо.
Реиндексация обновляет статистику сама, сразу после нее обновлять статисику не надо.
Сделай копию базы, сделай на копии реиндексацию и сравни скорость тяжелых отчетов.
32 Mikeware
 
12.05.11
11:27
(31) Реиндексацию можно делать и выборочную. Скрипт валяется с незапамятных времен.
а вот насчет "лог резать не надо" - просвети?
33 Drac0
 
12.05.11
11:38
(30) Отчет самописный один, типа оборотки по определенным счетам. Писалось все до меня. SP3, хз, 12Гиг+.
(31) Спасибо, но планирую это в джобы поставить все-таки. Если удастся админов отвечающих за скуль убедить ...
34 val
 
12.05.11
11:40
(32) "Реиндексацию можно делать и выборочную" - можно.
Но телепатией я не владею, и какие именно таблицы автору нужно переиндексировать, я не знаю.
"а вот насчет "лог резать не надо" - просвети?" - каждую ночь будет идти переиндексация, и каждую ночь лог снова будет расти, а это время и задержки на рост лога, а вы снова и снова будете его шринковать? Лог должен быть такой величины, чтобы не требовался постоянно его рост. Конечно, не забываем про бекап логов (например, через каждые 15 минут).
35 Mikeware
 
12.05.11
11:43
(34) а и не нужно знать, "какие именно таблицы" - достаточно их переиндексировать последовательно.
Да и переиндексация каждую ночь - мягко говоря, излишество.
хотя все зависит от нагрузки на базу. Если я буду индексировать все таблицы разом - работа замедлится очень надолго, а в режиме 24*7 это критично.
36 val
 
12.05.11
11:48
(35) "хотя все зависит от нагрузки на базу" -золотые слова.
"в режиме 24*7 это критично" - у автора бухгалтерия.
Вот у меня в самом деле 24*7, поэтому переиндексацию я делаю раз в неделю, а обновление статистики - выборочно по нагруженным таблицам каждый час.
37 Mikeware
 
12.05.11
11:58
(36) некоторые и на бухии умудряются продажи вести...
38 Drac0
 
12.05.11
12:54
(37) Ну, у нас продажи и деятельность управленческие ведутся на AS 400, просто выгружается в бухию, но и в ней работа кипит, но, слава Богу, не 24/7.

(34) Если реиндексацию запускать планово после бэкапа, сколько она может проходить примерно на базе объема 12гиг+?
39 Mikeware
 
12.05.11
13:23
(38) на полтиннике - идет 4,5 часа полная.
а вообще, зависит от сервера - железа, настроек и т.п.
40 val
 
12.05.11
14:10
(38) база 9 гиг полная реиндексация - 7 минут.
Сервер хороший, с SSD дисками.
41 Drac0
 
12.05.11
14:41
(39)(40) Сегодня ночью делаем пробный запуск и посмотрим, сколько времени занимает и какие будут результаты.
42 FN
 
12.05.11
15:30
(38) достаточно древний ноут (Intel Core 2 Duo T7300, 2Гб RAM) с SSD KINGSTON SNVP325 под Вин7+локальный скуль 2000 перелопатил 18+ Гиг менее чем за 40 минут
43 Ageres
 
12.05.11
15:58
Индексируй, не индексируй, а бух. регистры под SQL медленные. Спасут только прямые запросы. И то в некоторых случаях большого прироста не будет.
44 Drac0
 
13.05.11
09:26
Фигня какая-то. С админом договорили, что он ночью после бэкапа в Maintance plan запускает разого реиндексацию, сейчас смотрю в SQL Server Logs и там кроме бэкапов ничего нет. Как я понимаю, там должен быть отмечен запуск реиндексации и его окнчание? Или я не прав?
45 chief accountant
 
13.05.11
10:10
(44) Не там смотришь.
Один фиг не поможет...
46 zahar140382
 
13.05.11
10:15
Выгрузка базы и загрузка в чистую базу SQL. предлогали?
47 zahar140382
 
13.05.11
10:16
тут явно либо касяк в файле DD либо кто то хорошо напрямую полазил в SQL
48 VladZ
 
13.05.11
10:17
(0) Проблему решить очень просто. Достаточно сделать:
1. Выяснить причину тормозов.
2. Избавится от этой причины.

:)

А вот выяснить причину - это целая наука!
Выясни, что у тебя все таки тормозит: терминал или SQL.

Возможно, у тебя активно юзаются диски на терминале.
49 chief accountant
 
13.05.11
10:18
(47) Канечно, так оно и есть, ага
50 Mikeware
 
13.05.11
10:19
(47) в днк у тебя "касяк"... или кто-то у тебя в мозгах полазил, напрямую через задний проход...
51 Mikeware
 
13.05.11
10:20
(44) скрипт от vde запускали?
52 zahar140382
 
13.05.11
10:22
(51) откуда тогда это?
Файл DT12027.dbf. Запись 459340. Поле SP12025. Неверное содержимое текстового поля - "                                                                                                  "
Файл DH12070.dbf. Запись 12319. Поле SP40382. Неверное содержимое текстового поля - "        "
Файл 1SBLOB.dbf. Запись 7600. Поле BLOCK. Неверное содержимое текстового поля - "1e
53 zahar140382
 
13.05.11
10:23
(52) адресовано (50)
54 VladZ
 
13.05.11
10:23
Ну и в целом: 1С-ские базы на SQL работают медленнее, чем на DBF.
55 chief accountant
 
13.05.11
10:26
(52) Само вырасло
56 vde69
 
13.05.11
10:29
(52) это легко обьяснимо :) просто кто-то вручную в SQL лазил...
57 zahar140382
 
13.05.11
10:29
(55) Само?интерестно с этого момента поподробнее.как это могло случится?или все таки прямой доступ к SQL
58 zahar140382
 
13.05.11
10:30
++(56) посмотри на пост (50) чел нефига незнает а пытается сразу оскорблят у самого в голове мухи е...ся
59 Drac0
 
13.05.11
10:33
Сейчас разворачиваю бэкап на бесплатном SQL 2005 локально. Посмотрим, как быстро будет работать.
(51) Пока нет.
60 zahar140382
 
13.05.11
10:37
(52) и кстати из за этих ошибок вполне могут тупить отчеты
61 chief accountant
 
13.05.11
10:40
(60) Да ни вопрос: неверное содержимое поля КППполучателя тормозит ОСВ
62 Mikeware
 
13.05.11
10:41
(60) из-за этих ошибок только ты тупить можешь...
(59) это надо было сделать в первую очередь. получил бы море информации.
63 zahar140382
 
13.05.11
10:42
(61)кто тебе сказал про КПП? )))
автор сказал что онибок масса
64 Mikeware
 
13.05.11
10:42
(61) несомненно. почти все ОСВ строятся именно по КПППолучателя (кроме тех, которые строятся по КПП отправителя).
65 zahar140382
 
13.05.11
10:43
(62) ты не тупи сам.я изначально сказал что накосячили в скуле.ты же как тормоз даже не как.начал оскарблять
66 Drac0
 
13.05.11
10:43
(63) Масса ошибок, которые я привел. Пол сотни первого типа, куча второго типа, и меньше всего третьего.
67 zahar140382
 
13.05.11
10:46
(66) залей куда нить файл DDS.
68 chief accountant
 
13.05.11
10:46
(63) А что по твоему DH12070 SP40382?
69 zahar140382
 
13.05.11
10:48
один справочник и то что это кпп я бы так говорить не стал
и документ какой я невижу без файла DDS
70 Drac0
 
13.05.11
10:49
(67) Эти ошибки скорее всего взялись из-за экспорта из AS 400. Обработку самого экспорта еще не копал, но возможно она иногда некорректно переносит данные, ее я уже потом покапаю.
71 Drac0
 
13.05.11
10:50
(69) Я в первом посте описал, какие это документы и какие реквизиты -_-
72 zahar140382
 
13.05.11
10:50
(71) оу не прочитал извини
73 zahar140382
 
13.05.11
10:53
попробуй на SQL в чистую(только так не выгрузить и загрузить туда же) базу развернуть свою.на том же серваке.(ошибки я бы поправил).
я бы сделал так это мое мнение.
74 zahar140382
 
13.05.11
10:56
и еще на сервак только по RDP подключаетесь или в офисе еще по сети работают?
75 chief accountant
 
13.05.11
10:56
(69) Если у тебя нет DDS от бухии, то видимо ты никогда её в глаза не видел
76 zahar140382
 
13.05.11
10:57
(75) для особо одаренных DDS может менятся если ты не знал
77 zahar140382
 
13.05.11
10:57
и то что у тебя один документ у меня может быть совершенно другим
78 Mikeware
 
13.05.11
10:58
пипец какой-то... чем тупее дятел, тем агрессивнее....
79 VladZ
 
13.05.11
10:59
Я бы на месте ТС для начала избавился от ошибок, потом уже разбирался с серваками.
80 zahar140382
 
13.05.11
10:59
если у тебя буха одна йз первых версий а я поставил ее сразу(не обнавлял) последнию сравни файлы DDS будешь удевлен
81 zahar140382
 
13.05.11
11:00
Mikeware ты уже все сказал и все это видели я тебя игнорю
82 zahar140382
 
13.05.11
11:01
+++(79) я тоже так считаю
83 chief accountant
 
13.05.11
11:02
(80) Конечно в каждом релизе бухии платежное поручение в разных таблицах
84 zahar140382
 
13.05.11
11:02
(83) еще раз повоторяю я не прочитал что это за таблицы
85 zahar140382
 
13.05.11
11:03
поэтому просил файл
86 chief accountant
 
13.05.11
11:05
(84) Так ты с начала читай, что люди пишут в т.ч. и ТС, может и не постил бы фуйню
87 Mikeware
 
13.05.11
11:05
(79) Ну, для начала надо посмотреть - есть ли ошибки в сиквельной базе, а не в "выгруженой-загруженой"
88 zahar140382
 
13.05.11
11:06
(75) кстати там вроде не буха а ТИС
89 Drac0
 
13.05.11
11:08
(88) -_- там буха. То что вы прочитали ТИС, это было ТИИ, просто опечатался.
90 viktor_vv
 
13.05.11
11:08
(88) Чего б тогда бухи жаловались :).
91 zahar140382
 
13.05.11
11:09
Попробовал ТИС на выгружнной и получил тьму ошибок вроде:
92 zahar140382
 
13.05.11
11:09
тогда уж комплексная наверное
93 chief accountant
 
13.05.11
11:10
(88) читай (86)
94 Mikeware
 
13.05.11
11:10
(88) в ТиС есть документ "ОперацияПоРасчСчету"?
95 zahar140382
 
13.05.11
11:12
(94) почитай вопрос внимательнее
в частности Попробовал ТИС на выгружнной и получил тьму ошибок вроде:
96 zahar140382
 
13.05.11
11:13
ТИС это торговля и склад?или что то другое скрывается за абривиатурой
97 zahar140382
 
13.05.11
11:14
почему вы решили что у него бухгалтерия а не комплексная
98 chief accountant
 
13.05.11
11:14
Мдя, вот упорный долбодятел.
(95) читай (38) и (89)
99 Mikeware
 
13.05.11
11:14
(95) млять. нужно не только читать написанное, но и думать над ним... хотя тебе слово "думать" определенно незнакомо...
100 zahar140382
 
13.05.11
11:16
(99) после того как ты сказал что в SQL не лазили вообще бы молчал
101 zahar140382
 
13.05.11
11:18
Drac0 правь ошибки
102 Drac0
 
13.05.11
11:18
(100) В SQL не лазили с 99% вероятностью. Возможную причину ошибок я уже написал.
103 упс
 
13.05.11
11:19
(44) Попробуйте выполнить вот это:
SELECT OBJECT_NAME (stat.object_id) [table], [name] [statistics name], STATS_DATE(stat.object_id, stat.stats_id) [update time] FROM sys.stats as stat
WHERE stat.object_id IN (SELECT obj.object_id FROM sys.objects obj WHERE type = 'U')
ORDER BY [update time] ASC

Увидите когда обновлялась статистика.
104 chief accountant
 
13.05.11
11:20
(103) достаточно посмотреть журнал заданий
105 Drac0
 
13.05.11
11:22
блджад! Забыл, что SQL 2005 Express ограничение до 4 гигов. Где-то у нас должны быть лицензия, буду искать ...
106 упс
 
13.05.11
11:30
(104) это будет особенно актуально, если админ забыл дописать в задание обновление статистики
107 chief accountant
 
13.05.11
11:31
(106) читай (44)
108 Mikeware
 
13.05.11
11:40
(105) вместо поисков - запустил бы сбор статистики...
109 Кириллка
 
13.05.11
11:43
(0)ошибки ниочем, даже голову греть не нужно. А вот самое забавное, это делать ТиИ базы, выгруженной из SQL в DBF.
110 val
 
13.05.11
11:45
(44) В логи реиндексация не пишется.
Но если создан JOB, можно посмотреть его History (правой кнопкой мышки по джобу)
111 Drac0
 
13.05.11
11:45
(108) Я бы рад. Да тут вот закавыка Query Analyzer не может подключиться к серву, который находится в другом домене. А как иначе можно выполнить скрипт на базе как-то не знаю ...
112 Drac0
 
13.05.11
11:46
(110) нету джоба. Если запускали реиндексацию разово, он должен был остаться?
113 val
 
13.05.11
11:48
(112) Разово как именно?
114 Mikeware
 
13.05.11
11:49
(111) попробуй через 1cQA :-)
115 Drac0
 
13.05.11
11:49
(113) Админ хотел через Meintenence Planner
116 Mikeware
 
13.05.11
11:49
(113) хранимкой. или скриптом. или из ТиИ...
117 val
 
13.05.11
11:57
(113) Meintenence Plan как раз генерит джоб, который и выполняется.
(111) Если IP SQL сервера пингуется, а он должен пинговаться, можешь подключиться по IP.
118 val
 
13.05.11
11:59
+(117) посмотри в конфигураторе параметы подключения к SQL серверу и смело используй то, что там написано.
119 Drac0
 
13.05.11
12:00
(117) Мде, совсем туго сегодня с головой. Не заметил, что сервер можно вручную ввести. Это бяда ...
120 Drac0
 
13.05.11
12:02
(117) А скрипт от vde не сильно будет нагружать сервер? Работать не станет слишком некомфортно?
121 Mikeware
 
13.05.11
12:05
(120) нет, не будет.
122 val
 
13.05.11
12:13
(105) Локально поднимай Developer Edition, он не имеет ограничений на размер базы.
123 VladZ
 
13.05.11
12:15
А точно проблема не в терминале?
124 opty
 
13.05.11
12:21
Сама структура хранения данных бух-компонентой (главным образом  способа хранения промежуточных итогов) , не оптимальна с точки зрения скуля , бух компонента дружит со скулем значительно хуже чем оперативный учет .
Торговля на бухкомпоненте это нормально , до определенных объемов данных , и если не требуется особо высокая детализация аналитики , масштабируемость такой системы будет не высокой , опять же из за , не очень хорошей работы с SQL
125 Drac0
 
13.05.11
12:25
(123) Точно, подключился не через терминал, отчет тормозит так же.
126 VladZ
 
13.05.11
12:27
"10 Мбит" - это канал между пользователями и терминалом? Или между терминалом и SQL-серваком?
127 Drac0
 
13.05.11
12:35
Реиндексация прошла нормально, но это не помогло. Есть нюанс: стандарта ОСВ работает на порядок быстрее, чем самописный отчет. Так что, думаю, можно этот отчет оптимизировать. Но обортка формируется все-равно заметно дольше,чем на файловой версии.
128 Drac0
 
13.05.11
12:36
(126) Уже писал, что между пользователями и терминалом.
129 opty
 
13.05.11
12:36
(0) Неверное содержимого текстого поля прямого влияние на быстродействие не оказывает , но базу проверить не помешает (и переиндексировать), видно что давно не обслуживалась
Посмотри "Управление бухгалтерскими итогами" , не стоит ли там какой нибудь 3-й квартал 2015 года , на некоторых бухзапросах перенесенный вперед период может вгонять базу в ступор . Хотя в общем не похоже , локально то все шустро.
Установи 1С прямо SQL-сервер , и проверь скорость сразу отсечешь вероятные причины по сети и терминалу
Между терминальныйм серваком и скульным , для клюшек настоятельно рекомендуется имет гигабитную сетку
130 VladZ
 
13.05.11
12:38
(127) Значит так отчет написан.
На файловой версии будет всяко быстрее.
131 VladZ
 
13.05.11
12:40
+130 Сколько строк кода в отчете?
132 val
 
13.05.11
12:41
(127) Вы уверены, что реиндексировали именно Вашу базу?
Вы это делали сами? Каким образом?
133 opty
 
13.05.11
12:41
(130) Для бухкомпоненты да , все отчеты использующие бухитоги , работают значительно быстрей в файловом варианте
134 Mikeware
 
13.05.11
12:42
(127) Значит, самописный написан не очень качественно. Хотя не факт.
Прямые запросы (класс AccountRecordset), конечно, помогут...
но это придется немного попотеть...
135 opty
 
13.05.11
12:43
(134) Прямыми запросами к бух-итогам очень геморно обращаться , и не факт что выигрыш будет в скорости
136 Drac0
 
13.05.11
12:44
(130) 241 строка, но меня несколько напрягает, что бух запрос сформирован с помощью конструктора ...
(132) Да, уверен. Посмотрел в  Maintanace Plann History
137 Drac0
 
13.05.11
12:45
Есть еще один вопрос тогда: насколько лучше дела обстоят на 8 в такой ситуации?
138 VladZ
 
13.05.11
12:45
(136) 240 строк - ни о чем... Запускай отладчик, втыкай замер производительности и оптимизируй.
139 Mikeware
 
13.05.11
12:46
(133) не только для бухии. для торговли файловая тоже быстрее. Но сиквельная все-таки надежнее и позволяет бОльшие объемы
140 Mikeware
 
13.05.11
12:47
(135) будет. От 3 до 10 раз.
141 opty
 
13.05.11
12:47
Бухгалтерия восьмерки намного лучше уживается со скулем чем семерочная , как впрочеми восьмерка в целом :)
142 Mikeware
 
13.05.11
12:48
(137) бух подсистема в ней гораздо лучше.
143 val
 
13.05.11
12:48
(135) Уже устал говорить: вы не любите собак? (с)
Прекрасно работают прямые запросы на бух. базе на проводках, выигрыш в скорости колоссальный - до 100 раз. Просто научитесь.
144 VladZ
 
13.05.11
12:48
(137) И в восьмерке можно наваять отчет, который будет тормозить и глючить...  :)
145 Drac0
 
13.05.11
12:48
(138) Переписать отчет не проблема, но таких отчетов у нас самописных достаточно много.
146 VladZ
 
13.05.11
12:49
(145) "Пилите, Шура, пилите! Они золотые" (с)   :)
147 opty
 
13.05.11
12:50
(140) Если отчет за период месяц или квартал то да , а если за произвольный период (скажем с 03.05.2011 по 24.05.2011) , то нет
(144) Ну это то само собой :)
148 Drac0
 
13.05.11
12:52
(146) Есть нюанс. Возможно жить этой семерке у нас полгода ... Поэтому надеялся на более оптимальный вариант.
Сначала поставлю и погоняю локально на 2005 скуле, если итога не будет, будем пилить, раз уж они золотые :)
149 VladZ
 
13.05.11
12:53
(148) Давно перешли на SQL?
150 opty
 
13.05.11
12:55
(143) На проводках да (это прямые записи в базу) , на итогах нет , что бы посмотреть оборот скажем за пол года по 41 счету , запросу придется обрабатывать МНОГО проводок , итогами проще и быстрее .
Надо использовать преимущество бухкомпоненты там где оно есть , не надо с ней как регистрами работать
151 chief accountant
 
13.05.11
12:56
(148) Ещё в (27) было написано - не взлетит. Не зависимо от версии SQL
152 val
 
13.05.11
12:59
(150) "Давайте спорить до хрипоты о вкусе устриц. Которых я не ел." (с) Жванецкий.
В бухкомпоненте кроме таблица проводок есть таблица итогов.
153 opty
 
13.05.11
13:01
То есть оборотку можно построить по бух итогам и от проводок
Оборотка от проводок умрет на файловом варианте (счету по 41)
На скуле при использовании прямых запросов она действительно будет работать в десятки раз быстрее , но сольет оборотке по итогам файлового варианта .
По поводу же того что быстрее бух-итоги на скуле , или прямые запросы на скуле к проводкам , от конкретного отчета зависит

(152) С периодичностью в месяц , и приходится делать много промежуточных запросов и расчетов к проводкам же опять , если период не цельный
154 val
 
13.05.11
13:07
(153) Открою секрет - я использовал прямые запросы в файловой (DBF) бухбазе к проводкам и итогам. Все равно прямые быстрее в 5-10 раз. Если вы умеете попадать в индекс.
155 val
 
13.05.11
13:09
(153)
"С периодичностью в месяц , и приходится делать много промежуточных запросов и расчетов к проводкам же опять , если период не цельный".
А с регистрами не так?
Совершенно одинаково.
156 Mikeware
 
13.05.11
13:20
(153) Разве бухитоги хранятся помесячно? :-))) всегда поквартально хранились...
более того, сама 1с считает точно так же... Только ввиду большей универсальности - менее оптимально, и через промежуточные таблицы (временные файлы)
157 Кириллка
 
13.05.11
13:28
(156)помесячно в том числе.
158 opty
 
13.05.11
13:39
(156) Считаются по квартально , хранятся по месячно
(155) Итоги  хранятся чаще , есть актуальные итоги , и можно создать произвольные регистры для храения итогов при необходимости , на бух компоненте , если только на забаланс , но и там особо не поизвращаешся :)
Или ты что бы посмотреть складские остатки в опер учете запрос по операциям делаешь ? Шучу :)
159 opty
 
13.05.11
13:50
И кстати я не спорю что прямые запросы быстрее , потому как сам их использую :)
Но ИМХО
Прямые запросы в бухкомпоненте геморойней чем к регистрам
Выйгрыш в скорости при переходе на прямые запросы выше в опер учете чем в бух учете
Очередное изменение типовой конфы бухии , может изменить ключевую структуру данных , и прямой запрос придется переписывать , в опер учете (по крайней мере в ТиС) ситуация помягче
Грамотное использование бух-запроса к итогам дает очень хорошие результаты но только при файловом типе базы

Возможно я и не прав , но думаю что без критической необходимости (по объему) , базу на бухкомпоненте на SQL лучше не загонять , геммороя будет мама не горюй
160 Кириллка
 
13.05.11
14:00
так, для справки: а как будут жить несколько десятков миллионов проводок в v8.x?
161 opty
 
13.05.11
14:09
Хуже чем несколько миллионов операций на регистрах , но намного лучше чем такой же объем на клюшках , все это касаемо скуля
На DBF просто больше 10 миллионов (примерно смотря как в проводки сконфигурированны) не запихнешь , 1SENTRY.DBF превысыт предельный размер
162 Кириллка
 
13.05.11
14:14
(161)теоретические рассуждения не интересны.
163 opty
 
13.05.11
14:20
На восьмерке пока не набрали еще приличный объем , пока два миллиона проводок в бухии , полет нормальный
На семерке файловой на 8-9 миллионах сворачиваемся , живет приемлемо, этот же объем в скуле , просто умирает , переписывать все отчеты и модули документов в более или менее типовой нет смысла
164 val
 
13.05.11
14:32
(163) Бухгалтерия живет на SQL с 2003г. без свертки. Много десятков миллионов проводок. Типовые отчеты не переписывались. Без тормозов.
165 opty
 
13.05.11
14:42
(164) А перепроводитесь как ?
А как же высокоэффективные прямые запросы ?
Пострение стандартной карточки счета (проводки через бух-запрос) на скуле тормоза еще те
166 val
 
13.05.11
14:55
(165) Если один документ, то спокойно и легко.
Если массово, то, как и в оперучете, используем ReconnectNative.
Прямые запросы использую в своих отчетах и при расшивке узких мест. Как, впрочем, и в оперучете.
167 val
 
13.05.11
15:14
(165) Повторюсь: я не вижу никакой разницы между работой прямыми запросами между регистрами и проводками.
Как в регистрах остатки и движения - RG и RA, так и в проводках остатки и движения. Периодичность чаще всего одинаковая - месяц.
Но структура таблицы проводок универсальная, а у регистров - уникальная для каждого регистра.
Поэтому для проводок один раз написать несколько универсальных процедур - и все.
168 opty
 
13.05.11
15:22
При перепроведении львиную долю занимет собственно расчеты остатков и себестоимости , ReconnectNative тут как бы ине при делах . Но честно говоря  я глубоко этот метод  не копал , первые весии (бетовые) прикручивал к опер учету , получалось глючно , предпочел смещать ТА при групповом проведении , а потом перешли на SQL 2005

(165) посмотри мой пост (147) , если периодичность месяц то естественно , а если период произвольный то нет
169 Кириллка
 
13.05.11
19:46
(167)нет, разница все-таки ощутима и различима.
в бухучете возможно только сканирование таблицы за период(!!), а в оперучете можно попадать в индекс, который можно крутить.
170 Drac0
 
15.05.11
14:16
Что ж, запустил связку Win7 64bit + SQl Server 2005 Developer Edition на ноуте с Core i3 M 350 2,27 и 3 Гиг оперативы. Самописный отчет и карточка счета формируются на порядок дольше, чем в файловом варианте на этом компе.
Думаю, может забить и перевести базу на файловый вариант? Только интересно, как 25 активных пользователей уживутся ...
171 opty
 
15.05.11
15:26
(170) В терминале легко , если объем базы не превысит критический см (161)
172 opty
 
15.05.11
15:34
Самописка на регистрах спокойно работала при нагрузке 70-80 пользователей (причем все достаточно активные) , правда с использованием Citrix (приличная экономия оперативы терминального сервака)
В файловой бухии (практически типовой) без проблем работают до 20 пользователей  (правда опять же под Citrix)
173 Drac0
 
15.05.11
15:46
(171) Таблица проводок весит 400+ метров, так что запас прочности достаточный.
174 Drac0
 
16.05.11
16:58
(172) Меня вот тут другой вопрос волнует: если кто-то вылетал с ошибкой, то сколько времени уходило на то, чтобы всех выгнать из 1С и провести переиндексацию?
175 FN
 
16.05.11
19:10
(174) ночью такие вещи делать надо...
176 opty
 
16.05.11
19:36
(174) Ну вылетел и вылетел , остальные продолжают работать , вылетевший штатно заходит и продолжает так же работать , ночью скриптом бекап , переиндексация , обмены данными , возможно тестирование и исправление  .
Но кстати одним из факторов перевода оперучета на скуль несколько лет назад у нас был переход складов на 24/7 , но бухгалтерия я думаю ночами не работает :)
177 opty
 
16.05.11
19:40
При грамотной настройке терминала , вылетевший (по разрыву связи или локальному зависону) кстати подхватывает свою сессию , то есть вылета из 1С не происходит . Вылет из 1С под терминалом - это серьезный сбой на сервере , а это достаточно редкий случай
178 К_Дач
 
17.05.11
00:09
Интересная ветка. Автор, так а что там с 10 мегабиткой? Ты таки попробовал всех на терминал згнать или нет?
179 Drac0
 
17.05.11
09:15
В общем не удалось уговорить перейти на файловый вариант. Пока решили перевести базу на отдельный сервер SQL. Просто на текущем крутится еще две тяжелые БД. Это уже хоть что-то. Ну и сделать свертку, отсечь два года. Хотя сомневаюсь, что будет большой результат.
(177) Просто опасаются каких-нибудь глюков самой 1С-ки и пользователей: зависла обработка и пользователь жестко закрыл 1С, выбило из-за ошибки платформы и прочее. Тогда придется всех выгонять и делать переиндексацию. Я понимаю, что вероятность подобных ошибок мала, но именно эта вероятность и останавливает других.
180 VladZ
 
17.05.11
09:19
(179) "Просто на текущем крутится еще две тяжелые БД"... Возможно причина в этом? :)
181 opty
 
17.05.11
09:24
(179) Дело конечно ваше и SQL по любому надежнее
но у клюшек файловый вариант не так уж плох.
Оперативный учет крутился в файловом фарианте несколько лет , база достигала почти 8-ми гигов (при переходе на скуль пришлось кстати переписать 60% всех запросов , в том числе и на прямые) , бухия клюшковая до сих пор крутится в файловом варианте . Размер базы больше 4-гигов , пользователей до 20 (в период месячной и квартальной отчетности и налоговых проверок , штатно 7-8)
При надежном железе , хорошей настройке служб терминала (Citrix-а) и своевременном обслуживании баз , проблем не наблюдается .
Восьмерка другое дело , только SQL , ИМХО файловый вариант в ней только для разработчика , ну максимум нескольких пользователей
182 opty
 
17.05.11
09:25
(180) На не хилом ноуте - тормоза ,
Остаюсь при мнении что бухкомпонента и SQL - достаточно несовместимые штуки , или все переписывать :)
183 opty
 
17.05.11
09:31
Если строить все отчеты строго за цельный период (месяц, квартал) вполне себе можно работать в бухии и на SQL (падение производительности будет , но не столь заметное) , но это не реально (всякие скрыжки за кородкие периоды и т.п.), а как только запрос (буховский или "черный") обращается к не цельному периоду , или напрямую к операции или проводке , на скуле можно тушить свет
184 opty
 
17.05.11
09:43
(179) Если есть возможность сделать свертку делайте , поможет именно для SQL , это связанно с особенностями реализации бухкомпоненты , процентов 25-30 по производительности выиграете .
И совет - сворачивайте в файловом режиме , с последующей загрузкой в новую SQL базу , типовая обработка свертки бухгалтерии под SQL это , слов нет . Или переписывать обработку свертки капитально.
185 Drac0
 
17.05.11
10:45
(184) Спасибо за совет. Когда все сделаем и потестим, отпишусь о результатах.
186 opty
 
17.05.11
12:23
Удачи :)
187 Drac0
 
27.05.11
11:32
В общем, все плохо. после свертки (отрезал почти 3 года) и полного ТиИ базы скорость банальнейшего отчета не ускорилась ни на ять. Даже наоборот, стала 4029 сек. против 4017 сек. (вертится все на другом сервере для теста, собранном на каленке) Ну это не считается, т.к. укладывается в погрешность и прочее.

Чутка переписал этот отчет, выиграл 20% при формировании за 1 неделю (по сути карточка двух счетов с доп. рассчитываемыми показателями). 99% времени занимает запрос к бухитогам. Посему такая просьба: может кто-нибудь подкинуть ссылочки на инфу по работе с прямыми запросами на бух. компоненте? Попробую, что это даст.
188 opty
 
27.05.11
11:44
(187) Привет
Странно , должно было улучшится , не намного но все же . загружал в новую SQL базу ?
Запрос бухгалтерский или "черный"
Строится за цельный период ?

Определенный прирост скорости на прямых запросах получишь , но значительно меньший чем на регистрах ,и муторно это для бухгалтерии . Тем более все равно насколько я поню возможно базе пол года осталось.
DBF вас спасет
189 Drac0
 
27.05.11
12:00
Собрали отдельный сервер, грубо говоря из того, что нашли. Девственно чистый. Поднял на нем SQL 2000. Создал в нем 2 базы под 1С: одну для старой, вторую для идентичной, но после свертки и ТиИ. Загрузил и запустил этот горе-отчет. Итог для старой - 4017 секунд, для новой - 4029 секунд. Период - месяц. Выводятся остатки и обороты по этим счетам в разрезе контрагентов.

Запрос бухгалтерский.

Беда этого отчета была в том, что там запрос делался дважды? сначала для первого выбранного счета, потом для второго. Это безобразие я убрал, заменив на один запрос. Проверил, что дало: 1230 секунд, против 1518 секунд при формировании отчета за неделю.

Тот кто курировал 1С до меня и до сих пор к ней причастен (просто работает, так сказать, в другом отделе) КАТЕГОРИЧЕСКИ против DBF, по той причине, что если понадобится переиндексация, то это будет сделать крайне сложно и долго (всех обзвонить, всех выгнать, потом всех обратно звать в 1С). Вот так вот. Поэтому хочу проверить, что дадут прямые запросы. Их надо для пары кретичных отчетов только реализовать.
190 opty
 
27.05.11
12:17
(189) ну есть выгонялка , и я уже писал что простом вылете реиндексация не требуется

2005 работает с бухией лучше , нет даже необходимости использовать ReconnectNative
после свертки бух итогов обязательно требуется сделать выгрузку загрузку базы , для очистки промежуточных таблиц , но похоже ты это уже сделал

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

10 минут простоя в оперативной базе может быть смерти подобно (это я про переиндексацию) , но бухия то не настолько оперативный учет ведет .
4000 сек это 66 мин , блин на DBF база в 3 гига типовой бухии реиндексируется 10-15 мин в зависимости от железа , по моему потери времени меньше .
191 Drac0
 
27.05.11
12:55
(190) А я и не говорю про разрыв терминальной сессии. Я про конкретный такой глюк 1С, или кривые руки пользователя, или еще что-либо. Хоть я и понимаю, что при отлаженной работе шанс таких ошибок стремится к 0, но убедить не получается. И даже догадываюсь, почему.

2005 ставил на ноуте локально и скорость работы не обрадовала :) Это я уже писал.
Выгрузка/Загрузка естественно была сделана.

Хм, про субконто и проводки интересно, попробую и посмотрю, какие даст результаты.

Бяда в том, что в этой бухии работают и кассиры, а у них оперативность должна быть ого-го. (раньше кассиры работали в управленческой системе, но так вышло, что они стали работать с 1С).

Но формировании отчета не останавливает работу на 100%. Хотя и понятно, что это сомнительное преимущество при столь сильных тормозах.
192 Drac0
 
27.05.11
13:11
+(190) Что-то не сразу подумал. Субконто - контрагенты, так что отбор по нему стоит. По поводу проводок: вы имеете ввиду добавить в отчет методы ВыбранаПоДт() и ВыбранаПоКт() ?
193 Mikeware
 
27.05.11
13:11
(190) почистить базу от нулевых итогов можно (и быстрее) и без выгрузки-загрузки
194 opty
 
27.05.11
13:53
(193) можно и быстрее (хоть шринком) , но так надежнее :)
(192) Если у объекта метаданных "Проводка" стоит режим отбора Дебет/кредит (в типовых по умолчанию отключен , включен только общий отбор), в разы возрастет скорость при использованиии "ФлагДК" при любой выборке результатов запроса , скорость собственно метода "ВыполнитьЗапрс" не изменится .
В самом запросе "ТипИтогов" очень влияет на производительность , без необходимости обороты межд счетами лучше не смотреть.
У "ИспользоватьСубконто" проверь использование группировки по группам , если нет необходимости - то же долой
195 Drac0
 
27.05.11
14:17
(194) Да вроде все нормально с типами. сам запрос

Ит.ИспользоватьСубконто(ВидСуб,ВыбКонтрагенты, 1);

Ит.ВыполнитьЗапрос(ВыбНачПериода, ВыбКонПериода, СпСчетов,,, 1,, "С");

Именно сам ВыполнитьЗапрос() и занимает 99% времени. Выборка результатов и формирование таблицы занимают от силы 3-7 секунд ...
196 Drac0
 
27.05.11
14:19
+(194) придется попробовать прямые запросы. Посмотрим, какой будет результат. Поэтому возвращаюсь к своей просьбе: поделитесь инфой по работе с бухгалтерской компонентой на прямых запросах :)
197 ado
 
27.05.11
14:31
(6) Это просто бух. подсистема сама такая ... нехорошая.
198 opty
 
27.05.11
14:45
(197) На скуле :)
Ну да запрос простой , косячить вроде неоткуда , если только в список счетов поподают счета у которых нет субконто Контрагенты , даже выборки периодичности нет
(196) Здесь я тебе к сожалению ничем не помогу , давненько еще ковырялся пр. запр в бухкомпоненте , запутался , не получил приемлемых результатов и бросил это дело , регистры дело другое .
Если у тебя ВыбКонтрагенты практически весь справочник , ну по крайней мере 3/4 , попробуй метод Рассчитать() , и работай через временные итоги .
С трудом припоминаю , но несколько лет назад чето такое было на халтурке со скулем то же , парадоксально но вроде помогло . Хотя врят ли поможет , но попытка не пытка
199 beholder
 
27.05.11
14:52
(196) Используй класс Accounts Recordset отличная штука.
200 Drac0
 
27.05.11
14:58
(199) А можно поподробней? Как я полагаю, это класс 1C++?
201 opty
 
28.05.11
04:28
(200) Угу
в ряде случаев , позволяет поднять производительность запроса в раза в три , по крайней мере версии 2007 года , сейчас может подоптимизирован , производительность сильно зависит от общей структуры плана счетов , скажем одно субконто на счете при нескольких сотнях (или тысячах) аналитик прилично производительность растет , если 2 (или три) субконто на счете уже не так все облачно. Просто сама структура журнала проводок и итогов (и индексов) не очень оптимально для скуля реализована
Просто ИМХО - ну перепишешь ты этот отчет на прямые , получишь прирост производительности (хотя не факт) , а с остальными то отчетами (и документами) , что делать ? , бухия в отличии от оперучета должна регулярно обновляться
202 Сияющий Асинхраль
 
29.05.11
01:20
А зачем 20-30 пользователей в бух базе пихать на сиквел, файловый вариант для данного случая работает намного быстрее, если не переписывать на прямые запросы
203 opty
 
29.05.11
01:48
(202) О том и разговор , вообще честно говоря не понятно что 30 пользователей могут делать в бухгалтерии если задействована программа оперативного учета .
Ну главбух , зам , несколько бухов , финансисты , ну кассир .
10 пользователей . У меня например в оперативном учете до 90 пользователей сидят в одной базе под скулем , в бухии как правило не более 8-9 . В период авралов только (отчетность там , проверки) до 20 доходит , и в  файловой бухии никаких проблем с надежностью и стабильностью нет.
В конце концов можно было бы подумать о вторичном реплицировании SQL базы в файловый вариант на автомате , типа скульная база надежно хранит , а файловой работают , но у TC похоже значительная часть оперативного учета именно в бухгалтерской программе ведется , так что этот вариант не проходит.
И и почему в предыдущие 2-3 года вопрос не возник , если после свертки 3 лет такие тормоза ?
204 opty
 
29.05.11
02:07
Такое ощущение что в конфе не так давно задействовали разделитель учета , и завязали его как-нибудь криво , на тип документа например
205 Злопчинский
 
29.05.11
02:45
(191) о блин, в ноутах стоят супербыстрые диски...
206 opty
 
29.05.11
15:02
(205) Вообще то файловые клюшки на более менее приличных объемах базы сильнее дисковую подсистему загружают чем скульные , особенно если оперативки достаточно . У TC на  ноуте 3 гига , что в принципе достаточно для имеющихся объемов и одном пользователе . Кроме того тестировалось в первую не абсолютное быстродействие а относительное (к файловой)
207 Drac0
 
02.06.11
09:49
(204) Снова здравствуйте :) Разделителя учета нет.

(203) Пользователей штатно 25: главбух, 14 бухов, 4-5 финансиста, 5 кассиров и еще некоторые.
 
По поводу копирования SQL в файловый у меня уже зародилась мысль, только несколько иная: каждую ночь делать выгрузку базы в файловый вариант, чтобы на этой копии гонять тяжелые отчеты. Надо только выяснить, наколько оперативная информация нужна бухам.

Оперативный учет ведется только у кассиров, но для них это крайне критично.

Думаю вопрос быстродействия возникал постоянно, только никто не хотел его решать :)
208 opty
 
02.06.11
10:22
(207) У меня оперативный учет какой то период реплицировался для построения тяжелых отчетов (ночью) , но репликация шла средствами скуля (из скуля в скуль на другой сервак)
С переходом на 24/7 и развитем у нас OLAP серверов от таких репликаций отказались
209 ДенисЧ
 
02.06.11
10:23
(208) а олап у тебя какого типа и как часто пересчтитывается?
210 opty
 
02.06.11
10:27
А извини за не скомный вопрос нафига столько бухов то , да и кассовые операции это в общем то оперативный учет
(209) стандартные кубы на SQL2008 с использованием MDA , оперативный пересчет идет ежедневно (ночно  , без прекращения работы) итоговый ежемесячно , клиент - excel
211 ДенисЧ
 
02.06.11
10:28
(210) ROLAP? Ночью никто в базе не работает?
212 opty
 
02.06.11
10:32
MOLAP , работают но нагрузка минимальна , и как правило на чтение - печать документов , построение наборных карточек , расчет маршрутов на завтра
213 ДенисЧ
 
02.06.11
10:39
(212) Понятно.
214 Drac0
 
02.06.11
10:50
(210) Извини за нескромны ответ, но я в душе не знаю :) Но этого пока не изменить. то что кассы - это опер. учет понятно, но того, что они ведутся в бухе это тоже пока не изменить.