برنامه های کاربردی برای خرج کردن پول در 1 ثانیه. سند "درخواست پرداخت". شرح فرم سند "درخواست پرداخت"

این مقاله را به ایمیل من ارسال کنید

در حسابداری، فاکتور برای پرداخت در 1C سندی است که یک سازمان برای یک محصول یا خدمات تحویل شده به خریدار ارائه می دهد تا از نیاز به واریز وجوه مطلع شود.

1C دو گزینه برای کار با فاکتورها برای پرداخت در 1C ارائه می دهد:

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

فرم چاپی فاکتور پرداخت که از سفارش مشتری یا سند فروش تهیه شده و برای ارسال به خریدار لازم است. شما می توانید آن را در هر زمان چاپ کنید، همچنین فرم نمایش داده شده را می توان در هر فرمتی در رایانه شخصی شما ذخیره کرد.

اینکه کدام یک از گزینه های بالا اعمال خواهد شد بستگی به ارزش فاکتورهای استفاده ثابت برای پرداخت به مشتریان دارد و در قسمت Master data and Administration → Sales → Wholesales → Payment invoice تنظیم می شود.

سند فاکتور برای پرداخت 1C 8.3

ایجاد حساب کاربری در 1s 8.3 با وارد کردن حساب جدید از ثبت اسناد تجاری و همچنین ورود بر اساس با رعایت شرایط خاص امکان پذیر است.

به سفارش مشتری در صورتی که:

در آن، قراردادی با ترتیب تعامل با سفارشات انتخاب می شود.

این نیازی به توافق ندارد، اما توافقنامه روش پرداخت توسط سفارشات را مشخص می کند.

فاکتور برای پرداخت در 1C بر اساس فروش کالا و خدمات ایجاد می شود اگر:

از قرارداد استفاده می شود که سفارش را توسط بارنامه تعریف می کند.

قرارداد مورد نیاز نیست، اما توافقنامه حاوی قوانین تسویه حساب توسط بارنامه است.

یک حساب در 1C 8.3 را می توان بر اساس هر یک از اسناد فوق ایجاد کرد، مشروط بر اینکه قوانین تسویه حساب متقابل با مشتری تحت توافق نامه باشد.

هنگام ایجاد فاکتور برای پرداخت 1C 8.3، با توجه به داده های هر یک از اشیاء مشخص شده، محل کار "ایجاد فاکتور برای پرداخت" در نظر گرفته شده است، با دستور ایجاد بر اساس در لیست باز می شود.

دو تب کار در اینجا ارائه شده است: مراحل و پرداخت ها و فاکتورهای پرداخت. هر کدام جزئیات خود را فرض می کنند و عملکردهای خاصی را انجام می دهند.

اولین مورد تمام پرداخت های برنامه ریزی شده ارائه شده توسط برنامه پرداخت را نمایش می دهد.

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

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

بیایید یک مثال بزنیم. شرایط تعامل برای مشتری تعیین شده است: برای ارسال محصولات طبق برنامه، خریدار باید 50٪ مبلغ این برنامه را پیش پرداخت کند، مابقی باید ظرف 5 روز پس از ارسال پرداخت شود. . تمامی پرداخت ها از طریق صندوق دار انجام می شود.

ورودی داده به این صورت است:

جزئیات: با سفارشات;

روش پرداخت: نقدی؛

گزینه های پرداخت: پیش پرداخت (قبل از حمل و نقل) 50٪ و اعتبار (بعد از حمل و نقل) 5 روز 50٪

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

پرچم‌ها در ستون اول برگه به ​​طور خودکار برای خطوطی تنظیم می‌شوند که برای پرداخت باید فاکتور صادر کنید. اگر پرداخت خط قبلاً انجام شده باشد (اسناد پرداخت وارد پایگاه داده شده باشد)، خط غیرفعال می شود و مبلغ دریافتی قبلاً در ستون "پرداخت" نمایش داده می شود. یک حساب کاربری با فشار دادن دکمه ای به همین نام ایجاد می شود. در این صورت یک فاکتور پست شده جدید ایجاد می شود که اطلاعات آن مطابق با داده های سند مبنا و مبلغ قابل پرداخت پر می شود. در لیست حساب ها در تب بعدی "فاکتورها برای پرداخت" در وضعیت صادر شده نمایش داده می شود.

حساب جدید در 1C حاوی اطلاعات زیر است:

در کلاه: بر اساس آنچه قرار داده شده، کی، به چه کسی و از چه کسی;

مراحل پرداخت، فرم پرداخت، حساب بانکی و/یا صندوق و برنامه پرداخت را نمایش می دهد.

علاوه بر این، مدیر، رئیس، حسابدار ارشد مشخص می شود، هدف پرداخت پر می شود و در صورت لزوم متن اضافی برای خروجی به فرم چاپی وارد می شود.

برای راحتی کاربر می توانید متن دلخواه دیگری را در نظر وارد کنید.

تمام فاکتورهای ایجاد شده برای پرداخت 1C 8.3 در لیست حساب ها در بخش "فروش" موجود است. می‌توانید با استفاده از گزارش «اسناد مرتبط»، تمام فاکتورهای صادر شده برای شی تسویه حساب را مشاهده کنید و با کلیک روی خطوط مربوطه گزارش، آنها را مستقیماً از گزارش باز کنید.

با استفاده از دستور «Print» در هر زمان که بخواهید می توانید یک فرم قابل چاپ برای یک حساب پست شده در 1C چاپ کنید، همچنین امکان گروه بندی خروجی چندین حساب انتخابی وجود دارد.

فرم قابل چاپ فاکتور پرداخت 1C 8.3

تشکیل تنها فرم چاپ شده Account for 1C 8.3 بدون ذخیره آن در پایگاه داده از اشیاء سیستم زیر در دسترس است:

از یک سفارش فروش، مشروط به شرایط زیر:

از قراردادی با تسویه حساب های دقیق با دستورات استفاده می کند.

قرارداد مورد نیاز نیست، اما در توافق، گزینه تسویه با دستورات.

از فروش کالا و خدمات در صورتی که:

توافق نامه ای استفاده می شود که در آن تسویه حساب های متقابل طبق صورتحساب ها انجام می شود.

قرارداد مورد نیاز نیست، اما توافقنامه جزئیات فاکتورها را مشخص می کند.

