Оперативно планиране на паричните потоци или как да изградим система за контрол на паричните потоци. Подсистема "електронни заявления" за разходване на средства Приложение за разходване на средства 1в уп

1. Въведение

Касовото планиране е една от основните задачи на управленското счетоводство, за разлика от финансовото счетоводство.

Разбира се, има и други съществени разлики между управлението и счетоводството (различни изисквания за анализ, за ​​оценка и преоценка на активи/пасиви, необходимост от създаване на резерви и т.н.), но необходимостта от решаване на проблемите на планирането е най-трудната от тях.
Сложността на планирането се състои не само в изготвянето на плана (изчисляването му, формирането му според различни сценарии), но също така е необходимо:

• Извършване на разсрочване;
• Актуализиране на планове, прехвърляне на корекции за следващи периоди;
• Изпълнение на план – фактологичен анализ.

Трябва да се признае, че в повечето предприятия (използващи 1C за автоматизация) планирането не се извършва в програмата.
„Трябва да създадем счетоводство...“ - така твърдят много хора.

Счетоводството трябва да се подобри, да, но не за сметка на планирането.
Разбира се, те все още правят планиране (но не в 1C, а в XLS). И първата, основна задача (която се опитват да решат) е планирането на паричните средства.

• (1) Стратегически (бюджетиране);
• (2) Оперативен.

И ако бюджетирането (разбира се, с подход отгоре надолу към планирането) може да се направи с помощта на XLS, тогава оперативното планиране не може да бъде направено.
Изводът е, че най-често минимум потребители (1-2 души) работят с бюджетни таблици. За повечето предприятия броят на бюджетните позиции и други анализи не е толкова много. Тоест всичко може да се обработва ръчно в XLS.

Но що се отнася до оперативното планиране на д/с, тук ситуацията е различна. Тоест често има голям брой фактури за плащане, много регулярни плащания, очаквани плащания за поръчки на клиенти и т.н.

И освен това всичко това може да бъде „свързано“ с голям брой първични документи, с които работят различни потребители на програмата, документи се коригират, ситуацията се променя и т.н.

Друга важна разлика между оперативното планиране и бюджетирането е, че то често идва отдолу нагоре. Тоест от „Искания за разходи за д/с“, които винаги се попълват от служители на отдела.

И тези заявления, съответно, трябва да бъдат обработени навреме, приети/отхвърлени, „планирани“ и платени.

Обща сума:оперативно планиране за д/с е първата задача за планиране, който трябва да бъде автоматизиран в 1C за всяко предприятие.

И в резултат на планирането финансовият отдел / хазната трябва да „види“ в системата:

• Кога, на кого, от коя банкова сметка/в брой, за каква сума трябва да се плати;
• Какво ще бъде паричното салдо на „такава и такава“ дата, като се вземат предвид текущите салда, планираните разходи и паричните постъпления. Трябва да се избягва т.нар. "парични разлики"

  Тоест има нужда от работа с платежния календар.

• Какъв дълг с контрагентите ще бъде на определени дати, като се вземат предвид планираните плащания, постъпленията и текущия баланс на взаимните разплащания.

  Тоест има нужда да се работи с изчислителния календар.

Целта на тази статия – говори за възможностите за автоматизиране на оперативното планиране за д/к. В същото време ще бъде извършен сравнителен анализ на 3 различни конфигурации на циркулация (две са стандартни от 1C, една е специализирана от компанията wiseadvice).

Всяка от конфигурациите може да се използва за решаване на проблеми с оперативното планиране, но трябва да се направи балансиран избор въз основа на обхвата и мащаба на вашия проект.

2. Характеристики на софтстартера 1.3

В момента 1C все още не е пуснал дългоочакваното ново издание на UPP (ревизия 2). И поради тази причина ще се съсредоточим върху това, което е налично - съответните подсистеми на SCP 1.3:

Трябва да се отбележи, че подсистемата „Искания за разход на пари“ беше актуализирана в конфигурацията сравнително наскоро (2011 г.). И в резултат на това в режим на управляван интерфейс в панела на разделите се появи елементът „Заявки за разход на d/s/“.

Ако се опитате в стандартна конфигурация, във файлов режим, да отворите формата на документа „Искане за D/s Expenses“ (известен още като ZRDS), веднага се появява грешка за променливата „Global Values“ от общия модул „Работа с Общи променливи”.

Такива грешки обаче могат да бъдат коригирани, както се казва: „утайката остава“. Тоест има достатъчно „неравности“ в подсистемата UPP ZRDS.
Възможността за изготвяне на ZRDS документ чрез WEB браузър е полезна, но на практика ще трябва да помислите внимателно за опростяването и ергономичността на стандартната форма на документа. Това ще бъде особено важно за мобилните устройства.

Но що се отнася до платежния календар, в режим на тънък клиент, дистанционно през WEB браузър и т.н. няма да можете да го използвате. Причината е, че подсистемата за управление на парични средства не е актуализирана от дълго време и по-специално отчетът за платежния календар не е изграден върху система за съставяне на данни. Следователно този отчет не може да се използва в тънки клиенти; няма възможност за създаване на персонализирани настройки за него.

При работа със ЗРДС важно място заема регламентът за съгласуване и одобрение на заявленията. Зависи от организационна структуракорпоративни и други бизнес характеристики, вътрешната процедура за одобрение на заявления (правила за одобрение) може да бъде доста сложна (многоетапна, променлива и т.н.). Така че това не е лесна задача за автоматизацията.

