0
- 05.08.2012 - 19:47
|
Штатным методом не получается - не загружаются в УТ поступление тмц, комплектация, оприходование и списание. Все заявки (неподтвержденые и обычные) загрузились как просто заявки на склад. В файл обмена выгружаются все документы. А вот УТ их режет. В чём может быть причина? Что посмотреть/сравнить? Подскажите, пожалуйста, кто сталкивался. ) | |
121
- 09.08.2012 - 14:38
|
(120) Потому что запрос к физ таблице не даст тебе агрегатов из таблицы Turnover, а будет копать значительно более жесткую основную таблицу регистра. Оба, а ну геть в школу! Слиняли с физры и теперь списываетесь на формуе. | |
122
- 09.08.2012 - 14:41
|
118-Lexusss > 1. Так тоже в основном 2005-й. Что-то ты меня в какие-то непонятные сомнения ввел... Надо еще поэкспериментировать. Вдруг, на старости лет меня уже память подводит? 2. Спорно... Вон, в типовых 1С тоже "стандарт" пытается изобразить... Но мы же не будем ему следовать, верно? Вот какая-то психологическая неприязнь к INNER JOIN... 3. Вот это ты меня приласкал :)))) | |
123
- 09.08.2012 - 14:42
|
121-Lexusss > Дяденька, не ругайся... Я больше не будууууу..... :) | |
124
- 09.08.2012 - 14:44
|
120-Sadovnikov > прошу прощения, дейстительно не отбор там А про физ.таблицу - а зачем нам доп.расходы на формирование вирт.таблицы со стороны 1С ? Учитывая, что используются поля Товар и ДокументПродажи, 1С будет строить таблицу Товар / Документ / ... (по-сути - копия физ.таблицы) и только потом делать отбор. Уверен на 90%, что запрос к физ.таблице будет быстрее. | |
125
- 09.08.2012 - 14:49
|
(122.2) Очень даже нормальный стандарт. А нормален он тем, что именно на нем учится 99,9% всех приходящих ко мне на работу. И код по уровню понимаемости должен соответствовать этому стандарту. Видя LEFT сразу ожидаешь NULL. Я вот сразу не понял смысл явного соединения с номенклатурой. У меня заняло некоторое время для пониманию его глубокого смысла. (122.3) На самом деле много зависит от статистики по полю фНеЗаказываем. Если там 98% лжи, то оптимизатор не будет раскрывать скобки и ты действительно можешь помочь системе. В противоположном случае, можно нарваться на строго противоположное. Получается, ты придумываешь проблемы и героически их решаешь. Вместо того, чтобы полностью довериться оптимизатору и рекомендациям 1С. | |
126
- 09.08.2012 - 14:50
|
118-Lexusss > 3. Блин, только сейчас обратил внимание, что переоценил 1С-ный оптимизатор: LEFT OUTER JOIN _Reference7 T7 WITH(NOLOCK) ON (T7._IDRRef = T1.Q_003_F_000RRef) ... LEFT OUTER JOIN _Reference7 T10 WITH(NOLOCK)ON T1.Q_003_F_000RRef = T10._IDRRef По доброте душевной думал, что он уже готовым связыванием воспользуется... | |
127
- 09.08.2012 - 14:55
|
125-Lexusss > Очень даже нормальный стандарт. Вот здесь ты меня не переубедишь... Так как не хочется ровняться на столь низкий уровень и ему соответствовать. Как-то расти над собой хочется. В качестве примера от той же 1С. В букварях (как минимум, для 8.0) они настоятельно рекомендовали писать связывания путем перечисления таблиц через запятую. Я еще не видел человека, который бы быстро понимал что с чем и как связывается в при таком написании. | |
128
- 09.08.2012 - 14:57
|
125-Lexusss > (122.3) Выберу время - поэспериментирую. Очень возможно, что был там не прав. | |
129
- 09.08.2012 - 15:04
|
+(126) Блин, балбес я... Начал писать запрос за здравие, а кончил за упокой... Вместо ВЫБРАТЬ Продажи.Товар КАК Товар, надо ВЫБРАТЬ спрТовары.Ссылка Товар И лишнее связывание уйдет и всё остальное на свои места встанет. | |
130
- 09.08.2012 - 15:04
|
(126) В 1С нет оптимизатора. Там простой транслятор из языка 1С в SQL. Остается надеяться на 1С, что она все таки подхватить из T7 поля и не будет позря мешать таблицы. И от T10 ты вряд ли избавишься при любой конструкции для компоновщика или построителя. Если у тебя прямой запрос - да, можно обратиться напрямую к наименованию (раз уж оно тебе так нужно). Но если ты выводишь Номенклатура.Наименование - молись на SQL! Кстати, в одном из первых релизов типовой УТ 10.2 был целый пакет багфикса, где таким образом выпиливали лишнее обращение к таблице номенклатуры. Выпили подчистую!!! (127) Хорошо, что я не читал букварей :))))))))))))) | |
131
- 09.08.2012 - 15:06
| (129) Гы. Прикольно придумано. Пошли ка вместе в школу :)))) | |
132
- 09.08.2012 - 15:07
| 131-Lexusss > Пошли :) | |
133
- 09.08.2012 - 15:08
| (132) Как ты думаешь, мы никому не мешаем? :) | |
134
- 09.08.2012 - 15:10
|
133-Lexusss > На меня сегодня уже потенциальные иногородние поставщики обиделись за то, что я отказался у них брать товар. С предоплатой 100%. Сроком поставки в 7-10 дней и на 15% дороже, чем я беру этот товар в Новосибирске с постоплатой. Так что после этого мне уже всё пофигу :) | |
135
- 09.08.2012 - 21:55
| я уже мысль потерял. вся эта адовая оптимизация - ради кассового фронта? это ничего, что 4гб памяти стоят дешевле часа работы специалиста? | |
136
- 09.08.2012 - 22:19
|
74-Sadovnikov >"Держу в руках десяток одинаковых упаковочек товара. И клацаю по ним сканером. С максимальной скоростью, которую мне сканер позволяет. В документе наблюдаю 8 штук. Клацаю медленно - все 10 попадают в документ." версия компоненты актуальная? был у меня случай похожий, после 10 сканирований или около того шк терялись, замена компоненту на свежую вернула все в норму | |
137
- 09.08.2012 - 22:31
|
77-Sadovnikov >"Безумно меня радует подход франчей к проблемам быстродействия: "Докупите серверов и будет вам щастье"... " нормальный такой подход. в бизнесе эффективность решения измеряется в деньгах, а не в тактах процессора. если железо стоит дешевле мозгов - надо купить железо. | |
138
- 10.08.2012 - 02:36
|
(80) смотреть настройки оборудования? использование буфера сканера? . как согласовать скорость железного сканирования - которое быстро! с темпом программной обработки сканов? | |
139
- 10.08.2012 - 02:55
| итак, уважаемые любители битв без правил, что мы наблюдаем на ринге..? а на ринге мы наблюдаем интересное действо! В ж елтом углу ринга - исзветчне тяжеловесы Лексус, дядяСтолбик и на подхвате пудель непонятно йориентации.. мдя.. в противоположном углу ринга бойкий и прыткий любитель-непрофессионал Садовод, известный своим высоким мастерстовм находить язвимые точки через нетрадиционные способы доступа... итак .. идет пятая минута схватки.. тяжеловесы, заманив нашего любителя в круг своих жирных туж раз за разом наносят мощнейшие джебы и хуки.. Но наш любительСадовод прыток и быстр до умопомрачения на каждый замах успевает ответить тремя соими ударами.. и они каждый раз достигают цели.. и вот снова - мощный удар одного из тяжеловесов троицы - их не различить до того все одинаковые и замашки одинаковые - справа сплеча - ибо так учили бить по канонам старой школы - и вот он этот мощный удар в копус..!! оппа! садовод быстрым сококом уходит с линии огня и по почкам..по почкам.. такое ощущение что наш легковес выигрывает по очкам..? или нам кажется?.. тяжеловесы аппелируют к судье и залу - жалуясь на неканонические удары противника.. да.. это вам не профессиональный спорт.. это жизнь - улицы, подворотни, зверьковые магазины - тут все решает скорость и нетрадиционность мышления... мы будем с интересом н аблюдать за продолжением боя... | |
140
- 10.08.2012 - 07:40
|
136-Управление торговлей 11 > Так тут дело именно в скорости сканирования. Если медленно клацаем - всё ОК. 137-Управление торговлей 11 > Нифига он не нормальный. Ибо в 90% случаев не даст ожидаемого результата. 138-Чучундер >использование буфера сканера? - а вот отсюда можно чуть поподробнее? 139-Чучундер > Флудер :))) | |
141
- 10.08.2012 - 13:30
|
140-Sadovnikov > (136) вот именно так и было (137) бугого. то-то все на бумажке столбиком считают, раз прирост вычислительной мощности ничего не дает | |
142
- 10.08.2012 - 13:34
|
141-Управление торговлей 11 > (137) Придуряешься? "в 90% случаев" принципиально не замечаешь? | |
143
- 10.08.2012 - 14:53
| 142-Sadovnikov >про 90% это ты какой-то свой опыт за уши притянул, у меня ничего подобного нет | |
144
- 10.08.2012 - 15:08
|
143-Управление торговлей 11 > Ничего не могу по этому поводу сказать. Мой опыт в данном вопросе родился после решения проблем быстродействия за франчами. Когда франчи вот именно так "решали проблемы клиента". | |
145
- 10.08.2012 - 15:11
| 144-Sadovnikov >ты как видеорегистратор - притягиваешь аварии :) | |
146
- 10.08.2012 - 15:13
| 145-Управление торговлей 11 > :))) | |
147
- 10.08.2012 - 16:18
| А может как раз драйвер сканера медленно клацанья обрабатывает? | |
148
- 10.08.2012 - 16:21
| 147-bma1 > Так раньше-то такого не было. А драйвер тот же самый был. Проявилось с ростом базы. | |
149
- 10.08.2012 - 16:25
|
2(148) Т.е. у тебя поиск номенклатуры осуществляется сразу после клацанья сканером? На каждый клац? А ищешь по индексированному полю? У меня сперва наклацывали промежуточную таблицу в накладной, а потом всю скопом обрабатывали, или по частям, как настроено пользователем было. | |
150
- 10.08.2012 - 16:26
| +(149) А поиск случаем не через запрос с условием LIKE? | |
151
- 10.08.2012 - 16:28
|
149-bma1 > Сразу после клацанья. Поле ШтрихКод - индексированное. У меня сперва наклацывали промежуточную таблицу в накладной, а потом А как определяешь момент возникновения "потом"? | |
152
- 10.08.2012 - 16:31
|
150-bma1 > Нет, конечно. Запрос = Новый Запрос( "ВЫБРАТЬ | спрНоменклатура.Ссылка Товар |ИЗ | Справочник.Номенклатура спрНоменклатура |ГДЕ | спрНоменклатура.ШтрихКод = &Штрихкод"); Запрос.УстановитьПараметр("Штрихкод", Штрихкод); РезультатЗапроса = Запрос.Выполнить(); | |
153
- 10.08.2012 - 16:31
| 2(151) Либо сканирование специальной бирки со словом "ENDSCAN", либо закрытием формы с таблицей нащелканных штрих-кодов, либо нажатием пользователем кнопика "Обработать без закрытия". | |
154
- 10.08.2012 - 16:32
| 153-bma1 > Понятно. В условиях розницы - не самый лучший вариант, к сожалению... | |
155
- 10.08.2012 - 16:33
| 2(152) ты запрос каждый раз создаешь заново? А в накладной проверяешь на наличие уже этого штрихкода ранее введенного? | |
156
- 10.08.2012 - 16:34
| 2(154) отчего же? Или тебе сразу надо видеть, что отсканировали и цену? | |
157
- 10.08.2012 - 16:36
|
155-bma1 >ты запрос каждый раз создаешь заново? Модуль РаботаСТорговымОборудованием дернут из типовой розницы. Чуть подрихтован под новые для него реалии и всё. Делалось в диком темпе перед открытием первого магазина. Сейчас смотрю на него и волосы дыбом встают - там выкашивать не перевыкашивать... А в накладной проверяешь на наличие уже этого штрихкода ранее введенного? Нет, сначала лезу товар найти, а потом - его наличие в документе. проблем-то раньше не было. Вот и не оптимизировалось никак... | |
158
- 10.08.2012 - 16:38
| 156-bma1 > Конечно сразу. Если это чек - покупатель должен в любой момент текущую сумму знать. Приходная накладная - надо сразу цены-количества сверять с документами поставщика. | |
159
- 10.08.2012 - 16:42
|
2(158) И цена небось в периодическом регистре сведений... Создай регистр текущих цен, непериодический и обновляй его по утрам или при проведении установок цен. Ускорит работу значительно. | |
160
- 10.08.2012 - 16:43
|
159-bma1 > Стоп. Цена-то здесь при чем? первый "клац" отрабатывается нормально. Функция СШКНоменклатура(Номенклатура, Количество) Экспорт СтрокаДокумента = Товары.Найти(Номенклатура, "Товар"); Если СтрокаДокумента = Неопределено Тогда СтрокаДокумента = Товары.Добавить(); СтрокаДокумента.Товар = Номенклатура; СтрокаДокумента.Количество = 1; СтрокаДокумента.Цена = Ценообразование.Цена(Номенклатура, КатегорияЦен, Дата); Иначе СтрокаДокумента.Количество = СтрокаДокумента.Количество + 1; КонецЕсли; СтрокаДокумента.Сумма = СтрокаДокумента.Количество * СтрокаДокумента.Цена; ЭлементыФормы.Товары.ТекущаяСтрока = СтрокаДокумента; Возврат Истина; КонецФункции | |
| Интернет-форум Краснодарского края и Краснодара |