Створення файлу затвердження постачальника

Файл затвердження постачальника має давати змогу особі, яка була відсутня, відтворити хід прийняття рішення. Вона повинна мати змогу ідентифікувати компанію, побачити, які докази були доступні, розрізнити факти й пояснення, знайти невирішені питання та зрозуміти, що саме було затверджено. Папка з безіменними PDF-файлами не може цього забезпечити.

Цей посібник призначений для закупівельника, який формує довготривалий запис після перевірки постачальника. Це не саме меморандум про затвердження. Якщо вам потрібен короткий документ, який читає особа, що затверджує, почніть з меморандуму про затвердження звіту компанії. Описаний тут файл розміщується поза цим меморандумом і зберігає ланцюжок доказів.

Починайте з рішення, а не з документів

Створіть односторінковий титульний аркуш перед тим, як робити папки. Вкажіть запропонованого юридичного постачальника, його китайську юридичну назву та Єдиний код соціального кредиту (USCC), транзакцію, продукт, валюту, очікувану вартість замовлення, етап оплати, пункт призначення та особу, відповідальну за рішення. Додайте дату початку перевірки та дату «актуальності доказів».

Визначте рішення вузько. «Затверджений постачальник» — це надто широко, якщо перевірка стосувалася одного замовлення на зразки та інструменти USD 18,000. Чітко вкажіть, чи підтримує файл онбординг, замовлення зразків, інструменти, виробниче замовлення на покупку, депозит чи поновлення. Майбутня команда не повинна використовувати обмежене рішення для більшого або суттєво іншого ризику.

Використовуйте папки, що відображають ролі доказів

Практичний каталог має сім пронумерованих розділів: `00 Рішення`, `01 Юридична ідентичність`, `02 Зв’язки між суб’єктами`, `03 Спроможність та якість`, `04 Платежі`, `05 Публічні ризики та комплаєнс` та `06 Контракт та моніторинг`. Нумерація забезпечує стабільний порядок у спільному диску, системі документообігу та паперовій папці.

Розміщуйте докази там, де оцінюється їхня роль, а не там, де на це вказує тип файлу. Банківський лист належить до розділу «Платежі», навіть якщо це PDF. Аудит фабрики належить до розділу «Спроможність», а не до різної папки «Звіти». Якщо один елемент підтримує два розділи, зберігайте один контрольований оригінал і посилайтеся на його ID доказу, а не створюйте неконтрольовані копії.

Архітектура папок має відповідати фактичній перевірці. ISO настанови щодо документованої інформації наголошують на комунікації, доказах та обміні знаннями, водночас дозволяючи організациям обирати обсяг документації, необхідний для підтримки їхніх процесів. Корисним критерієм є не кількість файлів, а те, чи показує запис, що сталося і чому.

Додайте рядок реєстру для кожного важливого елемента

Ведіть один реєстр доказів у корені файлу. Для кожного матеріального елемента зафіксуйте ID доказу; ім’я файлу; тип доказу; спостережувану назву компанії та USCC; джерело або видавця; особу, яка отримала доказ; час отримання або запиту; період, який представляє інформація; питання рішення, яке він підтримує; обмеження доступу; та дату або тригер оновлення.

Розрізняйте «отримано» та «інформація станом на». Пошук компанії, завантажений 15 липня, може містити річний звіт за попередній календарний рік. Фотографія бізнес-ліцензії, зроблена сьогодні, може показувати зміни, зареєстровані місяцями раніше. Ця відмінність особливо важлива під час читання китайських річних звітів.

Чинне в Китаї положення про розкриття інформації підприємствами передбачає виправлення неточної публічної інформації та відображення інформації річного звіту до і після виправлення. Збережіть результат, використаний для прийняття рішення, а потім додайте пізніший результат як нову версію. Ніколи не замінюйте історичні докази мовчки.

Називайте файли, не пошкоджуючи оригінали

Зберігайте оригінал файлу постачальника та створюйте чітко позначену робочу копію, якщо потрібне стандартне найменування. Практичний шаблон — `SUP-014_E03_business-licence_2026-07-15_original.pdf`. Він поєднує запис про постачальника, ідентифікатор доказів, роль документа, дату та стан, не вдаючи, ніби дата є датою набрання документом чинності.

Зафіксуйте початкове ім’я файлу в реєстрі. Для справ із високою вартістю або спірних моментів контрольна сума може показати, чи змінилася збережена копія згодом, але хешування кожного скриншота не замінює джерело, дату та контекст. Ніколи не редагуйте оригінальний скан, щоб зробити його чистішим; зберігайте переклади, анотації та обрізані копії для читання як окремі похідні файли.

Розділяйте чотири типи тверджень

Для кожного важливого питання запишіть чотири позначені записи: спостереження, інтерпретація, пояснення постачальника та відкрите питання. Наприклад: `Спостереження: сторона контракту — Компанія A; бенефіціар — Компанія B.` `Інтерпретація: платіж виходить за межі сторони контракту.` `Пояснення постачальника: B є експортною дочірньою компанією A.` `Відкрите питання: письмовий зв’язок та повноваження на платежі ще не підтверджені.`