یک حساب در 1s 8.3 را می توان با توجه به داده های هر یک از اسناد بالا ایجاد کرد، در صورتی که رویه تسویه حساب را تحت قراردادها اعمال کنند.

همچنین برای حساب های 1C امکان برداشت فاکتور با فکس اجرا شده است. برای این کار باید در تنظیمات چاپ، چاپ فکس را به کارت سازمانی اضافه کرد (روش افزودن در لینک «چگونه فکس بسازیم؟» موجود است. پرینت چنین فاکتوری برای پرداخت در 1C توسط دستور Print با انتخاب آیتم منوی مناسب انجام می شود.

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

کار با سند در مجله برنامه های کاربردی برای پرداخت انجام می شود. دسترسی به مجله از طریق آیتم منوی اصلی "درخواست‌های پرداخت" "ژورنال درخواست‌های پرداخت"و همچنین از طریق موارد موجود در کنترل پنل دسکتاپ های برنامه.

شرح فرم سند "درخواست پرداخت"

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

فرم سند "درخواست پرداخت"

جزئیات اساسی

لیست جزئیات اساسی:

• مدت پرداخت - مهلتی که تا آن درخواست باید پرداخت شود.
• تراکنش - یک معامله پرداخت که نوع تسویه حساب با طرف مقابل را تعیین می کند. شرط لازم برای پر کردن است.
• ماده DDS - طبقه بندی درخواست ثبت شده برای پرداخت مطابق با طبقه بندی مقالات اتخاذ شده در سازمان. شرط لازم برای پر کردن است.
• سازمان - شرکتی که درخواست در آن ثبت شده است. هنگام وارد کردن یک سند جدید، ویژگی به طور خودکار مقدار "سازمان اصلی" را از تنظیمات شخصی کاربر می گیرد (در قالب عنصر فهرست "کاربران" نشان داده شده است). شرط لازم برای پر کردن است.
• CFD - یک واحد ساختاری شرکت (بخش، بخش، بخش) مسئول تسویه حساب متقابل با طرف مقابل - گیرنده وجوه.
• آغازگر - فردی است که آغازگر معامله ای است که برای پرداخت ثبت شده است. مورد نیاز یک ویژگی اضافی برنامه است و به عنوان یک معیار انتخاب در گزارش‌ها و گزارش‌های زیرسیستم استفاده می‌شود.
• روش پرداخت - روش اولویت پرداخت برای برنامه (نقدی یا غیر نقدی) را تعیین می کند. هنگام وارد کردن یک سند جدید، ویژگی مقدار "غیر نقدی" را به خود می گیرد.
• نظر - یک خط اظهار نظر دلخواه به درخواست ثبت شده برای پرداخت؛
• مسئول - کاربری که سند درخواست را در برنامه ثبت کرده است. ویژگی به طور خودکار پر می شود و برای ویرایش در دسترس نیست.

برگه "هدف پرداخت".

هنگام ثبت سند در برگه "هدف پرداخت ها" باید مشخصات زیر را وارد کنید:

• طرف مقابل - شخص حقوقی یا حقیقی که دریافت کننده وجوه است، از فهرست "طرفداران" پر می شود. شرط لازم برای پر کردن است.
• توافقنامه - توافق نامه با طرف مقابل که براساس آن لازم است وجوه انتقال داده شود.
• مقدار پرداخت ؛
• نرخ مالیات بر ارزش افزوده؛
• مبلغ مالیات بر ارزش افزوده موجود در مبلغ پرداختی؛
• ارز وجوه؛
• هدف از پرداخت– رشته هدف پرداخت که موضوع تراکنش را مشخص می کند، یعنی. که برای آن نیاز به انتقال پول دارید. هدف از پرداخت می تواند به طور خودکار تولید شود.
• شماره سند بنیاد- شماره سندی که مبنای درخواست است (به عنوان مثال، شماره فاکتور برای پرداخت، شماره فاکتور و غیره).
• تاریخ سند تأسیس- تاریخ سندی که مبنای درخواست است.
• یک پایه سند- خط اطلاعاتی که سند اولیه دریافت شده از طرف مقابل را مشخص می کند و مبنایی برای انتقال وجوه است. اگر مبنای پرداخت فاکتور پرداخت باشد، مشخصات سند به صورت دستی پر می شود. این ویژگی به طور خودکار هنگام وارد کردن یک برنامه بر اساس سند تأمین کننده (فاکتور، گواهی تکمیل و سایر اسناد اولیه ثبت شده در 1C: حسابداری) پر می شود.

برگه "اسناد همراه".

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

درخواست پرداخت: برگه "مدارک همراه"

لیست لوازم موجود:

• عنوان سند- نام سند پیوست هنگام افزودن یک فایل سند، این قسمت به طور خودکار با نام فایل پر می شود. در صورت لزوم، کاربر می تواند مقدار مشخص شده را تغییر دهد.
• نوع سند - نوع سند پیوست. این فیلد قابل ویرایش نیست و با انتخاب فایل به صورت خودکار پر می شود.

شرکت می تواند به صورت نقدی و یا با انتقال وجه به حساب تسویه تامین کننده (پرداخت غیرنقدی) به تامین کننده پرداخت کند. پرداخت نقدی با استفاده از سند سفارش نقدی خروجی انجام می شود.

پرداخت غیر نقدی (انتقال وجوه به حساب تسویه تامین کننده) در سند انباشت وجوه غیرنقدی ثبت می شود.

اسناد قابل صدور بر اساس اسنادی که قبلاً اجرا شده است رسید کالا و خدمات. انتقال وجوه به حساب تسویه تامین کننده در دو مرحله اجرا و چاپ سند پرداخت (دستور پرداخت خروجی) و ثبت انتقال واقعی وجه از حساب تسویه شرکت به حساب تسویه تامین کننده (پس از دریافت بانک) انجام می شود. بیانیه).

این روش برای ورود اسناد می تواند در صورتی باشد که شرکت دریافتی را برنامه ریزی نکرده و هزینه وجوه را کنترل نمی کند. اگر شرکت نیاز به کنترل مخارج وجوه داشته باشد، هزینه وجوه مطابق با درخواست تایید شده برای هزینه وجوه انجام می شود. برای پیاده سازی چنین گزینه پرداختی در برنامه، در قسمت مدیریت - سازمان ها و وجوه باید تیک گزینه Applications for sping funds را علامت بزنید.

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