В UPP е внедрена подсистемата за координация и одобрение. Предоставя доста гъвкави настройки.

• Одобрението е потвърждение за необходимостта от заплащане на приложението. Обикновено одобрението трябва да премине през ръководителите на отдели, мениджърите и други отговорни лица на компанията.
• Одобрението е окончателното потвърждение (от касиера), че заявлението ще бъде платено. В този случай трябва да се определи датата на плащане и банковата сметка/каса, от която ще се извърши плащането. Така плащането попада в оперативния план (разплащателния календар).

Трябва да се отбележи, че редица аспекти на стандартната функционалност на софтстартера не осигуряват необходимото за реалното внедряване на подсистемата.
Ще пиша за тези „моменти“ по-късно, но засега нека да разгледаме каква функционалност предоставя типичната конфигурация.

1. Можете да разрешите използването на механизма за одобрение на приложения отделно за всяка организация.

• Възможно е да се конфигурира последователността на приложението чрез маршрути и йерархията на маршрутите.

1. Трябва да се отбележи, че йерархията в директорията на отдела не се взема предвид в механизмите за маршрутизиране на приложения.
2. Също така е необходимо да се отмени, че координацията и одобрението са технически изградени без използването на механизъм за бизнес процеси.

• Във всяка точка можете да посочите един/няколко потребители, за които ще бъде достъпно одобрение на приложението. Тоест заявлението може да бъде одобрено от всеки от тях (който успее първи).

• За всеки отдел можете да зададете съответна точка на маршрут за одобрение. Същността на това е следната: при попълване на заявление (ZRDS) трябва да се посочи Централният федерален окръг (подразделение). И в зависимост от посоченото подразделение, UPP „намира“ съответната точка за одобрение и „изпраща“ заявлението за одобрение до тази точка.

Възможно е също така да не посочите отдел, когато настройвате маршрута за одобрение. В този случай такава координационна точка ще бъде „приложена“ към всички CFD, за които съответната точка на маршрута не е конкретно посочена.

1. Самото одобрение се извършва чрез специална обработка „Одобрение на приложение“

1. Анализът на планираната наличност на средства, графикът на плащанията и проследяването на паричните разлики се извършва в отчета „Платежен календар“.

В допълнение към планираното потребление на d/s (ZRDS), можете да вземете предвид и планираното получаване на d/s. За тези цели се предвижда съставянето на специален документ „Планирано получаване на доходи“.

Трябва да се отбележи, че въпреки че документът „Планирано получаване на d/c“ има състояния (изготвени, съгласувани и т.н.), няма възможност за координиране на този документ (както и на ZRDS). Тоест промяната на статусите на документи е възможна само в „ ръчно управление».

И в UPP е възможно да се вземе предвид планираното получаване на пари от купувачите, без да се изготвят документи „Планирано получаване на пари“.

Тоест, ако за купувач се издават „Клиентски поръчки“, тогава в отделен отчет „Платежен календар, като се вземат предвид поръчките“ може да се види този планиран разписка.

1. В допълнение към отчета за календара на плащанията има отчет за анализ на паричните наличности.

В същото време е възможно да се резервират d/s (въз основа на заявления за разходи) или да се поставят заявления срещу планирани приходи.

Има и функционалност за затваряне на ЗРДС и планирани приходи от д/к. За тези цели в режим „редовен клиент” се предоставят документи „Приключване на заявки за разходи/постъпления”.

Тази функционалност обаче също не се поддържа в режим на тънък/уеб клиент.
Тук трябва да разберете, че техниката на „твърда резервация“ е силно обвързана с хронологията на въвеждане на документа и това затруднява корекциите и разсрочването.

Следователно функционалността е оставена в UPP по-скоро като „наследство от миналото“ и платежният календар трябва да се използва за анализ на наличността на d/s.

И така, разгледахме функционалността на софтстартера и сега ще изброя тези аспекти на стандартната конфигурация, които на практика, по проекти, трябва да бъдат модифицирани:

1. Съгласно документа „Заявление за разход на д/с“:
   1. В документа можете да посочите „Разделение“ (между другото, в конфигурацията е обозначено като Централен федерален окръг - център на финансова отговорност). Но е напълно възможно заявлението да бъде подадено от едно подразделение (CFD) и в този случай разходите ще трябва да бъдат допълнително приписани/разпределени към друго подразделение(а) (CFD - центрове за финансово управление).

      Възможност за задаване на цифрови функции и др. - отсъстващ.

      Няма възможност за промяна на маршрута или пренасочване на приложението към други маршрути.

1. Няма възможност за планиране на прехвърляне на парични средства между разплащателни сметки, от сметка към каса и др.
1. Процес на споразумение:
   1. Възможно е съгласуване на ЗРДС, но няма възможност за съгласуване на плановото получаване на д/с.
   2. На практика става необходимо да се извършват одобрения за други служители. В същото време системата също трябва да записва информация за това „кой е извършил одобрението и за кого“.

      Възможността за инсталиране на няколко възможни изпълнители в една координационна точка често не е подходяща, така че този изпълнител може да бъде посочен на други етапи на координация. В резултат на това всичко това ще доведе до факта, че служителят едновременно ще има както основни, така и непреки задачи за одобрение в списъка с искания за одобрение. Разбира се, това обърква потребителя и не е удобно.

      В обобщение, възможността за съгласуване за друг изпълнител, възможността да се посочи кой за кого има право да координира отсъства.

   3. В процеса на одобрение на заявления, когато дадено заявление се предава за одобрение на следващия по маршрута, се търси функционалността за автоматично информиране (по имейл) на следващия изпълнител, както и на автора на заявлението .
   4. Ако авторът на приложението вече е отговорен за координацията/одобрението (на всеки етап от маршрута!), тогава е съвсем логично програмата автоматично да „съкрати“ маршрута, пренасочвайки приложението към най-високото налично ниво. Това обаче не е предвидено в УПП.
   • Всички горепосочени изисквания, въпреки че не са включени в стандартната конфигурация, все пак са .

