- Добро пожаловать на форум умных покупателей! Присоединяйтесь к нашей уютной компании и участвуйте в обсуждениях – Регистрация
ValNet
Новичок
Уже выяснил, почему международный номер дали.
Посылка была заказана первым классом, но с трекингом (Registered mail service), и полностью отслеживалась ещё в США.
Проверил другие номера первого класса - там присылают номер тот же, что и отправителю - LC...US.
А тут вышло то же примерно, что и с гонконгскими RB...HK.
Посылка была заказана первым классом, но с трекингом (Registered mail service), и полностью отслеживалась ещё в США.
Проверил другие номера первого класса - там присылают номер тот же, что и отправителю - LC...US.
А тут вышло то же примерно, что и с гонконгскими RB...HK.
meehalych
Новичок
нифига, все равно LC..........US прислали
dokoff
Продвинутый
S
slonik141
Новичок
Почему не добавляются треки по которым нет еще данных? Можно же пока нет данных эту строку просто не показвать. Статистика формируется из наших треков и каждое даже самое незначительное препятствие снижает количество треков.
К тому же теряются из за этого данные первого столбца, когда человек не успел отследить поступление посылки на почту и занес трек позже когда статус посылки поменялся на Left.
К тому же теряются из за этого данные первого столбца, когда человек не успел отследить поступление посылки на почту и занес трек позже когда статус посылки поменялся на Left.
dokoff
Продвинутый
slonik141
Попробую объяснить ...
безусловно это было бы хорошо, но я, как один из разработчиков данного сервиса, не могу смотреть только на "плюсы" данного предложения.
Условия : Количество треков которые проверяются - ограниченно.
Добавляя трек в базу, мы все равно вынуждены будем его периодически проверять (на доступность информации о нем). Исходя из Вашей идеи (дабы не пропустить POSTED) - это необходимо делать каждые 4-6 часов. Даже если информации по треку нет, запрос к БД сервера все равно формируется. Получаем : ограничение количества треков минус (текущее количество треков плюс количество по которым еще нет данных). Итого, когда уравнение будет равно нолю .. Вы не сможете добавить реальные треки (по которым уже есть данные).
К тем трекам, по которым нет данных, Вы смело можете плюсовать те, которые были введены с ошибкой, просто набор символов для "посмотреть что будет дальше".
Конечно ) Вы предложите проверять чексумму каждого трека. Это да, тогда мы избавимся от мусора, но теперь представьте, что мы проверяем треки по дате POSTED и LEFT для того, что бы на одну дату было < X треков. в общем Вы поняли, что такая проверка невозможна пока нет данных по треку. Иначе в статистике, начнется хаос !
Удалять треки если по ним не появились данные - тож не вариант, т.к. это в итоге, создаст "паразитную" нагрузку на сайты "доноры".
Более того, мы не можем предоставлять некоторые услуги без проверки "читабельности" трека.
Колонка POSTED бесспорно страдает от всего этого, но разумных решений мы пока не видим.
Текущие решения только замутят прозрачность данных и создадут пирамиду условностей (правил), которые будут не совсем понятны обычному пользователю.
Спасибо за Ваше мнение.
Попробую объяснить ...
безусловно это было бы хорошо, но я, как один из разработчиков данного сервиса, не могу смотреть только на "плюсы" данного предложения.
Условия : Количество треков которые проверяются - ограниченно.
Добавляя трек в базу, мы все равно вынуждены будем его периодически проверять (на доступность информации о нем). Исходя из Вашей идеи (дабы не пропустить POSTED) - это необходимо делать каждые 4-6 часов. Даже если информации по треку нет, запрос к БД сервера все равно формируется. Получаем : ограничение количества треков минус (текущее количество треков плюс количество по которым еще нет данных). Итого, когда уравнение будет равно нолю .. Вы не сможете добавить реальные треки (по которым уже есть данные).
К тем трекам, по которым нет данных, Вы смело можете плюсовать те, которые были введены с ошибкой, просто набор символов для "посмотреть что будет дальше".
Конечно ) Вы предложите проверять чексумму каждого трека. Это да, тогда мы избавимся от мусора, но теперь представьте, что мы проверяем треки по дате POSTED и LEFT для того, что бы на одну дату было < X треков. в общем Вы поняли, что такая проверка невозможна пока нет данных по треку. Иначе в статистике, начнется хаос !
Удалять треки если по ним не появились данные - тож не вариант, т.к. это в итоге, создаст "паразитную" нагрузку на сайты "доноры".
Более того, мы не можем предоставлять некоторые услуги без проверки "читабельности" трека.
Колонка POSTED бесспорно страдает от всего этого, но разумных решений мы пока не видим.
Текущие решения только замутят прозрачность данных и создадут пирамиду условностей (правил), которые будут не совсем понятны обычному пользователю.
Спасибо за Ваше мнение.
dokoff
Продвинутый
SMS-Track.ru - Бесплатная, расширенная статистика почты России. Получать статус посылки по SMS !
SMS-Track.ru - Бесплатная, расширенная статистика почты России. Получать статус посылки по SMS !
dokoff
Продвинутый
ViP®
ага .. есть проблемы .. подправим. (подправили)
shushlev
Прогноз из статистики .. так что "бабка нагадала" .. это все равно останется предсказанием.
И хватит издеваться тут такие пироги с рашапостом .. что сам Гидрометцентр ошибется в предсказаниях похлеще чем с погодой :twisted:
Ps В IE немного коряво отображается сводная статистика. Обязательно подправим.(подправили)
ага .. есть проблемы .. подправим. (подправили)
shushlev
Прогноз из статистики .. так что "бабка нагадала" .. это все равно останется предсказанием.
И хватит издеваться
тут такие пироги с рашапостом .. что сам Гидрометцентр ошибется в предсказаниях похлеще чем с погодой :twisted:Ps В IE немного коряво отображается сводная статистика. Обязательно подправим.(подправили)
С
Серафим
Новичок
Нововведения - здорово, но есть замечания по оформлению. Не знаю уж, насколько они ценны. :twisted:
В сводной таблице "увеличелось" вместо "увеличилось". Число "насколько увеличилось" стоит отформатировать до #.##.
То, что "сократилось" - зеленым, а "увеличилось" - красным - это правильно, но стрелки стоило бы направить в противоположную сторону, а может быть и положить набок (зеленым влево, красным вправо).
Не знаю уж, насколько они ценны. :twisted:В сводной таблице "увеличелось" вместо "увеличилось". Число "насколько увеличилось" стоит отформатировать до #.##.
То, что "сократилось" - зеленым, а "увеличилось" - красным - это правильно, но стрелки стоило бы направить в противоположную сторону, а может быть и положить набок (зеленым влево, красным вправо).
Live
