तुमच्या पीडीएफ/ए फाइल्स कंप्लायन्स ऑडिटमध्ये का नाकारल्या जात आहेत

हे चित्र. फायनान्स टीम क्लायंट स्टेटमेंट्स आणि ट्रान्झॅक्शन रेकॉर्ड म्हणून संग्रहित करत आहे PDF/A गेल्या सहा वर्षांपासून. प्रत्येक फाइलमध्ये योग्य मेटाडेटा टॅग असतो. प्रत्येक कर्मचाऱ्याचा विश्वास आहे की फाइल जतन केल्यावर काम पूर्ण झाले आहे. मग एक नियामक नियमित पुनरावलोकनासाठी दर्शवितो, त्या मूठभर फायली एका व्हॅलिडेटरद्वारे चालवतात आणि त्यापैकी अर्ध्या अयशस्वी होतात.

कोणत्याही कागदपत्रांना कधीही हात लावला नाही, काहीही वेगळे केले गेले नाही. हे दस्तऐवज सुरुवातीला कधीच अनुरूप नव्हते, त्यांनी फक्त अनुपालनाचा दावा केला. आणि "पीडीएफ/ए असल्याचा दावा करणे" आणि "पीडीएफ/ए असणे" मधील हाच फरक आज दस्तऐवज संग्रहणाच्या सर्वात वारंवार आणि महागड्या अंधस्थळांपैकी एक आहे.

म्हणून जर तुमचे संग्रहणाचे प्रयत्न अयशस्वी होत असतील आणि/किंवा तुम्हाला प्रक्रियेच्या उजव्या बाजूला राहायचे असेल तर, खरोखर काय चूक होत आहे आणि त्यासाठी एक मजबूत कार्यप्रवाह कसा स्थापित करायचा ते येथे आहे पीडीएफ/ए अनुपालन.

पीडीएफ/ए अनुपालन बहुतेक संघांच्या लक्षात येण्यापेक्षा अधिक महत्त्वाचे का आहे

PDF/A हे फक्त "संग्रहित पीडीएफ" नाही. दस्तऐवज उघडेल आणि आत्ता, दहा वर्षांत आणि पन्नास वर्षांत, त्या वेळी ते वाचण्यासाठी कोणतेही सॉफ्टवेअर किंवा फॉन्ट स्थापित केले गेले असले तरीही ते अगदी तशाच प्रकारे उघडेल याची खात्री करण्यासाठी हे ISO मानकांद्वारे परिभाषित केलेले स्वरूप आहे.

जेथे नियमन संबंधित आहे तेथे ते खूप महत्त्व घेते. GDPR सारख्या नियमांनी कंपनीने त्याच्या वैयक्तिक डेटाची अखंडता, गोपनीयता आणि उपलब्धता राखली पाहिजे. MiFID II सारखे नियम हे आदेश देतात की एखादी फर्म क्लायंटकडून वर्षानुवर्षे संप्रेषण आणि व्यवहार डेटा अशा स्वरूपात संग्रहित करते जी गुप्तपणे बदलली जाऊ शकत नाही. येथे काहीतरी चुकीचे करा, आणि तुम्हाला तुमच्या वार्षिक कमाईच्या एकल-अंकी टक्केवारीत मोजल्या जाणाऱ्या दंडाला सामोरे जावे लागू शकते, जी मोठ्या कंपनीसाठी एक महत्त्वपूर्ण रक्कम आहे.

जे का कधी पीडीएफ/ए अनुपालन संग्रहणात कमतरता आहे, ती तंत्रज्ञानासह समस्या मानली जात नाही. ही नियामक अनुपालन समस्या मानली जाते आणि जबाबदारी संबंधित फर्मची आहे.

PDF/A फायली प्रमाणीकरण अयशस्वी होण्याची सर्वात सामान्य कारणे

बहुतेक पीडीएफ/ए अयशस्वी पुनरावृत्ती समस्यांच्या छोट्या सूचीकडे परत येतात. येथे गोष्टी सहसा चुकतात.

फॉन्ट जे पूर्णपणे एम्बेड केलेले नाहीत