1. Справки, права за достъп.
   1. Изисква се възможност за ограничаване на достъпа до приложения само от налични автори/изпълнители (координатори); по отдели, достъпни за потребителя.
   2. Няма отчетност за мониторинг (по дни и интервали) на реално и планирано задължение. Това важи както за купувачите, така и за доставчиците.
   3. Отчитането и някои от функционалностите не са подходящи за работа в режим на тънък/уеб клиент.
2. Счетоводно отчитане на редовни споразумения и договори.
   1. Често има ситуации, когато е необходимо редовно да плащате на доставчиците. Например наеми и др.

      UPP не го отразява автоматично в платежния календар и т.н. тези предстоящи разходи. Тоест, необходимо е ръчно да се проследяват такива плащания и да се попълват заявки за плащане, което е неудобно и отнема много време.

   2. Споразуменията с купувачи и доставчици могат да определят условия за процент на авансово плащане, условия на плащане и др.

      UPP не записва автоматично цялата тази информация и (в резултат на това) автоматично я отразява в платежния календар.

3. Характеристики на UT 11.1

С пускането на новата конфигурация „Trade Management Rev.11“ се появиха много нови, полезни функции за задачите на оперативното планиране и финансовия контрол.
Може би най-важното нещо в тази част в UT11 (в сравнение с UPP 1.3) е механизмът за отчитане на графика за плащане. Този механизъм „затваря” онова, което липсваше – автоматизация на планирането/отчитането по обичайните споразумения и договори.

По този начин в UT11 изобщо не е необходимо да съставяте документи (ако няма нужда, разбира се) за планиране на разходи и приходи, като в същото време календарът за плащане ще се формира нормално.

Можете да отмените, че „стандартните настройки“ на отчета „Платежен календар“ наистина не отговарят на очакванията (като такъв, календарът не се показва), но в потребителския режим можете да добавите групиране по „дата на плащане“ и отчета ще се генерира в обичайната форма.

Функционалността на отчета е значително разширена (в сравнение с SCP 1.3) поради използването на система за съставяне на данни. Сега отчетът може да бъде генериран в тънък/уеб клиент, записан в базата данни и присвоен на различни потребители настройките, от които се нуждаят.

В допълнение към планирането на потреблението и получаването на стоки за бита, UT11 вече има функционалност за планиране на движението на стоките за бита. За тези цели можете да съставите документи „Заповед за преместване на домакинствата“.

В сравнение с UPP 1.3 за документа „Заявление за разход на пари“ броят на разглежданите видове бизнес транзакции се е увеличил:

Вече е възможно да се одобряват както документи „Заявление за разходване на средства“, така и други поръчки:

За анализ на дълга по интервали/крайни срокове е предоставен отчетът „Вземания“. Ако е необходимо, можете да създадете и календар на задълженията. За да направите това, в потребителски режим трябва да добавите групиране по дати на плащане.

За съжаление, UT11 (както и преди) не предоставя възможност за анализ на календара на дълга по доставчици. Въпреки това, UT11 трябва да бъде финализиран за тази задача.

Да обобщим: нови методически решения "1С", заедно с възможностите на платформата 8.2, осигуряват добра основа за автоматизиране на задачите по оперативно планиране и управление на д/к.

Но в същото време трябва да разберете, че конфигурацията на UT11 не е пълна, готово решениеза автоматизация на каса и финансово планиране.

• Първо, UT11 прилага в много опростена форма механизъм за координиране/одобряване на искания за разходи и други документи за планиране на d/c. Тоест няма механизми за маршрутизиране, процесът на одобрение на приложения се свежда до просто задаване на статуси.
• Второ, UT11 няма подсистема за бюджетиране и (в резултат на това) няма функционалност за мониторинг на приложения за планирани бюджети.

4. Характеристики на WA: Финансист

В исторически план конфигурацията WA:Financier е разработена въз основа на продукта за управление на финансите.

И в същото време новото решение „Financier“ от WiseAdvice също включва:

• Подсистема за бюджетно планиране;
• Подсистема за управление на договори;
• Подсистема за формиране и отчитане на фактически плащания;
• Гъвкав, адаптивен механизъм за генериране/попълване на документи на базата на шаблони;
• Гъвкава подсистема за интеграция клиент-банка с възможност за персонализиране.

Нека разгледаме основната функционалност на "WA: Financier" по отношение на хазната - от отчитане на условията на договорите до създаване на календар за плащане.

1. По време на процеса на одобрение на заявлението можете не само да одобрите/отхвърлите документа (както се прави в UPP), но са налични и други функции: например да изпратите документ за преразглеждане или да поискате допълнителна информация. информация.

   Целият този процес е автоматизиран, съответно се предоставят отчети за състоянието на обработката на одобрението на документи.

