37-bma1 > Если выкрою время - обязательно так и сделаю... :(

Ты напиши хоть какие формы и отчеты поглядеть - всю конфу читать лениво же!

Явные тормоза при сканировании товара в приходную накладную.
Остальное - вот даже не скажу на вскидку. Оно всё потихоньку как-то неубедительно себя ведет в плане быстродействия...

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

32> спецов по ТиС всё меньше, они всё чаще болеют и не могут. А через пяток лет вообще на пенсию уйдут.
Оно вам надо?
.
оно - нам надо! я уже на пенсии! ковыряю тис помаленьку. так что если есть адекватные люди, желающие платить адекватные деньги - внесите меня в списо к в очередь к таким людям!

(42) ждем вестей с линии фронта

45-Чучундер > Ты неверно акценты расставил. Надо так: "Внесите их в список на очередь ко мне" :)

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

48-Чучундер > Ну... Тоже вариант, согласен. :)

(47) а почему штатную розницу не взял? у нас в магазины вроде поставили - вроде работает. Издалека посмотрел - я конечно не спец по юзабилити - но за такое убивать надо.. ;-)

50-Чучундер > Именно по этому и не взял... Продавщиц пожалел. Да и себя, любимого.
Не возникло у меня желания столько перепахивать, доводя ее до работоспособного состояния. Мне проще нужное написать с нуля, чем ненужное в чужом изделии выкашивать.

Пока глянул на регистрацию продажи. ТО подрубается дважды, и при открытии, и перед открытием. Кроме того я бы поменял запрос определяющий номер чека в пределах дня - группировал бы документы с наложением функции максимум на номер чека.

Приходную гляну попозжа. И отчеты подскажи.

а нафига определять номер чека? ТО его что, не возвращает?

52-Reaper >[em]ТО подрубается дважды, и при открытии, и перед открытием.[/em]
Ага, лошара я. Перекопипастил... Поправлю.
[em]Кроме того я бы поменял запрос определяющий номер чека в пределах дня[/em]
Полностью согласен.
У кого есть доступ на подпольный форум? Переадресуйте это писателям типовых - оттуда скопипизж...но.
Кстати, вот именно к регистрации продаж претензий по скорости работы практически нету...

53-Чучундер > Делалось больше года назад. Точнее - срисовалось с той самой типовой розницы, даже не вдаваясь в подробности.

52-Reaper > По отчетам - СравнениеПериодов и ЗаказТовараУПоставщиков.

(31)+ Вопрос магазины как работают?
распределенка? Терминал? web?

57-Кибер > Если это ко мне вопрос был, то - УРБД.

(58) нет это я у Reaper-а спрашивал

59-Кибер > меня плюсик после (31) смутил :)

у меня интерес к работе ут через web (безопастность доступа к дркгим данным сервера)
но это наверно только УТ11 так может

Да нормально десятка шустрит в файловом варианте.
Только вот моё мнение, что одинэсину на фронт ставить рановато.
Не, ну если две-три продажи в час, то можно, а вот с бОльшим потоком - тяжко она справляется.

Да, кстати, можете меня поздравить, скрестил я всё-таки ежа с ужём :)
Бэк на 10.3: файловый, терминал. 26000 позиций номенклатуры, 25 складов, 10 юзеров, базе 3.5 года, 17 гиг.
Фронт на Фронтоле, два кассовых узла, в одном пять локальных касс подключенных к кассовому серверу, в другом узле пять удалённых магазинов, работают через фронтоловский синхронизатор с кассовым сервером.
Синхронизация остатков фронт-бэк и обратно каждые 30 секунд. Тормозов не замечено. Пока все довольны :)

> 25 складов
- это такие маленькие кладовочки?

63-Чучундер >Не :)
Восемь магазинов, в большенстве по два склада (торговый зал и склад при магазине), в некоторых три.
Плюс база, плюс гараж, плюс небольшое производство.
Сейчас можно из офиса или с любой кассы продать товар с любого склада, в течении 30 секунд остатки будут синхронизированы.

(64) везет.. у меня за 30 секунд симтуация может измениться кардинально... не всегда конечно, но как напортачат.. " я же всего на минутку".. и трындец...

а у меня все работает нормально
может у вас компы отстойные и памяти по 512мб?

65-Чучундер >:)
за 30 секунд максимум 7-8 чеков, в среднем по 4-5 позиций. Вероятность накладок очень и очень мала. И даже если раз в неделю по одной-двум позициям произойдёт казус, то ради этого не строит строить полностью онлайн систему, не стоит оно того.

+(67) теоретически можно сократить и до пяти секунд, но пока необходимости нету. За неделю функцианирования системы, ни одной накладки.
А дальше будем смотреть по ситуации.
Всяко это лучше и быстрее РИБ :)

(57) В каждом магазине своя база, синхронизация при помощи обмена сделанного на КД.

Хм, поглядел я на приходную накладную - ИМХО там пичаль в функции цена. Срез последних в отборе использует только одно измерение из 2-х. Второе ищется уже в результате среза последних, а можно сразу было в отбор его сунуть. С учетом симптома "тормозить стало недавно" - перепиши получение цены.

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

(71) в чем принципиальная разница между сборов итогов по документам и по регистрам? - и там и там - таблички...
.
м.б. продажи не пишутся врегистр именно по причине ускорения оПЕРАТИВНой работы...?