निःसंशयपणे, हे समस्येचे सर्वात सामान्य कारण आहे. पीडीएफ/ए फाइलसाठी, दस्तऐवजात वापरलेले सर्व फॉन्ट फाइलमध्ये एम्बेड केलेले असणे आवश्यक आहे जेणेकरून दर्शकाला त्याच्या मशीनवर फॉन्ट स्थापित करावे लागणार नाहीत. बऱ्याच घटनांमध्ये, पीडीएफ फाइलमध्ये फॉन्टचा फक्त उपसंच एम्बेड केलेला असतो, जे सहसा प्रमाणीकरण प्रक्रियेत अपयशी ठरते. वास्तविक जीवनातील PDF/A फायलींवर केलेल्या मागील अभ्यासातून, असे आढळून आले आहे की अर्ध्याहून अधिक गैर-अनुरूप घटना फॉन्टमधून उद्भवतात.

नॉन-डिव्हाइस स्वतंत्र रंग स्पेस

PDF/A आवश्यकतांनुसार, तुम्ही दस्तऐवज पाहण्यासाठी कोणते डिस्प्ले मॉनिटर, प्रिंटर किंवा ॲप्लिकेशन सॉफ्टवेअर वापरत आहात याची पर्वा न करता सुसंगत रेंडरिंग सुनिश्चित करण्यासाठी डिव्हाइस स्वतंत्र ICC प्रोफाइलद्वारे रंगाचे वर्णन केले पाहिजे. विशेष म्हणजे, PDF/A निर्मितीमधील सर्वात सामान्यपणे वचनबद्ध त्रुटींपैकी एक दस्तऐवज काही रंगाच्या जागेवर आधारित आहे (जसे की साधा sRGB) ज्यामध्ये आवश्यक ICC प्रोफाइल नाही.

वास्तवाशी जुळणारा मेटाडेटा

प्रत्येक PDF/A दस्तऐवजात XMP मेटाडेटा असणे आवश्यक आहे की ते PDF/A च्या कोणत्या आवृत्तीचे पालन करते (PDF/A-1, -2 किंवा -3) आणि कोणत्या अनुपालन स्तरावर (A, B किंवा U). असा मेटाडेटा प्रदान करण्यात अयशस्वी होणे किंवा तो सदोष किंवा दिशाभूल करणाऱ्या पद्धतीने प्रदान करणे म्हणजे ऑडिटिंग सुरू होण्यापूर्वी त्वरित अपयश.

एक गोंधळलेला वाढीव अद्यतन इतिहास

संपूर्ण दस्तऐवज सुरवातीपासून पुन्हा न लिहिता वाढीव अद्यतन विद्यमान PDF दस्तऐवजात अतिरिक्त डेटा जोडते. मानक पीडीएफ फाइल्समध्ये हा एक सोयीस्कर पर्याय आहे, परंतु यासाठी पीडीएफ/ए फाइल्स, हे काळजीपूर्वक केले जाते:

• •PDF/A-1 वाढीव अद्यतनांना अजिबात अनुमती देत ​​नाही. कोणत्याही संपादनासाठी फाइलचे संपूर्ण पुनर्लेखन तयार करावे लागते.
• •PDF/A-2 आणि PDF/A-3 मध्ये, वाढीव अद्यतनांना परवानगी आहे; तथापि, जोडलेला डेटा उर्वरित दस्तऐवजाशी सुसंगत असणे आवश्यक आहे. नॉन-एम्बेडेड फॉन्ट वापरून पुनरावृत्ती जोडणे, उदाहरणार्थ, संपूर्ण फाइल अवैध ठरते.
• •फाईलच्या शीर्षलेखातील आवृत्ती क्रमांक देखील दस्तऐवजाच्या अंतर्गत कॅटलॉगमध्ये घोषित केलेल्या आवृत्तीशी जुळणे आवश्यक आहे. येथे न जुळणे ही चुकणे सोपे आहे आणि प्रमाणीकरण अयशस्वी करण्याचा एक सोपा मार्ग आहे.

दस्तऐवजाचे PDF/A मध्ये रूपांतर करणे PDF/A च्या प्रमाणीकरणाच्या समतुल्य नाही

हे असे क्षेत्र आहे जिथे अनेक कंपन्या अडखळतात; आणि ते स्पष्टपणे नमूद केले पाहिजे.