5. Резултати

Изводи:

1. Да автоматизира работата на финансови отдели, каси, организации със сложна организационна структура. структура най-подходящото решение е "WA: Финансист".

   Това решение се развива и развива дълго време, акумулирайки съответно спецификите и изискванията на различни финансови институции. отдели и каси. Общите разходи за труд за разработване на решението възлизат на повече от 5000 човекочаса.

   Предимството на решението WA: Financier е неговата разширена функционалност и голям брой механизми за програмни настройки. По този начин прилагането на това решение е възможно в кратко време(т.нар. „извън кутията имплементация“), без доп. разработка, програмиране и др.

   Тъй като решението съдържа механизми за двупосочен обмен с всички основни стандартни конфигурации, интегрирането в съществуващата структура (обмен на данни с бази данни UT, UPP, Kompleksnaya, Bukh) няма да бъде трудно.

2. За автоматизиране на финансовия отдел / касата в рамките на цялостен проект за автоматизациянай-доброто решение е на база UPP.

   В същото време трябва да разберете, че функционалността на софтстартера ще изисква подобрения.

   Специфика, финансови изисквания. отделите и касите не са вградени в UPP толкова дълбоко, колкото се прави в отделни, специализирани решения.

   Следователно внедряването на SCP за тези задачи трябва да се извършва само като част от проект за автоматизация.

3. За големи организации, за автоматизация на касовия отдел UT11не пасва.

   В това решение, първо, липсват механизми за съгласуване/одобряване на устройствените документи.

   Второ, липсва подсистема за бюджетиране и контрол върху изпълнението на бюджетите по време на оперативното планиране.

   Въпреки това, UT11 перфектен заавтоматизация (включително оперативно планиране d/c) малки финансови фирмени отдели.

Документът „Искане за разход на средства” е предназначен за планиране и координиране на плащанията.
Документът „Искане за разходване на DS” може да бъде създаден, като отидете в раздел „Каса” - „Планиране и контрол на средствата” - „Искания за разходване на DS” - Създаване.
Документът „Искане за разход на DS” има няколко типа операции, които се избират при създаването. Всеки тип приложение е предназначено да отразява различни бизнес транзакции, всяка от които ще бъде описана в тази инструкция.
Създадените документи „Заявка за разходване на ДС” се събират и съгласуват чрез документ „Регистър на плащанията”. След одобрение, на базата на заявленията, автоматично се създават документи „Отписване на безкасови DS“, които се качват в клиентската банка за плащане от банката.
Следват примери за изпълнение на документи „Заявление за разход на DS“ за всеки вид операция.

Плащане към доставчика
За обработка на платежни транзакции към доставчик е предназначен типът транзакция на документа „Искане за разход на DS“ - „Плащане към доставчика“.
В новия документ „Заявка за разходване на ДС” в червено са отбелязани полетата, които трябва да бъдат попълнени за обработка на документа. Документът се създава в статус „Неодобрен“, статусът се променя автоматично по време на одобрението на регистъра на плащанията. Приоритетът на приложението при създаване автоматично се задава на „Среден“.

Фигура 1. Форма на документ „Заявка за разход на DS“, тип операция „Плащане към доставчик“ (не се попълва)
Реквизитите на документа „Заявление за разходване на DS“ трябва да бъдат попълнени, както следва:
Основен раздел
Номер– генерира се автоматично по време на изпълнение, не може да се задава ръчно.
дата– при създаване се задава текущата дата.
Организация– трябва да изберете от предложения списък с организации чрез бутона , или чрез въвеждане на името в полето ще бъде предложена желаната стойност за избор.
Подразделение– от директория „Структура на предприятието” трябва да изберете подразделението, за което да се извърши плащането.
Заявител– по подразбиране се посочва текущият системен потребител, създаващ приложението.
Планиране– настройката по подразбиране е „Във валута на плащане“ и не може да се променя.
Сума– посочва размера на необходимото плащане.
Валута– посочете валутата на необходимото плащане.
Операция– отразява се вида на операцията на избрания при създаване документ „Заявка за разход на ДС“.
дата за плащане– посочва датата, на която трябва да бъде планирано плащането към доставчика.
Форма на плащане– настройката по подразбиране е „Във всякаква форма“ и не може да се променя.
Получател– посочва доставчика от справочник „Контрагенти”, към когото трябва да се извърши плащане.
Акаунт на получателя– при избор на „Получател” автоматично се задава сметката на получателя, при необходимост, ако във „Фактура за плащане” предоставена от доставчика е посочена друга сметка, трябва да изберете необходимата от директория „Банкови сметки”.
Над лимита– ако системата поддържа система за ограничаване на паричните разходи в контекста на клонове и съответно елементи на паричния поток, ако сумата на извършеното плащане не е била включена преди това в лимита, при осчетоводяване на документа потребителят ще получи съобщение за грешка и заявлението няма да бъде обработено.

Фигура 2. Пример за грешка при пускане на поръчка, за която не е планиран лимит.
За да направите поръчка над лимита, трябва да зададете флага „Над лимита“.
Трансфер към бюджета– този флаг се поставя, ако плащането е превод към бюджета. Задаването на флага ви позволява да въведете стойностите на KBK, OKTMO и др., необходими за плащания към бюджета.

Фигура 3. Пример за настройка на флага „Прехвърляне към бюджета“.
UIP– уникален идентификатор на плащането, посочва се само ако това е предвидено в договора с получателя.
Цел на плащането- програмата предоставя няколко опции за автоматично попълване на целта на плащане чрез бутона "Вмъкване".

