Вход | Регистрация

  1  2   
1С:Предприятие :: 1С:Предприятие 8 общая

v8: Замена регистра накопления регистром сведений, минус к производительности?

v8: Замена регистра накопления регистром сведений, минус к производительности?
Я
   etc
 
28.12.12 - 19:20
На сколько я знаю многие WMS на базе 1С уходят от регистров накопления в сторону регистров сведений. И в принципе это логично поскольку например хранить резервы в регистре остатков особого смысла нет. История по движениям с резервами как правило никому не нужна. Есть срез на текущий момент и всё. Минусы которые я вижу это необходимость траты ресурсов на группировку записей, лишаемся таблицы итогов что явно не ускорит поиск записей, хотя учитывая что есть индексы и общее количество записей будет не велико может расходы и минимальны. Но наибольшие непонятки как это ударит производительности при записи наборов при увеличении количества пользователей?
 
 
   etc
 
1 - 28.12.12 - 19:22
Акселотовцы на сколько я знаю в свое время ушли на Регистры сведений. Как там у них сейчас дела в последних версиях?
   kiruha
 
2 - 28.12.12 - 19:23
В 8.3 к регистру сведений добавят таблицу "итогов"
так что опаздал
   etc
 
3 - 28.12.12 - 19:24
(2) а смысл? Или там можно будет сразу задать по каким измерениям сворачивать?
   Fragster
 
4 - 28.12.12 - 19:26
если неправильно сделать структуру регистра - то будет долго производится запись-обновление.

у нас используется это дикое извращение от того, что РН перестал помещаться в файловые базы (итоги), и предыдущий программист сделал РН оборотами. Остатки считались оборотами за весь период. Пришлось эмулировать таблицу текущих итогов на РС, вместо того, чтобы в свое время отключить итоги месячные, и оставить только текущие.
   kiruha
 
5 - 28.12.12 - 19:26
(3)
Это к 1С
Смысл - более оптимальное получение результата
На данный момент рег сведений - это просто таблица с наборами индексов.
   kiruha
 
6 - 28.12.12 - 19:29
http://v8.1c.ru/overview/release_8_3_1/
>>
В регистрах сведений реализовано хранение итогов, за счет чего ускорено получение среза первых и среза последних регистра сведений,
<<

Полюбасу тема уже из за этого смысла не имеет
   etc
 
7 - 28.12.12 - 19:31
(6) это для периодических регистров. Там конечно смысл есть. Но для даных такого типа когда тебе история изменений не нужна периодический регистр тоже не нужен. Нужна тупо таблица со срезом на тек. момент.
   etc
 
8 - 28.12.12 - 19:33
Представь что тебе в принципе не нужны остатки на вчера. Только на "сейчас". А нужен ли тогда регистр накоплений?
   Steel_Wheel
 
9 - 28.12.12 - 19:35
(1) У них дела хорошо. Тема к чему создана?
   etc
 
10 - 28.12.12 - 19:35
Если посмотреть на WMS-ки которые не 1С то у них в принципе нет возможности правки задним числом. Хочешь исправить остаток - делай коррекцию. Да в журнале(логе) появится что тогда-то была сделана следующая операция. Но поправить её открыв "документ" нельзя.
 
 Рекламное место пустует
   kiruha
 
11 - 28.12.12 - 19:36
(8)
А где ты будешь хранить остатки на сейчас ?
И что будет если вдруг оператор ошибся ?

И что будет если в рег сведений будет млн записей
и вдруг понадобится результат плохо укладывающийся в индекс - полный скан таблицы ?

Вообще уже проходили еще в 7.7 - многие умельцы актуальные остатки на справочниках держали. Потом появилось 1С++ и как то это все ушло
   etc
 
12 - 28.12.12 - 19:36
(9) мнение интересно тех кто заморачивался.
   Steel_Wheel
 
13 - 28.12.12 - 19:37
(11) Как раз все будет хорошо. РС независимы, каждая запись атомарна. А что ты будешь делать с РН?
   Steel_Wheel
 
14 - 28.12.12 - 19:37
(12) Я заморачивался. Или ты хотешь до арзитектора решения Акселота достучаться?
   Fragster
 
15 - 28.12.12 - 19:38
(13) не всегда
   Steel_Wheel
 
16 - 28.12.12 - 19:38
Кстати, могу подсказать как
   etc
 
