Як ChinaValidate перевіряє звіти про компанії
Дізнайтеся про поточні перевірки в браузері, часові мітки даних, межі PDF-файлів, відомі обмеження та журнал версій, що супроводжують звіти ChinaValidate про компанії.
Почніть з китайської юридичної назви або USCC. Підтвердьте відповідність компанії, перш ніж відкривати її профіль.
На цій сторінці описано, як ChinaValidate перевіряє дані звітів про компанії та де закінчуються ці підтвердження. Звіт може успішно пройти перевірку оформлення, але покупцю все одно потрібно самостійно верифікувати транзакцію, першоджерела, договір, продукт та платіжні реквізити. Наведена нижче методика є фіксацією версії релізу, а не сертифікатом безпеки компанії.
Знімок методу: Метод v1, перевірено 15 липня 2026
Інтерфейс для тестування: публічний зразок звіту про компанію
Поточні докази з браузера: встановлений стабільний Chrome, керований Playwright 1.60
Області перегляду: 1440 x 1000, 390 x 844 та 320 x 800 пікселів CSS
Методика починається зі змісту, а не зі скріншотів
Перший тест полягає в тому, чи зберігає звіт цілісність ідентичності однієї компанії. Зареєстрована китайська назва, Єдиний код соціального кредиту (USCC), статус реєстрації, законний представник, дата звіту та посилання на звіт мають залишатися пов’язаними з тим самим суб’єктом у верхній частині сторінки. Візуально охайний звіт вважається невдалим, якщо поле належить іншій компанії-кандидату або втрачає свою часову прив’язку до джерела.
Другий тест стосується того, чи залишаються стани даних різними. Модуль із повернутими записами відрізняється від перевіреного модуля без відповідних записів, і обидва вони відрізняються від джерела, яке тимчасово було недоступне. Презентація звіту ChinaValidate окремо відображає ці стани. Це важливо, тому що «записи не повернуто» не повинно переписуватися як «судових справ немає»; посібник з інтерпретації негативних результатів пояснює цю межу.
Третій тест є часовим. Часи генерації та завершення на рівні звіту ідентифікують пакет, тоді як модулі публічних записів мають власний час фіксації. Чинні в Китаї правила розкриття інформації про підприємства покладають на державні органи та підприємства відповідальність за достовірність і своєчасність інформації, яку кожен із них розкриває, та передбачають виправлення. Тому знімок звіту можна розглядати як доказ із зазначеного часу; його не слід описувати як такий, що є актуальним назавжди.
Поточні дані з браузера
15 липня 2026 публічний зразок звіту було завантажено з чистого контексту браузера в кожній із наведених нижче областей перегляду. Перевірка вимагала HTTP 200, правильний заголовок H1 компанії, ті самі дані ідентичності у верхній частині, відсутність горизонтального переповнення всього документа, відсутність помилок у консолі або на сторінці та відсутність невдалих мережевих відповідей.
| Профіль | Область перегляду | Спостережуваний результат |
|---|---|---|
| Настільний комп’ютер | 1440 x 1000 | Пройдено; ширина звіту 1440, наявні дані ідентичності у верхній частині та послідовність розділів |
| Мобільний пристрій | 390 x 844 | Пройдено; звіт адаптовано до ширини 390 без переповнення документа |
| Вузька адаптація | 320 x 800 | Пройдено; всі 28 розділи звіту залишилися присутніми при ширині 320 |
Перевірка шириною 320 пікселів пов’язана з поясненням W3C щодо адаптації макету, яке використовує 320 пікселів CSS як вертикальний орієнтир вмісту для уникнення двовимірної прокрутки, з винятками для вмісту, який дійсно цього потребує. Успішне проходження цієї ширини є одним із корисних сигналів макета; це не є заявою про повну відповідність стандартам WCAG.
Що саме фіксує перевірка в браузері
- Неправильний маршрут або відсутній звіт: початкова відповідь не є 200 або очікувана назва звіту відсутня.
- Розбіжність ідентифікації: видимий заголовок компанії або ключові поля не відповідають тестовому шаблону.
- Пошкоджена адаптивна верстка: документ стає ширшим за область перегляду, зазвичай через таблицю, значення, схоже на код, або модуль із фіксованою шириною.
- Помилки ресурсів або запитів: зображення не мають природних розмірів або запит сторінки повертає помилку.
- Розбіжність між клієнтом і сервером: помилки гідратації, JavaScript або сторінки з’являються в консолі браузера.
Playwright можна налаштувати для Chromium, Firefox, WebKit, брендованих браузерів і мобільних проєктів. Його емуляція пристроїв також може керувати областю перегляду, екраном, сенсорним введенням, локаллю та часовим поясом. Це доступні можливості тестування, а не доказ того, що кожна конфігурація пройшла поточну збірку звіту ChinaValidate. Наведена вище матриця фіксує лише те, що було фактично запущено.
Звіт із браузера та PDF — це окремі результати
Звіт у браузері підтримує перевірку на екрані та зберігає повну ієрархію сторінки. Завантажуваний PDF є друкованою копією розблокованої сторінки деталей компанії: він використовує той самий збережений знімок, розгортає розширені модулі та містить той самий аналіз ШІ, джерела й обмеження, але не включає навігацію та інтерактивні елементи керування. Процеси генерації потребують завершеного звіту та перевіряють, чи записано файл для завантаження; незавершені звіти відхиляються, а не експортуються як готові докази.
У PDF перелічено статус модулів і час захоплення, а також включено розділ «Джерела та обмеження». Коли модуль містить більше даних, ніж може вмістити макет документа, PDF позначає, що містить перші 100 нормалізованих записів. Покупець не повинен розглядати скорочений PDF як повний базовий набір даних. Збережіть посилання на звіт і скористайтеся посібником із файлів затвердження для збереження пов’язаних контрактів і платіжних записів.
Відомі обмеження методу v1
Покриття браузерами: поточний документований запуск використовує стабільну версію Chrome, а не Firefox, Safari/WebKit, допоміжні технології чи кожну операційну систему. Покриття пристроями: фіксовані області перегляду відтворюють обмеження макета, але не замінюють тестування на фізичних телефонах, із різними налаштуваннями шрифтів, рівнями масштабування, повільними мережами або корпоративними політиками браузерів.
Покриття даними: прохід рендерингу не доводить, що публічне джерело було повним, що переклад має юридичну силу, або що в компанії немає неповернених записів. Зразковий звіт використовує вигадані дані та тестує лише подання. Для таких полів, як річні звіти, зберігайте рік звітності та дату поля, використовуючи метод читання річних звітів.
Покриття рішень: звіт є інструментом підтримки прийняття рішень. Тестування не може гарантувати ідентичність, платоспроможність, якість продукту, продуктивність, повноваження на укладання контрактів, наявність банківського рахунку чи майбутню поведінку. Для рішень із вищою цінністю можуть все ще знадобитися оригінальні документи, незалежне підтвердження, інспекція, аудит, консультації щодо контрактів або локальний професійний огляд.
Журнал версій та умови повторного тестування
Метод v1 — 15 липня 2026: зафіксовано три області перегляду Chrome, твердження DOM і мережі, перевірки стану даних, часові мітки знімків, межу PDF V2 та відомі обмеження браузера. Версія PDF і версія методу є окремими позначками.
Повторне тестування потрібне, коли змінюється контракт даних звіту, додається або перейменовується модуль публічних записів, змінюються поля ідентифікації, змінюється рендерер PDF, суттєво змінюється підтримувана версія браузера або виправлення макета впливає на спільні компоненти звіту. Результат слід записати як новий датований запис методу, а не тихо перезаписувати те, що фактично охоплював попередній реліз.
Щоб переглянути вивід, використаний у цьому методі, відкрийте покроковий огляд зразкового звіту або виконайте пошук компанії в Пошук компаній ChinaValidate.