(72) У регистров есть таблицы итогов. Кроме того там отчет оба по оборотам - будь все данные в регистре продаж, при необходимости можно было бы посчитать агрегаты и ускорить еще значительнее систему. А сейчас там навороченные запросы, местами с избыточными группировками, со вложенностью, вводящей оптимизатор СКД в ступор. Я не удивлюсь, если на таких запросах отчет по одной позиции строится столько же времени как без отбора вовсе.

70-Reaper > Глянул Цена(). Руки, конечно, мне оторвать за эту функцию надо, но не сильно. Где-то по локоть. Категорий цен всего 3. Так что сильно погоды не делает.
Разумеется, исправил. И, разумеется, пасиба за замечание.
Однако, не в этом тормоза. Обрисую ситуацию подробнее. Держу в руках десяток одинаковых упаковочек товара. И клацаю по ним сканером. С максимальной скоростью, которую мне сканер позволяет. В документе наблюдаю 8 штук. Клацаю медленно - все 10 попадают в документ.

71-Reaper > [em]Основная причина торможения отчетов - то, что расходная накладная в регистр "продажи" ничего не пишет[/em]
Не соглашусь... Если она туда начнет писать - колом встанут отчеты, где расходные накладные не нужны. Соотношение продаж чек-расходная - примерно 500:1.

[em]местами с избыточными группировками[/em]
Покажи, где именно? Сильно подозреваю, что пытался СКД забороть.

[em]со вложенностью, вводящей оптимизатор СКД в ступор.[/em]
Э нет. Нормальный оптимизатор вложенными запросами в ступор не введешь. Тот же мелкомягкий скуль просто на ура с ними справляется. А программисту читать запрос удобнее.

73-Reaper > [em]У регистров есть таблицы итогов. [/em]
Которая моментально идет лесом при использовании СКД. Тот самый ПериодСекунда и иже с ним. При использовании СКД глубоко фиолетово какую таблицу юзать в запросе - регистр или документ. Лишь бы в индексы попасть.
В файловом же варианте и индексы топают под руку с таблицей итогов. Ибо не можем мы (по крайней мере - я) четко отследить - какой именно индекс и как используется.

+(74) [em]В документе наблюдаю 8 штук...[/em]
Не дописал чуток. При сканировании второй и далее штучки за ценой мы уже не лезем, так как она у нас уже есть в документе.

66-Управление торговлей 11 >[em]а у меня все работает нормально
может у вас компы отстойные и памяти по 512мб? [/em]
Безумно меня радует подход франчей к проблемам быстродействия: "Докупите серверов и будет вам щастье"...

[quote=Sadovnikov;26310476]Безумно меня радует подход франчей к проблемам быстродействия: "Докупите серверов и будет вам щастье"...[/quote]
(ОФФ) Хм... вспоминается обратный случай, я еще работал в Политехе заведующим учебным классом. На просьбу выделить денег на обновление сервера завкафедрой посмотрел на сервер, покачал головой и заявил: "да, он у вас тут какой-то старенький, потёртый. А вы его покрасьте и будет как новенький!"

[quote=Sadovnikov;26310194]С максимальной скоростью, которую мне сканер позволяет. В документе наблюдаю 8 штук. Клацаю медленно - все 10 попадают в документ.[/quote]
Такую хреновину я видел только один раз, когда админ на переходник COM-USB самолично питание перепаивал. В итоге оборудование с ума посъезжало. В обоих магазинх такая ботва у тебя?

[quote=Sadovnikov;26310194]Покажи, где именно?[/quote]
В отчете ЗаказТовараУПоставщиков запрос с объединением обернут в группирующий. Там проблема не столько в группировке, сколько в работе с таблицей регистра.

[quote=Sadovnikov;26310258]Которая моментально идет лесом при использовании СКД[/quote] Отчету по оборотным регистрам период секунда не нужен, с оборотными регистрами все проще. А вообще тех. журнал у 8.2.15 умеет даже для файловой версии собирать планы выполнения запросов.

[quote=Sadovnikov;26310194]Э нет. Нормальный оптимизатор вложенными запросами в ступор не введешь.[/quote] Так то, нормальный, а мы об 1С говорим. Я на самом деле говорю о механизме, который еще на стороне 1С парсит текст запроса и удаляет из него неиспользуемые в текущей настройке поля/таблицы и вставляющий параметры и условия в запрос в зависимости от отборов. Твои вложенные запросы сейчас либо не обрабатываются, либо обрабатываются каким-нить затейным образом. Нужно либо вручную описать параметры отбора для каждого вложенного запроса, чтобы компоновка их нормально переварила, либо перетащить все в регистр продаж - она тогда сама нормально справится.

[quote=Sadovnikov;26310194]Если она туда начнет писать - колом встанут отчеты, где расходные накладные не нужны. Соотношение продаж чек-расходная - примерно 500:1.[/quote]
На счет "Колом" это я сомневаюсь. Ну введи в него измерение еще одно с подразделением или видом деятельности, чтобы отделить мух от котлет. У тебя уже сейчас должна быть дикая разница в производительности отчетов только по регистру продаж, и вот этими двумя, которая как раз и показывает всю выгоду от регистра.

79-Reaper > [em]В обоих магазинх такая ботва у тебя?[/em]
Во всех трех... В обоих магазинах и в офисе. Если, упаси боже, запускаем базу по сети, то тихий трындец. Из десятка отсканированных товаров в документе можем получить и 5 и 4.