Фигура 4. Опции за автоматично попълване на полето „Цел на плащането“.
Списък с документи, вкл. ДДС- ще покаже информация за обекти за сетълмент от раздела „декриптиране на плащане“.

С ДДС (18%) (за цялата сума), вкл. ДДС (10%) (за цялата сума), Без данък (ДДС)- Към въведения текст ще бъде добавена информация за ДДС.

Текст от банковата сметка на получателя- вмъква текста, посочен в полето "Текст на целта на плащането" от картата на сметката на контрагента.

Фигура 5. Пример за попълване на раздела „Основни“.

Раздел Детайли за плащане
Разделът „Декодиране на плащане“ предоставя подробна информация за плащането и взаимните разплащания с получателя.
Плащането може да се въведе като списък, т.е. разпределете върху няколко изчислителни обекта или без разделяне, възможно е да изберете само един изчислителен обект.
Заплащане от държавни средства за отбрана– флагът се поставя само ако плащането се извършва в рамките на държавна поръчка за отбрана, в други случаи флагът не се поставя.
Обект на изчисление– като обект на сетълмент можете да посочите „Споразумение с контрагента“ (за този тип операция на документа за кандидатстване, когато е избрано, са налични договори с тип взаимоотношения „С доставчик/изпълнител“) или договорения документ „Поръчка към доставчика”.
Доставчик
Размер на взаимните разплащания– задава се автоматично при осчетоводяване на документ.
Валута– задава се автоматично при избор на обект на изчисление.
DDS статия– посочете позицията на паричния поток, съответстваща на вида плащане.
Коментар– ако е необходимо, посочете коментар към разшифроването на плащането.

Фигура 6. Пример за попълване на раздела „Декодиране на плащане“.
Раздел за разпределение на акаунта
В раздела „Разпределение по сметки“ е посочена банковата сметка на организацията, от която трябва да се дебитират средствата. Сумата и датата на плащане се задават автоматично според данните, посочени в раздела „Основни“.

Фигура 7. Пример за попълване на раздела „Разпределение по сметки“.

Фигура 8. Пример за автоматично създаден документ „Отписване на безкасови DS“ за приложение с тип транзакция „Плащане към доставчик“.

Връщане на плащането на клиента
За обработка на транзакции за възстановяване на средства към клиенти е предназначен типът транзакция в документа „Заявление за изразходване на DS“ - „Връщане на плащане на клиента“.
Съставът на реквизитите на документа „Заявка за разход на DS” при този вид операция е идентичен със състава на реквизитите при плащане на доставчика, разликата е само във вида на контрагента и обекта на сетълмент.

Фигура 9. Форма на документа „Заявление за разходване на DS“, тип операция „Връщане на плащане на клиента“
Получател– посочва клиента от директория „Контрагенти”, който трябва да извърши плащане.
Обект на изчисление– като обект на сетълмент можете да посочите „Споразумение с насрещната страна“ (за този тип операция на документа за кандидатстване, при избора, са налични споразумения с типа на взаимоотношенията „С купувача/клиента“) или договорения документ „ Клиентска поръчка".
Купувач– полето се попълва автоматично при избор на обект за изчисление. Инсталиран е елементът от директорията „Партньори“, посочен в съответното поле на обекта за изчисление.

Фигура 10. Пример за попълване на раздела „Декодиране на плащане“.
След преминаване на всички етапи на одобрение, на документа „Заявление за разходване на DS“ ще бъде присвоен статус „За плащане“ и документът „Отписване на безналични DS“ ще бъде създаден автоматично.

Фигура 11. Пример за автоматично създаден документ „Отписване на безналични DS“ въз основа на приложение с тип операция „Връщане на плащане на клиента“.

Издаване на отговорните
За регистриране на транзакции за издаване на средства по банкова сметка на отговорно лице е предназначен типът транзакция на документа „Заявление за изразходване на DS“ - „Издаване на отговорно лице“.

Фигура 12. Форма на документа „Заявление за разходване на DS“, тип операция „Издаване на отговорните“
Отговорно лице– служителят се посочва от указателя „ Физически лица”, на когото е необходимо да се преведат парите.
Докладвай– от предложения списък с периоди е необходимо да се посочи периодът, до който счетоводителят трябва да отчете получената сума.

Фигура 13. Пример за попълване на раздела „Декодиране на плащане“.
След преминаване на всички етапи на одобрение, на документа „Заявление за разходване на DS“ ще бъде присвоен статус „За плащане“ и документът „Отписване на безналични DS“ ще бъде създаден автоматично.

Фигура 14. Пример за автоматично създаден документ „Отписване на безналични DS“ въз основа на приложение с тип операция „Издаване на отговорните“.

Съществено условие за ефективното съществуване на едно предприятие в съвременна конкурентна среда е създаването на ефективен механизъм за управление парични потоциосигуряване на генериране на бърза и надеждна информация, регулиране на взаимните разплащания, повишаване на платежната дисциплина и в крайна сметка ускоряване на паричния оборот.

Конфигурацията съдържа инструменти за автоматизирано управление на парични средства в предприятието, което изпълнява две основни функции:

• оперативно отчитане на действителното движение на средствата на предприятието по сетълмент сметки и каси;
• оперативно планиране на паричните постъпления и разходи на предприятието.

