[IT-инфраструктура, Управление проектами] Как мы ускоряли время разгрузки товара на складе
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Терминал сбора данных Zebra WT-40 со сканером-кольцом. Нужен для того, чтобы была возможность быстро сканировать товар, при этом укладывать физически короба на паллету (свободные руки).
На протяжении нескольких лет мы очень быстро открывали магазины и росли. Закончилось это тем, что сейчас наши склады принимают и отправляют порядка 20 тысяч паллет в день. Естественно, сегодня у нас уже больше складов: два больших в Москве — 100 и 140 тысяч квадратных метров, но есть и небольшие в других городах.
Каждая сэкономленная секунда в процессах приёмки, сборки или отправки товара в таких масштабах — это возможность сберечь время на операции. А ещё это огромная экономия.
Именно поэтому два главных множителя эффективности — это продуманный алгоритм действий (процесс) и настроенные ИТ-системы. Желательно «как часы», но «работающие чуть менее, чем идеально» тоже вполне подойдёт. Всё же мы в реальном мире.
История началась шесть лет назад, когда мы присмотрелись к тому, как именно поставщики разгружают фуры у нас на складе. Это было настолько нелогично, но привычно, что сотрудники даже не замечали неоптимальности процесса. Более того, в тот момент у нас не было промышленной системы управления складом, и в основном логистические операции мы доверяли 3PL-операторам, которые использовали свой софт и опыт в построении процессов.
Приёмка товара
Как мы уже говорили, наша компания на тот момент (как, в принципе, и сейчас) стремилась открыть много магазинов, поэтому пришлось оптимизировать складские процессы для увеличения пропускной способности (больше товаров за меньшее количество времени). Это непростая задача, и решить её, просто увеличив персонал, было нельзя хотя бы потому, что все эти люди будут друг другу мешать. Таким образом, мы начали думать о внедрении информационной системы WMS (warehouse management system). Как и полагается, мы начали с описания целевых складских процессов и уже в самом начале обнаружили непаханое поле для улучшений в процессе приёмки товара. Нужно было отработать процессы на одном из складов, чтобы потом накатить их на остальные.
Приёмка — это одна из первых больших операций на складе. Она бывает нескольких типов: когда мы просто пересчитываем количество грузовых мест и когда нам необходимо, помимо этого, посчитать, сколько и каких артикулов лежит на каждой паллете. Большая часть товаров у нас проходит по потоку кросс-докинг. Это когда товары приезжают на склад от поставщика, а склад выступает в роли роутера и старается тут же переотправить их на конечного получателя (магазин). Есть и другие потоки, например, когда склад выступает в роли кэша или в роли накопителя (нужно положить поставку в сток, разделить на части и постепенно вывозить в магазины). Наверное, про работу со стоком лучше расскажут мои коллеги, которые занимаются математическими моделями оптимизации остатков. Но тут сюрприз! Проблемы стали возникать чисто на ручных операциях.
Процесс выглядел так: грузовик приезжал, водитель менялся документами с администратором склада, администратор понимал, что там приехало и куда его отправить, потом направлял грузчика забирать товар. Всё это занимало около трёх часов (конечно, во многом время приёмки зависит от того, какой логистический поток мы принимаем: где-то необходимо делать внутритарный пересчёт, а где-то — нет). Большее количество людей на один грузовик направить нельзя: будут друг другу мешать.
Какие были потери? Их было море. Во-первых, работники склада получали бумажные документы. Они ориентировались и принимали решения, что делать с поставкой, по ним. Во-вторых, они считали паллеты вручную и в этих же товарных накладных отмечали количество. Потом заполненные бланки приёмки относились к компьютеру, где данные забивались в XLS-файл. Данные из этого файла затем импортировались в ERP, и только тогда наше ИТ-ядро по факту видело товар. Мы имели очень мало метаданных о заказе вроде времени прибытия транспорта, либо эти данные были неточными.
Первое, что мы сделали, — это начали автоматизировать сами склады так, чтобы у них появилась поддержка процессов (понадобилось поставить кучу софта, железа наподобие мобильных сканеров штрихкодов, развернуть инфраструктуру для всего этого). Потом связали эти системы с ERP через шину. В конечном итоге информация о наличии товара обновляется в системе, когда грузчик проводит сканером штрихкода по паллете на приехавшем грузовике.
Стало так:
- Поставщик сам заполняет данные о том, что отправляет к нам и когда. Для этого есть связка из SWP и EDI-порталов. То есть магазин публикует заказ, а поставщики берутся выполнить заявку и поставить товар в нужном количестве. Они же при отправке товара указывают состав паллет в фуре и всю необходимую информацию логистического характера.
- Когда машина уехала от поставщика к нам, мы уже знаем, какой товар к нам идёт; более того, с поставщиками налажен электронный документооборот, поэтому мы знаем, что УПД уже подписан. Готовится схема оптимального перемещения этого товара: если это кросс-докинг, то мы уже заказали транспорт со склада, рассчитывая на товар, а также для всех логистических потоков мы уже определили, какое количество складских ресурсов нам понадобится для обработки поставок. В деталях для кросс-докинга предварительный план по транспорту со склада делается на более раннем этапе, когда поставщик только зарезервировал слот на поставку в системе управления складскими воротами (YMS — yard management system), которая интегрирована с порталом поставщика. Информация приходит в YMS сразу.
- YMS получает номер грузовика (если быть точнее, то номер отгрузки из SWP) и записывает водителя на приёмку, то есть отводит ему необходимый слот времени. То есть теперь водителю, который приехал вовремя, не нужно ждать живой очереди, а под него отведены его законное время и док разгрузки. Это позволило нам, кроме всего прочего, оптимально распределять грузовики по территории и эффективнее использовать разгрузочные слоты. А ещё, поскольку мы заранее составляем график, кто, куда и когда приедет, то знаем, сколько людей и где нужно. То есть это ещё связано с рабочими графиками сотрудников склада.
- В итоге этой магии грузчики уже не нуждаются в дополнительной маршрутизации, а лишь ожидают машины для их разгрузки. Фактически их инструмент — терминал — говорит им, что делать и когда. На уровне абстракции это как API грузчика, но в human-computer interaction-модели. Момент сканирования первой паллеты с грузовика — это ещё запись метаданных по поставке.
- Разгрузка пока делается всё так же руками, но по каждой паллете грузчик проводит сканером штрихкодов и подтверждает, что данные этикетки в порядке. Система контролирует, чтобы это была правильная паллета, которую мы ожидаем. К концу разгрузки в системе будет точный пересчёт всех грузовых мест. На этой стадии ещё отсеивается брак: если есть явные повреждения транспортной тары, то достаточно просто отметить это в процессе разгрузки или вовсе не принять этот товар, если он совсем негодный.
- Раньше паллеты пересчитывались в зоне разгрузки после того, как все будут выгружены из машины. Сейчас уже процесс физической выгрузки является пересчётом. Брак мы возвращаем сразу же, если он очевидный. Если он неочевидный и обнаруживается потом, то мы накапливаем его в специальный буфер на складе. Гораздо быстрее прокинуть паллету дальше в процесс, собрать с десяток таких и дать возможность поставщику забрать всё сразу за один отдельный приезд. Некоторые виды брака переводятся в зону утилизации (это часто касается зарубежных поставщиков, которым проще получить фотографии и прислать новый товар, чем принимать его обратно через границу).
- В конце разгрузки подписываются документы, и водитель уезжает дальше по своим делам.
В старом процессе паллеты перемещались зачастую в специальную буферную зону, где уже с ними работали: считали, регистрировали брак и так далее. Нужно было это для того, чтобы освободить док для следующей машины. Сейчас все процессы настроены так, что эта буферная зона просто не нужна. Есть выборочные пересчёты (один из примеров — процесс выборочного внутритарного пересчёта для кросс-докинга на складе, реализованный в проекте «Светофор»), но большая часть товара обрабатывается сразу по факту приёмки и именно из дока едет на оптимальное место на складе или сразу в другой док для погрузки, если транспорт на отгрузку со склада уже прибыл. Знаю, для вас это звучит немного обыденно, но пять лет назад на огромном складе возможность обработать поставку сразу на конечные точки вроде дока погрузки для другого грузовика — это нам казалось чем-то вроде космической программы.
Что дальше происходит с товаром?
Дальше, если это не кросс-докинг (и товар уже не уехал в буфер перед отправкой или прямо в док), то его нужно положить в сток на хранение.
Нужно определить, куда этот товар пойдёт, в какую ячейку хранения. В старом процессе нужно было зрительно определить, в какой зоне мы храним товары данного типа, и потом выбрать там место и отвезти, положить, записать, что положили. Сейчас у нас настроены маршруты размещения по каждому товару по топологии. Мы знаем, какой товар в какую зону и в какую ячейку должен попасть, знаем, сколько ячеек занять дополнительно рядом, если это негабарит. Человек подходит к паллете и сканирует её SSCC с помощью ТСД. Сканер показывает: «Вези в А101-0001-002». Дальше он везёт туда и отмечает, что положил, тыкая сканером в код на месте. Система проверяет, что всё правильно, и отмечает. Ничего писать не нужно.
На этом первая часть работы с товаром заканчивается. Дальше магазин готов забирать его со склада. И это порождает следующий процесс, про который лучше расскажут коллеги из отдела снабжения.
Итак, в системе сток обновляется в момент приёмки заказа. А запас ячейки — в момент постановки паллеты в неё. То есть мы всегда знаем, сколько товара есть на складе итого и где какой лежит конкретно.
Очень много потоков работает напрямую в хабы (региональные перевалочные склады), потому что у нас много местных поставщиков в каждом регионе. Те же кондиционеры из Воронежа удобнее ставить не на федеральный склад, а сразу в хабы на местах, если это быстрее.
Обратные потоки брака тоже слегка оптимизированы: если товар на кросс-докинге, то поставщик может забрать его со склада в Москве. Если брак вскрылся уже после открытия транспортной упаковки (и снаружи это было непонятно, то есть он появился не по вине транспортников), то есть зоны возврата в каждом магазине. Брак можно забросить на федеральный склад, а можно отдавать поставщику прямо из магазина. Второе случается чаще.
Ещё один процесс, который сейчас нуждается в оптимизации, — это обработка непроданных сезонных товаров. Дело в том, что у нас есть два важных сезона: Новый год и время сада-огорода. То есть в январе мы получаем на РЦ нереализованные искусственные ёлки и гирлянды, а к зиме — газонокосилки и другие сезонные товары, которые нужно сохранить, если они выдержат ещё год. По идее, нужно распродавать их полностью в конце сезона либо отдавать кому-то ещё, а не тащить обратно на склад — вот это та часть, куда у нас ещё не дошли руки.
За пять лет мы сократили время приёмки товара (разгрузку машины) в четыре раза и ускорили ряд других процессов, что в общей сложности улучшило оборачиваемость кросс-докинга чуть больше, чем вдвое. Наша задача — оптимизация, чтобы снизить запас и не «замораживать» деньги на складе. И дали возможность магазинам получать нужный товар чуть более вовремя.
По складским процессам большие улучшения заключались в том, чтобы автоматизировать то, что раньше было бумагой, избавиться от лишних этапов в процессе за счёт оборудования и правильно настроенных процессов и соединить все ИТ-системы компании в единое целое, чтобы заказ из ERP (например, в магазине чего-то не хватает на третьей полке слева) в конечном итоге превращался в конкретные действия в системе складского хранения, заказа транспорта и так далее. Сейчас оптимизация больше касается тех процессов, до которых мы ещё не добирались, и математики прогнозирования. То есть эпоха бурного внедрения закончилась, мы сделали те 30 % работы, которые дали 60 % результата, и дальше надо постепенно покрывать всё остальное. Либо двигаться на другие участки, если там можно сделать больше.
Ну и если считать в спасённых деревьях, то переход поставщиков на EDI-порталы тоже очень много дал. Сейчас практически все поставщики не звонят и не общаются с менеджером, а сами в личном кабинете смотрят заказы, подтверждают их и везут товар. По возможности отказываемся от бумаги, с 2014 года уже 98 % поставщиков — на электронном документообороте. В общей сложности это сохранённые 3 000 деревьев за год только на отказе от распечатки всех нужных бумаг. Но это без учёта тепла от процессоров, но и без учёта сэкономленного рабочего времени людей вроде тех же менеджеров на телефоне.
За пять лет у нас стало в четыре раза больше магазинов, в три раза больше различных документов, и, если бы не было EDI, у нас было бы в три раза больше бухгалтеров.
Мы не останавливаемся на достигнутом и продолжаем подключать к EDI новые сообщения, новых поставщиков к электронному документообороту.
В прошлом году мы открыли крупнейший распределительный центр в Европе — 140 тыс. кв. м — и взялись за его механизацию. Об этом я расскажу в другой статье.
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-инфраструктура, Сетевое оборудование, Сетевые технологии] Huawei DCN. Сети ЦОД на основе намерений: новые решения по управлению сетями
- [Дизайн игр, Разработка игр] Как мы сделали детскую образовательную веб-игру для Банка России
- [IT-инфраструктура, SAN, Виртуализация, Хранение данных] СХД Qsan в системах видеонаблюдения
- [Разработка под Android] Редактор кода на Android: часть 2
- [] Обзор архитектуры и сервисов Тинькофф-журнала
- [IT-инфраструктура, Распределённые системы, Сетевое оборудование, Системное администрирование] Добавление ноды в Skydive топологию вручную через Skydive client
- [Высокая производительность, Производство и разработка электроники, Разработка под Linux, Сетевые технологии, Тестирование IT-систем] Генератор трафика Cisco TRex: запускаем нагрузочное тестирование сетевых устройств
- [Agile, Конференции, Управление персоналом, Управление проектами] «Колесо баланса». Как Scrum помогает самому scrum-мастеру
- [Разработка игр] Страх и ненависть в геймдеве: от первых шагов до первых денег
- [IT-инфраструктура, Open source, Разработка под Linux, Учебный процесс в IT] Мастер-курсы по Istio и Kafka, книга про Python и немного про навыки веб-разработки
Теги для поиска: #_itinfrastruktura (IT-инфраструктура), #_upravlenie_proektami (Управление проектами), #_avtomatizatsija (автоматизация), #_optimizatsija (оптимизация), #_erp, #_razrabotka (разработка), #_sklad (склад), #_blog_kompanii_lerua_merlen (
Блог компании Леруа Мерлен
), #_itinfrastruktura (
IT-инфраструктура
), #_upravlenie_proektami (
Управление проектами
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 01:54
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Терминал сбора данных Zebra WT-40 со сканером-кольцом. Нужен для того, чтобы была возможность быстро сканировать товар, при этом укладывать физически короба на паллету (свободные руки). На протяжении нескольких лет мы очень быстро открывали магазины и росли. Закончилось это тем, что сейчас наши склады принимают и отправляют порядка 20 тысяч паллет в день. Естественно, сегодня у нас уже больше складов: два больших в Москве — 100 и 140 тысяч квадратных метров, но есть и небольшие в других городах. Каждая сэкономленная секунда в процессах приёмки, сборки или отправки товара в таких масштабах — это возможность сберечь время на операции. А ещё это огромная экономия. Именно поэтому два главных множителя эффективности — это продуманный алгоритм действий (процесс) и настроенные ИТ-системы. Желательно «как часы», но «работающие чуть менее, чем идеально» тоже вполне подойдёт. Всё же мы в реальном мире. История началась шесть лет назад, когда мы присмотрелись к тому, как именно поставщики разгружают фуры у нас на складе. Это было настолько нелогично, но привычно, что сотрудники даже не замечали неоптимальности процесса. Более того, в тот момент у нас не было промышленной системы управления складом, и в основном логистические операции мы доверяли 3PL-операторам, которые использовали свой софт и опыт в построении процессов.  Приёмка товара Как мы уже говорили, наша компания на тот момент (как, в принципе, и сейчас) стремилась открыть много магазинов, поэтому пришлось оптимизировать складские процессы для увеличения пропускной способности (больше товаров за меньшее количество времени). Это непростая задача, и решить её, просто увеличив персонал, было нельзя хотя бы потому, что все эти люди будут друг другу мешать. Таким образом, мы начали думать о внедрении информационной системы WMS (warehouse management system). Как и полагается, мы начали с описания целевых складских процессов и уже в самом начале обнаружили непаханое поле для улучшений в процессе приёмки товара. Нужно было отработать процессы на одном из складов, чтобы потом накатить их на остальные. Приёмка — это одна из первых больших операций на складе. Она бывает нескольких типов: когда мы просто пересчитываем количество грузовых мест и когда нам необходимо, помимо этого, посчитать, сколько и каких артикулов лежит на каждой паллете. Большая часть товаров у нас проходит по потоку кросс-докинг. Это когда товары приезжают на склад от поставщика, а склад выступает в роли роутера и старается тут же переотправить их на конечного получателя (магазин). Есть и другие потоки, например, когда склад выступает в роли кэша или в роли накопителя (нужно положить поставку в сток, разделить на части и постепенно вывозить в магазины). Наверное, про работу со стоком лучше расскажут мои коллеги, которые занимаются математическими моделями оптимизации остатков. Но тут сюрприз! Проблемы стали возникать чисто на ручных операциях. Процесс выглядел так: грузовик приезжал, водитель менялся документами с администратором склада, администратор понимал, что там приехало и куда его отправить, потом направлял грузчика забирать товар. Всё это занимало около трёх часов (конечно, во многом время приёмки зависит от того, какой логистический поток мы принимаем: где-то необходимо делать внутритарный пересчёт, а где-то — нет). Большее количество людей на один грузовик направить нельзя: будут друг другу мешать. Какие были потери? Их было море. Во-первых, работники склада получали бумажные документы. Они ориентировались и принимали решения, что делать с поставкой, по ним. Во-вторых, они считали паллеты вручную и в этих же товарных накладных отмечали количество. Потом заполненные бланки приёмки относились к компьютеру, где данные забивались в XLS-файл. Данные из этого файла затем импортировались в ERP, и только тогда наше ИТ-ядро по факту видело товар. Мы имели очень мало метаданных о заказе вроде времени прибытия транспорта, либо эти данные были неточными. Первое, что мы сделали, — это начали автоматизировать сами склады так, чтобы у них появилась поддержка процессов (понадобилось поставить кучу софта, железа наподобие мобильных сканеров штрихкодов, развернуть инфраструктуру для всего этого). Потом связали эти системы с ERP через шину. В конечном итоге информация о наличии товара обновляется в системе, когда грузчик проводит сканером штрихкода по паллете на приехавшем грузовике. Стало так:
В старом процессе паллеты перемещались зачастую в специальную буферную зону, где уже с ними работали: считали, регистрировали брак и так далее. Нужно было это для того, чтобы освободить док для следующей машины. Сейчас все процессы настроены так, что эта буферная зона просто не нужна. Есть выборочные пересчёты (один из примеров — процесс выборочного внутритарного пересчёта для кросс-докинга на складе, реализованный в проекте «Светофор»), но большая часть товара обрабатывается сразу по факту приёмки и именно из дока едет на оптимальное место на складе или сразу в другой док для погрузки, если транспорт на отгрузку со склада уже прибыл. Знаю, для вас это звучит немного обыденно, но пять лет назад на огромном складе возможность обработать поставку сразу на конечные точки вроде дока погрузки для другого грузовика — это нам казалось чем-то вроде космической программы.  Что дальше происходит с товаром? Дальше, если это не кросс-докинг (и товар уже не уехал в буфер перед отправкой или прямо в док), то его нужно положить в сток на хранение. Нужно определить, куда этот товар пойдёт, в какую ячейку хранения. В старом процессе нужно было зрительно определить, в какой зоне мы храним товары данного типа, и потом выбрать там место и отвезти, положить, записать, что положили. Сейчас у нас настроены маршруты размещения по каждому товару по топологии. Мы знаем, какой товар в какую зону и в какую ячейку должен попасть, знаем, сколько ячеек занять дополнительно рядом, если это негабарит. Человек подходит к паллете и сканирует её SSCC с помощью ТСД. Сканер показывает: «Вези в А101-0001-002». Дальше он везёт туда и отмечает, что положил, тыкая сканером в код на месте. Система проверяет, что всё правильно, и отмечает. Ничего писать не нужно. На этом первая часть работы с товаром заканчивается. Дальше магазин готов забирать его со склада. И это порождает следующий процесс, про который лучше расскажут коллеги из отдела снабжения. Итак, в системе сток обновляется в момент приёмки заказа. А запас ячейки — в момент постановки паллеты в неё. То есть мы всегда знаем, сколько товара есть на складе итого и где какой лежит конкретно. Очень много потоков работает напрямую в хабы (региональные перевалочные склады), потому что у нас много местных поставщиков в каждом регионе. Те же кондиционеры из Воронежа удобнее ставить не на федеральный склад, а сразу в хабы на местах, если это быстрее. Обратные потоки брака тоже слегка оптимизированы: если товар на кросс-докинге, то поставщик может забрать его со склада в Москве. Если брак вскрылся уже после открытия транспортной упаковки (и снаружи это было непонятно, то есть он появился не по вине транспортников), то есть зоны возврата в каждом магазине. Брак можно забросить на федеральный склад, а можно отдавать поставщику прямо из магазина. Второе случается чаще. Ещё один процесс, который сейчас нуждается в оптимизации, — это обработка непроданных сезонных товаров. Дело в том, что у нас есть два важных сезона: Новый год и время сада-огорода. То есть в январе мы получаем на РЦ нереализованные искусственные ёлки и гирлянды, а к зиме — газонокосилки и другие сезонные товары, которые нужно сохранить, если они выдержат ещё год. По идее, нужно распродавать их полностью в конце сезона либо отдавать кому-то ещё, а не тащить обратно на склад — вот это та часть, куда у нас ещё не дошли руки. За пять лет мы сократили время приёмки товара (разгрузку машины) в четыре раза и ускорили ряд других процессов, что в общей сложности улучшило оборачиваемость кросс-докинга чуть больше, чем вдвое. Наша задача — оптимизация, чтобы снизить запас и не «замораживать» деньги на складе. И дали возможность магазинам получать нужный товар чуть более вовремя. По складским процессам большие улучшения заключались в том, чтобы автоматизировать то, что раньше было бумагой, избавиться от лишних этапов в процессе за счёт оборудования и правильно настроенных процессов и соединить все ИТ-системы компании в единое целое, чтобы заказ из ERP (например, в магазине чего-то не хватает на третьей полке слева) в конечном итоге превращался в конкретные действия в системе складского хранения, заказа транспорта и так далее. Сейчас оптимизация больше касается тех процессов, до которых мы ещё не добирались, и математики прогнозирования. То есть эпоха бурного внедрения закончилась, мы сделали те 30 % работы, которые дали 60 % результата, и дальше надо постепенно покрывать всё остальное. Либо двигаться на другие участки, если там можно сделать больше. Ну и если считать в спасённых деревьях, то переход поставщиков на EDI-порталы тоже очень много дал. Сейчас практически все поставщики не звонят и не общаются с менеджером, а сами в личном кабинете смотрят заказы, подтверждают их и везут товар. По возможности отказываемся от бумаги, с 2014 года уже 98 % поставщиков — на электронном документообороте. В общей сложности это сохранённые 3 000 деревьев за год только на отказе от распечатки всех нужных бумаг. Но это без учёта тепла от процессоров, но и без учёта сэкономленного рабочего времени людей вроде тех же менеджеров на телефоне. За пять лет у нас стало в четыре раза больше магазинов, в три раза больше различных документов, и, если бы не было EDI, у нас было бы в три раза больше бухгалтеров. Мы не останавливаемся на достигнутом и продолжаем подключать к EDI новые сообщения, новых поставщиков к электронному документообороту. В прошлом году мы открыли крупнейший распределительный центр в Европе — 140 тыс. кв. м — и взялись за его механизацию. Об этом я расскажу в другой статье. =========== Источник: habr.com =========== Похожие новости:
Блог компании Леруа Мерлен ), #_itinfrastruktura ( IT-инфраструктура ), #_upravlenie_proektami ( Управление проектами ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 01:54
Часовой пояс: UTC + 5