17 - 28.12.12 - 19:39
(11) РС и есть остатки на сейчас. Миллион записей - да. Но с другой стороны в итоговой таблице РН их было бы столько же.
   Steel_Wheel
 
18 - 28.12.12 - 19:39
(15) Эхххх. Нюансы всегда были есть и будут.
Никто никогда не раскроет рецепт коронного блюда, могут лишь подсказать ингридиенты и примерный принцип изготовления
   etc
 
19 - 28.12.12 - 19:40
(14) мне достаточно что ты заморачивался :)
   Steel_Wheel
 
20 - 28.12.12 - 19:40
(19) Тогда спрашивай. Что помню -- подскажу
   etc
 
21 - 28.12.12 - 19:41
(20) производительность при записи сильно падает? Даже субьективно?
   etc
 
22 - 28.12.12 - 19:42
(21)+ просто РС он же сначала DELETE делает а потом INSERT.
   etc
 
23 - 28.12.12 - 19:44
На РН я так понимаю DELETE только при перепроведении.
   Steel_Wheel
 
24 - 28.12.12 - 19:47
(21) Тут не в том дело. Дело в том, что "складская накладная" имеет несколько десятков сотен строк. Когда запись идет в РН, то она идет одной транзакцией. В то время, как запись в РС проводиться по каждой строке: т.е. транзакция идет на каждую строку, все это делается не в проведении, а в записи. Т.е. если мы не смогли провести 1 строку из 3000, мы не откатываем весь документ, мы одной строке ставим неуспешный статус.
Т.е. процесс проведения максимально выведен из-под платформы

Хотя, тут есть вопрос: о какой Логистике идет речь. Я прримерно про 3-ю рассказываю. 2-ая работает на типовом механизме проведения
   Steel_Wheel
 
25 - 28.12.12 - 19:53
Тут вопрос в невозможности записать тразакцию из 20 000 записей, если 1 из них не валидна. ПОтому и РС
   etc
 
26 - 28.12.12 - 19:56
(24) "мы не откатываем весь документ, мы одной строке ставим неуспешный статус"
Не совсем понимаю как так, ну да ладно. Видимо еще не дозрел.
Но в общем проблематика понятна, спасибо за наводку.
   Steel_Wheel
 
27 - 28.12.12 - 20:00
(26) Объясню: если ты ставишь Статус = Отказ при проведении доумента, который делает движения по РН, то у тебя ВСЕ движения откатываются.
Алгоритм расчета размещений долог. Т.е. ты ждал 4 часа, чтобы узнать, что у тебя все зафейлилось. Это неприемлемо.
Сейчас алгоритм проверяет (валидирует) каждую строку документа и записывает в документ (например "Приемка") статус строки "Ок", "Не ОК", "Еще что-то". За счет того, что у нас РС, то строки "Не ОК" не требуют отката строк "ОК". Но при перепароведении документа, ты должен чистить РС по регистратору (а "Регистратор" -- это пользовательское измерение в этом случае, а не системное)
   Fragster
 
28 - 28.12.12 - 20:01
(27) скока-скока у вас проведение документа занимает?
   Fragster
 
29 - 28.12.12 - 20:03
овер100к строк с контролем остатков (кстати, на том самом РС) проводится менее 3 минут
   Fragster
 
30 - 28.12.12 - 20:03
(29)+ в худшем случае
   Steel_Wheel
 
31 - 28.12.12 - 20:05
(29) А на РН?
   kiruha
 
32 - 28.12.12 - 20:05
Рн конечно не оптимальны.
На данный момент, то что читал по теории- самое оптимальное - сеть из узлов, где каждый узел сети хранит "свои" остатки и другие данные и отрабатывает запросы независимо от других узлов.
В случае уменьшения количества остатка на узле - данные перераспределяются по соседним узлам, или сливаются в один узел
Запросы "юзерам" по разным узлам запрещены(  точнее данные периодически сливаются в "общую" базу, с которой работают только аналитики)
wiki:BigTable
   Steel_Wheel
 
33 - 28.12.12 - 20:07
+31 Тут смысл в том, что "история" начинает тормозить после определенного периода. А она совсе-совсем ненужна. Мы решаем задачу Опертивного Остатка, а не того, как он образовался

Любой пример можно сделать абсурдным
 
 
   Steel_Wheel
 
