আর্থিক রেকর্ড ধরে রাখতে ডাটাবেসগুলি ডিজাইন করার সময় কোন বিশেষ বিবেচনার প্রয়োজন?


15

আমি আশা করি এই প্রশ্নটি খুব বেশি বিস্তৃত নয়। ভবিষ্যতে আমার কিছু অ্যাপ্লিকেশনে কিছু অ্যাকাউন্টিং এবং আর্থিক-ট্র্যাকিং সিস্টেম যুক্ত করার প্রয়োজন হতে পারে (বেশিরভাগ ওয়েব-ভিত্তিক অ্যাপ্লিকেশন, তবে আমার প্রশ্নগুলি ডেস্কটপ অ্যাপ্লিকেশানগুলির সাথেও সম্পর্কিত)।

এখন, আর্থিক লেনদেনের একটি সহজ রেকর্ড তৈরি করা তাত্ত্বিকভাবে সহজ। কয়েকটি কলাম সহ একটি ডাটাবেস সারণি কাজটি করতে পারে। এমনকি এমএস অ্যাক্সেস, এক্সেল, এমনকি কেবল একটি সরল ASCII পাঠ্য ফাইলও লেনদেনের তারিখ, অ্যাকাউন্ট আইডি এবং ডলারের পরিমাণ সঞ্চয় করতে ব্যবহৃত হতে পারে। তবে, আমি অনুভব করি যে লেনদেনের অখণ্ডতার সাথে প্রায়শই ব্যাক আপযুক্ত এসকিউএল টেবিল গুরুতর আর্থিক ট্র্যাকিংয়ের জন্য যথেষ্ট শক্তিশালী নাও হতে পারে।

আমি "ডাবল-এন্ট্রি অ্যাকাউন্টিং" এর মতো শব্দগুলি শুনি এবং আমার অনুভূতিটি পাওয়া যায় যে বেশিরভাগ আর্থিক ট্র্যাকিং অ্যাপ্লিকেশনগুলিতে (উদাহরণস্বরূপ, Mint.com, বা GnuCash) স্থিরভাবে আরও জটিল ডেটা কাঠামো বা প্রক্রিয়া রয়েছে যাতে ডাবল-নিশ্চিত হয়ে যায় যে সবকিছু একেবারে নিখুঁতভাবে যুক্ত করা উচিত, ঠিক যেমনটি হওয়া উচিত এবং কোনও ডেটা কখনও ক্ষতিগ্রস্ত বা ক্ষতিগ্রস্থ হয় না।

আমার প্রশ্নটি: আর্থিক লেনদেনের উপর নজর রাখার জন্য কোনও অ্যাপ্লিকেশন ডিজাইন করার সময় কোন বিশেষ নকশার বিবেচনা করা উচিত? দেখে মনে হচ্ছে অনেকগুলি সম্ভাব্য সমস্যা রয়েছে ... গোলাকার যথার্থতা, প্যারিটি চেকস, এক ধরণের নিরীক্ষা প্রক্রিয়া, বিশেষ ব্যাকআপ, সুরক্ষা / এনক্রিপশন, ক্র্যাশ মিড ডেটা-প্রবেশের ক্ষেত্রে ডেটা সুরক্ষার অতিরিক্ত উপায় সহ সমস্যা with ... আমি বিশেষভাবে আমার কী জিজ্ঞাসা করা উচিত তা আমি জানি না, তবে আমি অনুভূতিটি পেয়েছি যে প্রোগ্রামিং শিল্পের একটি সেরা অনুশীলন রয়েছে যা সম্পর্কে আমি কিছুই জানি না। তারা কি?

সম্পাদনা:

দেখে মনে হচ্ছে আমি কৃমির বড় ক্যানটি আমার প্রত্যাশার চেয়ে খুলেছি। স্পষ্ট করার জন্য, আমি বিশেষত দুটি ধরণের অ্যাপ্লিকেশনগুলি নিয়ে ভাবছি:

  1. "রেজিস্ট্রি চেক করুন" -র মতো অ্যাপ্লিকেশনগুলি গনুক্যাশ বা কুইকেন যা তাদের নিজস্ব ব্যবহারের জন্য কোনও ব্যক্তির লেনদেনের রেকর্ড বজায় রাখে।
  2. অ্যাপ্লিকেশনগুলি যে কোনও কোম্পানির সাথে লেনদেনকারী বিক্রেতাদের এবং গ্রাহকদের জন্য চালান / জমা / / "পয়েন্ট" ট্র্যাক করে।

আমি সম্ভবত কোনও সরাসরি ব্যাংকিং বা (এএফআইকে) এমন কিছু করবো না যার সাথে সংযুক্ত এক টন অর্থ-সংক্রান্ত সরকারি বিধি রয়েছে।


4
যতবার আমি এই প্রশ্নটি দেখি, আমি একটি ফেটে যাই "আমাকে আমার অভিজ্ঞতা আপনার উপর চাপিয়ে দিন!" এবং তারপরে এটি চলে যায় কারণ ডেটা নিছক ভলিউম এত বিশাল যে আমি কোথায় শুরু করব তা বুঝতে পারি না। আমি বলব যে এটি ব্যবসায়ের ধরণ, ব্যবসায়ের পরিমাণ এবং আপনি যে শূন্যগুলির সাথে আচরণ করছেন তার উপর নির্ভর করে। দ্বিতীয় দুটি ক্ষেত্রে, আপনি যদি অনেক কিছু নিয়ে কাজ করে থাকেন তবে একজন হিসাবরক্ষক পান।
স্যাটোনিকপপি

3
আপনার ভয় কিছুটা কমিয়ে আনার জন্য, অ্যাপ্লিকেশনটি কতটা শক্তিশালী হওয়া উচিত তার সাথে "ডাবল এন্ট্রি অ্যাকাউন্টিং" এর কোনও সম্পর্ক নেই। এই পদটি কেবল একাউন্টিং অনুশীলন যা বলে যে আপনি যখনই কোনও অ্যাকাউন্টের বিপরীতে ডেবিট লেনদেন করেন (বলুন, নগদ), তখন এটি অন্য অ্যাকাউন্টের সাথে ক্রেডিট লেনদেনের সাথে মিলে যায় (বলে, ইনভেন্টরি)।
মাইক ক্লার্ক

@ স্যাটানিকপুপি - আচ্ছা, ধরুন আমি একটি নতুন GnuCash তৈরি করতে চাইছি? আমি একটি বেসিক লেনদেন বা চালানের রেজিস্ট্রি ভাবছি। সিসি বিলিং অ্যাপ বা স্টক-ট্রেডিং অ্যাপের মতো কিছুই নেই।
জোশুয়া কারমোডি

@ জোশুয়া: দয়া করে আপনার প্রশ্নের মধ্যে এটি সম্পাদনা করুন: "আমি একটি মৌলিক লেনদেন বা চালানের রেজিস্ট্রি ভাবছি a সিসি বিলিং অ্যাপ্লিকেশন বা স্টক-ট্রেডিং অ্যাপের মতো কিছুই নয় othing" (আপনি আপনার প্রশ্নের শেষের দিকে "আর্থিক পরিষেবা" উল্লেখ করেছেন। অ্যাকাউন্টিং এবং আর্থিক পরিষেবাদি হুবহু এক নয়))
14:30 এ রাওং

2
@ জোশুয়া: আর্থিক পরিষেবাগুলি আরও বেশি সরকারী বিধি সাপেক্ষে, সুতরাং অ্যাকাউন্টিং সিস্টেমের চেয়ে স্টক ট্রেডিং সফ্টওয়্যারটির জন্য প্রচুর "বিশেষ বিবেচনা" থাকবে। ট্যাক্স সফটওয়্যারগুলিও ট্যাক্স বিধিগুলির অধীন হতে পারে।
rwong

