| 0
- 05.08.2012 - 19:47
|
Штатным методом не получается - не загружаются в УТ поступление тмц, комплектация, оприходование и списание. Все заявки (неподтвержденые и обычные) загрузились как просто заявки на склад. В файл обмена выгружаются все документы. А вот УТ их режет. В чём может быть причина? Что посмотреть/сравнить? Подскажите, пожалуйста, кто сталкивался. )     | | |
| 161
- 10.08.2012 - 16:44
|
148-Sadovnikov >"Проявилось с ростом базы." любопытно, сколько товаров в базе, сколько документов/строк? | | |
| 162
- 10.08.2012 - 16:44
| И еще, посмотри что у тебя творится при поиске строки в документе, что проиходит при нахождении дубля, нет ли повторного обращения к расчету цен, сумм, ндс и т.п. как если бы это была совершенно новая, незаполненная строка. | | |
| 163
- 10.08.2012 - 16:45
|
Ценообразование.Цена(Номенклатура, КатегорияЦен, Дата); Медленная функция будет... | | |
| 164
- 10.08.2012 - 16:49
|
161-Маус > Товаров - около 3000 всего... Документов - несколько сотен приходных накладных, пара десятков тысяч чеков. Ну и остального понемногу. 162-bma1 > Я там выше код выложил. 163-bma1 > Ну да. Скоростью блистать не должна. Но отрабатывает только на первой штучке товара. А мы теряем последующие. | | |
| 165
- 10.08.2012 - 16:51
| 2(164) Потому что в накладной не держите штрих-код. Ищите сразу дубли строк по щтрих-коду, без поиска номенклатуры. | | |
| 166
- 10.08.2012 - 16:54
|
165-bma1> Согласен, стоит попробовать. Когда рисовал базу - был уверен, что восьмерка по индексу с охренительной селективностью должна просто со свистом искать. | | |
| 167
- 10.08.2012 - 16:56
| 2(166) у меня 38000 позиций. Ищет практически мгновенно. | | |
| 168
- 10.08.2012 - 20:01
|
Розница 2.0, около 40 тысяч позиций, комп - на intel atom нет проблем с производительностью | | |
| 169
- 10.08.2012 - 20:18
| (166) Не, не стоит. Просто вытащи функцию поиска товара по штрихкоду в общий модуль с повторным использованием значений. Хотя ИМХО дело все равно не в поиске номенклатуры, замер надоть. Кстати приходные накладные начинают тупить с первого сканирования или нет? | | |
| 170
- 10.08.2012 - 21:11
|
я за вами слежу. и записываю. попутное имхо - должно быть сделано так, чтобы во врем яОПЕРАТИВНОЙ РРАБОТЫ - ничего не вычислялось. ничего не анализировалось. а дергалось уже готовое. | | |
| 171
- 11.08.2012 - 01:32
| вот теоретики. зашпыняли садовникова. нет бы выложили оптимальный по быстродействию код, а там бы уже и сравнили кто в чём прав. | | |
| 172
- 11.08.2012 - 11:02
| там структура данных неоптимальная, на мой взгляд. надо добавить как минимум один реквизит в регистр. а потом уже писать код. | | |
| 173
- 11.08.2012 - 14:15
|
167-bma1 > Вот так и должно быть. Сегодня планирую базу помучать маленько и погледеть в чем затыки. Я тоже не особо верю, что именно в поиске по штрихкоду - уж больно малые объемы информации в базе. 168-Управление торговлей 11 > Вот извини, но твоим уверениям что со скоростью все хорошо я поверю в последнюю очередь. Уж больно разные у нас понятия о приемлимом быстродействии. 170-Чучундер > Поясни? Точнее, покажи, что именно в моей конфиге считаешь неверным в этом плане? 171-Зелёный тролль > Да, вроде, не зашпыняли :) Нормальное обсуждение идет. 172-Пудель > Имеешь в виду регистр Подажи или что-то другое? | | |
| 174
- 11.08.2012 - 15:19
|
(173) если это розница с высокой интесивностью - то блин все должно работать просто - жмакнули сканером, нашли обект по штрихкоду, из карточки выдрали требуемые данные. нахрен никаких регистров с данным и, никаких подчиненных справочников, периодики, расчетов и прочей хрени. Регламентным заданием раз в сутки на сегодня прописали требуемые данные и вперед.. . но я не спец, так что на мое мнение ориентироваться вряд ли стоит. | | |
| 175
- 11.08.2012 - 15:42
|
2(174) ты прав, хотя с "регламентным заданием раз в сутки" погорячился, чуток почаще надо. P.S. Я видел на днях понравившуюся мне реализацию, где был регистр сведений со штрих-кодом, текущими остатками (в регистре присутствовали только те позиции, что были на остатке), ценой и ссылкой на справочник номенклатуры. Так как в той конторе справочник номенклатуры был за 250000 позиций, из которых на складе реально пристуствовало позиций 10000 - это давало существенный прирост скорости поиска. | | |
| 176
- 11.08.2012 - 17:49
|
(175) возмолжно, тут от специфики наверное зависит. единственное, что врознице любят всякие развесистемые схемы дискацнтов всяких... . ну и глубоко укоренившееся во мне мнение - универсальные решени - зло. Хочешь чтобыбыло хорошо - делай спецрешение. . ну а садовников, я думаю, порвет всех, как только поймет/выяснит чт о и где и как 1с ведет себя неправильно... ;-) | | |
| 177
- 11.08.2012 - 21:04
| (176) Ну пока себя неправильно ведет Садовников. Снеговика все-таки нужно готовить по методичкам от 1С, а не пытаться угадать поведение СУБД. Отчеты тормозят только из-за того, что структура данных спроектирована по классической теории БД, без оглядки на 1С. А по штрихкодам нужен замер - без него гадание на кофейной гуще. ИМХО там тоже какая-то не слишком трудноразрешимая лажа. | | |
| 178
- 12.08.2012 - 00:02
|
(173) Я уже подзабыл какие там регистры в отчёте, примерно так: 1. в одном месте условие по типу регистратора - я бы переделал на индексированный реквизит или даже измерение, и вообще ситуация, когда мы отбираем по типу регистратора - ненормальна с методической точки зрения. 2. плюс вполне возможно, что реквизит номенклатуры, по которому отбор, лучше будет смотреться не в справочнике, а регистре/регистрах накопления допреквизитом, 3. а также подумать, для того же реквизита не будет ли быстрее работать регистр сведений. | | |
| 179
- 12.08.2012 - 11:17
|
177-Reaper >178-Пудель > 1С умудрилась нарисовать систему, попирающую законы построения БД? 178-Пудель >2 и 3 не понял. Поясни? | | |
| 180
- 12.08.2012 - 11:20
|
174-Чучундер > Не высокая интенсивность этой розницы. Совсем невысокая. Именно по этому еще и не дошли руки до нормальной оптимизации. И тормоза, как я неоднократно писал выше, совсем не в розничном куске. 175-bma1 >(в регистре присутствовали только те позиции, что были на остатке - а как там поступали в ситуации, если покупатель притащил на кассу товар, которого нет на остатках? | | |
| 181
- 12.08.2012 - 11:55
|
Для настаивающих на том, что в регистр Продажи необходимо запихать движения расходных накладных и доп измерение, говорящее о том, это была именно расходная накладная. Вот количества документов в базе (чеков и расходных накладных): ЧекККМ 25 720 РасходнаяНакладная 552 В 95% случаев по этому регистру анализируются именно продажи по чекам. Абсолютно не вижу смысла делать так, что бы расходная писала в регистр Продажи... | | |
| 182
- 12.08.2012 - 12:08
| (181) Я тебе уже накидал вариантов и с измерением и с отдельными ресурсами. Ты хоть что-то попробовал? Или теоретизировать интереснее? | | |
| 183
- 12.08.2012 - 12:12
|
182-Reaper > Каюсь - нифига не делал. Вчера планировал поэкспериментировать, но пришлось срочно в магазин ехать... Я ж говорю - еще не прижало так, что бы всё бросать и срочно увеличивать скорость работы. | | |
| 184
- 12.08.2012 - 12:13
| 182-Reaper > Кстати, а ты чего в выходной день на форуме зависаешь? | | |
| 185
- 12.08.2012 - 12:51
|
(181) учитывая это, лучше убрать в запросе обращение к движениям регистра остатков, переписать на выборку по документам. размер таблицы РН меньше таблицы движений остатков на два порядка. методически это порнография, но в данном конкретном случае тормозить должно меньше, чем обращение к регистру остатков. (179) -> (182) :) | | |
| 186
- 12.08.2012 - 12:55
|
185-Пудель > Вот с этим предложением согласен. "методически это порнография" - идут лесом методологи, непонимающие, что и регистр и табличная часть документа - это таблицы. | | |
| 187
- 12.08.2012 - 14:19
| (186) вот это меня тоже всегда настораживало... обосновывали тем что де регистры оптимизированы типа... правда что там принципиально автоматизировать...? | | |
| 188
- 12.08.2012 - 14:46
| в базах данных всё - таблицы | | |
| 189
- 12.08.2012 - 14:50
|
187-Чучундер > Вот-вот-вот... В 7.7 еще можно было как-то обосновать возможностью индексы на регистры наставить. В ограниченных пределах, конечно же. В восьмерке же большую часть индексов отдали на откуп прогеру. 188-Маус > Расскажи это методологам от 1С... | | |
| 190
- 12.08.2012 - 15:19
| 184-Sadovnikov > У меня в течении следующей недели должна взлететь первая туча из грозового фронта. Да, да, именно так. Это у маркетологов "облака", а когда в этой каше варишься - имеешь грозовой фронт с толпой туч, каждая из которых норовит тебе молнию выслать. 2 недели без выходных, эта вот третья будет. Молюсь, чтоб хотя бы следующие выходные отдохнуть... А на форум выглядываю, пока у меня интеграции гоняются, или тяжелые алгоритмы пашут. | | |
| 191
- 12.08.2012 - 16:04
| 190-Reaper > Та же фигня... Сижу, ваяю обмен с "горячо любимым" МосПивом. Пока сохраняется, тыкаю "Обновить" на форуме... | | |
| 192
- 12.08.2012 - 16:19
| Цитата:
| | |
| 193
- 12.08.2012 - 16:31
| 192-bma1> То есть, товар отбирается у покупателя и откладывается в сторону до окончания разборок? | | |
| 194
- 12.08.2012 - 17:26
|
2(193) А как иначе? Представь себе, что ты владелец, к примеру, продуктового магазина. Покупатель приносит на кассу тот товар, кторого по базе быть не должно. Ты пробиваещь чек и сидишь ждешь, когда этот покупатель по этому чеку подаст в суд, например за просроченный товар (ты же не можешь гарантировать ничего, продав тот товар, которого у тебя быть не должно), может покупатель специально пронес в магазин этот товар, чтоб тебя подставить. В том магазине продают запчасти, и если будет разборка, откуда у покупателя на руках взялась бракованная или поддельная деталь - магазину серьезно не повезет. | | |
| 195
- 12.08.2012 - 22:53
| Главное не чтобы товар не пронесли просроченный, а главное чтоб покупателя не пронесло | | |
| 196
- 13.08.2012 - 07:51
|
194-bma1 > У меня немного по другому. При продаже не анализируются остатки. Однако, ежемесячная инвентаризация, плюс постоянные проверки сроков годности. Шанс нарваться на просрочку (тьфу-тьфу-тьфу) - минимальный. По этому исходил из принципа, что если покупатель притаранил к кассе товар, то он его купит. | |
Интернет-форум Краснодарского края и Краснодара |
