Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
sobolevъ Papyrus не умеет проверять маржу при отгрузке. Я не вижу тут проблемы, но ни один из клиентов не разу не обратился с таким вопросом. Всяких ограничений просят (и получают), но об этом ни кто не заикался. Да и вообще, я согласен, что проблема из разряда нерешаемых. Мы ведь не можем позвонить клиенту и сказать: "давай бобы назад, а то мы, идиоты, тебе ниже себестоимости отгрузили". Я коротенько описал поведение системы в контексте subj'а (не больше). PS А чего в вопросе обидного? Тут два разных события. 1. Выписка счета - система проанализировала маржу и разрешила счет распечатать (послать клиенту), и например "зарезервировать". 2.Отгрузка со склада (накладная) - система по FIFO рассчитала какой материал ушел в отгрузку - маржа может быть другой здесь разве что резервирование и поможет - если товар по ДРУГОЙ цене это ДРУГОЙ товар. При другом варианте - какая разница общая сумма прибыли (налогооблагаемой) неизменна, меняется только доходность КОНКРЕТНОЙ операции. п.2. может быть повторен в конце месяца для приведения в порядок бухучета. Для ОПЕРАТИВНОГО учета можно распечатать выписанные счета-фактуры с двумя колонками "маржа при выписке", "маржа при отгрузке" - а с кого снимать разницу - с менеджера или с завсклада (отдела логистики) руководитель сам разберется. ______________ на нобелевскую не претендую ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2006, 18:56 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
iscrafm Uncle_Alex Оприходовали партию. Себестоимость "на сейчас" включает стоимость товара согласно инвойса. Продали партию. Через 4 дня ввели недостающие данные. Посчитали себестоимость. Сформировали отчет о продажах, посмотрели маржу, поделили. Чего-то я не понимаю :) Хочу понять принцип согласно которому в отчет по всем продажам попадет откорректированная себестоимость во всех продажах данной поставки. Цена средневзвешанная и процес повторяемый, партий нет, как нет и партионных цен. С самими партиями если использовать, тоже головнять с автоматическим перераспределением с изменениями в прошлом. Мы постепенно ушли от общего в конкретику. Речь изначально идет о наличии предворительных оперативных расчетов и проблем актуализации этих расчетов при внесении изменений в прошлое. Роль этих расчетов ускорить оперативную и периодическую отчетность. Проблема не откорректировать банальный остаток партии товара или остаток по кассе. Для быстрого получения отчета о продажах в разных плоскостях маржа должна уже сидеть в расчитанном виде а не вычисляться путем обхода цены партий для каждой продажи и каждой позиции. Есть две крайности получения отчетности: вообще не пользоваться промежуточными вычислениями и тупо сканировать всю базу данных на любой отчет, здесь любые изменения в прошлое до печки или принцип OLAP где реактивность системы практически не зависит от объема базы, но и менять ничего нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2006, 18:59 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Uncle_AlexЦена средневзвешанная и процес повторяемый, партий нет, как нет и партионных цен. ... Речь изначально идет о наличии предворительных оперативных расчетов и проблем актуализации этих расчетов при внесении изменений в прошлое. Роль этих расчетов ускорить оперативную и периодическую отчетность. В таких случаях мы так и поступаем. Отдельная табличка с результатами расчета себестоимости и процедура, которая ее обрабатывает. Вся отчетность формируется только по ней, а не по первичке. В таблице храняться все показатели, вплоть до рентабельности и дата актуализации. Процедура пересчета запускается по требованию, т.е. тогда, когда нужно актуализировать данные для принятия решения или периодически за период, от заданной даты (периода) до текущей. По времени не критична, несколько минут занимает пересчет за 3 года. Данные, которые лежат в этой табличке на рис. ниже. Мелковато правда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2006, 19:47 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
iscrafmПроцедура пересчета запускается по требованию т.е. тогда, когда нужно актуализировать данные.... Ну вот, этой фразой Вы фактически и ответили. Я же в свою очередь отказываюсь воспринимать систему учета как достоверную если актуализация реализована в отдельных разрезах и воспроизводится по требованию. Высокую достоверность дает баланс активов и пассивов на момент каждой операции, что у Вас не гарантировано. Если я не прав и издержки на актуализацию в реальном времени не критичны, почему систему не сделать автоактуализируемой? Хотя конечно Ваш подход, как вариант, вполне имеет право на жизнь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2006, 20:54 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Uncle_AlexНу вот, этой фразой Вы фактически и ответили. Я же в свою очередь отказываюсь воспринимать систему учета как достоверную если актуализация реализована в отдельных разрезах и воспроизводится по требованию. Высокую достоверность дает баланс активов и пассивов на момент каждой операции, что у Вас не гарантировано. Если я не прав и издержки на актуализацию в реальном времени не критичны, почему систему не сделать автоактуализируемой? Хотя конечно Ваш подход, как вариант, вполне имеет право на жизнь. Можно сделать и автоактуализируемой, если нужно конечно. Никто не мешает делать точечные расчеты в момент учета транзакции (остатки же поддерживаются в актуальном состоянии). Вопрос в другом - кому нужна "real time" актуализация в вопросах вычисления маржи. Что выполнять в момент учета транзакции определяется только требованиями к актуальности информации со стороны заказчика. Нужно ему видеть маржу после каждого изменения - включаете в процедуру учета пересчет маржи и вперед. В приведенном примере заказчику это не нужно было. Он научился хотя бы на неделю вперед планировать, чтобы не контролировать маржу "он-лайн". Т.е. выбор за Вами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2006, 21:04 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
iscrafm Можно сделать и автоактуализируемой, если нужно конечно. Никто не мешает делать точечные расчеты в момент учета транзакции (остатки же поддерживаются в актуальном состоянии). Вопрос в другом - кому нужна "real time" актуализация в вопросах вычисления маржи. Да конечно никому не нужна. Если система по принципу своей структуры способна обеспечить абсолютную автоактуализацию с приемлимой степенью реактивности(скажем до 0.1с для самых глубоких откатов), то снимается целый пласт проблем связанных с реализацией этой самой актуализации в разрезе конкретных отчетов. Вы ведь организуя транзакцию свято верите что скуль не подведет, не вникая че он блокирует и как уходит от дедлоков. А с автоактуализацией до такого совершенства похоже не дошло. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2006, 21:35 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Uncle_AlexВы ведь организуя транзакцию свято верите что скуль не подведет, не вникая че он блокирует и как уходит от дедлоков. А с автоактуализацией до такого совершенства похоже не дошло. Если понадобится автоактуализация такого уровня, то вместо MS SQL будем использовать другую СУБД, тот же ANTS Data Server, благо ограничений в этом нет. Каждой задаче нужно подбирать соответствующий инструмент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2006, 21:42 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
iscrafmт.е. тогда, когда нужно актуализировать данные для принятия решения или периодически за период, от заданной даты (периода) до текущей. По времени не критична, несколько минут занимает пересчет за 3 года. Нет, мы таки очевидно говорим о разной актуализации. Это как же получается? Главнейший показатель деятельности фирмы - маржанальный доход может быть не актуальным 3 года. Как же прошлые месяцы закрываюся в плане расчета прибыли. Или маржа для расчета прибыли актуализируется отдельно. Но так наверное не бывает. Логически получается что не актуальным по марже может быть только последний месяц, че тогда напрягать расчетную часть системы последними тремя годами. Речь скорей всего идет об актуализации части базы самого отчета. Это далеко не одно и то же, что актуализация системы в целом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 14:17 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Uncle_AlexНет, мы таки очевидно говорим о разной актуализации. Это как же получается? Главнейший показатель деятельности фирмы - маржанальный доход может быть не актуальным 3 года. Я Вам пример привел сколько времени требуется для пересчета 3-х летнего периода, объем номенклатуры около 30000. И уж точно не для того, чтобы говорить о неактуальных данных в течении 3-х лет, естественно :). Если требуется актуализация real-time, нужно выбирать что-либо из версионников, безблокировочников, in-memory и т.п. Но опять же, это не та категория информации для которой нужна ежесекундная (т.е. после каждой транзакции) актуализация. Да и с обычным блокировочником не будет проблем вообще-то. Основные потребители информации из расчетной таблицы - "читатели". Частота поставок импортных партий здесь не помеха. Цепляете процедуру пересчета в учет поставки или накладных расходов и будет Вам постоянно актуальная информация (на данный момент естественно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 14:46 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
iscrafmЕсли требуется актуализация real-time, нужно выбирать что-либо из версионников, безблокировочников, in-memory и т.п. Прошу простить мне мою дремучесть, а что это такое? Можно что нибудь конкретное для обзора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 15:06 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Uncle_Alex iscrafmЕсли требуется актуализация real-time, нужно выбирать что-либо из версионников, безблокировочников, in-memory и т.п. Прошу простить мне мою дремучесть, а что это такое? Можно что нибудь конкретное для обзора. Транзакция читает данные, изменяемые в это время другой транзакцией. В блокировочнике она ждет завершения, в версионнике - читает данные зафиксированные до начала второй транзакции. Т.е. читатели не ждут писателей. In-memory - таблицы размещаются в памяти. В двух словах. Поиск в интернете даст много информации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 15:22 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
G> В примере, который я привел чуть выше, как раз о цене списания G> и идет речь. Она может измениться, если добавить задним числом еще один G> приход или расход, стараясь при этом соблюсти принцип FIFO (или LIFO). зачем соблюдать чисто бухгалтерский принцип FIFO (LIFO, средневзвешенный) при расчете прибыли по сделке в оперативном учете, по которому делят бабло? Вот по умолчанию пусть будет FIFO или LIFO но партию можно чтобы было сменить, чтоб продать "с колес", а не "со склада" И зафиксировать именно эту партию. Тогда и проблем нет при вводе прихода задним числом - этот приход уйдет на склад, а проданные партии так и остануться проданными. Зачем их пересчитывать то? Зачем менять прибыль по сделке, если в результате сделки продали именно ту партию, которую и указали? А бухгалтерия пусть живет там сама по себе, ее не надо слушать: пусть клепает отчеты для налоговой и все. -- С уважением Кочмин Александр Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 15:49 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
iscrafm Транзакция читает данные, изменяемые в это время другой транзакцией. В блокировочнике она ждет завершения, в версионнике - читает данные зафиксированные до начала второй транзакции. Т.е. читатели не ждут писателей. In-memory - таблицы размещаются в памяти. В двух словах. Поиск в интернете даст много информации. Ну не скромничайте сказавши А скажите Б. Интернет могучая сила, дай те хоть название СУБД отражающие приведенные тенденции. С читающей транзакцией Вы меня просто озадачили. Я всегда под термином "транзакция" понимал алгоритм связанный с модификацией данных??? Заранее благодарен за источники. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 16:41 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 16:51 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Uncle_Alex GaryaКак вы "перепроведете" документы, в которых цена ранее уже была посчитана, документы выданы на руки клиентам и эти клиенты разъехались по странам и весям? Хвала всевышнему :) Речь не шла об изменениях параметров документа введенных непосредственно оператором. Имелась в виду себестоимость/цена списания, которая извлекается системой самостоятельно. Вот она то при вмешателство в прошлое и может оказаться не актуальной для более поздних по оси времени операций.Допустим вы измените задним числом в приходной накладной цену товара в партии 1000шт... Как минимум должна изменится себестоимость во всех созданых после этого прихода расходных документах (это очень обобщенно). Технически то это все можно сделать, но будет такая путаница в последующем.. Документы созданы, отчеты о прибыли уже у рук-ва и т.д и т.п.. Лучше сторнирующей проводкой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 17:10 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Ден Документы созданы, отчеты о прибыли уже у рук-ва и т.д и т.п.. Лучше сторнирующей проводкой Смотря для кого лучше. Пару лет назад делали проект по созданию ИС для транспортной компании. Продолжительность кругорейсов до 2-х месяцев. Отчетность за прошлые периоды акутализировалась по мере завершения рейсов. Естественно бух. информация не трогалась, но руководство с ней и не работало. Что толку анализировать прибыль, если фура еще в рейсе. Так что, только по факту завершения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 18:31 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Ден Uncle_Alex GaryaКак вы "перепроведете" документы, в которых цена ранее уже была посчитана, документы выданы на руки клиентам и эти клиенты разъехались по странам и весям? Хвала всевышнему :) Речь не шла об изменениях параметров документа введенных непосредственно оператором. Имелась в виду себестоимость/цена списания, которая извлекается системой самостоятельно. Вот она то при вмешателство в прошлое и может оказаться не актуальной для более поздних по оси времени операций.Допустим вы измените задним числом в приходной накладной цену товара в партии 1000шт... Как минимум должна изменится себестоимость во всех созданых после этого прихода расходных документах (это очень обобщенно). Технически то это все можно сделать, но будет такая путаница в последующем.. Документы созданы, отчеты о прибыли уже у рук-ва и т.д и т.п.. Лучше сторнирующей проводкой Не будем опускаться до принципа это не нужно, потому что не нужно никому и никогда. Изменения задним числом делали и делают. И не барское это дело задумываться какие из них повлияют на достоверность отчетности, а какие нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 18:36 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
iscrafm По версии википедии Осилил :) Это другая история, - принцип паралельного доступа к данным во время их модификации другим пользователем. Осталось попытаться осилить "in memory - таблицы в памяти" И позволю себе еще раз формализовать проблему: Как автоматически реализовать актуализацию динамической отчетности по ссылочным данным. Ссылочные данные модифицируются в прошлом и динамическая отчетность находится в прошлом, построена по версии данных до модификации. Пока ссылочное значение не меняется динамическая отчетность актуальна, после модификации ссылочного значения только оно акуально, вся остальная зависимая отчетность уже не актуальна, относительно ссылочного значения.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 19:13 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Избавьтесь от влияния ссылочных данных на отчетность и проблема решится сама собой. Не формируйте отчетность по "живым документам". Входящие данные - > Постинг - > Хранилище - > Отчетность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 19:19 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
iscrafmИзбавьтесь от влияния ссылочных данных на отчетность и проблема решится сама собой. Не формируйте отчетность по "живым документам". Входящие данные - > Постинг - > Хранилище - > Отчетность. Мысль хорошая, только время реакции системы может не удовлетворить пользователей. Дайте pls. сылочку на таблицы в памяти, может там найду утешение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 19:33 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Uncle_Alexвремя реакции системы может не удовлетворить пользователей. Дайте pls. сылочку на таблицы в памяти, может там найду утешение. ANTS или TimesTen к примеру. Только не думаю, что задача стоит, в случае с TimesTen 20 килобаксов. Все таки это не RT задача. Но хозяин барин :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2006, 19:49 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Uncle_AlexПрактически ни разу не встречал в описании на учетные системы акцента на алгоритм указанный в теме. Похоже ВСЕ учетные системы при отражении фактов хоз. деятельности, кроме регистрации параметров события формируют сводные значения, используя имеющиеся данные и данные определенные событиями предшествующих периодов. Кроме того алгоритмы обработки текущих событий также могут использовать те же сводные значения. У нас как раз реализованно по другому. Хранятся все события, и баланс собирается каждый раз по всем проводкам. Т.е. любые изменения - любым задним числом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 15:36 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
iscrafm Uncle_Alex iscrafmЕсли требуется актуализация real-time, нужно выбирать что-либо из версионников, безблокировочников, in-memory и т.п. Прошу простить мне мою дремучесть, а что это такое? Можно что нибудь конкретное для обзора. Транзакция читает данные, изменяемые в это время другой транзакцией. В блокировочнике она ждет завершения, в версионнике - читает данные зафиксированные до начала второй транзакции. Т.е. читатели не ждут писателей. In-memory - таблицы размещаются в памяти. В двух словах. Поиск в интернете даст много информации.Ну, не всё так просто. На самом деле каких-то существенных отличий между версионниками и блокировочниками нет. Ждет или не ждет блокировочник, может зависеть от уровня изоляции транзакий. Если "грязное чтение" разрешено, то он может и не ждать. С версионником - аналогично. Если версионник не ждет, значит он рискует получить несогласованные данные. Если контроль согласованности данных отрабатывается в триггерах, то на уровне версий данных для параллельных транзакций могут получиться согласованные данные, а при записи версий этих транзакций в единую базу данных они все равно окажутся несогласованными. Это "болезнь" версионников. Пример: В базе данных в разных таблицах находятся значения A и B, которые исходя из их согласованности никогда не должны быть равны (что проверяется триггером). В исходном состоянии A=1; B=2. На версионнике одновременно запускаются две транзакции. Одна пытается присвоить A:=5, другая пытается присвоить B:=5. В каждой из этих транзакций считываются значения A и B ДО их запуска. Срабатывает триггер в транзакции №1 и проверяет (А=5) != (B=2) - значит изменение A разрешено. Срабатывает триггер в транзакции №2 и проверяет (A=1) != (B=5) - значит изменение B тоже разрешено. Обе транзакции сохраняют новые значения A и B и закомичивают свои транзакции, новые версии A=5 и B=5 сохраняются в базе данных, нарушив согласованность данных. Такая ситуация не может произойти на блокировочнике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 17:41 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Uncle_AlexНу не скромничайте сказавши А скажите Б. Интернет могучая сила, дай те хоть название СУБД отражающие приведенные тенденции. С читающей транзакцией Вы меня просто озадачили. Я всегда под термином "транзакция" понимал алгоритм связанный с модификацией данных??? Заранее благодарен за источники.MS SQL Server - блокировочник (хотя начиная с версии 2005 там появилась возможность выполнения транзакций в стиле версионника). Oracle - версионник, хотя у него есть возможность выполнения "по требованию" некоторых транзакций в стиле блокировочника (в таких случаях, как в приведенном мной примере). InterBase - чистый версионник. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 17:48 |
|
||
|
Актуализация при вмешательстве в прошлое.
|
|||
|---|---|---|---|
|
#18+
Garya Если контроль согласованности данных отрабатывается в триггерах, то на уровне версий данных для параллельных транзакций могут получиться согласованные данные, а при записи версий этих транзакций в единую базу данных они все равно окажутся несогласованными. Это "болезнь" версионников. Garya, перебор даже в картах плох. Зачем рассуждать о том, чего не знаете? Garya Пример: В базе данных в разных таблицах находятся значения A и B, которые исходя из их согласованности никогда не должны быть равны (что проверяется триггером).В исходном состоянии A=1; B=2. На версионнике одновременно запускаются две транзакции. Одна пытается присвоить A:=5, другая пытается присвоить B:=5. Я хоть и не спец в версионниках, но уверен, что вторая транзакция обламается или сразу, или после коммита первой - в зависимости от настроек (это касается Интербейза и Фаейрбёрда). Garya В каждой из этих транзакций считываются значения A и B ДО их запуска. Срабатывает триггер в транзакции №1 и проверяет (А=5) != (B=2) - значит изменение A разрешено. Срабатывает триггер в транзакции №2 и проверяет (A=1) != (B=5) - значит изменение B тоже разрешено. Обе транзакции сохраняют новые значения A и B и закомичивают свои транзакции, новые версии A=5 и B=5 сохраняются в базе данных, нарушив согласованность данных. Этого не может быть, откуда Вы это взяли? Garya Такая ситуация не может произойти на блокировочнике. А если грязное чтение? Кстати, в Интербейзе и ему подобных грязного чтения нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2006, 23:49 |
|
||
|
|

start [/forum/topic.php?fid=29&msg=34007077&tid=1527922]: |
0ms |
get settings: |
6ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
133ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 218ms |
| total: | 442ms |

| 0 / 0 |
