2008/10/26

‫انواع حساب‌ها و کدینگ آنها در حسابداری (حساب‌های اصلی و فرعی)

حساب‌های اصلی: در سیستم حسابداری یک حساب اصلی داریم که عبارت است از مجموعه سلسله مراتبی گروه حساب، دفتر کل، تعدادی طبقه معین (وجود آن اجباری نیست) و نهایتا خود حساب معین. در این مجموعه «حساب معین» نقش اصلی را بازی می‌کند و بقیه فقط برای دسته بندی به کار می‌روند. کلیه اسناد حسابداری حتما باید با استفاده از حداقل یک «حساب معین» و تعدادی حساب فرعی اختیاری ثبت شوند. کد هر حسابی (چه در حساب‌های اصلی و چه در حساب‌های فرعی) در ساختار سلسله مراتبی حساب‌ها به صورت پیمایش از ریشه درخت تا حساب مورد نظر به دست می‌آید. به این صورت که کد همه حساب‌ها و طبقه بندی‌های پیمایش شده به ترتیب از ریشه تا برگ کنار هم چیده شده و کد حساب مورد نظر به دست می‌آید.

دقت شود که «گروه حساب» اولین سطح درخت حساب‌ها را تشکیل می‌دهد و فقط و فقط همین یک ردیف هم از آن وجود دارد نه کمتر و نه بیشتر. «حساب کل» هم که زیر مجموعه «گروه حساب» است در ردیف دوم درخت قرار داشته و رفتارش کاملا مشابه «گروه حساب» می‌باشد. زیر هر «حساب کل» هم می‌توان هیچی، یکی یا هر تعداد «طبقه معین» به صورت درختی و نامحدود داشت. در واقع «طبقه معین» (در صورت وجود) از سطح سوم شروع و به تعداد دلخواه ادامه دارد. «حساب‌های» معین هم بلافاصله زیر مجموعه یک «حساب کل» یا به صورت زیر مجموعه یکی از «طبقات حساب معین» تعریف می‌شوند. یادآوری می‌گردد که در اسناد حسابداری چیزی که ثبت می‌گردد حساب معین است نه حساب کل یا طبقه معین یا گروه حساب. به عکس زیر دقت کنید:

PrimaryAccountsLargeSize

حساب‌های فرعی: حساب‌های فرعی برای کمک به روشن شدن جزییات اسناد حسابداری به وجود آمده‌اند و ثبت آنها برای اسناد حسابداری ضروری نیست. با کمک حساب‌های فرعی می‌توان گردش مالی را به تفکیک مراکز هزینه، پروژه‌ها، افراد، حساب‌های مختلف و... به دست آورد. سه دسته از حساب‌های فرعی عبارتند از حساب تفصیلی (تفضیلی هم گفته می‌شود)، حساب پروژه و حساب مرکز هزینه. ساختار هر سه تای این حساب‌ها کاملا مشابه با هم و به صورت درختی است. هر درخت با هیچی، یکی یا هر تعداد طبقه حساب تودرتو شروع شده و به یک حساب فرعی منتهی می‌شود. به عکس زیر دقت کنید:

SecondaryAccountsLargeSize

* با تشکر از ناصر حاجلو برای تهیه عکس‌ها




2008/10/16

‫مصائب پیاده سازی پروتکل ECE

تا زمانی که فقط صحبت از نوشتن کدهای پروتکل و تست آن با دبیرخانه خودتان است همه چیز مثل قند و عسل شیرین است. ولی وقتی که قرار شد این ارتباط با دبیرخانه‌های دیگر تست شود آن وقت می‌فهمید که زهر مار چه مزه‌ای است!

یکی از بزرگترین مشکلات و مصیبت‌ها عدم تست بیشتر دبیرخانه‌های موجود است چون بیشتر دبیرخانه‌های شرکت‌ها صرفا با خودشان تست شده و کار می‌کنند. برای این دسته از دبیرخانه‌ها هیچ وقت پیش نیامده که به دبیرخانه یا اتوماسیونی غیر از محصول شرکت خودشان نامه ECE بفرستند یا بگیرند. و در این حالت این بدبختی من برنامه نویس است که باید هم کدهای خودم را تست کنم و هم محصول شرکت‌های آن طرف خط را که بعضا مدت‌هاست روی کد مربوط به پروتکل کار نکرده‌اند و یا حتی برنامه نویس مربوطه از آن شرکت رفته است. این را هم بیفزایید که بعضی دوستان اصرار دارند از موضع برتر صحبت کرده و هیچ وقت قبول نمی‌کنند که برنامه‌ای که نوشته‌اند ایراد دارد یا این که پروتکل ارتباطی را بد فهمیده‌اند. مثلا یکی از شرکت‌ها که اتفاقا از شرکت‌های قدیمی ایران در امر نرم افزار است رشته زیر را به عنوان تاریخ نامه در XML ارسال می‌کند. در حالی که در پروتکل گفته شده که این رشته باید بر اساس استاندارد ISO 8601 باشد. در تعریف استاندارد ۸۶۰۱ هم گفته شده که این استاندارد بر مبنای تاریخ میلادی است و شامل هیچ رشته‌ای مثل +03:30 هم نمی‌باشد.

 1387-07-22T16:15:35+03:30

عدم رعایت کوچک و بزرگی حروف یا همان Case Sensitivity هم یکی دیگر از مشکلات رایج است. این مشکل در همه جا نمود دارد هم در هدرهای ایمیل و هم در XML تولیدی. مثلا فلان شرکت elementها و attirbuteهای XML را بدون توجه به این که XML به کوچک و بزرگی حروف حساس است تولید می‌کند و بهمان شرکت هم هدر ایمیل را با فرض حساس بودن به کوچک و بزرگ بودن حروف پردازش می‌کند در حالی که هدر ایمیل به حروف کوچک و بزرگ حساس نیست.

در مورد حساسیت هدر ایمیل به کوچکی و بزرگی حروف هم باید گفت که مطابق RFC 2822 و توضیحات اینجا حساس نیست. در اینجا هم گفته شده که نام هدر همیشه غیر حساس به حروف کوچک و بزرگ است ولی مقدار هدر بسته به حالت ممکن است حساس باشد یا نباشد. اگر از literal استفاده شود یعنی از حروف الفبای انگلیسی که محصور در دابل کوتیشن باشند مثل A و Header1 آن وقت حساسیتی وجود ندارد ولی اگر از از مقادیر داده‌ای که شبیه مقادیر اسکی دسیمال و... می‌باشد مثل «%d» قضیه فرق می‌کند.




2008/10/06

‫راهی برای اضافه کردن دستی header به ایمیل‌ها

header بخشی از اطلاعات موجود در یک ایمیل است که با کمک آن می‌تواند قابلیت‌های زیادی به یک ایمیل بخشید. مثلا با اضافه کردن هدر خاصی به یک ایمیل می‌توان آن را به عنوان یک ایمیل ECE معتبر شناساند. خواندن هدر ایمیل‌های وارده تقریبا از همه برنامه‌های ارسال/دریافت ایمیل و کلاس‌های کار با ایمیل در دات نت امکان پذیر است. اما اضافه کردن هدر از طریق برنامه‌های ارسال/دریافت یا سرویس دهنده‌های ایمیل مثل جی میل و یاهو کار چندان ساده‌ای نیست. بعد از مدت‌ها گشت و گذار و تست کردن‌های مختلف فهمیدم که می‌توان با Customize کردن Thunderbird این کار را کرد. روش این کار در اینجا گفته شده است. من با کمک یک اکانت جی میل و Mozilla Thunderbird موفق شدم بدون هیچ مشکلی هدر مورد نظر خودم را به ایمیلم الصاق و آن را ارسال کنم. البته حتما می‌دانید که هدف از این کار تست دستی دبیرخانه‌هایی است که در دریافت ایمیل‌های دارای هدر ECE مشکل دارند.

اضافه کردن هدرهای دلخواه از طریق «مرغ طوفان»‏

این هم سورس تولیدی:

Message-ID: <48E8B367.9090709@gmail.com>
Date: Sun, 05 Oct 2008 16:00:31 +0330
From: ECE Tester <ece.tester@gmail.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: afshar.mohebbi@gmail.com
Subject: testing ece
X-ECE_SEND: 1.01


پ. ن.: Thunderbird برای ارسال فایل به همراه نامه مشکلاتی دارد که برای رفع
آن باید از این راه حل استفاده کرد.