Це запобігає копіюванню пояснення постачальника в запис як перевіреного факту. Це також не дозволяє рецензенту трактувати висновок аналітика як результат із реєстру. Якщо зв’язок є матеріальним, застосуйте перевірку зв’язку між банком і бенефіціаром та збережіть документи, які усувають прогалину.

Ведіть реєстр відкритих питань

Одне невирішене питання може бути приховане в десятках листувань електронною поштою. Ведіть короткий реєстр із ідентифікатором проблеми, поясненням її важливості, переліком запитаних доказів, відповідальною особою, контактом постачальника, крайнім терміном, блокувальною віхою, поточним статусом та ідентифікатором доказів закриття. Використовуйте прості статуси, такі як `відкрито`, `очікування відповіді постачальника`, `на розгляді`, `прийнято з умовами` та `закрито`.

Прив’яжіть кожне питання до етапу затвердження транзакції. Відсутність доказів зв’язку з фабрикою може заблокувати затвердження виробництва, але не замовлення зразків низької вартості. Непідтверджені повноваження бенефіціара зазвичай мають блокувати відповідний платіж. Якщо докази є неоднозначними або потребують експертизи в галузі права, санкцій, лабораторних досліджень чи виїзних перевірок, зафіксуйте передачу справи та використайте межу професійної ескалації.

Ризик-орієнтована рамка комплексної перевірки ОЕСР розглядає комплексну перевірку як безперервний процес: виявлення, дії, моніторинг, комунікація та коригування. У файлі затвердження це означає наявність конкретних дій і доказів закриття, а не постійного ярлика «середній ризик» без відповідальної особи.

Фіксуйте затвердження як подію з контролем версій

Підписаний запис має містити рішення, сферу застосування, версію маніфесту доказів, суттєві виключення, відкриті умови, осіб, які затвердили, та їхні ролі, часову мітку затвердження, а також строк дії або тригер для перегляду. Пишіть «затверджено для одного замовлення зразків на суму до USD 3,000, без інструментального оснащення, бенефіціар має залишатися Company A», а не просто «постачальник затверджений».

Зберігайте записи про відхилені та замінені рішення. Пізніше затвердження має посилатися на попередню версію та пояснювати, що змінилося. Підписання контракту, зміна бенефіціара, збільшення вартості замовлення, нова категорія продукції, переїзд, негативні публічні дані, зміна власності або тривалий період без замовлень можуть стати підставою для оновлення. Докази з боку контракту мають відповідати перевіркам юридичної особи та повноважень, а не лише вказувати на статус затвердження.

Контролюйте доступ і строки зберігання

Файл постачальника може містити копії документів, що посвідчують особу, підписи, прямі телефонні номери, банківські реквізити або інформацію про співробітників, яка не потрібна більшості рецензентів. Зберігайте конфіденційні матеріали в обмеженій підпапці, надавайте ширшій команді редаговану робочу копію та фіксуйте, чому саме потрібні ці персональні дані.

Для організацій, на які поширюється режим Великої Британії, керівництво ICO щодо мінімізації даних зазначає, що персональні дані мають бути достатніми, релевантними та обмеженими метою обробки. Його керівництво щодо обмеження строку зберігання рекомендує встановлювати документально зафіксовані строки зберігання та періодично їх переглядати. Застосовуйте закони та політики, актуальні для вашої організації; не зберігайте матеріали, що посвідчують особу, необмежено довго лише тому, що сховище є дешевим.

Перевірте файл під час передачі справ

Уявіть, що менеджер із закупівель залишає компанію через два тижні після затвердження вигаданого постачальника `Harborline Components`. Новий співробітник відкриває файл перед виробничим авансом у розмірі 30%. Титульна сторінка вказує, що рішення стосувалося лише зразків та інструментального оснащення. Маніфест ідентифікує юридичну особу та датує кожне джерело. Реєстр відкритих питань показує, що фабрика є пов’язаною, але новий бенефіціар не верифікований. Запис про затвердження зазначає, що будь-яка зміна бенефіціара повторно відкриває перевірку платежу.

Новому співробітнику не потрібно відновлювати інформацію про постачальника з поштової скриньки чи припускати, що старе затвердження покриває новий аванс. Він може призупинити лише питання платежу, зберегти решту роботи та додати нову версію рішення, коли надійдуть докази. Саме це є стандартом для придатного до використання файлу.

Завершуйте перевіркою можливості відтворення

Перед закриттям файлу попросіть колегу, який не проводив перевірку, визначити постачальника, сферу транзакції, вирішальні докази, невирішені питання, умови, осіб, які затвердили, та наступний тригер для оновлення. Якщо йому доводиться запитувати, який PDF є актуальним, або шукати в електронній пошті причину умови, файл не є завершеним.

Для ширшої послідовності робіт з ідентифікації, оцінки спроможності, платежів, контрактів та моніторингу використовуйте процес комплексної перевірки постачальників. Файл затвердження є його довготривалою пам’яттю: достатньо компактним для навігації, достатньо детальним для захисту рішень і чітким щодо того, що залишається невідомим.