34 - 28.12.12 - 20:08
ПыСы, я не сотрудник Акселота, я просто сталкивался с их решением. Моя трактовка этого решения -- это всего лишь моя трактовка.
Но я в нем вижу рациональное зерно. А может, лекторы Акселота донесли
   Fragster
 
35 - 28.12.12 - 20:08
(31) у нас нет >100к строк по РН с итогами. по РС - там не только РС, там еще + обороты по РН при проведении задним числом
   etc
 
36 - 28.12.12 - 20:11
(27) во, перепроведение. Это видимо из за привязки всех записей к одному родительскому документу (приемка, размещение). А нужно ли оно? Если брать размещение то да, время на расчет "куда что" наибольшее, но это зависит от сложности алгоритма. Перепроведение на мой взгляд как понятие тут вообще лишнее. Полюбому алгоритм будет работать с квантами данных (отдельными товарами) и если че-то где-то сбойнуло при записи то останется незаписанным то что неразмещено. Доформируют.
   etc
 
37 - 28.12.12 - 20:15
Я наверно просто пытаюсь натянуть на 1С логику работы с данными чуждую для 1С. Вот и бродят мысли всякие.
   etc
 
38 - 28.12.12 - 20:20
кстати если сталкивались, какой потолок по пользователям в Акселоте по терминалам когда начинают лезть блокировки/тормозить?
   Злопчинский
 
39 - 28.12.12 - 20:43
> На данный момент рег сведений - это просто таблица с наборами индексов
- чем это отличается от справочника?
   exwill
 
40 - 28.12.12 - 20:48
(39) В справочнике нельзя указать составной уникальный ключ.
   Злопчинский
 
41 - 28.12.12 - 20:48
(36) какое "перепроведение" для реальных складских сотатков? Провелось 1 раз (то есть разместилось) - все, капец. Никакое перепровдение не может изменить уже свершившийся и зафиксированный факт. такое мое мнение.
   Steel_Wheel
 
42 - 28.12.12 - 20:50
(36) Не, смысл в атомарности транзакции (которую вряд ли можно обеспечить при работе с РН) и истории, которая не нужна в системе оперативного учета (и от которой РН отвязать нельзя)
   Steel_Wheel
 
43 - 28.12.12 - 20:51
(41) 9999 строк разместилось, 1 нет.
Как прогорамма должна реагировать?
   Злопчинский
 
44 - 28.12.12 - 20:52
(38) возможность тормозить только тогда, когда что-то хватается надолго. если в "регистр" писать атомарные операции то они, по идее, будут выполняться практически мгновенно. и возможно даже можно поставить тупо три-пять попыток. если одна "запись" делается в районе 0.001 сек, то можно в случае блокировки и 5 раз попробовать.. и даже 10.. (если это интерактивная работа через терминалы).
.
у меня работает куча терминалов, но под своей простой самопиской 7.7. блокировок - нет. Вернее, они есть - но там, где мне было влом думать ;-) - и они настолько редкие что хз.. когда дни там бывают...
   Злопчинский
 
45 - 28.12.12 - 20:53
(43) считается ПЛАН размещения?
мое простое мнение - 9999 строк зафикисровать как успешные, 1 строку поставить в очередь на очередное планирование.
   Рэйв
 
46 - 28.12.12 - 20:53
(0)>>История по движениям с резервами как правило никому не нужна.

Что за бред?

Проведение задним числом пока никто не отменял.  Так что ты подумай еще раз над тем, что ты сказал.
   Fragster
 
47 - 28.12.12 - 20:57
(42) атомарность - это немного другое
   Рэйв
 
48 - 28.12.12 - 20:57
(40)Да запросто. ЗначениеВСтрокуВнутр из скольки хочешь сущностей.
   Рэйв
 
49 - 28.12.12 - 20:58
Ключ=ЗначениеВСтрокуВнутр(чтото1)+ЗначениеВСтрокуВнутр(чтото2)+ЗначениеВСтрокуВнутр(чтото3)
 
 Рекламное место пустует
   Злопчинский
 