रूपांतरण दस्तऐवज त्याच्या मूळ स्वरूपाकडे दुर्लक्ष करून घेते (ते वर्ड डॉक, एचटीएमएल पृष्ठ किंवा पीडीएफ असो) आणि त्याचे रूपांतर पीडीएफ/ए फाइल. असे करताना, सॉफ्टवेअर मेटाडेटा जोडते जे नवीन तयार केलेल्या फाइलला PDF/A-अनुरूप फाइल म्हणून प्रमाणित करते.

प्रमाणीकरण ही पूर्णपणे वेगळी प्रक्रिया आहे जिथे विशेष प्रोग्राम सत्यापित करतो की फाइल प्रमाणित होण्यासाठी सर्व आवश्यकता पूर्ण करते.

परंतु येथे ट्विस्ट आहे: रूपांतरण स्टेजवर समाविष्ट केलेला मेटाडेटा हा दावा आहे, पुरावा नाही. फाइलमध्ये त्याच्या मेटाडेटामध्ये माहिती असू शकते की ती PDF/A-2b अनुरूप आहे, तरीही PDF/A-2b पडताळणी पास करण्यात अयशस्वी झाली आहे.

हे वाईट बनवत आहे, अनेक विनामूल्य आणि मुक्त स्रोत PDF/A प्रमाणीकरणकर्ते ह्युरिस्टिक्सचा वापर करा आणि संपूर्ण स्पेसिफिकेशनशी ओळ-दर-लाइन तुलना करा. याचा अर्थ असा की ते अनेकदा दावा करतील की एखादे दस्तऐवज "कदाचित" वैध आहे, जे सुरुवातीला चांगली बातमी वाटेल, परंतु ते निश्चितपणे नाही. अनुपालनाची पडताळणी करण्याचा आणखी एक मार्ग म्हणजे दृष्यदृष्ट्या, जिथे कोणीतरी कागदपत्र उघडते आणि ते योग्य आहे की नाही ते पाहते.

किमान, प्रत्येक PDF/A फाईलला हे आवश्यक आहे:

• •सर्व फॉन्ट, प्रतिमा आणि सामग्री थेट एम्बेड करा, बाहेरून काहीही संदर्भित नाही
• •ऑडिओ, व्हिडिओ, JavaScript आणि XFA फॉर्म पूर्णपणे टाळा
• •LZW कॉम्प्रेशन, एन्क्रिप्शन आणि पासवर्ड संरक्षण वगळा
• •प्रत्येक संवादात्मक फॉर्म फील्डला योग्य स्वरूपाचा शब्दकोश द्या
• •XMP मानक वापरून मेटाडेटा संचयित करा

प्रमाणीकरण वगळा, आणि तुमचा विश्वास आहे की यापैकी प्रत्येक बॉक्स अचूकपणे तपासला गेला आहे, त्याची पुष्टी न करता.

अनुरूपता पातळी अदलाबदल करण्यायोग्य नाहीत

अयशस्वी ऑडिटचा आणखी एक शांत स्त्रोत म्हणजे अनुरूपता-स्तर जुळत नाही, जिथे फाइल प्रत्यक्षात पूर्ण होत नसलेल्या अनुपालनाच्या पातळीचा दावा करते.

येथे दोन गोष्टी समजून घेण्यासारख्या आहेत:

मानके स्वतः एकमेकांपासून भिन्न आहेत. PDF/A-1, PDF/A-2, आणि PDF/A-3 अनेक वर्षांच्या अंतराने प्रकाशित झाले होते आणि त्यांचे समान नियम नाहीत. PDF/A-1, उदाहरणार्थ, पारदर्शकता किंवा स्तरांना समर्थन देत नाही आणि केवळ A आणि B अनुरूपता स्तर प्रदान करते. PDF/A-2 पारदर्शकता, स्तर आणि अगदी नवीन स्तरासह, इतर PDF/A फायली एम्बेड करण्यासाठी समर्थन जोडते, U.