Общото планиране на разходите и получаването на средства на предприятието се извършва в рамките на бюджетирането. Финансовият план, който се изготвя - бюджетът - действа като набор от насоки и ограничения за подсистемата за управление на парични средства.

Но в рамките на функционалността за управление на парични средства се поддържа оперативен финансов план - платежен календар. Логично е да създадете платежен календар няколко дни предварително.

Платежният календар е колекция от заявки за разходване на средства и планирани парични постъпления. Разплащателният календар се съставя с подробности до местата, където се съхраняват парични средства - банкови сметки и каси на предприятието. При съставяне на платежен календар автоматично се проверява неговата осъществимост - достатъчността на паричните резерви в местата, където се съхраняват.

Разделянето на функцията за финансово планиране на две конфигурационни подсистеми - подсистемата за бюджетиране и подсистемата за управление на парични средства - съответства на разделението на функциите за финансово управление между различни отдели и служители на предприятието. Ако бюджетът се изготвя от финансови услуги, тогава заявките за изразходване на средства се генерират от служители и отдели, които пряко взаимодействат с контрагентите на компанията.

В конфигурацията се генерират парични документи (платежни нареждания, касови бележки и дебитни нареждания и др.), осигурява се взаимодействие със специализирани банкови програми като „Банков клиент“, контролират се финансовите потоци и се контролира наличността на средства в складовите помещения. наблюдавани. Осигурена е възможност за плащане в брой в чуждестранна валута.

Документът „Искане за разходване на средства“ е предназначен за записване на решението за извършване на плащане в брой или безкасово (група плащания) или преместване на средства. Реквизитите на документа и процедурата за тяхното използване са по принцип подобни на документите „Платежно нареждане (изходящо)“ и „Разходен касов ордер“.

Параметрите за резервация и разположение могат да се попълват автоматично. За целта документът предвижда флагове и „Автоматично разположение“.

Ако тези флагове са зададени, тогава колоната „Разположение“ може да се попълни автоматично, когато щракнете върху бутона „Попълване и публикуване“.

Автоматичната и ръчната схема на поставяне могат да се комбинират. Когато флаговете са поставени "Автоматична резервация"И „Автоматично разположение“Можете ръчно да посочите опцията за поставяне за част от сумата на заявката. След това, когато натиснете бутона „Попълване и публикуване“Ще има автоматично пласиране само за останалата сума.

Когато типът операция е зададен на " Плащане към доставчика"или " Възстановяване на сумата на купувача"се правят промени в оперативните разплащания с контрагенти.

Въз основа на документа „Заявка за разходване на средства” могат да се въвеждат банкови и касови платежни документи. Такива документи осигуряват необходимите „ Приложение", който се попълва, докато пишете въз основа на него, или може да се попълни ръчно. При осчетоводяване на платежни документи с посочено заявление за разходване на средства се проверява съответствието на сумата на документа с текущия баланс на неуредените плащания за това заявление.

При настройване на допълнителни права е възможно да се забрани на потребителя да обработва платежни документи, без да посочва заявление за изразходване на средства.

Документът „Искане за разход на средства“ може да служи и като връзка между подсистемата за управление на парични средства и подсистемата за бюджетиране. За тази цел приложението предоставя блок от подробности, подобни на документа „Бюджетна операция“ (планов сценарий, оборотна позиция, централен финансов район, проект и др.). По посочените реквизити при подаване на заявление се следи съответствието на общия размер на одобрените за разход средства с предварително установените гранични стойности.

Характеристики на работа с приложения при използване на механизма за одобрение на приложения

Механизмът за одобрение на заявлението се използва по избор: за списък с организации.

Когато използвате механизма за съпоставяне на приложения, възникват следните функции:

Ако в приложението не е посочена организация, това приложение не участва в одобрението




Пътят за одобрение на заявлението се определя в съответствие с настройките в зависимост от отдела, посочен в заявлението.




Ако заявлението не е преминало пътя на одобрение (статусът на заявлението не е „Одобрено“), на негова база не може да бъде издаден платежен документ




Ако приложението започне да преминава през пътя на одобрение, приложението може да бъде променено



• 
  

  Потребителят, чиято кандидатура се одобрява в момента

  
  

  Потребители, които одобряват приложение на по-високи етапи на одобрение
  Други потребители не могат да променят приложението.




Ако поръчката е в състояние "Одобрена", тя не може да бъде променена




Ако приложението влезе в състояние „Отхвърлено“, приложението се анулира




Текущият статус на приложенията е в списъка с приложения



• 
  

  състоянието се показва в отделна колона

  
  

  Използва се групиране по статус на поръчката

  
  

  приложенията се маркират с фонов цвят

  
  
  
  
  • 
    

    отхвърлен - розов

Във втората част на статията ще разгледаме принципа на създаване на „Искания за изразходване на средства“, предаването му по пътя на одобрение и издаване на средства според създаденото приложение.
Да разгледаме един пример:

1. Счетоводителят по снабдяването формира заявка за разход на средства, за да извърши авансово плащане на доставчика на ИП Добронравов за доставка на материали;
2. Финансовият директор трябва да прегледа и одобри заявлението;
3. Въз основа на одобреното заявление счетоводителят по снабдяването генерира приходен касов ордер (без знак „Платено“, но с знак „Отразяване в оперативното счетоводство“);
4. Старшият касиер, след като провери касовата бележка, издава средства (и маркира документа като „Платено“);
5. Счетоводителят на касовите операции проверява касовия ордер (маркира полето за отразяване в счетоводните и данъчните счетоводни записи, така че да се генерират счетоводни и данъчни счетоводни записи).