50 - 28.12.12 - 20:58
(46) все правильно сказал. В ряде случаев ИСТОРИЯ резервов - не волнует. волнует состояние РЕЗЕРВА на сейчас. и правится состояние резерва ВСЕГДА сейчас. Поэтому при проведении задним числом - РЕЗЕРВЫ ОСТАВЛЯЕМ КАК БЫЛО. У меня так и сделано - при проведении задним числом состояние заявок, резервов - не анализируется и не меняется. если в результате проведеняи задним числом ПО ОСТАТКАМ - что -то вылезер "криво" - это сразу же всплывет НА САЙЧАС. СЕЙЧАС и будет правиться.
   pavlov
 
51 - 28.12.12 - 20:58
несколько вопросов напрашиваются:
зачем для wms контроль остатков ?
зачем для wms План размещения ?
   Steel_Wheel
 
52 - 28.12.12 - 20:59
(45) В Логистике так и сделано. Но как это с РН сделать? С РС легко и просто и не надо взрывать мозг
(47) А ведь она непосредственно влияет на производительность. Почему это другое. Это просто обратная сторона медали. Хочешь производительности на "больших данных", давай "атомарность данных" реализуй. Или я не прав?
   Александр_Тверь
 
53 - 28.12.12 - 20:59
(46) а я тебе ответственно заявляюсь, что бред несешь ты.
Размещение задним числом не нужно!
В минус забрать с ячейки - невозможно!

Реально интересен только текущее количество.
Всякая там аналитика, движения товара и т.д. это не задача WMS.
   Рэйв
 
54 - 28.12.12 - 20:59
(50)Да геморно все это:-)
   Steel_Wheel
 
55 - 28.12.12 - 20:59
(51) контроль остатков нужен, чтобы не отгрузили того, что нет
   Злопчинский
 
56 - 28.12.12 - 21:00
особенно, например, в тисе радоволо: стоит документ снятие резерва, = 100штук товара снять срезерва. в один прекрасный момент при восстановлении ГП - документ не проводится, потому что на резерве висит 99 штук и снять 100 ну никак нет возможности. Пришлось тупо переделать - снимать столько сколько есть. сразу жить стало легче.
   vde69
 
57 - 28.12.12 - 21:00
вообще странная тема...

у меня вопросы
1. ЗАЧЕМ ???
2. Как быть с единообразием и общими нотациями
3. Чего нельзя реализовать на регистре остатков того что есть на РС
   Steel_Wheel
 
58 - 28.12.12 - 21:00
(54) Все решаемо. Просто нужно отвязаться от РН. С РС все просто
   Рэйв
 
59 - 28.12.12 - 21:01
(53)я конечно понимаю, что идеален вариант желателен:-)_

но когда храниит ся текущзее состояние того же резерва на сегодня, а проводят документ за месяц назад , когда он был в 100 раз больше по позиции.. а отнимится то от остатков  текущий, не так ли?
   Steel_Wheel
 
60 - 28.12.12 - 21:01
Народ, в все понимают, что KIS и WMS -- это две разные системы со своими задачами?
   pavlov
 
61 - 28.12.12 - 21:01
(55) если покупатель поднес к кассе товар, которого нет в остатках, то он его не получит ?
   Злопчинский
 
62 - 28.12.12 - 21:02
(51) мое мнение - нужен только контроль остатков НА СЕЙЧАС (ну чтобы тупо не выдать/выпрлнить количества больше чем есть на остатке ;-). все операции на складе проводить только реальным временем.
   Steel_Wheel
 
63 - 28.12.12 - 21:03
(62) плюсую. Остальное в этом разрезе управления не интересно
   Steel_Wheel
 
64 - 28.12.12 - 21:04
(61) Он его получит.
Но потом борльших киздюлей получит работник на складе.
Это искуственное ограничение. Спайс должен поступать
   Александр_Тверь
 
65 - 28.12.12 - 21:04
(63) тоже его плюсую, у меня уже 3 года так работают. Все отлично все довольны.
   Рэйв
 
66 - 28.12.12 - 21:04
(62)я всегда убеждаю бухов все править текущим периодом ...Ты сам пробовал их в этом убедить?...Непробиваемо:-)
Хотим задним числом и все.
   pavlov
 
67 - 28.12.12 - 21:04
(62) т.е. чел с тсд пикает товар, а программа говорит пнх, товара нет в ячейке (например из-за косяка предыдущего оратора)
   Злопчинский
 