अनुरूपता पातळी एकमेकांवर तयार होतात. लेव्हल U मध्ये लेव्हल B साठी आवश्यक असलेल्या सर्व गोष्टींचा समावेश होतो आणि लेव्हल A मध्ये लेव्हल U साठी आवश्यक असलेल्या सर्व गोष्टींचा समावेश होतो, तसेच अधिक. योग्य पातळी निवडणे हा केवळ तांत्रिक तपशील नसून, तुमचे संग्रहण किती वर्षे वापरता येईल याचे वास्तविक परिणाम असलेला हा निर्णय आहे. दावा संग्रहण जेथे कागदपत्रे शोधण्यायोग्य आणि मजकूर काढण्यायोग्य राहणे आवश्यक आहे, उदाहरणार्थ, किमान U स्तर आवश्यक आहे. केवळ B स्तर याची हमी देत ​​नाही.

स्तर U विशेषतः मजकूर अखंडतेबद्दल आहे. हे सुनिश्चित करते की दस्तऐवजातील अंतर्निहित युनिकोड मजकूर विश्वासार्हपणे काढला जाऊ शकतो किंवा नंतर शोधला जाऊ शकतो, जे कोणत्याही संग्रहणासाठी खूप महत्त्वाचे आहे ज्याचे पुनरावलोकन किंवा फाइलिंगनंतर अनेक वर्षांनी शोध घेणे आवश्यक आहे.

ऑडिट-प्रूफ PDF/A पाइपलाइन प्रत्यक्षात कशी दिसते

एक संरक्षित संग्रहण प्रक्रिया सामान्यतः या आकाराचे अनुसरण करते:

स्त्रोत दस्तऐवज सामान्य करा → PDF/A मध्ये रूपांतरित करा → स्वतंत्रपणे सत्यापित करा → फाइल संग्रहित करा

ही अशी पायरी आहे जी बहुतेक संस्था सहसा वगळतात, परंतु ही सर्वात महत्वाची पायरी आहे. जर फाइलला दुसऱ्या फॉर्ममध्ये रूपांतरित करणारे सॉफ्टवेअर हे रूपांतरण प्रक्रियेचे प्रमाणीकरण करणारे सॉफ्टवेअर असेल, तर तुम्ही फक्त सॉफ्टवेअरद्वारे व्युत्पन्न केलेल्या आउटपुटचे प्रमाणीकरण करत आहात जे सॉफ्टवेअरला समजते. जोपर्यंत फाइल स्वतंत्र व्हॅलिडेटरद्वारे प्रमाणित होत नाही तोपर्यंत सॉफ्टवेअरद्वारे केलेल्या तपशीलाचे चुकीचे स्पष्टीकरण शोधले जाणार नाही.

ठोस ऑडिट ट्रेलमध्ये हे समाविष्ट असावे:

• •प्रत्येक फाईल कोणी आणि केव्हा रूपांतरित केली याची नोंद
• •वापरलेल्या साधनाचे नाव आणि आवृत्ती
• •दावा केलेल्या अनुरूपता पातळीची पुष्टी करणारा एक स्वतंत्र प्रमाणीकरण अहवाल, आदर्शपणे टाइमस्टँप केलेला आणि दस्तऐवजाच्या बाजूला संग्रहित

निर्मिती आणि प्रमाणीकरण वेगवेगळ्या प्रणालींद्वारे करणे अपेक्षित आहे; प्रमाणीकरण अहवाल मशीन-वाचनीय आणि ऑडिट पुरावा म्हणून जतन करणे आवश्यक आहे; आणि दावा केलेला आणि वास्तविक सामग्रीमधील सुसंगतता वास्तविक असणे आवश्यक आहे. GDPR आणि MiFID II नुसार, अखंडतेचा पुरावा सुनिश्चित करण्याची जबाबदारी संपूर्णपणे संग्रह धारकाची आहे, सॉफ्टवेअर प्रदात्याची नाही.

निष्कर्ष

पीडीएफ/ए फाईल जी स्वतंत्रपणे प्रमाणित केली गेली नाही ती खरोखर फक्त एक फाईल आहे जी आशा करते की ती अनुरूप आहे. नियामकाने संग्रहण पाहण्यास सांगेपर्यंत ते वर्षानुवर्षे ठीक असू शकते. इमारत PDF/A प्रमाणीकरण एक स्वतंत्र, स्वतंत्र पायरी म्हणून पाइपलाइनमध्ये जाणे हे आशादायक संग्रहणाचे संरक्षण करण्यायोग्य बनवते आणि नंतर दंड भरण्यापेक्षा आता तयार करणे ही खूपच स्वस्त सवय आहे.

---