উত্তর:


10

আপনি এর অনেক উত্তর পেয়ে যাবেন আমি নিশ্চিত, অনেক আদর্শবাদী উত্তরও, আমি কেবল আর্থিক সাথে আমার অভিজ্ঞতা থেকে উত্তর দিতে পারি এবং আসলে কী চলে।

আপনি ইতিমধ্যে বেশিরভাগ ইস্যু কভার করেছেন।

রাউন্ডিং স্পষ্টতা আমার অভিজ্ঞতায় আসলে খুব বেশি সমস্যা হয় না। রাতারাতি বড় হয়নি এমন বেশিরভাগ বড় বড় আর্থিক সংস্থার (যেমন হেজ ফান্ড ব্যতীত সমস্ত কিছুই) বিভিন্ন ধরণের জ্বালানির কারণে বিভক্ত হয়ে যাওয়া লিগ্যাসি অ্যাপ্লিকেশনগুলির একটি বিশাল পরিসীমা রয়েছে। তারা নিয়মিত বৃত্তাকার যথার্থতা না করার ঝোঁক; সাধারণত একটি নির্দিষ্ট ত্রুটি লাভ এবং লোকসান রাউন্ডিংয়ের জন্য সহজভাবে গৃহীত হয়। প্রকৃতপক্ষে অনেক লোকের সময় আমি কাজ করেছি যেখানে মানুষ যেখানে চূড়ান্ত 'হ্যাঁ যথেষ্ট যথেষ্ট' নির্বাচক নির্বাচিত যখন সঠিক / প্রত্যাশার যোগফল মেলে আসে সেখানে ব্যয় হয়। মনে রাখবেন, এটি বাস্তবতার ভিত্তিতে একটি উত্তর, যা হওয়া উচিত তা নয়।

এনক্রিপশন - খোলামেলাভাবে এর উপর নির্ভর করবেন না। শারীরিক ও যৌক্তিকভাবে পৃথক সিস্টেমে ডে-শনাক্ত করা ডেটার (যেমন অ্যাকাউন্টের কোড সর্বত্র, ব্যক্তিগত ডেটা পৃথক) -এর পরিচয় দেওয়ার তথ্য সঞ্চয় করুন।

সাধারণত যখন ব্যাকআপগুলি প্রয়োজন হয় তখন অফলাইনে ব্যাকআপগুলি খুব কমই কল করা হয় - বিষয়গুলি সেই সময়ে খারাপভাবে ভুল হয়ে গেছে। উষ্ণ উত্পাদন কপিগুলি সাধারণত প্রয়োজন হয় - তবে এটি আপনার নিজস্ব নির্দিষ্ট প্রয়োজনের উপর নির্ভর করবে। সাধারণ অনুশীলনে আমাদের কাছে সমস্ত সিস্টেমের একটি উষ্ণ অনসাইটসাইট উত্পাদন কপি এবং নিজস্ব উত্পাদন এবং উষ্ণ অনুলিপি সহ একটি দুর্যোগ পুনরুদ্ধার সাইট রয়েছে। উষ্ণ অনুলিপিগুলি প্রতিলিপি ইত্যাদিতে কয়েক মিনিটের পিছনে থাকে tend

আমি যে সমস্ত আর্থিক ব্যবস্থায় কাজ করেছি তার জন্য নিরীক্ষণ চাবিকাঠি। আপনার 2 টি মৌলিক প্রয়োজনীয়তা রয়েছে ক) আপনি কি ডেটাতে করা প্রতিটি একক পরিবর্তন ট্র্যাক করতে পারেন, কার দ্বারা, কখন এবং কেন? খ) আপনি কি আপনার ডেটার historicalতিহাসিক অবস্থা প্রমাণ করতে পারবেন? যে এটি নিয়ে কোনও ছলনা হয়নি?