68 - 28.12.12 - 21:05
(51) с планом размещения - тут у меня такое соображение - с точки зрения эффективного использования склада - мне желательно полпаллеты запихнуть не в пустую ячейкук, а вту ячейку где лежит такие же полпалеты...
.
в принципе, у меян сейчас за счет наличия запаса ячеек никакого плана размещения не строится - товар размещается в ячейку хранения ближайшую к ячейке отбора.
.
но в сложных (общих) случаях - такое не прокатит..? размещение будет неэффективным - что выльется ПОТОм в скорость работы...?
   Александр_Тверь
 
69 - 28.12.12 - 21:05
(66) ты путаешь бухгалтерский учет и складской учет.
   Steel_Wheel
 
70 - 28.12.12 - 21:05
Кстати, есть же документы "Корректировки". Почему их не может быть в актуальном решении. Все зависит от области допустимых значений
   Рэйв
 
71 - 28.12.12 - 21:06
(69) Ну логистиков..один хрен они все для меня бухи.
   Рэйв
 
72 - 28.12.12 - 21:07
буду я еще их делить на отряды и подвилы:-))
   Steel_Wheel
 
73 - 28.12.12 - 21:07
(66) Ты путаешь упр. и бух. учет
Упр. учет нельзя править -- он просто есть. И он такой, как он есть. Это есть сама компания
Бух. учет -- это хоз опреации компании в формальном виде. Конечно, правок быть не должно. Но если они есть, их надо согласовать с глав. бухом. Ему же потом отдуваться
   pavlov
 
74 - 28.12.12 - 21:08
(68) недалекая глупость заранее городить План размещения, адрес для конкретной паллеты должен определяться в момент ее телепортации. за счет встречного движения (приход-расход) экономится много ячеек.
   Рэйв
 
75 - 28.12.12 - 21:09
(73)еще как можно править. Так как данные в него идут как раз в из бух базы с обменом.Только там внтри интрепретируются и дополняются по упровски
   Fragster
 
76 - 28.12.12 - 21:09
   Steel_Wheel
 
77 - 28.12.12 - 21:09
(67) Нет, в РС "Большие киздюли" будет сделана запись того, что подне  сканнер. Все хорошо
   Злопчинский
 
78 - 28.12.12 - 21:10
(66) буховские хотелки и оперативная работа - это немного разные вещи...
.
например - сделан вычерк в накладной при сдаче нашим экспедитором (хотя по всем регламентам товар прошел)
.
бух хочет вычеркнуть товар из расходной накладной - да заради бога. только это вычерк не меняет состояния остатков. Состояние остатков меняет факт приема товара на склад СЕЙЧАС от экспедитора. Или есть другой вариант решения...
.
но могут быть проблемы...
.
мне вот дофигища не нравится разнесение ВЭЭМЭС в отдельную систему. у себя прикрутил к общей базе продажников. Все равно - участик в подавляющем колве случаве не пересекаются там гд кончил работу продажник - началась работа вээмэс.
.
все прблемы начинаются в блин пиипец тяжелых случаях... но жосткое следование вээмэс не дает им вылезти...
   Александр_Тверь
 
79 - 28.12.12 - 21:10
(71) я не понимаю тебя.
Причем исправление документа задним числом и остатки в конкретных ячейках?

От того, что документ изменили, что-то физически изменилось в ячейках? Товар появился или исчез?
   Steel_Wheel
 
80 - 28.12.12 - 21:11
(75) Погоди, т.е. ты скажешь:
"А давайте в этой накладной мы изменим склад поступления, и номенклатура тут дорлжна быть другой: вот вы 100 привезли, а мы приняли 95"?
Так что-ли или что ты имеешь в виду?
   Злопчинский
 
81 - 28.12.12 - 21:11
(67) все зависит от частностей, хитрый какой.. ;-)
если система направила сборщика к ячейке и он там нашел нужный товар - то по барабану все ошибки всех предыдущих (описано упрощенно!)
   Рэйв
 
82 - 28.12.12 - 21:12
(78)Как это не меняет остатков?  Если клиент не принял товар, ты хочешь сказать на всю эту хренб они будут делать официальные возвраты??...Окстись. Они просто подправят расходную как будто так было с самого начала. Не с нашими объемами еще и врозвраты городить..и так обмен уже еле дышит
   Steel_Wheel
 
83 - 28.12.12 - 21:12
Блин, народ, вы все путаете
   Александр_Тверь
 