برای کنترل مخارج وجوه از سند درخواست هزینه وجوه استفاده می شود.

نحوه برنامه ریزی و هماهنگی با مدیریت هزینه وجوه.

برای استفاده از سازوکارهای برنامه ریزی و کنترل مصارف وجوه، لازم است در قسمت مدیریت - سازمان ها و صندوق ها، چک باکس درخواست های هزینه کرد وجوه علامت زده شود.

همچنین امکان کنترل هزینه وجوه مطابق با محدودیت های تعیین شده در مصرف وجوه وجود دارد. برای اعمال چنین کنترلی، باید چک باکس های اضافی را برای کنترل محدودیت در بخش مدیریت - سازمان ها و وجوه تنظیم کنید.

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

برای هر بخش و برای هر سازمان می توان محدودیت هایی را برای هزینه وجوه تعیین کرد.

لازم به ذکر است که اگر کنترل مخارج برای هر یک از اقلام جریان نقدی ضروری نباشد، همچنان باید در بخش جدولی سند محدودیت های هزینه DS گنجانده شود، برای آن گزینه کنترل نباید محدود شود. . این امکان وجود دارد که به طور خودکار قسمت جدولی سند را با تمام موارد جابجایی مربوط به هزینه وجوه یا آن محدودیت های هزینه برای DS که در ماه قبل تعیین شده است پر کنید.

فرآیند تایید و تایید درخواست شامل مراحل زیر می باشد.

• تهیه درخواست توسط آغازگر پرداخت.
• تایید درخواست ها.
• تایید درخواست ها (تهیه درخواست ها برای پرداخت).

تهیه درخواست توسط آغازگر پرداخت.

درخواست هزینه وجوه توسط مدیر بر اساس سند تحویل تهیه می شود. یک برنامه برای خرج کردن پول می تواند از یک لیست یا از یک فرم سند ایجاد شود.

همچنین امکان صدور یک درخواست برای چندین سند تحویل یا بدون ذکر سند تسویه حساب وجود دارد.

در یک درخواست جدید برای هزینه کردن وجوه، تمام داده های سندی که بر اساس آن درخواست انجام شده است پر می شود. مدیر صحت پر کردن داده ها را در برنامه کنترل می کند، تاریخ مورد انتظار پرداخت را تعیین می کند و آن را انجام می دهد. درخواست در وضعیت تایید نشده ارسال شده است.

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

تایید درخواست ها.

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

در لیست، می توانید برنامه های متناقضی را که مهلت پرداخت برای آنها مناسب است، انتخاب کنید. برای انجام این کار، در لیست، باید انتخاب را بر اساس وضعیت تایید نشده و تاریخ پرداخت تنظیم کنید.

همچنین می توانید به طور جداگانه برنامه هایی را که دارای بالاترین اولویت هستند و برنامه های کاربردی برای هر سازمان بررسی کنید.

هنگام مشاهده برنامه ها، رئیس بخش (خزانه دار، مدیر مالی) تمام اطلاعات لازم در مورد برنامه را در لیست می بیند: مبلغ درخواست، گیرنده و غیره. بدون باز کردن لیست، می تواند توجیهی برای درخواست مشاهده کند. نیاز به صرف بودجه برای برنامه (فایل های پیوست). برای این کار بر روی آیکون کلیک کنید.

برای تأیید (رد) چندین درخواست پرداخت، می توانید درخواست های لازم را در لیست انتخاب کنید و دستورات مناسب را انتخاب کنید:

• برنامه های هماهنگ - در صورت نیاز به هماهنگی برنامه ها برای هزینه کردن بودجه.
• رد درخواست ها - در صورتی که درخواست های خرج کردن پول باید رد شود.

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

شما می توانید تایید درخواست توسط چندین نفر را سازماندهی کنید. در این مورد، فرآیند تأیید درخواست را می توان در برنامه 1C: Document Management با استفاده از امکان استفاده مشترک از برنامه های Trade Management و 1C: Document Management سازماندهی کرد.

تایید درخواست ها (تهیه درخواست ها برای پرداخت).

برای تأیید برنامه ها، کاربر باید یک نقش اضافی تعریف کند - تأیید پرداخت برنامه های کاربردی برای هزینه کردن وجوه. در برنامه، این نقش برای پروفایل دسترسی Treasurer تنظیم شده است.

اطلاعات مربوط به برنامه های کاربردی تایید شده در تقویم پرداخت گنجانده شده است (بخش امور مالی).

مقدار پرداخت های توافق شده روی برنامه ها در ستون همه در انتظار نمایش داده می شود.

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

مستقیماً از تقویم می توانید دستور انتقال وجه (از صندوق نقدی دیگر، حساب جاری دیگر) یا ثبت دریافت مورد انتظار وجه (دریافت وام اضافی، اعتبار و غیره) صادر کنید.

پس از تعیین تاریخ و روش پرداخت، سرمایه‌دار درخواست‌ها را تأیید می‌کند (وضعیت برای پرداخت را برای آنها تعیین می‌کند).

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

پس از تأیید برنامه (تنظیم وضعیت برای پرداخت)، می توانید یک سند پرداخت برای خرج کردن پول تهیه کنید.

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

در مورد پرداخت های نقدی، سند سفارش خروجی نقدی تنظیم می شود. درخواست برای هزینه وجوه به عنوان دستور پرداخت در لیست کوپن های خروج نقدی نشان داده می شود. برای رفع مشکل، کافیست روی دکمه پرداخت کلیک کنید. اطلاعات در ضمانت نامه نقدی خروجی مطابق با داده های برنامه تأیید شده تنظیم می شود.

انتقال وجوه از حساب جاری در دو مرحله انجام می شود:

1. دستور پرداخت تنظیم و چاپ می شود. دستور پرداخت به بانک ارسال می شود.
2. حذف واقعی وجوه از حساب جاری با دریافت عصاره بانک در مورد جابجایی وجوه در حساب جاری ثبت می شود.

نحوه صدور و چاپ سند پرداخت.

در برنامه می توانید هر نوع سند پرداختی را صادر کنید: دستور پرداخت خروجی، اعتبار اسنادی منتقل شده، دستور وصول انتقالی و غیره. برای ثبت همه این نوع اسناد، برنامه از یک سند استفاده می کند - رد وجوه غیرنقدی. .

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

