পরিধি ও ঐতিহাসিক সংস্করণ
এই প্রবন্ধ 19 আগস্ট 2020-এ প্রকাশিত IRAS-এর তৃতীয় সংস্করণের CRS XML ব্যবহারকারী নির্দেশিকা অনুসরণ করে। এতে OECD-এর CRS XML স্কিমা সংস্করণ 2.0 বর্ণিত, যা 1 ফেব্রুয়ারি 2021 থেকে জমা দেওয়ার জন্য আবশ্যক; তার আগের জমায় সংস্করণ 1.01 ব্যবহৃত হতো। নির্দেশিকাটি সিঙ্গাপুরের শনাক্তকারী, অনুপস্থিত TIN-এর কারণ, নিষ্ক্রিয় NFE-এর রিপোর্টিং এবং সংশোধন পরিচালনার জন্য OECD-এর নির্দেশনা মানিয়ে নিয়েছে। এটি নির্দিষ্ট সংস্করণের কারিগরি নির্দেশিকা, যা CRS Regulations ও রিপোর্টিং নির্দেশনার সঙ্গে পড়তে হবে; কোনো অ্যাকাউন্ট রিপোর্টযোগ্য কি না নির্ধারণের বিকল্প নয়।
ইলেকট্রনিক ফাইল ও জমা দেওয়ার ক্রম
শূন্য রিটার্নসহ সব CRS রিটার্ন ইলেকট্রনিকভাবে জমা দিতে হয়। একটি প্রতিষ্ঠান বিভিন্ন রিপোর্টযোগ্য অধিক্ষেত্রের অ্যাকাউন্ট এক রিটার্নে একত্র করতে পারে। নির্দেশিকা অনুযায়ী ডিজিটাল স্বাক্ষর, এনক্রিপশন বা কম্প্রেশন ছাড়াই নিরাপদ পোর্টালে XML আপলোড করা যায়; কম্প্রেশনবিহীন ফাইলের সর্বোচ্চ আকার 5 MB। বড় রিটার্ন ভাগ করুন এবং প্রথম ফাইল IRAS গ্রহণ করার পরেই পরের ফাইলগুলো জমা দিন। ভুল থাকা প্রাথমিক জমার পরের দিনের আগে সংশোধন বা বাতিলের ফাইল জমা দেওয়া উচিত নয়। XML ফাইল ছাড়াই AEOI e-Services-এ সরাসরি শূন্য রিটার্ন দাখিল করা যায়; পূরণযোগ্য PDF-এর বিকল্পও উল্লেখ করা হয়েছে। বাধ্যতামূলক ফাইলের নাম নেই, তবে MessageRefID দিয়ে নাম রাখার পরামর্শ দেওয়া হয়েছে।
এনকোডিং, বিশেষ চিহ্ন ও যাচাইয়ের অবস্থান
ফাইলের শুরুতে XML declaration দিন, UTF-8 ব্যবহার করুন এবং byte order mark বাদ দিন। অ্যাম্পারস্যান্ড, অ্যাপস্ট্রফি, দুই কোণবন্ধনী ও উদ্ধৃতিচিহ্ন XML entity দিয়ে লিখুন। নির্দেশিকায় তথ্যের মধ্যে হ্যাশচিহ্ন, পরপর দুটি ড্যাশ এবং স্ল্যাশ-অ্যাস্টেরিস্কের ক্রম নিষিদ্ধ; এগুলোর গ্রহণযোগ্য বিকল্প দেওয়া নেই। আবশ্যক validation উপাদান উপস্থিত থাকতে হবে; validation choice হলে প্রযোজ্য বিকল্পটি দিতে হবে। স্কিমায় ঐচ্ছিক কিছু উপাদান নির্দিষ্ট পরিস্থিতিতে তথ্য অনুপলব্ধ না হলে বিষয়গতভাবে বাধ্যতামূলক। অন্য ঐচ্ছিক উপাদান প্রস্তাবিত, অথবা CRS-এর জন্য প্রাসঙ্গিক নয়। সংস্করণ 2.0-তে স্ট্রিংয়ে অন্তত একটি অক্ষর থাকা আবশ্যক: অনুপলব্ধ ঐচ্ছিক উপাদান ফাঁকা না-পাঠিয়ে বাদ দিন। জমা দেওয়ার আগে স্কিমার সঙ্গে ফাইল যাচাই করুন।
হেডারে পরিচয়, দেশ ও বার্তার ধরন
SendingCompanyIN প্রেরককে শনাক্ত করে; প্রেরক রিপোর্টকারী প্রতিষ্ঠান বা নিযুক্ত সেবাদাতা হতে পারে। Entity ID Type, একটি স্পেস এবং Entity ID এই ক্রমে লিখুন; যেমন ASGD A1234567D। তালিকাভুক্ত ধরন হলো UEN-Business, UEN-Local Co, UEN-Others, ASGD ও ITR। IRAS-এ রিপোর্ট করার জন্য TransmittingCountry ও ReceivingCountry দুটোই SG এবং MessageType হলো CRS। Warning ও Contact ফাঁকা রাখুন: প্রক্রিয়াকরণ স্বয়ংক্রিয়, আর যোগাযোগ হয় নিবন্ধিত যোগাযোগকারী অথবা জমার acknowledgement ID উল্লেখ করে CRS@iras.gov.sg-এর মাধ্যমে। স্ট্রিং ফাঁকা না-থাকার নিয়ম অনুযায়ী এই ফাঁকা উপাদানগুলো বাদ দিতে হবে।
MessageRefID ও রিপোর্টিংয়ের তারিখ
IRAS অনন্য 25-অক্ষরের MessageRefID নির্ধারণ করেছে: চার অঙ্কের রিপোর্টিং বছর, দশ অক্ষরের প্রেরকের কর-রেফারেন্স, আট অঙ্কের ফাইল তৈরির তারিখ YYYYMMDD এবং তিন অঙ্কের ক্রমিক নম্বর। কর-রেফারেন্স দশ অক্ষরের ছোট হলে শেষে হাইফেন যোগ করুন; সত্তার ধরন বোঝানো লেবেল যোগ করবেন না। একই দিনে তৈরি ফাইলের ক্রমিক নম্বর 000 থেকে 999 হতে পারে; নির্দেশিকার উদাহরণে 001 ও 002 ব্যবহৃত। ReportingPeriod হলো বছরের শেষ তারিখ, YYYY-MM-DD বিন্যাসে; যেমন 2017-12-31। Timestamp-এর বিন্যাস YYYY-MM-DDThh:mm:ss; সেকেন্ডের ভগ্নাংশও থাকতে পারে। বার্তার শনাক্তকারীতে সেবাদাতার প্রেরক নম্বর ব্যবহৃত হয়, কিন্তু নথির শনাক্তকারীতে রিপোর্টকারী প্রতিষ্ঠানের নম্বর ব্যবহৃত হয়।
নতুন, সংশোধিত ও শূন্য বার্তার নির্দেশক
MessageTypeIndic আবশ্যক এবং পোর্টালে নির্বাচিত জমার ধরনের সঙ্গে মিলতে হবে। CRS701 মানে নতুন তথ্য; CRS702 আগে জমা দেওয়া তথ্যের সংশোধন বা মুছে ফেলা; CRS703 মানে আবশ্যক অ্যাকাউন্ট পর্যালোচনার পর কোনো রিপোর্টযোগ্য তথ্য নেই। শূন্য XML রিটার্নে AccountReport বাদ দেওয়া যায়। CRS-এ হেডার বা DocSpec কোনো স্তরেই CorrMessageRefID ব্যবহৃত হয় না। পুরো বার্তা বাতিল করতে হেডারের বাতিল-রেফারেন্সের বদলে তার রেকর্ডগুলো মুছে ফেলতে হয়।
ব্যক্তির কর-আবাসিকতা ও অনুপস্থিত কর-শনাক্তকরণ নম্বর
PersonParty_Type ব্যক্তি অ্যাকাউন্টধারী ও নিয়ন্ত্রণকারী ব্যক্তির জন্য ব্যবহৃত। প্রতিটি রিপোর্টযোগ্য কর-আবাসিক অধিক্ষেত্রের জন্য আলাদা AccountReport দিন; IRAS-এর এক অ্যাকাউন্ট রেকর্ডে সব অধিক্ষেত্র একত্র করবেন না। গৃহীত তথ্যের কর-আবাসিকতা বদলাতে হলে সংশ্লিষ্ট রিপোর্ট বাতিল করে নতুন দেশের কোডসহ নতুন রিপোর্ট জমা দিতে হবে। নথিবিহীন অ্যাকাউন্টে SG ব্যবহার হয়। আবাসিক অধিক্ষেত্রে স্বীকৃত একাধিক নম্বর থাকলে TIN পুনরাবৃত্তি করা যায়। নম্বর অনুপলব্ধ হলে প্রস্তাবিত কারণ-কোড হলো: TIN ইস্যু না-করার জন্য IRAS101; রিপোর্টের আবশ্যকতা না-থাকলে IRAS102; পরিস্থিতি পরিবর্তনে নতুন self-certification সংগ্রহ চললে IRAS103; অন্যান্য নথিসমর্থিত কারণে IRAS104। TIN বা কারণ কোনোটিই না-দিলে শূন্য বা কৃত্রিম অক্ষর না-বসিয়ে উপাদানটি বাদ দিন। ইস্যুকারী দেশ অজানা হলে issuedBy বাদ দিন।
ব্যক্তির নাম ও জন্মসংক্রান্ত তথ্য
FirstName ও LastName আবশ্যক। পূর্ণ প্রথম নাম অনুপলব্ধ হলে আদ্যক্ষর বা NFN ব্যবহার করা যায়; আইনত ব্যবহৃত পূর্বাংশ, পরাংশ বা দুটি পদবি LastName-এ রাখা যায়, যদিও সুগঠিত নাম দেওয়া অগ্রাধিকার পায়। ঐচ্ছিক অংশে আগের সম্মানসূচক উপাধি, উপাধি, মধ্যনাম, নামের পূর্বাংশ, প্রজন্ম-শনাক্তকারী ও পরাংশ অন্তর্ভুক্ত। নামের ধরন-কোড OECD202–208 যথাক্রমে ব্যক্তির নাম, বিকল্প নাম, ডাকনাম, অন্য পরিচিত নাম, ব্যবসায় ব্যবহৃত নাম, আইনগত নাম ও জন্মনাম বোঝায়। Birthdate-এর বিন্যাস YYYY-MM-DD; আগে থেকে থাকা অ্যাকাউন্টে তা অনুপলব্ধ হলে বাদ দেওয়া যায়। জন্মস্থান রিপোর্ট করলে শহর, ঐচ্ছিকভাবে তার উপবিভাগ এবং বর্তমান দেশের কোড অথবা আগের দেশের নাম দিন। CRS-এর জন্য Nationality প্রযোজ্য নয়।
ঠিকানা ও নথিবিহীন অ্যাকাউন্ট
স্থায়ী আবাসের ঠিকানা ব্যবহার করুন; তা অনুপলব্ধ হলে রেকর্ডে থাকা ডাকের ঠিকানা দিন। AddressFix অগ্রাধিকার পায়: City আবশ্যক, PostCode থাকলে অন্তর্ভুক্ত করা উচিত; ঐচ্ছিক অংশে সড়ক, ভবন, ইউনিট, তলা, জেলা, পোস্টবক্স ও রাজ্য/প্রদেশ আছে। সুগঠিত ঠিকানায় শহর, প্রদেশ ও পোস্টকোড নির্দিষ্ট তথ্যঘরে রেখে সড়কের লাইন AddressFree-তে দেওয়া যায়। সুগঠিত ঠিকানা সম্ভব না হলে স্পেস, স্ল্যাশ বা নতুন লাইন দিয়ে বিভক্ত একটি AddressFree স্ট্রিং ব্যবহার করে AddressFix বাদ দিন। তবুও CountryCode আবশ্যক। নথিবিহীন অ্যাকাউন্টে SG এবং AddressFree-তে “Undocumented” ব্যবহার হয়। আইনগত ঠিকানার কোড OECD301–305 যথাক্রমে আবাসিক/ব্যবসায়িক, আবাসিক, ব্যবসায়িক, নিবন্ধিত অফিস ও অনির্দিষ্ট বোঝায়।
সত্তার পরিচয়
OrganisationParty_Type-এ কর-আবাসিকতা, শনাক্তকরণ নম্বর, আইনগত নাম ও ঠিকানা থাকে। একাধিক রিপোর্টযোগ্য কর-আবাসিকতা হলে আলাদা AccountReport প্রয়োজন; গৃহীত আবাসিক কোড বদলানোর ক্ষেত্রেও বাতিল করে নতুন রিপোর্ট দেওয়ার পদ্ধতি প্রযোজ্য। সত্তার IN হতে পারে TIN, কোম্পানির নিবন্ধন নম্বর বা আবাসিক কর কর্তৃপক্ষের স্বীকৃত অন্য নম্বর; এটি একাধিকবার দেওয়া যায়। অনুপস্থিত IN-এর কারণেও একই IRAS101–104 কাঠামো প্রযোজ্য; অন্যথায় নম্বর বানিয়ে না-লিখে অনুপলব্ধ উপাদান বাদ দিন। issuedBy ইস্যুকারী অধিক্ষেত্র বোঝায় এবং INType নম্বরের ধরন বর্ণনা করতে পারে। আইনগত নাম ও ঠিকানা validation উপাদান। নামের ধরনসংক্রান্ত attribute ঐচ্ছিক।
রিপোর্টকারী প্রতিষ্ঠান ও CRS-এর মূল অংশ
প্রতিটি CrsBody-তে ReportingFI ও একটি ReportingGroup দিন। ওই group-এর মধ্যে AccountReport পুনরাবৃত্তি হয়। ReportingFI অ্যাকাউন্ট রক্ষণাবেক্ষণকারী প্রতিষ্ঠানকে শনাক্ত করে, ফাইল প্রেরণকারী সেবাদাতাকে নয়। এর IN-এ নিবন্ধিত সিঙ্গাপুরি কর-রেফারেন্স ব্যবহার হয়, যার মধ্যে সত্তার ধরন, স্পেস ও শনাক্তকারী থাকবে; সত্তার ধরন INType-এ সরাবেন না। প্রতিষ্ঠানের একাধিক রেফারেন্স থাকলে CRS নিবন্ধনের সঙ্গে যুক্তটি ব্যবহার করুন। trustee-documented trust-এর ক্ষেত্রে শুধু trustee নয়, trust ও IRAS-এর দেওয়া TDT রেফারেন্স শনাক্ত করুন। ReportingFI ও অ্যাকাউন্ট রিপোর্টে DocSpec থাকে। CRS-এর জন্য Sponsor, Intermediary ও PoolReport প্রযোজ্য নয়। শূন্য রিটার্ন বা শুধু প্রতিষ্ঠান-সংক্রান্ত সংশোধন ছাড়া AccountReport বাধ্যতামূলক।
অ্যাকাউন্ট নম্বর, অবস্থা ও ধারকের শ্রেণি
প্রতিষ্ঠানের অ্যাকাউন্ট নম্বর বা সমতুল্য অনন্য শনাক্তকারী ব্যবহার করুন; কোনো নম্বর-পদ্ধতিই না-থাকলে কেবল ব্যতিক্রমী ক্ষেত্রে NANUM ব্যবহার করুন। OECD601–605 কোড যথাক্রমে IBAN, অন্য ব্যাংক নম্বর, ISIN, অন্য সিকিউরিটিজ নম্বর ও অন্য শনাক্তকারী বোঝায়। IBAN/ISIN থাকলে যথাযথ ধরনসহ দিন। অ্যাকাউন্টে নথিবিহীন, বন্ধ ও নিষ্ক্রিয় অবস্থার Boolean attribute থাকতে পারে। AccountHolder হবে Individual অথবা Organisation; সত্তার জন্য AcctHolderType-ও প্রয়োজন। CRS101 হলো রিপোর্টযোগ্য নিয়ন্ত্রণকারী ব্যক্তিসহ নিষ্ক্রিয় NFE, CRS102 রিপোর্টযোগ্য ব্যক্তি এবং CRS103 নিজেই রিপোর্টযোগ্য এমন নিষ্ক্রিয় NFE। ব্যক্তি অ্যাকাউন্টধারীর জন্য সত্তার শ্রেণি প্রয়োগ করবেন না।
নিষ্ক্রিয় NFE ও নিয়ন্ত্রণকারী ব্যক্তির রিপোর্টিং: ছয় পরিস্থিতি
IRAS সাধারণত প্রতিটি রিপোর্টযোগ্য নিয়ন্ত্রণকারী ব্যক্তির জন্য আলাদা অ্যাকাউন্ট রিপোর্ট চায়। নির্দেশিকার ছয় পরিস্থিতি হলো: (1) সত্তা ও একমাত্র CP উভয়েই X-এর কর-আবাসিক হলে একটি CRS101 রিপোর্ট; (2) সত্তা ও দুই CP সবাই X-এর কর-আবাসিক হলে প্রত্যেক CP-এর জন্য একটি করে মোট দুটি CRS101 রিপোর্ট; (3) সত্তা রিপোর্টযোগ্য X-এ এবং CP-রা রিপোর্টযোগ্য Y ও Z-এ হলে দুটি CRS101 এবং সত্তার জন্য একটি CRS103 রিপোর্ট; (4) সত্তা X-এ, একজন CP X-এ এবং অন্যজন Y-এ হলে সত্তার আলাদা রিপোর্ট ছাড়া দুটি CRS101 রিপোর্ট; (5) সত্তা রিপোর্টযোগ্য নয় এমন X-এ এবং CP রিপোর্টযোগ্য Y-এ হলে একটি CRS101 রিপোর্ট; (6) সত্তা রিপোর্টযোগ্য X-এ এবং CP রিপোর্টযোগ্য নয় এমন Y-এ হলে একটি CRS103 রিপোর্ট। প্রত্যেক CP-এর পরিচয়ের তথ্য PersonParty_Type অনুযায়ী দেওয়া হয়। একই দেশে থাকেন বলেই একাধিক রিপোর্টযোগ্য CP-কে এক রিপোর্টে একত্র করবেন না।
নিয়ন্ত্রণকারী ব্যক্তির সম্পর্ক
তথ্য থাকলে CtrlgPersonType দিয়ে CP-এর ভূমিকা শনাক্ত করা হয়। CRS801–803 হলো আইনগত সত্তার মালিকানার মাধ্যমে নিয়ন্ত্রণ, অন্য উপায়ে নিয়ন্ত্রণ অথবা জ্যেষ্ঠ ব্যবস্থাপনা কর্মকর্তা। trust-এর CRS804–808 ভূমিকা হলো প্রতিষ্ঠাতা, trustee, protector, সুবিধাভোগী ও অন্য। অন্য আইনগত ব্যবস্থার সমতুল্য ভূমিকা একই ক্রমে CRS809–813। কারও একাধিক ভূমিকা থাকলে, যেমন trust-এর প্রতিষ্ঠাতা ও সুবিধাভোগী, একই অ্যাকাউন্ট রিপোর্টে প্রতিটি সম্পর্কের জন্য controlling-person উপাদান পুনরাবৃত্তি করুন। প্রতিষ্ঠানের রেকর্ডে তথ্য না-থাকলে ভূমিকার উপাদান বাদ দিন।
ব্যালান্স, বন্ধ হওয়া ও অর্থপ্রদানের শ্রেণি
অ্যাকাউন্ট অনুযায়ী ব্যালান্স বা মূল্য রিপোর্ট করুন: আমানত/হেফাজতি অ্যাকাউন্টের ব্যালান্স, বিমা বা annuity চুক্তির cash value, অথবা ঋণ/ইকুইটি স্বার্থের মূল্য। বন্ধ অ্যাকাউন্টে শূন্য ব্যালান্স ও closed-account নির্দেশক আবশ্যক। অঙ্কে দশমিকের পরে দুটি ঘর এবং আবশ্যক তিন অক্ষরের ISO 4217 মুদ্রাকোড ব্যবহার হয়। আমানত অ্যাকাউন্টে মোট সুদ রিপোর্ট হয়; হেফাজতি অ্যাকাউন্টে মোট লভ্যাংশ, সুদ, বিক্রয়/রিডেম্পশন থেকে প্রাপ্ত অর্থ ও সম্পদ থেকে অন্য আয় রিপোর্ট হয়। ঋণ/ইকুইটি এবং বিমা/annuity অ্যাকাউন্টে রিডেম্পশনসহ মোট অর্থপ্রদান রিপোর্ট হয়। ধরন অনুযায়ী Payment পুনরাবৃত্তি করুন: CRS501 লভ্যাংশ, CRS502 সুদ, CRS503 বিক্রয়লব্ধ মোট অর্থ/রিডেম্পশন এবং CRS504 অন্য CRS আয়। প্রতিটি অর্থপ্রদানের নিজস্ব অঙ্ক ও মুদ্রা থাকে।
নথির ধরন ও অনন্য রেকর্ড-শনাক্তকারী
DocSpec-এ OECD0 অপরিবর্তিত প্রতিষ্ঠান-তথ্য পুনঃপ্রেরণ, OECD1 নতুন তথ্য, OECD2 সংশোধন এবং OECD3 মুছে ফেলা বোঝায়। OECD10–13 হলো সমতুল্য পরীক্ষামূলক মান, যা প্রকৃত তথ্যের সঙ্গে মেশানো যাবে না। OECD0 কেবল একই রিপোর্টিং সময়ের অপরিবর্তিত ReportingFI-এর জন্য; নতুন বছরে OECD1 প্রয়োজন। ReportingFI-এর DocRefID হলো রিপোর্টিং বছর + দশ অক্ষরের প্রতিষ্ঠানের রেফারেন্স + FI + তিন অঙ্কের ক্রমিক নম্বর। AccountReport-এর DocRefID হলো রিপোর্টিং বছর + দশ অক্ষরের প্রতিষ্ঠানের রেফারেন্স + সর্বোচ্চ ত্রিশ অক্ষরের অনন্য পরাংশ। ছোট কর-রেফারেন্সে হাইফেন যোগ করুন; trustee-documented trust-এর জন্য TDT রেফারেন্স ব্যবহার করুন। নতুন সংশোধন/মুছে ফেলার ক্ষেত্রে নতুন DocRefID প্রয়োজন। CorrDocRefID সর্বশেষ গৃহীত সংস্করণকে নির্দেশ করে, সব সময় প্রাথমিক রেকর্ডকে নয়। প্রতিটি বার্তারও অনন্য MessageRefID প্রয়োজন। একই DocRefID কেবল OECD0-সহ পুনঃপ্রেরিত অপরিবর্তিত ReportingFI-তেই ব্যবহৃত হয়।
সংশোধনের নিয়ম ও অনুমোদিত সমন্বয়
কেবল ReportingFI ও AccountReport স্বাধীনভাবে সংশোধনযোগ্য। কোনো অধীনস্থ উপাদান বদলাতে সম্পূর্ণ সংশ্লিষ্ট সংশোধনযোগ্য উপাদান ও তার সব অধীনস্থ অংশ আবার পাঠান; সম্পর্কহীন অ্যাকাউন্ট আবার পাঠাবেন না। সংশোধনে CRS702 ব্যবহার হয়; এতে OECD2 এবং/অথবা OECD3 রেকর্ড চলে, কিন্তু নতুন OECD1 রেকর্ড চলে না। অপরিবর্তিত প্রতিষ্ঠান একই DocRefID ও কোনো correction reference ছাড়া OECD0 হিসেবে আবার পাঠানো হয়। সমন্বয়-তালিকায় OECD2 প্রতিষ্ঠানকে অ্যাকাউন্ট ছাড়া, সংশোধিত অ্যাকাউন্টসহ বা মুছে ফেলা অ্যাকাউন্টসহ পাঠানো যায়; OECD3 প্রতিষ্ঠানকে অ্যাকাউন্ট ছাড়া বা মুছে ফেলা অ্যাকাউন্টসহ পাঠানো যায়, তবে তার সব সংশ্লিষ্ট অ্যাকাউন্ট ইতিমধ্যে মুছে ফেলা হতে হবে; OECD0 কেবল সংশোধিত বা মুছে ফেলা অ্যাকাউন্টসহ চলে। সংশোধনের সংশোধন করতে প্রথম সংশোধন গৃহীত হওয়া পর্যন্ত অপেক্ষা করে সেই সর্বশেষ গৃহীত রেকর্ডকে নির্দেশ করতে হবে। সংযুক্ত সব বার্তা একই রিপোর্টিং সময়ের হতে হবে।
সংশোধনের প্রথম ও দ্বিতীয় উদাহরণ: ধারাবাহিক সংস্করণ
প্রথম উদাহরণে প্রথমে অ্যাকাউন্টের অর্থপ্রদান, পরে তার ব্যালান্স সংশোধন করা হয়। দ্বিতীয় সংশোধন প্রথম সংশোধনের DocRefID-কে নির্দেশ করে, অপরিবর্তিত প্রতিষ্ঠানকে OECD0 রাখে এবং অপরিবর্তিত দ্বিতীয় অ্যাকাউন্ট বাদ দেয়। দ্বিতীয় উদাহরণে প্রথমে শুধু প্রতিষ্ঠানের ঠিকানা, পরে একটি অ্যাকাউন্ট সংশোধন করা হয়। পরের অ্যাকাউন্ট-সংশোধনে প্রতিষ্ঠানের সর্বশেষ সংশোধিত সংস্করণকে OECD0 হিসেবে আবার পাঠাতে হয়, তার প্রাথমিক সংস্করণকে নয়। শুধু প্রতিষ্ঠান-সংক্রান্ত সংশোধনে কোনো অ্যাকাউন্ট না-বদলালে অ্যাকাউন্ট রিপোর্ট বাদ দেওয়া যায়। প্রতিটি পরবর্তী কাজ যেন বর্তমান সংস্করণকে নির্দেশ করে, সে জন্য গৃহীত রেকর্ড-শনাক্তকারীর ধারাটি সংরক্ষণ করুন।
সংশোধনের তৃতীয় থেকে সপ্তম উদাহরণ: অধীনস্থ উপাদান বদলানো ও মুছে ফেলা
তৃতীয় উদাহরণে CP-এর ঠিকানা বদলাতে নম্বর, ধারক, CP ও ব্যালান্সসহ সম্পূর্ণ অ্যাকাউন্ট এবং প্রতিষ্ঠান আবার পাঠানো হয়। চতুর্থ উদাহরণে প্রতিষ্ঠানের ঠিকানা ও একটি অ্যাকাউন্টের ব্যালান্স উভয় বদলায়; সম্পূর্ণ দুটি উপাদান আবার পাঠানো হয়, অপরিবর্তিত দ্বিতীয় অ্যাকাউন্ট নয়। পঞ্চম উদাহরণে প্রতিষ্ঠানের দুটি ঠিকানার একটি সরাতে সংশোধিত প্রতিষ্ঠানে নাম ও বাকি ঠিকানা রাখা হয়; অ্যাকাউন্ট বাদ যায়। ষষ্ঠ উদাহরণে OECD3 দিয়ে একটি অ্যাকাউন্ট, তার অধীনস্থ তথ্য ও প্রতিষ্ঠান পাঠিয়ে অ্যাকাউন্টটি মুছে ফেলা হয়; অপরিবর্তিত অ্যাকাউন্ট বাদ যায়। কোনো সংশ্লিষ্ট অ্যাকাউন্ট রয়ে গেলে প্রতিষ্ঠান মুছে ফেলা প্রত্যাখ্যাত হয়। সপ্তম উদাহরণে আলাদা নতুন payment রেকর্ড দিয়ে নয়, বিদ্যমান সম্পূর্ণ অ্যাকাউন্ট OECD2 দিয়ে প্রতিস্থাপন করে Payment অধীনস্থ উপাদান যোগ করা হয়।
সংশোধনের অষ্টম ও নবম উদাহরণ: প্রকৃত নতুন রেকর্ড
অষ্টম উদাহরণে আগে রিপোর্ট করা প্রতিষ্ঠানের আরেকটি অ্যাকাউন্ট যোগ হয়। নতুন CRS701 বার্তায় নতুন অ্যাকাউন্ট OECD1 এবং অপরিবর্তিত প্রতিষ্ঠান OECD0 দিন। এটি ভাগ করা ফাইল বা দেরিতে রিপোর্টের ক্ষেত্রে প্রাসঙ্গিক; বিদ্যমান অ্যাকাউন্টে অধীনস্থ উপাদান যোগ করা থেকে আলাদা। নবম উদাহরণে নতুন CRS701 বার্তায় ভিন্ন প্রতিষ্ঠান ও তার অ্যাকাউন্ট যোগ হয়; প্রতিষ্ঠান ও অ্যাকাউন্ট সবই নতুন রেকর্ড। এই নতুন রেকর্ডগুলো CRS702 সংশোধন-ফাইলে মেশাবেন না।
স্কিমার চিত্র, নেমস্পেস ও উৎসের অসংগতি
পরিশিষ্ট A-তে হেডার, মূল অংশ, রিপোর্টকারী প্রতিষ্ঠান/group, অ্যাকাউন্ট, অ্যাকাউন্ট নম্বরের attribute, ব্যক্তি/সত্তা ধারক, CP, অর্থপ্রদান, নাম ও ঠিকানার সঙ্গে স্কিমার সম্পর্ক দেখানো হয়েছে। এতে CRS-বহির্ভূত pool/sponsor/intermediary শাখাও আছে, যেগুলোকে সিঙ্গাপুরের CRS-এর আবশ্যকতা ভাবা যাবে না। পরিশিষ্ট B-তে crs-এর সঙ্গে CrsXML_v2.0.xsd, cfc-এর সঙ্গে CommonTypesFatcaCrs_v2.0.xsd, ftc-এর সঙ্গে FatcaTypes_v1.2.xsd, stf-এর সঙ্গে OECDCrsTypes_v5.0.xsd এবং iso-এর সঙ্গে isocrstypes_v1.1.xsd যুক্ত। 2018-এর সংশোধনে ফাইলের আকার 2 MB থেকে 5 MB করা হয়; 2020-এর সংশোধনে সংস্করণ 2.0, স্ট্রিংয়ের ন্যূনতম দৈর্ঘ্য, সর্বোচ্চ দৈর্ঘ্য, সেকেন্ডের ভগ্নাংশসহ timestamp ও হালনাগাদ দেশের তালিকা যোগ হয়। কয়েকটি চিত্রের মন্তব্যে DocRefID কর-রেফারেন্স দিয়ে শুরু বলা হলেও IRAS-এর বিস্তারিত বিন্যাসে রিপোর্টিং বছর আগে থাকে। সরলীকৃত চিত্রের শনাক্তকারীর বদলে পূর্ণ বছর-ও-রেফারেন্স বিন্যাস ব্যবহার করুন। শুধু প্রতিষ্ঠান-সংক্রান্ত সংশোধনচিত্রের মন্তব্য নিয়ে মূল নিবন্ধে অসংগতির উল্লেখ আছে; তবে দ্বিতীয় উদাহরণে প্রতিষ্ঠানের ঠিকানা বদলানো হয়েছে, তাই মুদ্রিত পৃষ্ঠা 42-এর চিত্রে ReportingFI-কে OECD2 সংশোধিত তথ্য বলা যথাযথ। নির্দিষ্ট পরিবর্তন ও সঠিক রেফারেন্স-ধারা অনুসরণ করুন।
সরকারি উৎস
এই প্রবন্ধে সরকারি PDF-এর প্রাসঙ্গিক শর্ত, পদ্ধতি ও সংযোজনীসহ মূল বিষয়বস্তু স্বাধীনভাবে ব্যাখ্যা করা হয়েছে। মূল শব্দচয়নের প্রামাণ্য উৎস সংযুক্ত নথি; পরবর্তী পরিবর্তন আলাদাভাবে যাচাই করতে হবে।
সরকারি PDF পড়ুন ↗