ক) অপারেশন দলগুলির জন্য প্রয়োজনীয় - আপনার সিস্টেমটি এমন 100 টি উপায়ে ব্যবহার করা হবে যা আপনি প্রত্যাশা করেননি এবং এই তথ্যটি প্রসারণ, অ্যাড-হক রিপোর্টিং, আইনী কারণ এবং ডিবাগিংয়ের জন্য অত্যাবশ্যক।

খ) অ্যামেক্স বনাম বনাম ভি ভিন্নী কেসটি দেখুন - যেখানে এএমএক্স তাদের কাছে k০ টাকা আদায় করতে অক্ষম ছিল কারণ তারা প্রমাণ করতে পারেনি যে তাদের রেকর্ডগুলি তৈরি হয়নি। সাধারণত এর জন্য ব্যবহৃত সমাধানটি হ'ল বিশ্বস্ত সময় স্ট্যাম্পিং। বড় আর্থিকগুলির গ্যারান্টর ব্যাংক থাকে যা লেনদেনের গ্যারান্টি দেয় এবং এইভাবে সহজাতভাবে বিশ্বস্ত সময় স্ট্যাম্পিং সরবরাহ করে। অন্যান্য স্তরের জীবন / পরিস্থিতিগুলির জন্য এর জন্য বাণিজ্যিক সরবরাহকারী রয়েছে।


6

বিবেচনাগুলি বেশিরভাগ আইনী are । আপনি যদি কেবল এটির সুরক্ষা / নির্ভরযোগ্যতার দৃষ্টিকোণ থেকে দেখে থাকেন তবে কোনও ড্রয়ারের কাগজের শীট থেকে কোনও এক্সেল শীট সহজাতভাবে কম সুরক্ষিত নাও হতে পারে। অ্যাক্সেসের লেনদেনের অখণ্ডতা কলার দ্বারা বাধা প্রাপ্ত ক্লার্কের চেয়ে আরও ভাল।

তবে, যাতে আপনার গ্রাহকদের এটি ব্যবহারের অনুমতি দেওয়া হয়, আপনাকে আপনার স্থানীয় আইন মেনে চলতে হবে। আমি কিছু জিনিস মুখোমুখি হয়েছি (জার্মানিতে)

  • স্টোরেজ ম্যাটারের জন্য ডকুমেন্ট ফর্ম্যাট , কারণ এমন আইন রয়েছে যে ব্যবসাগুলি তাদের কাগজপত্র 10 বছরের জন্য রাখতে হবে। 10 বছরে, সম্ভবত আপনার প্রোগ্রামটি আর উপলভ্য নয়। অতএব, আপনাকে একটি ডিআইএন / আইএসও-প্রত্যয়িত উপায়ে নথি সংরক্ষণ করতে হবে (.pdf জার্মানিতে যথেষ্ট বলে মনে হচ্ছে)
  • অডিট ট্রেলগুলি প্রায়শই প্রয়োজনীয় হয়, উদাহরণস্বরূপ, আপনাকে পরিবর্তনের তারিখ সহ একই ডকুমেন্টের বিভিন্ন সংস্করণ উপস্থাপন করতে হতে পারে।
  • স্টোরেজ বিষয়গুলির অবস্থান, 'ডেটেনশুটজ' (গোপনীয়তা) এর কারণে, যা স্টোরেজের দেশে আলাদা হতে পারে। এটি মেঘ-ভিত্তিক পরিষেবাগুলিকে কিছুটা জটিল করে তোলে।
  • কিছু নথি অপরিবর্তনীয় উপায়ে সংরক্ষণ করতে হয় । এটি কীভাবে অর্জন করা যায় তা বেশিরভাগ ক্ষেত্রে আইনতাত্ত্বিক নিটপিকিংয়ের উপর নির্ভর করে (একটি কাগজ অপরিবর্তনীয়, একটি সিডি পরিবর্তনযোগ্য, কোনও শ্রমিকের স্বাক্ষরিত সিডি নয়)