لیست اسنادی که پرداخت باید برای آنها ثبت شود در صفحه برای پرداخت لیست اسناد پرداخت های غیر نقدی نمایش داده می شود.

اگر از برنامه ریزی نقدی استفاده نمی شود (چک درخواست برای خرج کردن پول نقد در تنظیمات پاک می شود)، این لیست تمام اسنادی را که برای آنها لازم است هزینه های نقدی صادر شود نمایش می دهد: سفارش به یک تامین کننده، دریافت کالا و خدمات. ، و غیره.

اگر تسویه حساب های متقابل با تامین کننده به طور کلی تحت قرارداد انجام شود (بدون ذکر جزئیات در مورد سفارشات یا فاکتورها)، در این صورت لیست میزان بدهی به تامین کننده تحت قرارداد را نشان می دهد.

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

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

پس از ارسال سند، مبلغ و ارز تسویه حساب های متقابل به صورت خودکار پر می شود. ارز تسویه حساب های متقابل توسط ارز تسویه حساب های متقابل تعیین می شود که در شی تسویه مشخص شده در سند پرداخت تعریف شده است. در مورد ما، موضوع تسویه حساب سند رسید است، این نشان دهنده ارز تسویه حساب های متقابل، روبل است، بنابراین میزان تسویه حساب های متقابل نیز به روبل ثابت می شود.

سند پرداخت چاپ شده و به بانک ارسال می شود. برای اجرای صحیح دستور پرداخت، باید تمام جزئیاتی را که در قسمت هدف پرداخت ارائه شده است، به دقت بررسی و در صورت لزوم تصحیح کنید. برای تکمیل خودکار هدف پرداخت، از دستور Insert استفاده کنید. با استفاده از این دستور، می توانید لیست اسنادی را که برای آنها باید پرداخت را ثبت کنید (که در قسمت جدول سند به عنوان یک شی تسویه مشخص شده است) پر کنید.

نحوه ثبت واقعیت انتقال وجه از حساب جاری شرکت به حساب جاری تامین کننده.

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

امکان تنظیم یک علامت گروهی برای بانک برای انجام لیست انتخابی از پرداخت ها وجود دارد.

در زمان دریافت صورت حساب بانکی، حسابدار باید مراحل زیر را انجام دهد.

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

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

لازم به ذکر است که در این برنامه امکان ثبت خودکار پرداخت ها با استفاده از برنامه «مشتری بانک» فراهم شده است. این برنامه با کلیک روی دکمه Exchange با یک بانک در لیست پرداخت های بدون نقد راه اندازی می شود.

پرداخت مختلط نیز ارائه می شود. یعنی بخشی از مبلغ را می توان به صورت نقدی پرداخت کرد و بخشی را - با انتقال وجه به حساب تسویه حساب تامین کننده. در همان زمان، بر اساس درخواست برای هزینه کردن وجوه (یا یک سند دریافت)، دو سند تنظیم می شود: حکم وجه نقد هزینه و رد وجوه غیر نقدی.

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

نحوه پرداخت ارز به تامین کننده با انتقال وجه به حساب جاری ارزی.

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

وجوه باید از حساب ارزی شرکت به حساب ارزی تامین کننده منتقل شود.

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

1. مقدمه

برنامه ریزی وجه نقد بر خلاف حسابداری یکی از وظایف اصلی حسابداری مدیریت است.

البته تفاوت های قابل توجه دیگری نیز بین CM و BU وجود دارد (الزامات مختلف برای تجزیه و تحلیل، برای ارزیابی و تجدید ارزیابی دارایی ها / بدهی ها، نیاز به ایجاد ذخایر و غیره)، اما نیاز به حل مشکلات برنامه ریزی سخت ترین آنها است. .
پیچیدگی برنامه ریزی نه تنها در تهیه یک برنامه (محاسبه، شکل گیری آن با توجه به سناریوهای مختلف) نهفته است، بلکه لازم است:

• انجام برنامه ریزی مجدد؛
• به روز رسانی برنامه ها، انتقال تنظیمات به دوره های بعدی؛
• انجام یک طرح - تحلیل واقعی.

باید دانست که اکثر شرکت ها (از 1C برای اتوماسیون استفاده می کنند) در برنامه برنامه ریزی نمی کنند.
"ما باید حسابداری را تنظیم کنیم .." - بسیاری از مردم استدلال می کنند.

حسابداری باید تعدیل شود، بله، اما نه به ضرر برنامه ریزی.
البته، برنامه ریزی هنوز درگیر است (اما نه در 1C، بلکه در XLS). و اولین وظیفه اصلی (که آنها سعی در حل آن دارند) برنامه ریزی بودجه است.

• (1) استراتژیک (بودجه).
• (2) عملیاتی.

و اگر بودجه بندی (البته با رویکرد برنامه ریزی از بالا به پایین) با استفاده از XLS قابل انجام باشد، برنامه ریزی عملیاتی نمی تواند.
نکته اصلی این است که حداقل کاربر (1-2 نفر) اغلب با جداول بودجه کار می کنند. برای بسیاری از شرکت ها، تعداد آیتم های بودجه بندی، و غیره تحلیلگر - تعداد زیادی از آنها وجود ندارد. یعنی همه چیز را می توان با "دسته" در XLS پردازش کرد.

اما با توجه به برنامه ریزی عملیاتی برای d / s، وضعیت در اینجا متفاوت است. یعنی اغلب تعداد زیادی فاکتور برای پرداخت، بسیاری از پرداخت های منظم، پرداخت های مورد انتظار برای سفارشات مشتری و غیره وجود دارد.

و علاوه بر این ، همه اینها را می توان به تعداد زیادی اسناد اولیه که کاربران مختلف برنامه با آنها کار می کنند "گره خورده" ، اسناد اصلاح می شوند ، وضعیت تغییر می کند و غیره.

تفاوت مهم دیگر بین برنامه ریزی عملیاتی و بودجه ریزی این است که اغلب از پایین به بالا پیش می رود. یعنی از "برنامه های مصرف d / s" که همیشه توسط کارمندان بخش ها صادر می شود.

و بر این اساس ، این برنامه ها باید به موقع پردازش شوند ، پذیرفته شوند / رد شوند ، "در برنامه قرار بگیرند" و پرداخت شوند.

جمع:برنامه ریزی عملیاتی برای d/s می باشد اولین کار برنامه ریزی، که باید در "1C" برای هر شرکتی خودکار شود.

و در نتیجه برنامه ریزی، بخش دارایی / خزانه داری باید در سیستم "ببینید":

• چه زمانی، به چه کسی، از کدام حساب جاری / صندوق نقدی، برای چه مبلغی باید پرداخت کنید.
• با در نظر گرفتن مانده های جاری، هزینه های برنامه ریزی شده و دریافتی های d / c در تاریخ "فلان" چقدر است. لازم است از به اصطلاح اجتناب شود. "شکاف های نقدی".

  یعنی نیاز به کار با تقویم پرداخت وجود دارد.

• با در نظر گرفتن پرداخت های برنامه ریزی شده، دریافت ها و مانده جاری تسویه حساب های متقابل، چه بدهی با طرف مقابل در تاریخ های مشخص شده خواهد بود.

  یعنی نیاز به کار با تقویم محاسبات وجود دارد.

هدف این مقاله - در مورد امکانات خودکارسازی برنامه ریزی عملیاتی برای d / s صحبت کنید. در همان زمان، یک تجزیه و تحلیل مقایسه ای از 3 پیکربندی گردش مختلف انجام خواهد شد (دو مورد از 1C معمولی هستند، یکی از wiseadvice تخصصی است).

هر یک از پیکربندی ها را می توان برای حل وظایف برنامه ریزی عملیاتی برای c / c مورد استفاده قرار داد، با این حال، انتخاب متعادلی باید بر اساس دامنه و مقیاس پروژه شما انجام شود.

2. قابلیت های SCP 1.3

در حال حاضر، 1C هنوز نسخه جدید و مورد انتظار SCP (نسخه 2) را منتشر نکرده است. و بنابراین، ما بر آنچه در دسترس است تمرکز خواهیم کرد - زیر سیستم های مربوطه SCP 1.3:

باید لغو شود که سیستم فرعی "برنامه های مربوط به هزینه وجوه" نسبتاً اخیراً (2011) در پیکربندی به روز شده است. و در نتیجه، در حالت رابط مدیریت شده، مورد "برنامه های کاربردی برای صرف d / s /" در پانل بخش ها ظاهر شد.

اگر در یک پیکربندی معمولی امتحان کنید، در حالت فایل، فرم سند "برنامه هزینه d / s" (با نام مستعار، ZRDS) را باز کنید، سپس یک خطا بلافاصله در متغیر "GlobalValues" از ماژول عمومی رخ می دهد. کار با متغیرهای عمومی.

این نوع خطا را می توان اصلاح کرد، اما همانطور که می گویند: "رسوب باقی می ماند." یعنی در زیرسیستم ZRDS UPP "زبری" کافی وجود دارد.
امکان صدور سند WRDS از طریق مرورگر وب مفید است، اما در عمل لازم است به دقت در مورد ساده سازی و ارگونومی فرم استاندارد سند فکر کنید. این امر به ویژه برای دستگاه های تلفن همراه مهم خواهد بود.

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

هنگام کار با ZRDS، روش هماهنگی و تأیید برنامه ها مکان مهمی را اشغال می کند. بسته به ساختار سازمانی شرکت و سایر ویژگی های تجاری، رویه داخلی تأیید برنامه ها (مقررات تأیید) می تواند کاملاً پیچیده باشد (چند مرحله ای، متغیر و غیره). بنابراین، برای اتوماسیون، این کار آسانی نیست.

در SCP زیر سیستم هماهنگی و تایید پیاده سازی می شود. تنظیمات کاملاً انعطاف پذیری را ارائه می دهد.

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

این باید لغو شود که تعدادی از نقاط عملکرد معمولی SCP آنچه را که در اجرای واقعی زیرسیستم مورد نیاز است را ارائه نمی دهد.
من بعداً در مورد این "لحظه ها" خواهم نوشت، اما در حال حاضر بیایید در نظر بگیریم که یک پیکربندی معمولی چه عملکردی را ارائه می دهد.

1. می توانید استفاده از مکانیسم تایید برنامه را به طور جداگانه برای هر سازمان فعال کنید.

• امکان تنظیم توالی عبور برنامه در طول مسیرها، سلسله مراتب مسیرها وجود دارد.

1. در عین حال، باید توجه داشت که سلسله مراتب در فهرست زیربخش در مکانیسم های مسیریابی برنامه در نظر گرفته نمی شود.
2. همچنین لازم است لغو شود که هماهنگی و تایید از نظر فنی بدون استفاده از مکانیزم فرآیند تجاری ساخته شده است.

• در هر نقطه می توانید یک یا چند کاربر را مشخص کنید که اجرای تاییدیه اپلیکیشن برای آنها در دسترس خواهد بود. یعنی هر یک از آنها می توانند درخواست را تأیید کنند (که اول وقت دارند آن را انجام دهند).

• برای هر واحد می توانید نقطه مربوط به مسیر تایید را تعیین کنید. نکته اصلی این است: هنگام ایجاد یک برنامه (ZRDS)، CFD (بخش فرعی) باید نشان داده شود. و بسته به زیربخش مشخص شده، SCP نقطه تطبیق مربوط به آن را پیدا می کند و درخواست تأیید را به این نقطه «ارسال می کند».

همچنین عدم تعیین دپارتمان در تنظیم مسیر هماهنگی جایز است. در این مورد، چنین نقطه توافقی برای تمام CFD هایی که نقطه مسیر مربوطه برای آنها مشخص نشده است، "اعمال" خواهد شد.

1. خود هماهنگی با استفاده از پردازش ویژه "تصویب برنامه ها" انجام می شود.

1. تجزیه و تحلیل در دسترس بودن برنامه ریزی شده وجوه، برنامه پرداخت و ردیابی شکاف های نقدی در گزارش "تقویم پرداخت" انجام می شود.

علاوه بر مصرف برنامه ریزی شده d / s (ZRDS)، دریافت برنامه ریزی شده d / s را نیز می توان در نظر گرفت. برای این منظور، یک سند ویژه "دریافت برنامه ریزی شده d / s" ارائه می شود.

لازم به ذکر است که اگرچه در سند "دریافت برنامه ریزی شده d / s" حالت هایی (تهیه شده، تایید شده و غیره) وجود دارد، اما امکان توافق بر روی این سند (و همچنین ZRDS) وجود ندارد. یعنی تغییر وضعیت سند فقط در حالت "کنترل دستی" امکان پذیر است.

و با این حال در SCP فرصتی وجود دارد که دریافت برنامه ریزی شده d / s از خریداران بدون صدور اسناد "دریافت برنامه ریزی شده d / s" در نظر گرفته شود.

یعنی اگر "سفارشات مشتری" برای خریدار صادر شود، در یک گزارش جداگانه "تقویم پرداخت با در نظر گرفتن سفارشات"، این رسید برنامه ریزی شده d / c قابل مشاهده است.

1. علاوه بر گزارش «تقویم پرداخت»، گزارش «تحلیل موجودی وجوه» ارائه شده است.

در همان زمان، امکان رزرو d / c (در برنامه های مربوط به هزینه ها) یا قرار دادن برنامه ها به حساب رسیدهای برنامه ریزی شده وجود دارد.

همچنین قابلیت بستن ZRDS و دریافت های برنامه ریزی شده d / s وجود دارد. برای این منظور، در حالت "مشتری عادی"، اسناد "بستن درخواست برای هزینه / دریافت d / s" ارائه می شود.

با این حال، این عملکرد در حالت thin/web client نیز پشتیبانی نمی‌شود.
در اینجا شما باید درک کنید که تکنیک "رزرو سخت" به شدت با زمان بندی ورود اسناد مرتبط است و این تنظیمات و زمان بندی مجدد را دشوار می کند.

بنابراین، عملکرد در SCP به جای "میراث گذشته" باقی مانده است و باید از تقویم پرداخت برای تجزیه و تحلیل در دسترس بودن d / c استفاده شود.

بنابراین، عملکرد SCP در نظر گرفته شد و اکنون من آن لحظات یک پیکربندی معمولی را که در عمل، در پروژه ها باید نهایی شوند، فهرست می کنم:

1. طبق سند "برنامه هزینه d / c":
   1. در سند، می توانید "بخش فرعی" را مشخص کنید (به هر حال، در پیکربندی به عنوان CFR - مرکز مسئولیت مالی تعیین شده است). اما کاملاً ممکن است که برنامه از یک واحد (FSC) ساخته شده باشد، و در عین حال، هزینه ها باید بیشتر به بخش دیگر / سایر بخش ها (FSC - مراکز مدیریت مالی) نسبت داده شود / توزیع شود.

      امکان تعیین DFS و ... - گم شده

      امکان تغییر مسیر وجود ندارد، برنامه را به مسیرهای دیگر هدایت کنید.

1. امکان برنامه ریزی برای انتقال وجه نقد بین حساب های تسویه، از حساب به صندوق و ... وجود ندارد.
1. فرآیند توافق:
   1. فرصتی برای هماهنگی ZRDS وجود دارد، اما هیچ امکانی برای هماهنگی دریافت برنامه ریزی شده d / s وجود ندارد.
   2. در عمل، انجام هماهنگی برای سایر کارکنان ضروری می شود. در عین حال، سیستم همچنین باید اطلاعاتی در مورد "چه کسی و برای چه کسی هماهنگی را انجام داده" را ثبت کند.

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

      به طور خلاصه، هیچ امکانی برای هماهنگی برای مجری دیگر وجود ندارد، توانایی نشان دادن اینکه چه کسی و برای چه کسی حق هماهنگی دارد - وجود ندارد.

   3. در فرآیند تایید درخواست ها، زمانی که درخواست به سمت تایید بعدی در طول مسیر حرکت می کند، قابلیت اطلاع رسانی خودکار (از طریق ایمیل) مجری بعدی و همچنین نویسنده درخواست الزامی است. .
   4. اگر نویسنده برنامه قبلاً مسئول تأیید / تأیید است (در هر مرحله از مسیر!) ، کاملاً منطقی است که برنامه به طور خودکار مسیر را "کوتاه" کند و برنامه را به بالاترین سطح موجود هدایت کند. با این حال، این در PPP پیش بینی نشده است.
   • همه الزامات ذکر شده، اگرچه در پیکربندی معمولی نیستند، با این وجود.

1. گزارش ها، حقوق دسترسی
   1. امکان محدود کردن دسترسی به برنامه ها فقط برای نویسندگان / مجریان موجود (هماهنگ کننده) مورد تقاضا است. بر اساس تقسیمات موجود برای کاربر.
   2. هیچ گزارشی در مورد کنترل (بر اساس روز و فواصل زمانی) بدهی واقعی و برنامه ریزی شده وجود ندارد. این هم برای خریداران و هم برای تامین کنندگان صادق است.
   3. گزارش و بخشی از عملکرد برای کار در حالت نازک / سرویس گیرنده وب مناسب نیست.
2. حسابداری تحت قراردادهای منظم، قراردادها.
   1. اغلب شرایطی وجود دارد که لازم است به طور منظم به تامین کنندگان پرداخت شود. به عنوان مثال، پرداخت اجاره و غیره.

      UPP بازتاب در تقویم پرداخت و غیره را خودکار نمی کند. این هزینه های آینده یعنی باید این گونه پرداخت ها را در حالت کنترل دستی پیگیری کرد و درخواست های پرداخت را پر کرد که ناخوشایند و وقت گیر است.

   2. در قرارداد با خریداران، با تامین کنندگان می توان شرایط درصد پیش پرداخت، شرایط پرداخت و ... را پیش بینی کرد.

      UPP به طور خودکار تمام این اطلاعات را ثبت نمی کند و (در نتیجه) به طور خودکار آن را در تقویم پرداخت منعکس می کند.

3. ویژگی های UT 11.1

با انتشار پیکربندی جدید "Trade Management Rev. 11"، بسیاری از ویژگی های جدید و مفید برای وظایف برنامه ریزی عملیاتی و کنترل مالی ظاهر شده اند.
شاید مهمترین مورد در این بخش در UT11 (در مقایسه با SCP 1.3) مکانیسم حسابداری برای برنامه پرداخت باشد. این مکانیسم فقط آنچه را که به شدت کمبود داشت "بسته" می کند - اتوماسیون برنامه ریزی / حسابداری تحت قراردادهای منظم، قراردادها.

بنابراین ، در UT11 می توان به هیچ وجه (البته در صورت عدم لزوم) اسنادی برای هزینه های برنامه ریزی و رسیدهای d / c تهیه نکرد و در همان زمان ، تقویم پرداخت به طور معمول تشکیل می شود.

می‌توانید لغو کنید که «تنظیمات معمولی» گزارش «تقویم پرداخت» واقعاً انتظارات را برآورده نمی‌کند (به این ترتیب، تقویم نمایش داده نمی‌شود)، اما در حالت کاربر، می‌توانید گروه‌بندی را براساس «تاریخ پرداخت» اضافه کنید و گزارش به شکل معمول تولید شود.

عملکرد گزارش با استفاده از سیستم ترکیب داده ها (در مقایسه با SCP 1.3) بسیار گسترش یافته است. اکنون می توان یک گزارش در یک کلاینت نازک / وب تولید کرد، در پایگاه داده ذخیره کرد و با تنظیمات مورد نیاز به کاربران مختلف اختصاص داد.

علاوه بر برنامه ریزی جریان و دریافت d / s، UT11 دارای عملکرد برنامه ریزی حرکت d / s است. برای این منظور می توانید اسناد "دستور جابجایی d / s" را تهیه کنید.

در مقایسه با UPP 1.3، برای سند "برنامه هزینه d / c"، تعداد انواع معاملات تجاری در نظر گرفته شده افزایش یافته است:

اکنون می توان هم مدارک "درخواست هزینه d/c" و هم سایر دستورات را تأیید کرد:

برای تجزیه و تحلیل بدهی بر اساس فواصل / شرایط، گزارش "حساب های دریافتنی" ارائه شده است. در صورت لزوم، می توانید یک تقویم بدهی ایجاد کنید. برای انجام این کار، در حالت کاربر، گروه بندی بر اساس تاریخ پرداخت را اضافه کنید.

متاسفانه، UT11 (مانند قبل) امکان تجزیه و تحلیل تقویم بدهی توسط تامین کننده را فراهم نمی کند. با این حال، UT11 را برای این کار نهایی کنید.

به طور خلاصه: راه حل های روش شناختی جدید "1C" به همراه قابلیت های پلت فرم 8.2 مبنای خوبی برای خودکارسازی وظایف برنامه ریزی عملیاتی و کنترل d / s فراهم می کند.

اما در عین حال، باید درک کرد که پیکربندی UT11 یک راه حل کامل و آماده برای خودکارسازی خزانه و برنامه ریزی d / s نیست.

• در مرحله اول، در UT11، به شکل بسیار ساده، مکانیزمی برای هماهنگی / تایید برنامه های کاربردی برای مصرف و سایر اسناد برنامه ریزی برای d / s اجرا می شود. یعنی هیچ مکانیزم مسیریابی وجود ندارد، روند تأیید برنامه ها به یک تنظیم ساده از وضعیت ها کاهش می یابد.
• ثانیاً، در UT11 هیچ زیرسیستم بودجه بندی وجود ندارد و (در نتیجه) هیچ عملکردی برای نظارت بر درخواست ها برای بودجه های برنامه ریزی شده وجود ندارد.

4. فرصت های WA: سرمایه گذار

از لحاظ تاریخی، پیکربندی WA:Financier بر اساس محصول مدیریت خزانه داری توسعه یافته است.

و در عین حال، راه حل جدید Financier از WiseAdvice نیز شامل:

• زیر سیستم برنامه ریزی بودجه;
• زیر سیستم مدیریت قرارداد؛
• زیر سیستم برای تشکیل و حسابداری پرداخت های واقعی؛
• مکانیزم انعطاف پذیر و قابل تنظیم برای تولید/پر کردن اسناد بر اساس الگوها.
• زیرسیستم انعطاف پذیر و قابل تنظیم برای ادغام با مشتری-بانک.

بیایید عملکرد اصلی "WA: Financier" را از نظر خزانه در نظر بگیریم - از حسابداری شرایط تحت قراردادها تا تشکیل تقویم پرداخت.

1. در فرآیند تأیید یک برنامه، شما نه تنها می توانید سند را تأیید / رد کنید (همانطور که در SCP انجام می شود)، بلکه عملکردهای دیگری نیز در دسترس هستند: به عنوان مثال، سند را برای بازبینی ارسال کنید یا اطلاعات اضافی را درخواست کنید. اطلاعات

   کل این فرآیند به ترتیب خودکار است، گزارشی از وضعیت کار تایید سند ارائه می شود.

5. نتایج

نتیجه گیری:

1. برای خودکار کردن کار بخش های مالی، خزانه داری، سازمان هایی با سازمان های پیچیده. ساختار مناسب ترین راه حل است "WA: Financier".

   این راه حل برای مدت طولانی در حال توسعه و تکامل بوده است، بنابراین ویژگی ها و الزامات فنلاندی های مختلف را جمع آوری می کند. ادارات و خزانه داری کل هزینه های کار برای توسعه راه حل بالغ بر 5000 نفر در ساعت است.

   مزیت راه حل WA: Financier عملکرد پیشرفته و تعداد زیادی مکانیسم تنظیمات برنامه است. بنابراین، اجرای این راه حل در زمان کوتاه (به اصطلاح "پیاده سازی جعبه")، بدون اضافی امکان پذیر است توسعه، برنامه نویسی و غیره

   از آنجایی که راه حل حاوی مکانیسم هایی برای تبادل دو طرفه با تمام تنظیمات اصلی معمولی است، ادغام در ساختار موجود (تبادل داده با پایگاه های داده UT، SCP، Complex، Bukh) دشوار نخواهد بود.

2. برای خودکارسازی بخش مالی / خزانه داری به عنوان بخشی از پروژه اتوماسیون یکپارچهبهترین راه حل مناسب بر اساس SCP.

   در عین حال، باید بدانید که عملکرد SCP نیاز به بهبود دارد.

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

   بنابراین، اجرای SCP برای این وظایف باید تنها به عنوان بخشی از یک پروژه اتوماسیون انجام شود.

3. برای سازمان های بزرگ، برای اتوماسیون بخش خزانه داری UT11مناسب نیست.

   در این تصمیم اولاً هیچ مکانیزمی برای هماهنگی / تصویب اسناد برنامه ریزی وجود ندارد.

   ثانیاً هیچ زیرسیستم بودجه ریزی و کنترلی بر اجرای بودجه در طول برنامه ریزی عملیاتی وجود ندارد.

   با این حال، UT11 عالی برایاتوماسیون (از جمله برنامه ریزی عملیاتی برای d / c) باله کوچک بخش های شرکت.

فرآیند کسب و کار "هماهنگی و تایید درخواست ها برای هزینه کردن وجوه"

در شرایط ثبات مالی، شرکت قادر است به طور کامل و به موقع تعهدات خود را انجام دهد - در این مورد، شرکت نیازی به بهینه سازی استفاده از وجوه ندارد. در حال حاضر، در شرایط بحران مالی، مکانیسم توزیع وجوه کمیاب برای تعهدات شرکت اهمیت ویژه ای دارد.

این فرآیند شامل شش مرحله متوالی است:

1. نماینده واحد (مدیران، مهندسان و ...) درخواستی را برای صرف پول در تعهدات - پیش پرداخت قراردادها و بازپرداخت بدهی در اسناد تسویه تنظیم می کند.

2. رئیس اداره با استفاده از ابزارهای مناسب، صحت درخواست ها را بررسی و در صورت لزوم تصحیح می کند.

3. نماینده مسئول خدمات مالی (مدیر مالی، معاون مالی یا رئیس سازمان) تعیین می کند که وجوه از کدام حساب های جاری، به چه کسانی و به چه میزانی واریز شود.

4. رئیس بخش مبالغ مجاز برای پرداخت را برای برنامه های خاص (در واقع برای تعهدات - سفارش ها، فاکتورها، اسناد تسویه حساب) توزیع می کند.

5. بخش حسابداری مؤسسه، بر اساس درخواست های تأیید شده و تخصیص یافته برای تعهدات، دستور پرداخت خروجی ایجاد می کند.

6. دستورات پرداخت به طور خودکار در بانک مشتری بارگذاری می شود.

ساخت اپلیکیشن برای خرج کردن پول

ثبت عملیات برای هزینه وجوه از حساب های تسویه حساب همیشه با برنامه ریزی هزینه وجوه آغاز می شود - یعنی اجرای برنامه های کاربردی برای هزینه توسط تمام بخش های شرکت درگیر در فرآیند.

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

بنابراین، کل هزینه برنامه ریزی شده وجوه برای کلیه خدمات باید در قالب درخواست برای هزینه وجوه در سیستم منعکس شود.

تشکیل یک برنامه برای هزینه وجوه با استفاده از سند "برنامه برای هزینه وجوه" انجام می شود.

عکس. 1.

بررسی برنامه های آماده شده

رئیس اداره فهرست درخواست های خرج وجه صادر شده توسط زیردستان را بررسی و آن را تصحیح و برای تایید به خدمات مالی ارسال می کند. برای تأیید درخواست برای هزینه کردن، سند "تصویب برنامه ها" تنظیم می شود که در آن اسناد تکمیل نشده "درخواست برای هزینه کردن وجوه" انتخاب می شود.

شکل 2.

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

شکل 3.

تایید درخواست ها توسط خدمات مالی

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

شکل 4

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

شکل 5.

تخصیص پرداخت های تایید شده به درخواست های پرداخت.

رئیس اداره با استفاده از سند "توزیع درخواست ها" مبالغی را که به طور کلی برای خدمات یا به طور خاص برای طرفین تایید شده است را به درخواست های هزینه کرد وجوه انتخاب شده توسط خود توزیع می کند.

شکل 6

در صورتی که مبلغ تایید شده برای درخواست کمتر از میزان برنامه ریزی شده باشد، به صورت خودکار برای مابقی مبلغ درخواستی برای صرف وجوه ایجاد می شود که می تواند در روز دیگر توسط رئیس واحد برای تایید خدمات مالی ارائه شود.

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

ثبت عملیات در مورد هزینه واقعی وجوه.

پس از گذراندن درخواست های هزینه وجوه از فرآیند هماهنگی با مدیر مالی، واحد مالی واحد حسابداری بر اساس درخواست های تایید شده، سند "دستور پرداخت خروجی" را وارد می کند. در این صورت، در سند "دستور پرداخت خروجی" تمام فیلدهای لازم به صورت خودکار پر می شود، حسابدار هدف پرداخت را نشان می دهد (برای فرم چاپی دستور پرداخت) و سند "دستور پرداخت خروجی" را بدون نیاز به ارسال می کند. علامت "پرداخت شده".

سفارش های پرداخت ایجاد شده و ارسال شده از 1C به سیستم مشتری-بانک وارد می شود.

روز بعد، پس از دریافت عصاره ای از بانک در مورد تراکنش های انجام شده، حسابدار در هر دستور پرداخت علامت "پرداخت" را نشان می دهد و همچنین عملیات سیستم را برای خرج وجوهی که بانک از حساب جاری کسر کرده است وارد می کند. بدون پذیرش - اسناد "دستور پرداخت: حذف وجوه" و "درخواست پرداخت دریافت شده" را تنظیم می کند. در صورتی که وجوه بدون پذیرش به نفع طرفین بدهکار می شود، خدمات مربوطه باید سند تسویه حساب طرف مقابل را که برای آن پرداخت شده است انتخاب کنند و در صورتی که قبلاً صادر شده است، درخواست هزینه را ببندند.

می‌توانید تراکنش‌های انجام‌شده را برای هزینه وجوه در روز با صورت‌حساب با استفاده از پردازش استاندارد «صورت‌حساب بانک» بررسی کنید. در پردازش استاندارد "صورت حساب بانکی"، متخصص می تواند موجودی در ابتدا، درآمد، هزینه، موجودی را در پایان روز برای هر حساب بانکی سازمان در چارچوب اسناد کنترل کند. اگر از پرینت مشخص شود که سند به طور جزئی پرداخت شده است، کاربر می تواند پرداخت جزئی را مستقیماً از پردازش صادر کند.

تنها پس از ارسال اسناد مربوط به هزینه وجوه با علامت "پرداخت"، سیستم وجوه را از حساب ها حذف می کند و وضعیت تسویه حساب با طرف مقابل را تغییر می دهد.

گزینه های پیکربندی

این راه حل برای محصولات نرم افزاری "1C: Production Enterprise Management 8" و "1C: Trade Management 8" در نظر گرفته شده است.

هزینه کار

بر اساس ویژگی های پیکربندی مشتری به صورت جداگانه تعیین می شود.