За да улесним отразяването на транзакциите, нека превключим интерфейса на „Управление на парични средства“.
Преди да започнете работа със заявления за разходване на средства, трябва да въведете всички обща информация. Първото нещо, което трябва да попълните, е информационният регистър „Настройки за одобрение на заявления за разходване на средства“. В „Настройка на одобрение на приложения“ са посочени организациите, за които се използва този механизъм, и началната дата на използване на механизма за одобрение. Тази настройка е необходима, за да може програмата да определи, че организацията StroyTorg LLC ще използва механизъм за одобряване на заявки за изразходване на средства от 01.01.2013 г.

Също така е необходимо да се конфигурират координационни маршрути (фиг. 2). Тази настройка е посочена в информационния регистър „Настройки за начало на маршрути за одобрение“: определя се съответствието на маршрутите за одобрение към отделите. Маршрутът за одобрение (директорията „Маршрути за одобрение“) показва етапа и списъка с одобряващи лица на този етап. В нашия пример създаденото приложение ще трябва първо да премине през един етап на одобрение от финансовия директор.

Също така трябва да настроите информационния регистър „Настройка на одобрение на заявления за изразходване на средства“ (фиг. 1) и да определите етапите (маршрута) на одобрение на заявления (фиг. 2)

Ориз. 1

Ориз. 2

Координационен маршрутПриложението се определя в съответствие с настройките и в зависимост от отдела, посочен в приложението.

Забележкаче едно разделение трябва да съответства само на един координационен маршрут. За всяко подразделение трябва да бъде посочен маршрут на одобрение, в противен случай процесът на одобрение за всички приложения, създадени за това подразделение, няма да влезе в сила.

1. Счетоводителят по закупуването създава документ „Заявка за разход на средства”.

В интерфейса „Управление на паричните средства“, който сме избрали, отидете на елемент от менюто „Планиране“ - „Заявки“ - „Искане за изразходване на средства“ (фиг. 3). Да създадем „Заявка за разходване на средства“ със статус „Подготвен“ (Фиг. 5)

Приложението има няколко вида операции, които повтарят типовете операции „Нареждане за изходящо плащане в брой“ и „Нареждане за изходящо плащане“ (фиг. 4)

В „Искане за изразходване на средства“ в раздела „Разплащания с контрагенти“ е посочена основна информация: контрагентът за плащане, на когото се изисква да бъдат издадени средства, както и споразумението, сумата, организацията, разделянето и статута.

В раздела „Описание“ можете да посочите Допълнителна информацияпод всякаква форма.

Разделът „Разпределение“ предоставя възможност за резервиране и поставяне на средства (фиг. 6). Това означава, че в нашия пример счетоводителят по закупуване може да резервира средства, за да плати авансово на доставчика, и да посочи от коя каса ще бъдат издадени средствата. Параметрите за резервация и разположение могат да се попълват автоматично. В документа има флагове за тази цел. "Автоматична резервация"И „Автоматично разположение“. Ако тези флагове са зададени, тогава колоната „Разположение“ може да се попълни автоматично, когато щракнете върху бутона „Попълване и публикуване“. Автоматичната и ръчната схема на поставяне могат да се комбинират.

Данните в раздела „Бюджетиране“ могат да се използват като връзка между подсистемата за бюджетиране и подсистемата за управление на парични средства. Информацията, показана в този раздел, служи за контрол на размера на средствата, планирани за изплащане в съответствие с планирания бюджет (фиг. 7).

Тъй като счетоводителят по снабдяването има ограничени права на достъп, той може да задава само статус „Изготвен” в документа „Искане за разход на средства”, а статуси като: „Одобрено”, „Отложено”, „Съгласувано”, „Отхвърлено” са зададени от потребителите, отговорни за одобрението на приложението.

2. Финансовият директор разглежда и одобрява заявлението за разход на средства в размер на 120 000 рубли.

Финансовият директор може да анализира списъка с приложения, изискващи разглеждане, като използва обработката „Статус на одобрение на приложението“ (фиг. 8).

Когато започнете да обработвате „Статус на одобрение на приложението“, той показва списък с всички приложения, групирани по определени статуси (състояния), като например: „Подготвени“, „Одобрени“, „Отложени“, „Съгласени“, „Отхвърлени“. За удобство можете да направите избор „Задаване на периода“ с помощта на бутона, например за ден, седмица, месец, десетилетие, тримесечие, полугодие, година и т.н., след което, от всички приложения ще останат само тези, които попадат в даден период.

За да промените статуса на заявленията за изразходване на средства, например от „Подготвени“ на „Одобрени“, трябва да използвате друга обработка („Статус на заявлението“).

При тази обработка можете да избирате от общ списъкприложения, например приложения със статус „Очаква одобрение“, „Отложено“, „Очаква одобрение на предишни етапи“, „Обработва се“ (фиг. 9).

Обработката показва списък с некоординирани приложения и можете да промените състоянието на приложението (фиг. 10). Можете да отидете на тази обработка чрез елемента от менюто „Планиране“ - „Заявки“ - „Координиране на приложения“.

Финансовият директор може да „одобри“ искането за изразходване на средства, да го „отложи“ или да го „отхвърли“. Когато изберете “Промяна на статус” - “Съгласен”, квадратчетата за отметка маркират тези приложения, които трябва да бъдат одобрени. Останалите заявления, които са били в опашката, могат да се видят в дневника на документите „Одобрение на заявления“.

Ако заявлението не е преминало пътя на одобрение (статусът на заявлението не е „Одобрено“), тогава не може да бъде издаден платежен документ на негова основа.

Ако приложението започне да преминава през пътя на одобрение, тогава приложението може да бъде променено:

Потребителят, чиято кандидатура се одобрява в момента;

Потребители, които одобряват приложението на по-високи етапи на одобрение.

Други потребители не могат да променят приложението.

Ако приложението е в състояние „Одобрено“, тогава то не е достъпно за промяна (става неактивно за редактиране), така че полетата в приложението стават сиви за счетоводителя покупки и не могат да бъдат променяни.

3. Въз основа на одобреното заявление счетоводителят по покупките изготвя касова бележка с вид транзакция „Плащане към доставчик“ без маркировка „Платено“ за издаване на аванс на доставчика на ИП Добронравов (фиг. 11)

Забележка, че в създадения от счетоводителя закупуване приходен касов ордер са поставени отметки само в квадратчетата „Отразяване в управленско счетоводство” и „Отразяване в оперативно счетоводство”. Отметката „Платено“ трябва да бъде отметната от старши касиер след проверка на правилното формиране на касовия ордер. В приходния касов ордер посочваме и въз основа на кое приложение го генерираме.

Ако в касовия ордер има квадратчета за отметка само за управленско счетоводство, тогава такъв документ не генерира осчетоводявания (счетоводни записи). Но той прави записи в регистрите за натрупване: „Парични средства за отписване“ и „Разплащания с контрагенти“ (фиг. 12). Тази информация влиза в отчета „Платежен календар” в секция „Неплатени изходящи документи” (фиг. 13).

4. Старшият касиер проверява касовия ордер, поставя отметка в квадратчето „Платено“ и издава пари в брой.

След плащане на приходния касов ордер, полетата в документа стават сиви и не могат да се редактират от счетоводителя покупки и другите участници в нашия пример. В зависимост от това какви права за достъп са конфигурирани за конкретен потребител, определени документи, полета в документи и т.н. могат да бъдат достъпни за редактиране.

Забележка:Ако има много касови апарати и трябва да поставите отметка в полето „Платено“ във всяка от тях, можете да използвате групова обработка на указатели и документи (меню „Услуга“). Можете да преминете към тази обработка, като отидете на пълния интерфейс, елемент от менюто „Услуга“ (фиг. 14).

За да промените подробностите, щракнете върху бутона „Настройки“ и изберете флага „Разрешаване на промяна на детайлите на обекта“. За по-лесен анализ, нека зададем флага „Показване на всички колони“ (фиг. 15).

Използвайки групова обработка, искаме да поставим флага „Платено“ в касовия ордер. За да направите това, в секцията „Избор“ на груповата обработка посочваме организацията StroyTorg LLC; Избираме само обработени документи за периода от 01.01.2013 г. до 21.01.2013 г. с опция „Платено” - „Не”.

Когато щракнете върху бутона „Избор“ в раздела „Обработка“, ще се появят документи, в които трябва да отбележите „Платено“ (фиг. 16). В реда „Действие“ изберете „Промяна на подробности [Link.Paid] - Инсталиране. И "Бягай".

След като промените стойността на детайлите, трябва да осчетоводите отново променените документи: в полето „Действие“ изберете „Промяна: [Публикуване на документи] – Задаване – „Изпълнение“ (вижте Фиг. 17).

5. Касовият счетоводител проверява касовия ордер (маркира полето за отразяване в счетоводните и данъчните счетоводни записи, така че да се генерират счетоводни и данъчни счетоводни записи).

Освен това, например, в края на работния ден, счетоводител на касови транзакции проверява всички изходящи касови нареждания, които са маркирани „Платени“ и поставя отметки в полетата BU и NU в документа, така че документът да генерира счетоводни и данъчни счетоводни записи. (фиг. 18)

Забележка:ако има много поръчки за касови бележки, в които трябва да поставите отметка в полетата BU и NU, тогава можете да използвате „Групова обработка на справочници и документи“ (фиг. 19).

В груповата обработка на справочници и документи избираме документите „Разходен касов ордер [TC: Декодиране на плащане]“, в табличната част на който трябва да поставите отметка в квадратчето „Отразяване в счетоводството“.

В полето „Избор“ посочваме за коя организация трябва да изберем документи, посочваме, че се интересуваме само от документи, обработени за интервала от 01.01.2013 г. до 21.01.2013 г. (както и касови бележки, в които квадратчето за отметка „Отразяване в счетоводството“ не е отметнато) счетоводство“). След като попълните всички параметри, щракнете върху бутона „Избор“: ще бъдат избрани документи, които отговарят на зададените условия. В долната част на прозореца за обработка изберете „Промяна на атрибути“ - „Отразяване в счетоводство" - "Инсталиране" и щракнете върху бутона "Изпълнение". След като документите бъдат обработени, те трябва да бъдат повторно осчетоводени (фиг. 16). След това трябва да повторите същото, но да поставите отметка в квадратчето „Отразяване в данъчното счетоводство“

При осчетоводяване на документа „Касов разходен ордер“ се генерират не само движения в счетоводни сметки, но и в регистри (фиг. 20, 21)