আপনার অবশ্যই কোনও আইনজীবির সাথে যোগাযোগ করতে হবে, নির্দিষ্টকরণের জন্য, বা কোনও গ্রাহকের সাথে নিবিড় অংশীদারিতে কমপক্ষে কাজ করা উচিত।


3

আপনি যখন মানুষের অর্থের সাথে লেনদেন করেন তখন নির্ভরযোগ্যতার কারণগুলি আশ্চর্যজনকভাবে গুরুত্বপূর্ণ হয়ে ওঠে । টুইটার যদি কোনও টুইট হারিয়ে ফেলে তবে এটি এত বড় চুক্তি নয়; আপনি যদি কারও ক্রেডিট কার্ড চার্জ করেন তবে তার অর্ডার হারিয়ে ফেলেন তবে আপনার সংস্থার কেউ ক্রুদ্ধ গ্রাহকের কাছ থেকে অর্থ আদায় করতে চলেছে। সুতরাং দুটি জিনিস: ১. আপনি চান না যে এটি প্রথম স্থানে ঘটুক, তবে ২. অবশেষে এটি ঘটবে আপনি যতই সতর্ক থাকুন না কেন, তাই আপনি লগিং এবং ট্রেসিংয়ের পদ্ধতিতে প্রচুর পরিমাণে শক্তি রাখতে চান এটি আপনাকে ফিরে যেতে এবং "হারিয়ে যাওয়া" ক্রমটি সন্ধান করতে এবং পরিস্থিতি সংশোধন করতে সহায়তা করবে।

একেবারে নিকৃষ্টতম জিনিসটি হ'ল উদাহরণস্বরূপ, ক্রেডিট-কার্ড চার্জ নেওয়া, তবে এটি কীসের জন্য বা এটি কার সম্পর্কিত, এর কিছুই রেকর্ড নেই record

আর্থিক সামগ্রীর জন্য, আপনাকে আপাতদৃষ্টিতে অতি-অসম্ভব এমন পরিস্থিতিগুলির মধ্যেও চিন্তাভাবনা করা উচিত এবং সেগুলি কীভাবে পরিচালনা করতে হবে তার পরিকল্পনা: "আমরা ক্রেডিট কার্ডটি চার্জ করেছিলাম, তবে আমরা সংশ্লিষ্ট রেকর্ডটি আপডেট করার আগেই ডাটাবেস সার্ভারটি ডাউন রয়েছে" " ঠিক আছে, এখন কি? চার্জ অকার্যকর? কোনও ফাইলটিতে লেনদেন লগ করুন যাতে কোনও মানুষ পরে এটি ঠিক করতে পারে? ঠিক আছে, যদি ডিস্কটি পূর্ণ থাকে এবং আপনি ফাইলটিতে লিখতে না পারেন তবে? ইত্যাদি ইত্যাদি


3

[1] ব্যবহারকারীদের এবং আপনার অ্যাপ্লিকেশনের জন্য সুরক্ষা সারণীগুলি (অভ্যন্তরীণ ডিবি ব্যবহারকারীদের সাথে বিভ্রান্ত করবেন না) ব্যবহার করুন। মডিউল, ফর্ম, ওয়েবপেজ:

User = {userID, username, pwd, email1, email2}
Modules = {moduleID, moduleTitle, moduledescription}
ModulesPerUser = {modulesperuser, userID, moduleID}

[2] আপনার অ্যাপ্লিকেশনটিতে রেকর্ডগুলি মুছবেন না,, একটি স্থিতি ক্ষেত্র, সম্ভবত পূর্ণসংখ্যার, সম্ভবত বুলেট বা বিট ব্যবহার করুন, যা ইঙ্গিত করে যে রেকর্ডটি "মুছে ফেলা" হিসাবে বিবেচিত হয়। আপনাকে অ্যাপ তৈরি করুন। মুছে ফেলা হয়নি এমন রেকর্ডগুলি দেখান (সেই ক্ষেত্রের দ্বারা মুছে ফেলা হিসাবে চিহ্নিত করা হয়েছে) এবং অ্যাপ্লিকেশনটিতে কিছু বিশেষ কেস ফর্ম তৈরি করুন। মুছে ফেলা হিসাবে চিহ্নিত রেকর্ড প্রদর্শন করে না।

anytable = {anytableID, anytablefield1, anytablefield2, ..., bool anytableisdeleted }

এই বৈশিষ্ট্যটিকে "ভার্চুয়াল মোছা" বলা হয়। আসল মুছে ফেলা হ্রাস করে "শারীরিক মোছা" বলা হয়।

[3] অ্যাক্সেস সম্পর্কিত সমস্ত সারণীতে ক্ষেত্রগুলি ব্যবহার করুন, রেকর্ড তৈরি করা (একক) ব্যবহারকারীর সংরক্ষণ করুন এবং রেকর্ড পরিবর্তনকারী (শেষ) ব্যবহারকারী এবং তারিখের সময়টি সম্ভব হলে মডিউল বা বিকল্প যুক্ত করুন যেখানে প্রতিটি রেকর্ড ছিল সংশোধিত:

AnyTable = {anytableID, anytablecreateuserID, anytablecreatedatetime,
anytableupdateuserID, anytableupdatedatetime,
moduleID, anytablefield1, anytablefield2, ..., anytableisdeleted }

[]] কিছু ক্ষেত্রে, মুদ্রা বা অর্থের মানগুলি ফলাফলগুলিতে প্রভাব ফেলতে পারে, যখন বিস্তারিতভাবে বেশ কয়েকটি রেকর্ড ব্যবহৃত হয় এবং, একক মান হিসাবে যুক্ত হয়, আইএনএ হেডার রেকর্ড।

বেশিরভাগ ডাটাবেস ব্র্যান্ড সমর্থন করে, আজকাল, একটি মুদ্রা বা অর্থের ডেটা ক্ষেত্র। এটা ব্যবহার করো.

কিছু বিশেষ পরিস্থিতিতে কিছু লোক এগুলিকে স্থির ভাসমান মান হিসাবে সংরক্ষণ করে যা বেশ কয়েকটি দশমিক সংখ্যা, ("দশমিক") সমর্থন করে এমনকি স্ট্রিংয়ের মান হিসাবেও।

এই কৌশলটি এটি একটি দ্বি প্রান্তের তরোয়াল। আপনার অ্যাপ্লিকেশনটির যদি এই ধরণের অনুমানের প্রয়োজন হয় তবে কীভাবে এটি প্রয়োগ করা যায় তার টিউটোরিয়ালের জন্য, ওয়েবে অনুসন্ধান করুন properly

চিয়ার্স। [কিটিটিকে একটি খোলা টুনা দিতে ভুলে যাবেন না, বা উত্সাহিত করুন]


2

আপনি আপনার প্রশ্নটি সাথে ট্যাগ করেছেন securityতবে আপনি বেশিরভাগ ধারাবাহিকতা এবং নির্ভরযোগ্যতার কথা বলছেন, তাই আমি সমীকরণের সেই অংশটির উত্তর দেওয়ার চেষ্টা করব:

  • ব্যাচের ক্রিয়াকলাপের সততা নিশ্চিত করতে ডাটাবেস লেনদেনগুলি ব্যবহার করুন। সর্বাধিক প্রাথমিক উদাহরণ দুটি অ্যাকাউন্টের মধ্যে স্থানান্তর - একটি অ্যাকাউন্টের পরিমাণ হ্রাস করা হয় এবং অন্যটি জমা হয়। কোনও আংশিক স্থানান্তর কখনই ঘটে না তা নিশ্চিত করতে লেনদেনগুলি ব্যবহার করুন (কেবলমাত্র এক পক্ষের পরিবর্তন হবে)।
  • নির্ভুলতার জন্য, DECIMALফ্লোটের পরিবর্তে প্রকারটি ব্যবহার করুন । গণনাগুলি অনেক ধীর গতির তবে আপনার এটি অনুভব করা উচিত নয় কারণ বেশিরভাগ আর্থিক গণনা খুব মৌলিক
  • ব্যাকআপের জন্য আপটাইম এবং হটকপিগুলির জন্য প্রতিলিপি ব্যবহার করুন। পুনরুদ্ধারের জন্য আপনার LVM স্ন্যাপশটগুলিও লক্ষ্য করা উচিত

2

আমি বিবেচ্য কয়েকটি বিবেচনা হ'ল আপনাকে অভ্যন্তরীণ নিয়ন্ত্রণগুলির জন্য অ্যাকাউন্ট করতে হবে। এর অর্থ টেবিলগুলির বিরুদ্ধে ক্রিয়াকলাপের জন্য সমস্ত অ্যাক্সেস (সন্নিবেশ / মুছা / আপডেট) অবশ্যই সঞ্চিত প্রক্সের (এবং কোনও ডায়নামিক এসকিউএল) এর মাধ্যমে হওয়া উচিত যাতে কোনও টেবিলগুলি সিস্টেম প্রশাসক ব্যতীত অন্য কাউকে সরাসরি টেবিলে অধিকার লিখতে বা মুছতে দেয় না। আপনাকে অভ্যন্তরীণ নিয়ন্ত্রণগুলির জন্যও অ্যাকাউন্ট করতে হবে যা কাউকে নতুন সংস্থা তৈরি করার অনুমতি দেয় না এবং তারপরে সেই সংস্থায় আইটেম চার্জ করে (প্রতারণার পথে)। এর মতো ক্রিয়াকলাপগুলির জন্য সর্বদা দুটি পৃথক চরিত্রের লোকদের অনুমোদনের প্রয়োজন হবে। এছাড়াও একজন ব্যক্তি ডেটা প্রবেশ না করে এবং অন্যজন ব্যয়কে সম্মতি না দিলে চেকগুলি কাটা উচিত নয়।

সমস্ত টেবিলের ট্রিগার থাকা উচিত যা নিরীক্ষার রেকর্ড তৈরি করে। আপনি জালিয়াতি প্রতিরোধের জন্য সন্ধান করছেন এবং যদি ঠিক হয়ে যায় যে কখন এই পদক্ষেপ নিয়েছিল।

আর্থিক অ্যাপ্লিকেশনগুলিতে, আপনি অনেকগুলি ব্যাক এন্ড প্রক্রিয়াগুলির সাথে অনেক বেশি উদ্বিগ্ন হন যা ইউজার ইন্টারফেসের দ্বারা দেখা যায় না। আপনার প্রথম উদ্বেগ হ'ল জালিয়াতি রোধ করা এবং এভাবে অনেকগুলি চেক যা সম্পর্কে কেউ অবগত নয় তা ব্যাকএন্ডে করা হয়।

আমি GAAP না পড়া ছাড়া (মার্কিন যুক্তরাষ্ট্রে, অন্যান্য দেশের নিজস্ব অ্যাকাউন্টিং মান রয়েছে) এবং অ্যাকাউন্টিংয়ের ভুল পদ্ধতি হিসাবে পরামর্শক হিসাবে সিপিএ থাকার কারণে জেল সময় হতে পারে। এটি একটি অত্যন্ত প্রযুক্তিগত ক্ষেত্র এবং প্রয়োজনীয় জ্ঞানবিহীন কারও কাছে এই অঞ্চলে সফ্টওয়্যার তৈরি করার চেষ্টা করার কোনও ব্যবসা নেই।


1

অ্যাকাউন্টিং প্রায়ই যাচাইকরণ সম্পর্কে হয়। যতক্ষণ আপনি এটি মনে রাখবেন এবং প্রতিটি সত্তার মধ্যে সম্পর্ক বোঝেন ততক্ষণ পর্যন্ত এটির ভুল হওয়া খুব শক্ত।