84 - 28.12.12 - 21:15
(82) еще раз, ты путаешь складской и бухгалтерский учет.
У меня, к примеру, списание товара с ячеек происходит ОБРАБОТКОЙ. отдельной. Которая получает ТЕКУЩИЕ данные по документу и оформляет выдачу (в несколько этапов). Если что-то изменить задним числом, как например в твоем случае, то просто делают размещение товара по ячейкам.
т.е. документ исправили задним числом, а непосредственно товар здесь и сейчас разместили куда-то. Причем не факт что туда где взяли
   pavlov
 
85 - 28.12.12 - 21:16
(83) всегда интересно было - за какое время wms создаст задания на ручную комплектовку заказа из 100 строк ?
   Steel_Wheel
 
86 - 28.12.12 - 21:16
Задача WMS -- дать текущий остаток на складе, желательно по ячейкам (а ячейки эти у вас есть физически)?
Задача KIS -- свести показатели всех составляюих систем воедино, сделать приемлемую отчетность
   Александр_Тверь
 
87 - 28.12.12 - 21:17
(85) ты про то чтобы подобрать товар из ячеек и выдать на сбор? миллисекунды
   Злопчинский
 
88 - 28.12.12 - 21:18
(74) не возражаю! все зависит от частностей и возможностей.
разместить одн упаллету - это не ворпрос. разместить 10 паллет так, чтобы размещение 100 следующих палет было оптимальным - уже гораздо интереснее. Но у себя с такой необходимостью - не свтречался.
.
если делать мегапоуму, то должно считаться квазиоптимальное размещениевсех имеющихся на данный момент паллет по критерию минимизации какого-то показателя (например минимизация среднего времени сборки заказов за месяц).
.
но зачастую такая оптимизация ненужна...
   Fragster
 
89 - 28.12.12 - 21:18
(85) намного интереснее задача оптимальной раскладки по ячейкам в соответствии с правилами и фрагментацией
   Steel_Wheel
 
90 - 28.12.12 - 21:19
(85) Как обычно, все нюансы не раскрыты:
- в заказ входят разные детали?
- у деталей как там с комплектацией/разупаковкой?
- есть ли требования к самим заказам

Это только с первого взгляда
   Злопчинский
 
91 - 28.12.12 - 21:19
(82) да не вопрос - подправляйте! только в какой ячейке лежит этот возвращенный товар? вы ведь правите состояние остатков, ане сделанные ране с этим товаром вээмэсные операции.
   pavlov
 
92 - 28.12.12 - 21:19
(87) т.е. от момента поступления заказа из 100 строк через 100 мс готовы задания на сборку 100 товарных позиций ?
   pavlov
 
93 - 28.12.12 - 21:20
(90) в заказе 100 разных товарных позиций, без всяких аналогов и комплектов
   Рэйв
 
94 - 28.12.12 - 21:21
(84)Я вот тут как раз про складской.Ну я не в курсе твоей ситему:-)..Взял бы да выложил описание где-нить -  Хоть в книге знаний чтоли, если уж так хороша система...

Только у меня 47 филиалов в урибе на еле дышущей 77(срочно переводимой мной же на 8.2) с около 50 000 документов в день. в таких условия х сложно диктовать свой порядок. Сам ген дир подумал и встал на их сторону
   Fragster
 
95 - 28.12.12 - 21:21
(92) формирование листа сборки - вещь элементарная
   Steel_Wheel
 
96 - 28.12.12 - 21:21
(93) Производительность в этом случае ограничена регламентом обмена KIS и WMS
   Steel_Wheel
 
97 - 28.12.12 - 21:22
2 цикла, как я вижу
   Злопчинский
 
98 - 28.12.12 - 21:22
(92) а что, если вместо 100мс, задания на отбор будут спланированы через 500 мс - это сильно подломит физического сборщика комплектовщимка..? ;-)
   pavlov
 
99 - 28.12.12 - 21:22
(95) даже элементарные вещи требуют временных затрат - мне интересны оценки тех, кто уже сталкивался с подобным
   Злопчинский
 
100 - 28.12.12 - 21:23
(95) если просто товар отобрать - то совсем просто. если отобрать так, чтобы упаковщик все составные части шкапчика бпосле сборщика быстренько упаковал кучно - немножко сложнее... по всякому бывает..
  1  2   

Список тем форума
Рекламное место пустует  Рекламное место пустует
Независимо от того, куда вы едете — это в гору и против ветра!
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует