ثبت خودکار معاملات بین شرکتی: هر معامله یک بار ثبت، در دو دفتر

ثبت خودکار معاملات بین شرکتی نیمه دوم هر معامله بین شرکت‌های یک گروه را به‌جای شما ثبت می‌کند. وقتی شرکت پخش آلفا فاکتور فروش به فروشگاه بتا را قطعی می‌کند، سند خرید با همان مبلغ، تاریخ و شماره مرجع در دفتر فروشگاه ظاهر می‌شود، بدون اینکه کسی آن را دوباره تایپ کند. نتیجه، مانده‌های بین شرکتی است که هر روز با هم می‌خوانند، نه فقط بعد از یک تطبیق طولانی آخر ماه.

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

#معاملات بین شرکتی (درون‌گروهی) چیست؟

معاملات بین شرکتی یا درون‌گروهی، فروش، خرید، وام، هزینه خدمات، تسهیم هزینه یا پرداخت بین دو شرکت عضو یک گروه است. هر کدام باید دو بار ثبت شود: یک بار در دفتر فروشنده و یک بار در دفتر خریدار.

نمونه‌های رایج در یک گروه کوچک:

• شرکت پخش به فروشگاه خواهر کالا می‌فروشد.
• دفتر مرکزی اجاره یا حقوق را بین شرکت‌های عملیاتی تسهیم می‌کند.
• شرکت مادر به شرکت فرعی وام می‌دهد و سود دریافت می‌کند.
• یک شرکت فاکتور تأمین‌کننده را به‌جای شرکت دیگر پرداخت می‌کند.
• شرکت خدماتی هر ماه حق‌الزحمه مدیریت صادر می‌کند.

در صورت‌های مالی تلفیقی همه این‌ها حذف می‌شوند، اما در صورت‌های مالی هر شرکت، درآمد، هزینه، دریافتنی و پرداختنی واقعی‌اند و باید با هم بخوانند.

#چرا ثبت دستی معاملات بین شرکتی به مشکل می‌خورد؟

ثبت دستی شکست می‌خورد چون دو نفر یک رویداد را در دو زمان، از روی دو مدرک و در دو دفتر ثبت می‌کنند. اختلاف‌ها قابل پیش‌بینی‌اند:

همه این اختلاف‌ها باید پیش از تلفیق و حذف معاملات درون‌گروهی پیدا شوند. با ۵۰ فاکتور بین شرکتی در ماه، این یعنی چند ساعت کار تطبیق.

#ثبت خودکار معاملات بین شرکتی در Ledgeriano چطور کار می‌کند؟

Ledgeriano اسناد بین شرکتی را با گردش‌کار خودکار می‌کند: قاعده‌هایی که یک کسب‌وکار را زیر نظر دارند و در کسب‌وکار دیگر سند ثبت می‌کنند. هر گردش‌کار سه بخش دارد.

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

#فیلدهای قابل استفاده در شرط‌ها

#فرمول مبلغ و برچسب‌های متنی

ردیف‌های قالب به‌جای عدد ثابت، فرمول مبلغ می‌گیرند. پرکاربردترین‌ها:

• total: جمع بدهکار سند مبدأ.
• credit("4101"): جمع بستانکار حساب‌هایی که کدشان با ۴۱۰۱ شروع می‌شود.
• debit("11") و net("11"): جمع بدهکار، یا بدهکار منهای بستانکار، برای یک پیشوند.
• round(x, 2)، abs(x)، min(a, b)، max(a, b) و percent(x, 9) (مثلاً برای ۹ درصد).

شرح و شماره مرجع هم برچسب‌هایی مثل {{entry.number}}، {{entry.reference}}، {{entry.date}} و {{source.business}} را می‌پذیرند. فهرست کامل در صفحه گردش‌کارها آمده است.

#مثال کامل: فروش شرکت پخش به فروشگاه خواهر

این زنجیره با قالب سرفصل IFRS و دو کسب‌وکار اجرا می‌شود: شرکت پخش آلفا (فروشنده) و فروشگاه بتا (خریدار)، هر دو با ارز پایه دلار. در دفتر آلفا، فروشگاه بتا مشتری با کد C001 است و در دفتر بتا، شرکت آلفا تأمین‌کننده با کد S001.

#قدم ۱: آلفا سند فروش را قطعی می‌کند

روز ۵ مارس آلفا کالایی را طی فاکتور INV-1001 به مبلغ ۳۶٬۰۰۰ دلار به بتا می‌فروشد. بهای تمام‌شده این کالا برای آلفا ۲۴٬۰۰۰ دلار است. حسابدار یک سند از نوع فروش (SAL) قطعی می‌کند:

شرکت پخش آلفا، نوع سند SAL، مرجع INV-1001، وضعیت قطعی

دقت کنید جمع سند ۶۰٬۰۰۰ است، نه ۳۶٬۰۰۰؛ چون بهای تمام‌شده هم در همین سند آمده. به همین دلیل گردش‌کار پایین از credit("4101") استفاده می‌کند نه total: بدهی بتا مبلغ فروش است، نه جمع همه بدهکارها.

#قدم ۲: گردش‌کاری که دو دفتر را به هم وصل می‌کند

گردش‌کار فقط یک بار تعریف می‌شود:

• کسب‌وکار مبدأ: شرکت پخش آلفا
• رویداد: قطعی شدن سند
• شرط‌ها (همه): نوع سند برابر SAL؛ سند طرف‌حساب C001 دارد
• اقدام: ساخت سند در فروشگاه بتا
  • نوع سند: PUR (خرید)، وضعیت: قطعی، تاریخ: همان تاریخ سند مبدأ
  • شرح: Purchase from {{source.business}}, invoice {{entry.reference}} (یا معادل فارسی آن)
  • مرجع: ALPHA-{{entry.number}}
  • ردیف ۱: حساب ۱۱۲۴، بدهکار، مبلغ credit("4101")، شرح «دریافت کالا»
  • ردیف ۲: حساب ۲۱۱۱، بستانکار، مبلغ credit("4101")، طرف‌حساب S001، شرح «بدهی به آلفا»

#قدم ۳: سند خرید خودکار در دفتر بتا

چند ثانیه بعد از قطعی شدن سند آلفا، این سند در دفتر روزنامه بتا ثبت می‌شود:

فروشگاه بتا، نوع سند PUR، مرجع ALPHA و شماره سند آلفا، وضعیت قطعی

این سند برچسب «workflow» دارد و کسب‌وکار مبدأ و شماره سند مبدأ را نگه می‌دارد، پس هر کس در دفتر بتا آن را ببیند می‌تواند منشأ آن را پیدا کند. موجودی بتا ۳۶٬۰۰۰ دلار ثبت شده که بهای خرید بتاست. سود ۱۲٬۰۰۰ دلاری سود آلفاست و فقط در صورت‌های تلفیقی (اگر کالا هنوز در انبار بتا باشد) حذف می‌شود.

نکته: ردیف‌های بهای تمام‌شده را به سند مقصد نبرید. بهای خرید خریدار همان قیمت فروش فروشنده است؛ پس فرمول بر پایه حساب فروش (۴۱ یا ۴۱۰۱) تقریباً همیشه درست است، اما total مبلغ را دوبار حساب می‌کند.

#قالب یا سند آینه‌ای: کدام اقدام را انتخاب کنیم؟

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

همان قاعده آلفا به بتا را با سند آینه‌ای هم می‌شود نوشت: ۱۱۱۱ را به ۲۱۱۱ و ۴۱۰۱ را به ۱۱۲۴ نگاشت کنید، «جابه‌جایی بدهکار و بستانکار» و «رد کردن ردیف‌های بدون نگاشت» را روشن کنید (تا ردیف‌های بهای تمام‌شده نادیده گرفته شوند) و طرف‌حساب S001 را بدهید. کار می‌کند، اما قالب شش ماه بعد خواناتر است.

سند آینه‌ای با ضریب برای تسهیم عالی است. مثال: دفتر مرکزی ۴۰ درصد هر سند اجاره را با ضریب 0.4 و نگاشت ۶۲۰۵ به ۶۲۰۵ و ۱۱۰۳ به ۲۱۱۳ (بدهی به اشخاص وابسته) به شرکت فرعی منتقل می‌کند.

#سایر معاملات درون‌گروهی که ارزش خودکار شدن دارند

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

دو عادت این جریان‌ها را قابل اتکا می‌کند. اول، برای هر چیزی که فاکتور تجاری نیست از حساب‌های جداگانه «طلب از اشخاص وابسته» و «بدهی به اشخاص وابسته» (۱۱۱۵ و ۲۱۱۳ در قالب IFRS؛ در قالب استانداردهای ایران ۱۴۰۲ و ۳۲۰۸) استفاده کنید تا مانده‌ها راحت پیدا شوند. دوم، هر جا حساب به‌تنهایی کافی نیست، به سند برچسب «بین‌شرکتی» بزنید؛ شرط برچسب ساده و شفاف است.

#ارز متفاوت در دو طرف

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

#جلوگیری از حلقه، دسترسی‌ها و کلید یکتایی

اتوماسیون بین شرکت‌ها هرگز نباید زنجیره بی‌پایان یا سند تکراری بسازد. Ledgeriano چند محافظ داخلی دارد:

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

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

#آزمایش گردش‌کار پیش از فعال‌سازی

هر گردش‌کار را می‌توان بدون ثبت هیچ داده‌ای روی یک سند موجود آزمایش کرد. سندی را با شماره انتخاب کنید (یا آخرین سند را بگذارید) تا Ledgeriano نشان دهد:

1. هر شرط و اینکه برقرار بوده یا نه.
2. محتوای دقیق هر اقدام: تاریخ، نوع سند، ردیف‌ها، مبالغ و طرف‌حساب‌ها.
3. هر خطا، مثل کد حسابی که در مقصد وجود ندارد یا طرف‌حسابی که تعریف نشده.

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

#تطبیق حساب‌های بین شرکتی

تطبیق حساب‌های بین شرکتی یعنی مقایسه طلبی که یک شرکت از شرکت خواهر ثبت کرده با بدهی‌ای که آن شرکت ثبت کرده است؛ نتیجه باید صفر باشد. با اتوماسیون معمولاً صفر است، اما باز هم بررسی می‌کنید، چون ممکن است کسی سند دستی ثبت کرده باشد.

#روال ماهانه

1. در آلفا، گزارش مانده طرف‌حساب‌ها را برای مشتری C001 در پایان ماه بگیرید.
2. در بتا، همین گزارش را برای تأمین‌کننده S001 در همان تاریخ بگیرید.
3. دو عدد را مقایسه و اختلاف‌ها را فهرست کنید.
4. هر اختلاف را در دفتر معین حساب ۱۱۱۱ (آلفا) و ۲۱۱۱ (بتا) با فیلتر طرف‌حساب ریشه‌یابی کنید.
5. اصلاح را با سند اصلاحی یا سند برگشت در طرف اشتباه انجام دهید، هرگز با ویرایش سند قطعی.

#خودکار کردن سمت پرداخت

فروش فقط نیمی از جریان است. گردش‌کار دومی در بتا بسازید: وقتی سند پرداخت (PAY) با طرف‌حساب S001 قطعی شد، در آلفا سند دریافت (RCT) ثبت شود که حساب ۱۱۰۳ بانک را بدهکار و ۱۱۱۱ را برای C001 بستانکار می‌کند، با مبلغ debit("2111"). به این ترتیب دریافت‌ها و پرداخت‌ها هم با هم می‌خوانند و جدول تطبیق بالا صفر می‌ماند.

#اگر سند برگشت بخورد چه؟

اگر آلفا سند INV-1001 را برگشت بزند، گردش‌کار سومی با رویداد «برگشت سند» می‌تواند سند خرید معکوس را در بتا ثبت کند (بدهکار ۲۱۱۱، بستانکار ۱۱۲۴). شرط‌ها را همان نگه دارید تا فقط فروش‌های بین شرکتی را شامل شود.

#هزینه، محدودیت‌ها و چک‌لیست

هر اجرای گردش‌کار اعتبار مصرف می‌کند و هر سندی که می‌سازد یک سند عادی است و مانند سند عادی محاسبه می‌شود. هزینه اعتباری دقیق را مدیر سیستم تعیین می‌کند و در صفحه قیمت‌ها آمده است.

پیش از روشن کردن گردش‌کار بررسی کنید:

• هر دو کسب‌وکار کدهای حساب قالب (اینجا ۱۱۲۴ و ۲۱۱۱) را دارند.
• طرف‌حساب‌ها در هر دو دفتر تعریف شده‌اند (C001 در آلفا و S001 در بتا).
• نوع سند خرید (PUR) در مقصد وجود دارد.
• اجرای آزمایشی روی دست‌کم دو سند قبلی، مبالغ درست را نشان می‌دهد.
• مشخص است اگر سند موقت ساخته شد، چه کسی آن را بررسی و قطعی می‌کند.

اگر فروش اولیه در یک سیستم دیگر (فروشگاه اینترنتی یا ERP) ایجاد می‌شود، این گردش‌کار را با API حسابداری ترکیب کنید تا کل زنجیره بدون ثبت دستی اجرا شود. مستندات توسعه‌دهندگان دریافت وب‌هوک گردش‌کار در کد خودتان را توضیح می‌دهد و واژه‌نامه اصطلاحاتی مثل حذف معاملات درون‌گروهی را تعریف می‌کند.