আমি যতটা সম্ভব চেকগুলি তালিকাভুক্ত করার চেষ্টা করব তবে কিছুটা মিস করবো আশা করি আপনার নিজের খনন শুরু করার পক্ষে এটি যথেষ্ট হবে enough

মোট ডেবিটস == মোট ক্রেডিট, আপনি অ্যাকাউন্টের পুরো সেট বা বিচ্ছিন্নতার মধ্যে কেবল একটি লেনদেনের বিষয়ে কথা বলছেন কিনা তা সত্য। যদি এটি টেল না করে তবে আপনি কমপক্ষে একটি পোস্ট কোথাও মিস করেছেন। জেনারেল লেজার নিজেই ভারসাম্য বজায় রাখে।

অ্যাকাউন্টগুলি প্রাপ্তিযোগ্য (নিয়ন্ত্রণকারী অ্যাকাউন্টে নেট ডেবিট) == মোট বিল দেওয়া (সমস্ত বিলযোগ্য পরিমাণের সমষ্টি) - প্রাপ্ত মোট প্রাপ্ত (প্রাপ্ত অর্থের মোট পরিমাণ)। এটি প্রকৃত PHYSICAL এবং মজাদার নথির পদগুলিতে লেনদেনের পরিমাণ কীভাবে জেনারেল লেজার (ডাবল এন্ট্রি) এর সাথে ভারসাম্য বজায় রাখা উচিত তার একটি উদাহরণ।

ব্যাঙ্কের ভারসাম্য (আপনার ব্যাঙ্কের বিবৃতি অনুসারে) == আপনার অ্যাকাউন্টের জন্য সাধারণ জেনারেল লেজার + মোটামুটি যেই চেক জমা পড়ে তা জমা দেওয়া হয়নি - যে কোনও চেকই ব্যাংকটিতে জমা দেওয়া হয়নি তা উদাহরণস্বরূপ: কীভাবে ব্যাংক / নগদ অ্যাকাউন্টগুলি জেনারেলের সাথে তাল মিলবে লেজার।

আপনি দেখতে পাচ্ছেন, প্রতিটি লেনদেন, সাব-লেজার, এমনকি স্টক, সরাসরি জেনারেল লেজারের সাথে সম্পর্কযুক্ত।

আপনি যদি ইউনিট টেস্টিং করে থাকেন তবে পরীক্ষাগুলি চালানো এটির পক্ষে সহজ যা এই ব্যালেন্সগুলি যতবারই আপনি প্রবেশাধিকার সন্নিবেশ / আপডেট করার সময় যতক্ষণ জানেন আপনি যতক্ষণ না চেক করতে হবে তা বিদ্যমান থাকে ensure

অবশ্যই চেক / ট্যালি করার জন্য আরও বেশি ব্যালেন্স রয়েছে তবে আপনার প্রয়োজনীয় কাজের सारটি পাওয়া উচিত। মূলত, সমস্ত কিছু সামঞ্জস্য করে অন্য সমস্ত কিছুর সাথে, এটি শারীরিক নথি হোক, জেনারেল লেজার আইটেম, ব্যাঙ্কের স্টেটমেন্ট। এটি একটি নিখুঁত ভারসাম্য বলে মনে হয় বা এমন ক্ষেত্রে যেখানে আপনি গোলটি মোকাবেলা করতে অলস হন, নিখুঁত কাছাকাছি।

আপনি এটি বিকাশের সময় আপনি যত বেশি চেক সম্পাদন করতে পারবেন, আপনার কিছু ভুল হওয়ার সমস্যা কম।

বিটিডাব্লু, আপনি যখন গোল করার বিষয়টি মোকাবেলা করবেন, তখন ফ্লোটের পরিবর্তে দশমিকের সাথে যাওয়ার চেষ্টা করুন, এটি আপনাকে রাস্তার নিচে প্রচুর মাথা ব্যাথা সাশ্রয় করবে। : P: P

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.