Pagproseso ng mga aplikasyon para sa paggastos ng mga pondo. Mga aplikasyon para sa paggastos ng mga pondo Koordinasyon ng mga aplikasyon para sa pagbabayad sa 1c

Ang pagpapanatili ng kalendaryo ng pagbabayad ay ibinibigay lamang sa ilang mga pagbabago ng 1C 8.3 at 8.2 na programa:

1C ERP enterprise management 2.0.

1C Manufacturing Enterprise Management.

Ang kalendaryo ng pagbabayad ay isang ulat na nagbibigay-daan sa iyong mabilis na subaybayan ang lahat ng mga daloy ng pera sa lahat ng kasalukuyang account ng organisasyon at ang cash register, at agad na makakita ng mga kamalian.

Ang ulat ay nagpapakita ng mga nakaplanong resibo, gastos at balanse ng pera. Posible rin na makakuha ng detalyadong data sa lahat ng mga dokumento, kabilang ang mga pangunahin.

Kumuha tayo ng isang halimbawa ng pagtatrabaho sa kalendaryo ng pagbabayad sa 1C Trade Management 11 program Una, kailangan mong gumawa ng ilang mga setting. Pumunta sa tab na "Pamamahala," seksyong "Mga organisasyon at pondo." Sa iba pang mga bersyon ng programa, ang item na ito ay matatagpuan sa seksyong "Treasury":

Dito kailangan mong lagyan ng tsek ang kahon na "Mga kahilingan para sa paggastos ng mga pondo".

Dito maaari ka ring magtakda ng mga parameter para sa pagkontrol ng mga limitasyon para sa buong organisasyon o direkta para sa bawat departamento. Matapos magawa ang mga setting, lalabas ang item na “Cash Planning” sa seksyong “Finance”. (Iba pang mga bersyon ng mga programa - seksyong "Treasury"):

Halimbawa, gumawa tayo ng ilang kahilingan para sa paggastos sa DS. Ang dokumentong ito ang magiging pangunahing dokumento para sa pagkontrol ng daloy ng salapi:

Sa dokumentong "Application para sa paggasta ng DS", ang mahalagang larangan ay "Operasyon". Tinutukoy ng tinukoy na uri ng operasyon ang artikulo ng DDS.

Batay sa napiling operasyon, independiyenteng pinipili ng program ang artikulong gagamitin at sinenyasan ang user sa anyo ng na-filter na listahan. Kung pinagana ang kontrol sa limitasyon sa mga setting, maaaring magpakita ang 1C ng isang abiso tungkol sa imposibilidad ng pag-post ng isang dokumento. Mayroong dalawang paraan upang itama ang sitwasyon: lagyan ng check ang kahon na “Lampas sa limitasyon” o dagdagan ang halaga ng limitasyon para sa kinakailangang item:

Upang madagdagan ang limitasyon, kailangan mong lumikha ng isang dokumento na "Mga Limitasyon sa Pagkonsumo ng DS".

Ang bawat aplikasyon ay tinutukoy ng katayuan nito:

Sumang-ayon.

Hindi pumayag.

Magbayad.

Tinanggihan.

Ang mga aplikasyon na hindi naaprubahan ay makikita sa journal na "Mga kahilingan para sa paggasta ng DS para sa pag-apruba."

Ang pinaka-maginhawang paraan ay ang baguhin ang status sa "Naaprubahan" mismo sa listahang ito. Para sa pag-unawa, maaari kang gumawa ng "Kalendaryo ng pagbabayad ayon sa mga organisasyon at uri ng DS" at suriin ito.

Nagpapakita kami ng isang ulat para sa susunod na buwan ng mga hindi pagkakapare-pareho sa halaga ng cash register, iyon ay, ang pera na hindi sapat upang ilipat ang nakaplanong pagbabayad, ay mai-highlight sa pula. Ang bersyon na ito ng programa ay nagbibigay ng kakayahang bumuo ng mga dokumento para sa mga nakaplanong resibo at paggalaw ng pera nang direkta mula sa kalendaryo ng pagbabayad (ang tampok na ito ay hindi magagamit sa mga naunang bersyon):

Upang alisin ang puwang sa cash desk, lumikha ng dokumentong "Inaasahang resibo ng DS" sa pamamagitan ng pagpindot sa "Resibo" na key. Dito kailangan mong ipahiwatig nang tama ang artikulo ng DDS at ang nakaplanong petsa ng pagtanggap. Isinasagawa namin ito, sarado ang puwang.

Bilang karagdagan sa mga dokumento sa itaas, posible na lumikha ng mga dokumento sa pagbabayad. Upang gawin ito, piliin ang kinakailangang aplikasyon o dokumento para sa pagtanggap ng mga pondo. Sa pamamagitan ng button na "Mga Setting," posibleng mag-edit ng mga karagdagang parameter ng ulat, na maaaring i-configure ng bawat user sa kanilang sariling paghuhusga. Halimbawa, pinapayagan ka ng advanced na mode na itakda ang pagpapakita ng mga artikulo ng DDS sa anyo ng isang hierarchy, na ginagawang posible na magpakita ng mga resulta hindi lamang nang paisa-isa para sa bawat artikulo, kundi pati na rin ng mga grupo.

1. Panimula

Ang pagpaplano ng pera ay isa sa mga pangunahing gawain ng accounting ng pamamahala, kumpara sa accounting sa pananalapi.

Siyempre, may iba pang makabuluhang pagkakaiba sa pagitan ng pamamahala at accounting (iba't ibang mga kinakailangan para sa analytics, para sa pagtatasa at muling pagsusuri ng mga asset/liabilities, ang pangangailangan na lumikha ng mga reserba, atbp.), ngunit ang pangangailangan upang malutas ang mga problema sa pagpaplano ay ang pinakamahirap sa sila.
Ang pagiging kumplikado ng pagpaplano ay nakasalalay hindi lamang sa paghahanda ng plano (pagkalkula nito, pagbuo nito ayon sa iba't ibang mga sitwasyon), ngunit kinakailangan din:

• Magsagawa ng muling pag-iskedyul;
• I-update ang mga plano, ilipat ang mga pagsasaayos sa mga susunod na panahon;
• Magsagawa ng plano - pagsusuri sa katotohanan.

Kailangang pagbutihin ang accounting, oo, ngunit hindi sa gastos ng pagpaplano.
Siyempre, nagpaplano pa rin sila (ngunit hindi sa 1C, ngunit sa XLS). At ang pinaka una, pangunahing gawain (na sinusubukan nilang lutasin) ay ang pagpaplano ng pera.

• (1) Strategic (pagbabadyet);
• (2) Operasyon.

Ngunit tungkol sa pagpaplano ng pagpapatakbo ng d/s, iba ang sitwasyon dito. Ibig sabihin, kadalasan ay may malaking bilang ng mga invoice na babayaran, maraming regular na pagbabayad, inaasahang pagbabayad para sa mga order ng customer, atbp.

At bukod pa, ang lahat ng ito ay maaaring "nakatali" sa isang malaking bilang ng mga pangunahing dokumento kung saan gumagana ang iba't ibang mga gumagamit ng programa, nababagay ang mga dokumento, nagbabago ang sitwasyon, atbp.

Ang isa pang mahalagang pagkakaiba sa pagitan ng pagpaplano ng pagpapatakbo at pagbabadyet ay madalas itong nagmumula sa ibaba. Ibig sabihin, mula sa “Requests for d/s expenses”, na laging pinupunan ng mga empleyado ng departamento.

At ang mga aplikasyong ito, nang naaayon, ay kailangang maproseso sa oras, tinanggap/tanggihan, "naka-iskedyul" at binayaran.

Kabuuan: pagpaplano ng pagpapatakbo para sa d/s ay ang pinakaunang gawain sa pagpaplano, na dapat ay awtomatiko sa 1C para sa anumang negosyo.

At bilang resulta ng pagpaplano, ang departamento ng pananalapi / treasury ay dapat "makita" sa system:

• Kailan, kanino, mula sa aling bank account/cash, para sa anong halaga ang dapat bayaran;
• Ano ang magiging balanse ng pera sa petsa ng "ganyan at ganoon", isinasaalang-alang ang mga kasalukuyang balanse, nakaplanong gastos at mga resibo ng pera. Dapat iwasan ang tinatawag. "mga puwang sa pera"

  Iyon ay, may pangangailangan na magtrabaho kasama ang kalendaryo ng pagbabayad.

• Anong utang sa mga katapat ang magiging sa mga tinukoy na petsa, na isinasaalang-alang ang mga binalak na pagbabayad, mga resibo at ang kasalukuyang balanse ng mutual settlements.

  Iyon ay, may pangangailangan na magtrabaho kasama ang kalendaryo ng pagkalkula.

Ang bawat isa sa mga pagsasaayos ay maaaring gamitin upang malutas ang mga problema sa pagpaplano sa pagpapatakbo, ngunit ang isang balanseng pagpili ay dapat gawin batay sa saklaw at sukat ng iyong proyekto.

2. Mga tampok ng soft starter 1.3

Sa ngayon, hindi pa inilalabas ng 1C ang pinakahihintay, bagong edisyon ng UPP (rebisyon 2). At sa kadahilanang ito, tututukan namin kung ano ang magagamit - ang kaukulang mga subsystem ng SCP 1.3:

Dapat tandaan na ang subsystem na "Mga Kahilingan para sa Paggasta ng Cash" ay na-update sa configuration kamakailan lamang (2011). At bilang resulta, sa mode ng pinamamahalaang interface, ang item na "Mga kahilingan para sa paggastos ng d/s/" ay lumabas sa panel ng seksyon.

Kung susubukan mo sa isang karaniwang pagsasaayos, sa file mode, upang buksan ang form ng dokumento na "Kahilingan para sa Mga Gastos sa D/s" (aka, ZRDS), pagkatapos ay isang error ang agad na lilitaw para sa variable na "Mga Global na Halaga" mula sa pangkalahatang module na "Paggawa gamit ang Mga Pangkalahatang Variable”.

Ang gayong mga pagkakamali ay maaaring itama, gayunpaman, tulad ng sinasabi nila: "nananatili ang sediment." Ibig sabihin, may sapat na "mga gaspang" sa subsystem ng UPP ZRDS.
Ang kakayahang gumuhit ng isang ZRDS na dokumento sa pamamagitan ng isang WEB browser ay kapaki-pakinabang, ngunit sa pagsasanay kailangan mong mag-isip nang mabuti tungkol sa pagpapasimple at ergonomya ng karaniwang anyo ng dokumento. Lalo itong magiging mahalaga para sa mga mobile device.

Ngunit tungkol sa kalendaryo ng pagbabayad, sa thin client mode, malayuan sa pamamagitan ng isang WEB browser, atbp. hindi mo ito magagamit. Ang dahilan ay ang Cash Management subsystem ay hindi na-update sa loob ng mahabang panahon at, lalo na, ang ulat ng Payment Calendar ay hindi binuo sa isang data composition system. Samakatuwid, ang ulat na ito ay hindi magagamit sa mga manipis na kliyente, walang posibilidad na lumikha ng mga custom na setting para dito.

Kapag nagtatrabaho sa ZRDS, isang mahalagang lugar ang inookupahan ng mga regulasyon para sa koordinasyon at pag-apruba ng mga aplikasyon. Depende sa istraktura ng organisasyon ng negosyo at iba pang mga tampok ng negosyo, ang panloob na pamamaraan para sa pag-apruba ng mga aplikasyon (mga regulasyon sa pag-apruba) ay maaaring maging kumplikado (multi-stage, variable, atbp.). Kaya hindi ito isang madaling gawain para sa automation.

Sa UPP, ipinapatupad ang subsystem ng koordinasyon at pag-apruba. Nagbibigay ito ng medyo nababaluktot na mga setting.

• Ang pag-apruba ay kumpirmasyon ng pangangailangang magbayad para sa aplikasyon. Karaniwan, ang pag-apruba ay dapat dumaan sa mga pinuno ng mga departamento, tagapamahala at iba pang responsableng tao ng kumpanya.
• Ang pag-apruba ay ang huling kumpirmasyon (ng Ingat-yaman) na babayaran ang aplikasyon. Sa kasong ito, dapat matukoy ang petsa ng pagbabayad at ang bank account/cash office kung saan gagawin ang pagbabayad. Kaya, ang pagbabayad ay nahuhulog sa plano sa pagpapatakbo (kalendaryo ng pagbabayad).

1. Maaari mong paganahin ang paggamit ng mekanismo ng pag-apruba ng aplikasyon nang hiwalay para sa bawat organisasyon.

• Posibleng i-configure ang pagkakasunod-sunod ng kahilingan sa pamamagitan ng mga ruta at ang hierarchy ng mga ruta.

1. Dapat tandaan na ang hierarchy sa direktoryo ng departamento ay hindi isinasaalang-alang sa mga mekanismo ng pagruruta ng aplikasyon.
2. Kinakailangan din na kanselahin na ang koordinasyon at pag-apruba ay teknikal na ginawa nang hindi gumagamit ng mekanismo ng proseso ng negosyo.

• Sa bawat punto, maaari mong tukuyin ang isa/ilang user kung kanino magiging available ang pag-apruba ng application. Iyon ay, ang aplikasyon ay maaaring maaprubahan ng sinuman sa kanila (kung sino man ang unang gumawa nito).

• Para sa bawat departamento, maaari kang magtalaga ng kaukulang punto ng ruta ng pag-apruba. Ang kakanyahan nito ay ito: kapag pinupunan ang isang aplikasyon (ZRDS), dapat ipahiwatig ang Central Federal District (dibisyon). At depende sa tinukoy na dibisyon, "hinahanap" ng UPP ang kaukulang punto ng pag-apruba at "ipapadala" ang aplikasyon para sa pag-apruba sa puntong ito.

Posible rin na huwag tukuyin ang isang departamento kapag nagse-set up ng ruta ng pag-apruba. Sa kasong ito, ang nasabing punto ng koordinasyon ay "ilalapat" sa lahat ng CFD kung saan ang kaukulang punto ng ruta ay hindi partikular na ipinahiwatig.

1. Ang mismong pag-apruba ay isinasagawa gamit ang isang espesyal na pagproseso na "Pag-apruba ng aplikasyon"

1. Ang pagsusuri sa nakaplanong pagkakaroon ng mga pondo, iskedyul ng pagbabayad at pagsubaybay sa mga puwang sa pera ay isinasagawa sa ulat ng "Payment Calendar".

Bilang karagdagan sa nakaplanong pagkonsumo ng d/s (ZRDS), maaari mo ring isaalang-alang ang nakaplanong pagtanggap ng d/s. Para sa mga layuning ito, inaasahang gumuhit ng isang espesyal na dokumento na "Planned receipt of income".

Dapat tandaan na kahit na ang dokumentong "Planned receipt of d/c" ay may mga estado (inihanda, napagkasunduan, atbp.), walang pagkakataon na i-coordinate ang dokumentong ito (pati na rin ang ZRDS). Iyon ay, ang pagbabago ng mga katayuan ng dokumento ay posible lamang sa mode na "manual na kontrol".

At sa UPP posibleng isaalang-alang ang nakaplanong pagtanggap ng cash mula sa mga mamimili nang hindi naghahanda ng mga dokumentong "Planned receipt of cash".

Iyon ay, kung ang "Mga Order ng Customer" ay inisyu para sa isang mamimili, pagkatapos ay sa isang hiwalay na ulat na "Kalendaryo ng pagbabayad na isinasaalang-alang ang mga order" ay makikita ang nakaplanong resibo na ito.

1. Bilang karagdagan sa ulat sa Kalendaryo ng Pagbabayad, mayroong ulat ng Pagsusuri sa Availability ng Cash.

Kasabay nito, posibleng magreserba ng d/s (batay sa mga aplikasyon para sa mga gastos) o maglagay ng mga aplikasyon laban sa mga nakaplanong kita.

Mayroon ding functionality para sa pagsasara ng ZRDS at nakaplanong kita mula sa d/s. Para sa mga layuning ito, sa mode na "regular na kliyente", ang mga dokumentong "Pagsasara ng mga aplikasyon para sa mga paggasta/resibo" ay ibinigay.

Gayunpaman, hindi rin sinusuportahan ang functionality na ito sa thin/web client mode.
Dito kailangan mong maunawaan na ang pamamaraan ng "hard reservation" ay mahigpit na nakatali sa kronolohiya ng pagpasok ng dokumento, at ginagawa nitong mahirap ang mga pagsasaayos at muling pag-iskedyul.

Samakatuwid, ang functionality ay naiwan sa UPP sa halip bilang isang "legacy of the past", at ang kalendaryo ng pagbabayad ay dapat gamitin upang suriin ang availability ng d/s.

Kaya, isinasaalang-alang namin ang pag-andar ng soft starter at ngayon ay ililista ko ang mga aspeto ng karaniwang pagsasaayos na sa pagsasanay, sa mga proyekto, ay kailangang baguhin:

1. Ayon sa dokumentong "Application para sa d/s expenditure":
   1. Sa dokumento, maaari mong ipahiwatig ang "Dibisyon" (sa pamamagitan ng paraan, sa pagsasaayos ito ay itinalaga bilang Central Federal District - sentro ng pananagutan sa pananalapi). Ngunit ito ay lubos na posible na ang isang aplikasyon ay isinumite mula sa isang dibisyon (CFD), at sa kasong ito ang mga gastos ay kailangang higit pang maiugnay/ipamahagi sa ibang (mga) dibisyon (CFD - mga sentro ng pamamahala sa pananalapi).

      Kakayahang tukuyin ang mga digital na function, atbp. - wala.

      Walang kakayahang baguhin ang ruta o i-redirect ang application sa ibang mga ruta.

1. Walang posibilidad na planuhin ang paglipat ng cash sa pagitan ng mga kasalukuyang account, mula sa account patungo sa cash desk, atbp.
1. Proseso ng kasunduan:
   1. Posibleng i-coordinate ang ZRDS, ngunit walang posibilidad na i-coordinate ang nakaplanong pagtanggap ng d/s.
   2. Sa pagsasagawa, kinakailangan na magsagawa ng mga pag-apruba para sa iba pang mga empleyado. Kasabay nito, kailangan din ng system na magtala ng impormasyon tungkol sa "sino ang nagsagawa ng pag-apruba at para kanino."

      Ang opsyon ng pag-install ng ilang posibleng executor sa isang coordination point ay kadalasang hindi angkop, kaya ang executor na ito ay maaaring ipahiwatig sa ibang mga yugto ng koordinasyon. Bilang resulta, ang lahat ng ito ay hahantong sa katotohanan na ang empleyado ay magkakaroon ng parehong pangunahing at hindi direktang mga gawain sa pag-apruba sa listahan ng mga kahilingan para sa pag-apruba. Siyempre, nalilito nito ang gumagamit at hindi maginhawa.

      Upang buod, ang kakayahang mag-coordinate para sa isa pang performer, ang kakayahang ipahiwatig kung sino ang may karapatang makipag-coordinate para sa kung sino ang nawawala.

   3. Sa proseso ng pag-apruba ng mga aplikasyon, kapag ang isang aplikasyon ay ipinasa para sa pag-apruba sa susunod sa kahabaan ng ruta, ang pag-andar ng awtomatikong pagpapaalam (sa pamamagitan ng e-mail) sa susunod na tagapagpatupad, pati na rin ang may-akda ng aplikasyon, ay hinihiling .
   4. Kung ang may-akda ng aplikasyon ay may pananagutan na para sa koordinasyon/pag-apruba (sa anumang yugto ng ruta!), Kung gayon ito ay lubos na lohikal para sa programa na awtomatikong "paikliin" ang ruta, na nire-redirect ang aplikasyon sa pinakamataas na magagamit na antas. Gayunpaman, hindi ito itinatadhana sa UPP.
   • Ang lahat ng mga kinakailangan sa itaas, bagama't hindi kasama sa karaniwang pagsasaayos, ay gayunpaman .

1. Mga ulat, mga karapatan sa pag-access.
   1. May pangangailangan para sa posibilidad na limitahan ang pag-access sa mga aplikasyon lamang ng mga available na may-akda/tagaganap (co-ordinator); ayon sa mga departamentong magagamit ng gumagamit.
   2. Walang pag-uulat sa pagsubaybay (sa mga araw at pagitan) ng aktwal at nakaplanong utang. Ito ay totoo para sa parehong mga mamimili at mga supplier.
   3. Ang pag-uulat at ilan sa mga functionality ay hindi angkop para sa pagtatrabaho sa thin/web client mode.
2. Accounting para sa mga regular na kasunduan at kontrata.
   1. Kadalasan mayroong mga sitwasyon kung kailan kinakailangan na regular na magbayad ng mga supplier. Halimbawa, mga pagbabayad sa pag-upa, atbp.

      Hindi ito awtomatikong ipinapakita ng UPP sa kalendaryo ng pagbabayad, atbp. itong paparating na mga gastos. Iyon ay, kinakailangan na manu-manong subaybayan ang mga naturang pagbabayad at punan ang mga kahilingan sa pagbabayad, na hindi maginhawa at nakakaubos ng oras.

   2. Ang mga kasunduan sa mga mamimili at supplier ay maaaring magtakda ng mga kondisyon para sa porsyento ng paunang bayad, mga tuntunin sa pagbabayad, atbp.

      Hindi awtomatikong itinatala ng UPP ang lahat ng impormasyong ito at (bilang resulta) awtomatikong ipinapakita ito sa kalendaryo ng pagbabayad.

Sa paglabas ng bagong configuration na "Trade Management Rev.11", maraming bago, kapaki-pakinabang na pagkakataon ang lumitaw para sa mga gawain ng pagpaplano ng pagpapatakbo at kontrol sa pananalapi.
Marahil ang pinakamahalagang bagay sa bahaging ito sa UT11 (kumpara sa UPP 1.3) ay ang mekanismo para sa accounting para sa iskedyul ng pagbabayad. Ang mekanismong ito ay "nagsasara" kung ano ang kulang - automation ng pagpaplano/accounting sa ilalim ng mga regular na kasunduan at kontrata.

Kaya, sa UT11 posible na huwag gumuhit ng mga dokumento sa lahat (kung walang pangangailangan, siyempre) para sa pagpaplano ng mga gastos at mga resibo, at sa parehong oras, ang kalendaryo ng pagbabayad ay mabubuo nang normal.

Maaari mong kanselahin na ang "mga karaniwang setting" ng ulat ng "Kalendaryo ng pagbabayad" ay hindi talaga nakakatugon sa mga inaasahan (sa gayon, ang kalendaryo ay hindi ipinapakita), ngunit sa user mode maaari kang magdagdag ng isang pagpapangkat ayon sa "petsa ng pagbabayad" at ang ulat ay mabubuo sa karaniwang anyo.

Ang pagpapagana ng ulat ay lubos na lumawak (kumpara sa SCP 1.3) dahil sa paggamit ng isang sistema ng komposisyon ng data. Ngayon, ang ulat ay maaaring mabuo sa isang thin/web client, i-save sa database at italaga sa iba't ibang user ang mga setting na kailangan nila.

Bilang karagdagan sa pagpaplano ng pagkonsumo at pagtanggap ng mga gamit sa bahay, ang UT11 ay mayroon na ngayong functionality ng pagpaplano ng paggalaw ng mga gamit sa bahay. Para sa mga layuning ito, maaari kang gumuhit ng mga dokumentong "Order para sa relokasyon ng mga kabahayan."

Kung ikukumpara sa UPP 1.3 para sa dokumentong "Application para sa paggasta ng cash", ang bilang ng mga itinuturing na uri ng mga transaksyon sa negosyo ay tumaas:

Posible na ngayong aprubahan ang parehong mga dokumento na "Application para sa paggasta ng mga pondo" at iba pang mga order:

Upang pag-aralan ang utang ayon sa mga agwat/deadline, ibinibigay ang ulat na "Mga Account Receivable". Kung kinakailangan, maaari ka ring lumikha ng kalendaryo ng utang. Upang gawin ito, sa custom na mode dapat kang magdagdag ng pagpapangkat ayon sa mga petsa ng pagbabayad.

Sa kasamaang palad, ang UT11 (tulad ng dati) ay hindi nagbibigay ng kakayahang suriin ang kalendaryo ng utang ng mga supplier. Gayunpaman, kailangang baguhin ang UT11 para sa gawaing ito.

Upang ibuod: Ang mga bagong metodolohikal na solusyon na "1C", kasama ang mga kakayahan ng 8.2 platform, ay nagbibigay ng isang mahusay na batayan para sa pag-automate ng mga gawain ng pagpaplano ng pagpapatakbo at kontrol ng d/c.

Ngunit sa parehong oras, kailangan mong maunawaan na ang pagsasaayos ng UT11 ay hindi isang kumpleto, handa na solusyon para sa automation ng treasury at pagpaplano sa pananalapi.

• Una, ipinapatupad ng UT11 sa napakasimpleng anyo ang isang mekanismo para sa pag-uugnay/pag-apruba ng mga kahilingan para sa mga gastos at iba pang mga dokumento sa pagpaplano ng d/s. Iyon ay, walang mga mekanismo sa pagruruta, ang proseso ng pag-apruba ng mga aplikasyon ay nabawasan sa simpleng pagtatakda ng mga katayuan.
• Pangalawa, ang UT11 ay walang subsystem sa pagbabadyet at (bilang resulta) walang functionality para sa pagsubaybay sa mga aplikasyon para sa mga nakaplanong badyet.

Sa kasaysayan, ang WA:Financier configuration ay binuo batay sa produkto ng Treasury Management.

At kasabay nito, ang bagong "Financier" na solusyon mula sa WiseAdvice ay kinabibilangan din ng:

• Subsystem sa pagpaplano ng badyet;
• Subsystem ng pamamahala ng kontrata;
• Subsystem para sa pagbuo at accounting ng mga aktwal na pagbabayad;
• Flexible, nako-customize na mekanismo para sa pagbuo/pagpuno ng mga dokumento batay sa mga template;
• Flexible, nako-customize na subsystem ng integration ng client-bank.

1. Sa panahon ng proseso ng pag-apruba ng aplikasyon, hindi mo lamang maaaprubahan/matanggihan ang dokumento (tulad ng ginagawa sa UPP), ngunit available din ang iba pang mga function: halimbawa, magpadala ng dokumento para sa rebisyon, o humiling ng karagdagang impormasyon. impormasyon.

   Ang buong proseso ay awtomatiko nang naaayon, ang pag-uulat ay ibinigay sa katayuan ng pagproseso ng pag-apruba ng dokumento.

5. Mga resulta

Mga konklusyon:

1. Upang i-automate ang gawain ng mga kagawaran ng pananalapi, treasuries, mga organisasyon na may mga kumplikadong istruktura ng organisasyon. istraktura ang pinaka-angkop na solusyon ay "WA: Pinansyal".

   Ang solusyon na ito ay umuunlad at umuunlad sa mahabang panahon, naaayon sa pag-iipon ng mga detalye at pangangailangan ng iba't ibang institusyong pampinansyal. mga kagawaran at treasuries. Ang kabuuang gastos sa paggawa para sa pagbuo ng solusyon ay umabot sa higit sa 5,000 tao/oras.

   Ang bentahe ng WA: Financier solution ay ang advanced functionality nito at isang malaking bilang ng mga mekanismo ng setting ng program. Kaya, ang pagpapatupad ng solusyon na ito ay posible sa maikling panahon (ang tinatawag na "out-of-the-box na pagpapatupad"), nang walang karagdagang. pag-unlad, programming, atbp.

   Dahil ang solusyon ay naglalaman ng mga mekanismo para sa dalawang-daan na pagpapalitan sa lahat ng pangunahing karaniwang mga pagsasaayos, ang pagsasama sa umiiral na istraktura (pagpapalitan ng data sa mga database ng UT, UPP, Kompleksnaya, Bukh) ay hindi magiging mahirap.

2. Upang i-automate ang departamento ng pananalapi / treasury bilang bahagi ng isang komprehensibong proyekto ng automation ang pinakamagandang solusyon ay batay sa UPP.

   Kasabay nito, kailangan mong maunawaan na ang pag-andar ng soft starter ay mangangailangan ng mga pagpapabuti.

   Mga detalye, mga kinakailangan sa pananalapi. ang mga kagawaran at treasuries ay hindi naka-embed sa UPP na kasing lalim ng ginagawa sa hiwalay, espesyal na mga solusyon.

   Kaya, ang pagpapatupad ng SCP para sa mga gawaing ito ay dapat lamang isagawa bilang bahagi ng isang proyekto ng automation.

3. Para sa malalaking organisasyon, i-automate ang treasury department UT11 hindi kasya.

   Sa desisyong ito, una, walang mga mekanismo para sa koordinasyon/pag-apruba ng mga dokumento sa pagpaplano.

   Pangalawa, walang pagbabadyet subsystem at kontrol sa pagpapatupad ng mga badyet sa panahon ng pagpaplano ng pagpapatakbo.

   Gayunpaman, ang UT11 perpekto para sa automation (kabilang ang pagpaplano ng pagpapatakbo d/c) maliit na pananalapi mga departamento ng kumpanya.

Ang dokumentong "Paghiling para sa paggasta ng mga pondo" ay inilaan para sa pagpaplano at koordinasyon ng mga pagbabayad.
Ang dokumentong "Paghiling para sa paggastos ng DS" ay maaaring gawin sa pamamagitan ng pagpunta sa seksyong "Treasury" - "Pagpaplano at kontrol ng mga pondo" - "Mga kahilingan para sa paggastos ng DS" - Lumikha.
Ang dokumentong "Kahilingan para sa paggasta ng DS" ay may ilang uri ng mga operasyon na pinili sa panahon ng paggawa. Ang bawat uri ng aplikasyon ay inilaan upang ipakita ang iba't ibang mga transaksyon sa negosyo, ang bawat isa ay ilalarawan sa pagtuturo na ito.
Ang mga nilikhang dokumento na "Aplikasyon para sa paggastos ng DS" ay kinokolekta at napagkasunduan sa paggamit ng dokumentong "Rehistro ng Mga Pagbabayad". Pagkatapos ng pag-apruba, batay sa mga aplikasyon, ang mga dokumentong "Write-off of non-cash DS" ay awtomatikong nagagawa, na ina-upload sa bangko ng kliyente para sa pagbabayad ng bangko.
Ang mga sumusunod ay mga halimbawa ng pagpapatupad ng mga dokumento na "Application para sa paggasta ng DS" para sa bawat uri ng operasyon.

Pagbabayad sa supplier
Upang iproseso ang mga transaksyon sa pagbabayad sa isang supplier, ang uri ng transaksyon ng dokumentong "Paghiling para sa paggasta ng DS" ay inilaan - "Pagbabayad sa supplier".
Sa bagong dokumentong "Application for spending DS", ang mga field na kinakailangang punan para maproseso ang dokumento ay minarkahan ng pula. Ang dokumento ay nilikha sa katayuan na "Hindi naaprubahan" ang katayuan ay awtomatikong nagbabago sa panahon ng pag-apruba ng rehistro ng pagbabayad. Ang priyoridad ng application sa paggawa ay awtomatikong itatakda sa "Medium".

Figure 1. Form ng dokumento "Application para sa paggasta ng DS", uri ng operasyon "Pagbabayad sa supplier" (hindi napunan)
Ang mga detalye ng dokumentong "Application para sa paggastos ng DS" ay dapat punan tulad ng sumusunod:
Basic na tab
Numero– ay awtomatikong nabuo sa panahon ng pagpapatupad, hindi maaaring itakda nang manu-mano.
petsa– kapag ginawa, ang kasalukuyang petsa ay nakatakda.
Organisasyon– dapat kang pumili mula sa iminungkahing listahan ng mga organisasyon gamit ang pindutan, o sa pamamagitan ng pagpasok ng pangalan sa field, ang kinakailangang halaga ay iaalok para sa pagpili.
Subdivision– mula sa direktoryo ng “Enterprise Structure”, dapat mong piliin ang dibisyon kung saan dapat mangyari ang pagbabayad.
Aplikante– bilang default, ang kasalukuyang user ng system na gumagawa ng application ay ipinahiwatig.
Pagpaplano– ang default na setting ay “In payment currency” at hindi na mababago.
Sum– ipahiwatig ang halaga ng kinakailangang pagbabayad.
Pera– ipahiwatig ang pera ng kinakailangang pagbabayad.
Operasyon– ang uri ng transaksyon ng dokumentong "Application para sa paggasta ng DS" na pinili sa panahon ng paglikha ay makikita
petsa ng pagbabayad– nagsasaad ng petsa kung kailan dapat nakaiskedyul ang pagbabayad sa supplier.
Paraan ng pagbabayad– ang default na setting ay “Sa anumang anyo” at hindi mababago.
tatanggap– nagsasaad ng supplier mula sa direktoryo ng “Mga Counterparties” kung saan dapat bayaran ang pagbabayad.
Account ng tatanggap– kapag pinipili ang “Recipient”, ang account ng tatanggap ay awtomatikong itinatakda kung kinakailangan, kung ibang account ang ipinahiwatig sa “Invoice para sa pagbabayad” na ibinigay ng supplier, dapat mong piliin ang kinakailangan mula sa direktoryo ng “Mga Bank Account”.
Lampas sa limitasyon– kung ang system ay nagpapanatili ng isang sistema para sa paglilimita sa mga paggasta sa pera sa konteksto ng mga sangay at mga item sa daloy ng salapi, ayon sa pagkakabanggit, kung ang halaga ng pagbabayad na ginawa ay hindi kasama sa limitasyon, kapag nagpo-post ng dokumento ang user ay makakatanggap ng isang mensahe ng error at hindi mapoproseso ang aplikasyon.

Figure 2. Isang halimbawa ng error kapag naglalagay ng order kung saan ang limitasyon ay hindi binalak.
Upang maglagay ng order na lampas sa limitasyon, dapat mong itakda ang flag na "Lampas sa Limitasyon".
Ilipat sa budget– ang flag na ito ay nakatakda kung ang pagbabayad ay isang paglipat sa badyet. Ang pagtatakda ng bandila ay nagbibigay-daan sa iyong ipasok ang mga halaga ng KBK, OKTMO, atbp. na kinakailangan para sa mga pagbabayad sa badyet.

Figure 3. Halimbawa ng pagtatakda ng flag na "Ilipat sa badyet".
UIP– isang natatanging pagkakakilanlan ng pagbabayad, na ipinahiwatig lamang kung ito ay ibinigay para sa kasunduan sa nagbabayad.
Dahilan ng pagbabayad- ang programa ay nagbibigay ng ilang mga opsyon para sa awtomatikong pagpuno sa layunin ng pagbabayad gamit ang "Insert" na buton.

Figure 4. Mga opsyon para sa awtomatikong pagpuno sa field na "Layunin ng pagbabayad".
Listahan ng mga dokumento, kasama. VAT- ay magpapakita ng impormasyon tungkol sa mga bagay sa settlement mula sa tab na "decryption ng pagbabayad".

Incl. VAT (18%) (para sa buong halaga), incl. VAT (10%) (para sa buong halaga), Hindi kasama ang buwis (VAT)- Ang impormasyon ng VAT ay idaragdag sa ipinasok na teksto.

Text mula sa bank account ng tatanggap- inilalagay ang tekstong tinukoy sa field na "Text ng layunin ng pagbabayad" mula sa account card ng katapat.

Figure 5. Halimbawa ng pagpuno sa tab na "Basic".

Tab na Mga Detalye ng Pagbabayad
Ang tab na "Payment Decoding" ay nagbibigay ng detalyadong impormasyon tungkol sa pagbabayad at mga mutual settlement sa nagbabayad.
Maaaring ipasok ang pagbabayad bilang isang listahan, i.e. ipamahagi sa ilang mga bagay sa pagkalkula, o nang walang paghahati, posibleng pumili lamang ng isang bagay sa pagkalkula.
Pagbabayad mula sa mga pondo ng pagtatanggol ng estado– ang bandila ay itinakda lamang kung ang pagbabayad ay naganap sa loob ng balangkas ng isang utos ng depensa ng pamahalaan, sa ibang mga kaso ang bandila ay hindi nakatakda.
Bagay sa pagkalkula– bilang object ng settlement, maaari mong tukuyin ang “Kasunduan sa counterparty” (para sa ganitong uri ng pagpapatakbo ng dokumento ng aplikasyon, kapag pinili, ang mga kasunduan sa uri ng relasyon na “Sa supplier/performer” ay available) o ang napagkasunduang dokumento na “Order sa supplier”.
Provider
Dami ng mutual settlements– ay awtomatikong nakatakda kapag nagpo-post ng isang dokumento.
Pera– ay awtomatikong itinakda kapag pumipili ng bagay sa pagkalkula.
Artikulo ng DDS– ipahiwatig ang cash flow item na naaayon sa uri ng pagbabayad.
Komento– kung kinakailangan, magpahiwatig ng komento sa decryption ng pagbabayad.

Figure 6. Halimbawa ng pagpuno sa tab na "Payment Decoding".
Tab ng pamamahagi ng account
Sa tab na "Pamamahagi sa Mga Account," ipinahiwatig ang bank account ng organisasyon kung saan dapat i-debit ang mga pondo. Ang halaga at petsa ng pagbabayad ay awtomatikong itinatakda ayon sa data na tinukoy sa tab na "Basic".

Figure 7. Halimbawa ng pagpuno sa tab na "Distribution by Accounts".

Figure 8. Isang halimbawa ng awtomatikong nilikhang dokumento na "Write-off of non-cash DS" para sa isang application na may uri ng transaksyon na "Payment to supplier".

Pagbabalik ng bayad sa kliyente
Upang iproseso ang mga transaksyon sa refund sa mga kliyente, ang uri ng transaksyon sa dokumentong "Application para sa paggastos ng DS" ay inilaan - "Pagbabalik ng bayad sa kliyente".
Ang komposisyon ng mga detalye ng dokumentong "Application para sa paggastos ng DS" na may ganitong uri ng operasyon ay magkapareho sa komposisyon ng mga detalye kapag nagbabayad sa supplier, ang pagkakaiba lamang ay nasa uri ng katapat at ang object ng settlement.

Figure 9. Form ng dokumentong "Application for spending DS", uri ng operasyon "Return of payment to the client"
tatanggap– nagsasaad ng kliyente mula sa direktoryo ng “Counterparties” na kailangang magbayad.
Bagay sa pagkalkula– bilang object ng pag-areglo, maaari mong tukuyin ang "Kasunduan sa katapat" (para sa ganitong uri ng pagpapatakbo ng dokumento ng aplikasyon, kapag pumipili, ang mga kasunduan sa uri ng relasyon na "Sa mamimili/customer" ay magagamit) o ​​ang napagkasunduang dokumento " Order ng Customer”.
Mamimili– ang patlang ay awtomatikong napupunan kapag pumipili ng bagay sa pagkalkula. Ang elemento ng direktoryo ng "Mga Kasosyo" na tinukoy sa kaukulang field ng object ng pagkalkula ay naka-install.

Figure 10. Halimbawa ng pagpuno sa tab na "Payment Decoding".
Matapos maipasa ang lahat ng mga yugto ng pag-apruba, ang dokumentong "Application para sa paggastos ng DS" ay itatalaga sa katayuan na "Para sa pagbabayad" at ang dokumentong "Write-off ng non-cash DS" ay awtomatikong gagawin.

Figure 11. Isang halimbawa ng awtomatikong ginawang dokumento na "Write-off ng non-cash DS" batay sa isang application na may uri ng operasyon na "Pagbabalik ng bayad sa kliyente."

Pag-isyu sa may pananagutan
Upang magrehistro ng mga transaksyon para sa pag-isyu ng mga pondo sa isang bank account ng isang may pananagutan na tao, ang uri ng transaksyon ng dokumentong "Aplikasyon para sa paggastos ng DS" - "Isyu sa taong may pananagutan" ay inilaan.

Figure 12. Form ng dokumento "Application para sa paggastos ng DS", uri ng operasyon "Isyu sa nananagot"
May pananagutan na tao– nagsasaad ng empleyado mula sa direktoryo ng “Mga Indibidwal” kung kanino kailangang ilipat at iulat ang pera.
Ulat– mula sa iminungkahing listahan ng mga panahon, kinakailangang ipahiwatig ang panahon hanggang sa kung saan ang accountant ay kailangang mag-ulat sa halagang natanggap.

Figure 13. Halimbawa ng pagpuno sa tab na "Payment Decoding".
Matapos maipasa ang lahat ng mga yugto ng pag-apruba, ang dokumentong "Application para sa paggastos ng DS" ay itatalaga sa katayuan na "Para sa pagbabayad" at ang dokumentong "Write-off ng non-cash DS" ay awtomatikong gagawin.

Figure 14. Isang halimbawa ng isang awtomatikong nilikhang dokumento na "Write-off of non-cash DS" batay sa isang aplikasyon na may uri ng operasyon na "Isyu sa nananagot".

Maaaring bayaran ng kumpanya ang supplier sa cash o sa pamamagitan ng paglilipat ng mga pondo sa bank account ng supplier (hindi cash na pagbabayad). Ang pagbabayad sa cash ay ginawa gamit ang dokumentong Expenditure cash order.

Ang pagbabayad na hindi cash (paglipat ng mga pondo sa kasalukuyang account ng tagapagtustos) ay naitala sa dokumentong Pagpapawalang-bisa ng mga pondong hindi cash.

Ang mga dokumento ay maaaring iguhit sa batayan ng mga dati nang iginuhit na mga dokumento Pagtanggap ng mga kalakal at serbisyo. Ang paglipat ng mga pondo sa kasalukuyang account ng supplier ay nakumpleto sa dalawang yugto: pagpapatupad at pag-print ng isang dokumento sa pagbabayad (papalabas na order ng pagbabayad) at pagpapatupad ng aktwal na paglilipat ng mga pondo mula sa kasalukuyang account ng negosyo sa kasalukuyang account ng supplier (pagkatapos makatanggap ng isang bangko pahayag).

Ang pamamaraang ito para sa pagpasok ng mga dokumento ay maaaring mangyari kung ang negosyo ay hindi nagpaplano ng mga kita at hindi kinokontrol ang paggasta ng mga pondo. Kung ang negosyo ay kailangang kontrolin ang paggasta ng mga pondo, kung gayon ang paggasta ng mga pondo ay isinasagawa alinsunod sa naaprubahang aplikasyon para sa paggasta ng mga pondo. Upang ipatupad ang opsyon sa pagbabayad na ito sa programa, sa seksyong Pangangasiwa - Mga Organisasyon at pondo, dapat na lagyan ng check ang checkbox ng Mga Application para sa mga pondo sa paggastos.

Ang kontrol sa pera ay maaari lamang isagawa sa ilang mga cash desk o mga kasalukuyang account. Posibleng tukuyin ang isang listahan ng mga cash register at kasalukuyang account, ang daloy ng mga pondo mula sa kung saan ay makokontrol. Ito ay tinutukoy sa card ng isang partikular na cash register o kasalukuyang account.

Upang kontrolin ang paggasta ng mga pondo, ang dokumentong Aplikasyon para sa paggasta ng mga pondo ay ginagamit.

Paano magplano at makipag-ugnayan sa pamamahala sa paggasta ng mga pondo.

Upang magamit ang mga mekanismo para sa pagpaplano at pagkontrol sa paggasta ng mga pondo, kinakailangan na sa seksyong Pangangasiwa - Mga Organisasyon at pondo ang checkbox ng Mga Kahilingan para sa paggasta ng mga pondo.

Posible rin na kontrolin ang paggasta ng mga pondo alinsunod sa itinatag na mga limitasyon sa paggasta ng mga pondo. Upang ipatupad ang naturang kontrol, dapat kang pumili ng mga karagdagang checkbox upang kontrolin ang limitasyon sa seksyong Administration - Mga organisasyon at pondo.

Ang limitasyon sa paggasta ng pera ay itinakda para sa isang buwan at nakadetalye hanggang sa mga item sa daloy ng salapi (pagbabayad sa mga supplier, pagbabayad ng suweldo, gastos sa negosyo, atbp.). Ang listahan ng mga item sa daloy ng salapi ay maaaring opsyonal na dagdagan ng gumagamit (seksyon Pananalapi – Mga setting at reference na aklat – Mga item sa daloy ng pera).

Posibleng magtakda ng mga limitasyon sa paggasta ng mga pondo para sa bawat dibisyon at para sa bawat organisasyon.

Dapat tandaan na kung hindi na kailangang kontrolin ang gastos para sa anumang item ng cash flow, kailangan pa rin itong isama sa tabular na bahagi ng dokumento ng DS Expense Limits, at ang control option na "unlimited" ay dapat itakda para dito . Posibleng awtomatikong punan ang tabular na bahagi ng dokumento ng lahat ng mga item sa daloy ng salapi o mga limitasyon sa daloy ng salapi na itinakda noong nakaraang buwan.

Ang proseso ng pag-apruba at pag-apruba ng aplikasyon ay binubuo ng mga sumusunod na yugto.

• Paghahanda ng isang aplikasyon ng nagpasimula ng pagbabayad.
• Koordinasyon ng mga aplikasyon.
• Pag-apruba ng mga aplikasyon (paghahanda ng mga aplikasyon para sa pagbabayad).

Paghahanda ng isang aplikasyon ng nagpasimula ng pagbabayad.

Ang isang aplikasyon para sa paggastos ng mga pondo ay nakumpleto ng manager batay sa dokumento ng paghahatid. Ang isang aplikasyon para sa paggastos ng mga pondo ay maaaring gawin mula sa isang listahan o mula sa isang form ng dokumento.

Posible rin na magsumite ng isang aplikasyon gamit ang ilang mga dokumento sa paghahatid o walang tinukoy na dokumento sa pagbabayad.

Sa isang bagong aplikasyon para sa paggasta ng mga pondo, ang lahat ng data mula sa dokumento batay sa kung saan ang aplikasyon ay iginuhit ay napunan. Kinokontrol ng manager ang kawastuhan ng pagpuno ng data sa application, itinatakda ang inaasahang petsa ng pagbabayad at isinasagawa ito. Ang aplikasyon ay isinumite sa katayuan na Hindi naaprubahan.

Maaaring ilakip ng tagapamahala sa aplikasyon ang mga naka-print na kopya ng mga invoice na inisyu ng supplier, mga dokumento sa paghahatid o anumang iba pang dokumento na nagpapatunay sa pangangailangang gumastos ng mga pondo. Upang gawin ito, gamitin ang mekanismo ng Naka-attach na mga file (utos sa panel ng nabigasyon ng form). Kung kailangang bayaran ang isang aplikasyon, maaaring itakda ito ng manager sa mataas na priyoridad.

Koordinasyon ng mga aplikasyon.

Ang listahan ng mga hindi naaprubahang aplikasyon ay isinumite para sa pag-apruba sa pinuno ng departamento (treasurer, financial director). Upang i-coordinate ang mga aplikasyon, ang isang hiwalay na lugar ng trabaho ay ibinibigay para sa Mga Aplikasyon para sa pag-apruba (seksyon ng Pananalapi). Ang mga user lang na may karapatan (role) na Pag-apruba ng mga kahilingan para sa mga pondo sa paggastos ang makakapag-apruba ng mga kahilingan.

Sa listahan, maaari mong piliin ang mga hindi naaprubahang aplikasyon kung saan nalalapit na ang deadline ng pagbabayad. Upang gawin ito, kailangan mong pumili sa listahan ayon sa katayuan na Hindi napagkasunduan at sa petsa ng pagbabayad.

Maaari mo ring hiwalay na isaalang-alang ang mga aplikasyon na may pinakamataas na priyoridad at mga aplikasyon para sa bawat organisasyon.

Kapag tinitingnan ang mga aplikasyon, ang pinuno ng departamento (ingat-yaman, direktor ng pananalapi) ay nakikita sa listahan ang lahat ng kinakailangang impormasyon tungkol sa aplikasyon: ang halaga ng aplikasyon, ang tatanggap, atbp. Nang hindi binubuksan ang listahan, makikita niya ang katwiran para sa kailangang gumastos ng mga pondo sa aplikasyon (nakalakip na mga file). Upang gawin ito, i-click ang icon.

Upang aprubahan (tanggihan) ang ilang kahilingan para sa pagbabayad, maaari mong piliin ang mga kinakailangang kahilingan sa listahan at piliin ang naaangkop na mga utos:

• Mga kahilingan sa coordinate – kung kinakailangan upang i-coordinate ang mga kahilingan para sa mga pondo sa paggastos;
• Tanggihan ang mga aplikasyon – kung ang mga aplikasyon para sa paggastos ng mga pondo ay dapat tanggihan.

Ang aplikasyon ay isinumite sa katayuang Napagkasunduan. Kapag naaprubahan ang isang aplikasyon, ang itinatag na limitasyon sa mga paggasta sa pera ay sinusubaybayan. Ang kakayahang mag-apruba ng mga kahilingan na higit sa limitasyon ay magagamit sa lahat ng mga user na may karapatang mag-apruba.

Maaari mong ayusin ang pag-apruba ng aplikasyon ng ilang tao. Sa kasong ito, ang proseso ng pag-apruba ng aplikasyon ay maaaring ayusin sa 1C: Document Flow program, gamit ang mga posibilidad ng magkasanib na paggamit ng Trade Management at 1C: Document Flow programs.

Pag-apruba ng mga aplikasyon (paghahanda ng mga aplikasyon para sa pagbabayad).

Upang aprubahan ang mga aplikasyon, ang user ay dapat magkaroon ng karagdagang tungkulin na tinukoy - Pag-apruba para sa pagbabayad ng mga aplikasyon para sa paggastos ng mga pondo. Sa programa, ang tungkuling ito ay itinakda para sa profile sa pag-access ng Treasurer.

Ang impormasyon tungkol sa mga aprubadong aplikasyon ay kasama sa kalendaryo ng pagbabayad (seksyon ng Pananalapi).

Ang halaga ng mga napagkasunduang pagbabayad para sa mga aplikasyon ay ipinapakita sa column na Lahat ng Inaasahan.

Sinusuri ng financier ang posibilidad na magbayad para sa mga aplikasyon sa tinukoy na araw sa cash o sa pamamagitan ng paglilipat ng mga pondo mula sa isang kasalukuyang account. Maaaring buksan ang application nang direkta mula sa kalendaryo at maaaring tukuyin ang petsa at paraan ng pagbabayad para dito. Iyon ay, alinsunod sa magagamit na balanse ng pera sa iba't ibang mga cash register at kasalukuyang mga account, tinutukoy ng financier kung paano pinakamahusay na magbayad para sa application na ito.

Direkta mula sa kalendaryo, maaari kang mag-isyu ng isang order upang ilipat ang mga pondo (mula sa isa pang cash desk, isa pang kasalukuyang account) o irehistro ang inaasahang pagtanggap ng mga pondo (pagtanggap ng karagdagang mga pautang, mga kredito, atbp.).

Matapos tukuyin ang petsa at paraan ng pagbabayad, inaprubahan ng financier ang mga aplikasyon (nagtatakda ng katayuan Para sa pagbabayad para sa kanila).

Pagkatapos ng huling pag-apruba ng mga aplikasyon, sinusuri niya ang posibilidad ng pagbabayad ng mga aplikasyon. Ang halaga para sa mga aprubadong aplikasyon ay ipinapakita sa Payable column.

Pagkatapos aprubahan ang aplikasyon (pagtatakda ng katayuan Para sa pagbabayad), maaari kang mag-isyu ng dokumento ng pagbabayad para sa mga pondo sa paggastos.

Pagkatapos ng pag-apruba ng aplikasyon, ipinapayong mag-isyu ng mga dokumento sa pagbabayad na nagpapahiwatig ng uri ng pagbabayad na nakarehistro sa aplikasyon. Gayunpaman, pinapayagan din ang iba pang mga uri ng pagbabayad. Halimbawa, ang bahagi ng aplikasyon ay maaaring bayaran ng cash, at bahagi - sa pamamagitan ng paglilipat ng mga pondo mula sa kasalukuyang account.

Sa kaso ng mga pagbabayad ng cash, ang dokumento Cash receipt order ay iginuhit. Ang aplikasyon para sa paggastos ng mga pondo ay ipapakita bilang isang payment order sa listahan ng mga cash outgoing order. Upang ayusin ang pagbabayad, i-click lamang ang Pay button. Ang impormasyon sa cash receipt order ay ipo-format alinsunod sa data ng naaprubahang aplikasyon.

Ang paglipat ng mga pondo mula sa isang kasalukuyang account ay nakumpleto sa dalawang yugto:

1. Ang order ng pagbabayad ay inilabas at nai-print. Ang order ng pagbabayad ay ipinadala sa bangko.
2. Ang aktwal na pag-debit ng mga pondo mula sa kasalukuyang account ay naitala sa pagtanggap ng isang bank statement sa paggalaw ng mga pondo sa kasalukuyang account.

Paano mag-isyu at mag-print ng isang dokumento sa pagbabayad.

Sa programa, maaari kang mag-isyu ng anumang uri ng dokumento sa pagbabayad: papalabas na order ng pagbabayad, inilipat na Letter of Credit, inilipat na order ng koleksyon, atbp. Upang irehistro ang lahat ng mga uri ng dokumentong ito sa programa, isang dokumento ang ginagamit - Pagpapawalang-bisa ng hindi- mga pondong salapi.

Anong uri ng dokumento ng pagbabayad ang iginuhit para sa paglipat sa bangko ay tinutukoy sa pamamagitan ng pagtatakda ng naaangkop na uri sa dokumentong Pagpapawalang-bisa ng mga pondong hindi cash.

Ang listahan ng mga dokumento kung saan dapat irehistro ang pagbabayad ay ipinapakita sa Para sa pagbabayad na listahan ng mga dokumento na pahina ng Mga hindi cash na pagbabayad.

Kung hindi ginagamit ang pagpaplano ng pera (ang checkbox ng Mga Kahilingan para sa paggasta ng pera ay hindi naka-check sa mga setting), ipapakita ng listahang ito ang lahat ng mga dokumentong iyon kung saan kinakailangan upang iproseso ang paggasta ng pera: isang order sa isang supplier, pagtanggap ng mga kalakal at serbisyo, atbp.

Kung ang mutual settlements sa supplier ay isinasagawa sa kabuuan sa ilalim ng kontrata (nang walang detalye ng mga order o invoice), ipapakita ng listahan ang halagang dapat bayaran sa supplier sa ilalim ng kontrata.

Kung ang enterprise ay gumagamit ng cash planning, ang listahang ito ay magpapakita lamang ng mga aprubadong aplikasyon para sa paggastos ng mga pondo (mga application na may katayuan na Para sa pagbabayad).

Upang mag-isyu ng dokumento ng pagbabayad para sa pag-debit ng mga hindi cash na pondo, kailangan mong i-click ang Pay button. Mabubuo ang dokumentong Write-off ng non-cash DS. Ang impormasyon sa dokumento ay pupunan alinsunod sa aprubadong aplikasyon para sa paggastos ng mga pondo. Sa tabular na bahagi ng dokumento, ang settlement object (Kasunduan sa supplier, Order to supplier, Receipt of goods and services) na tinukoy sa application para sa paggastos ng mga pondo ay pupunan.

Pagkatapos i-post ang dokumento, ang halaga at pera ng mga mutual settlement ay awtomatikong napunan. Ang currency ng mutual settlements ay tinutukoy ng currency ng mutual settlements na tinukoy sa settlement object na tinukoy sa payment document. Sa aming kaso, ang object ng mga settlement ay ang dokumento ng resibo, ipinapahiwatig nito ang pera ng mutual settlements, rubles, kaya ang halaga ng mutual settlements ay itatala din sa rubles.

Ang dokumento ng pagbabayad ay naka-print at ipinadala sa bangko. Upang maisagawa nang tama ang isang order sa pagbabayad, kailangan mong maingat na suriin at, kung kinakailangan, itama ang lahat ng mga detalye na ipinakita sa field na Layunin ng pagbabayad. Upang awtomatikong punan ang layunin ng pagbabayad, gamitin ang Insert command. Gamit ang utos na ito, maaari mong punan ang isang listahan ng mga dokumentong iyon kung saan dapat na mairehistro ang pagbabayad (ipinahiwatig sa tabular na bahagi ng dokumento bilang isang bagay sa pag-areglo).

Paano irehistro ang katotohanan ng paglilipat ng mga pondo mula sa kasalukuyang account ng kumpanya sa kasalukuyang account ng supplier.

Pagkatapos makatanggap ng bank statement na may tala na nagsasaad ng paglilipat ng mga pondo mula sa kasalukuyang account ng merchant patungo sa kasalukuyang account ng supplier, ang checkbox ng Payment order ay nakatakda sa Posted by bank.

Posibleng magtakda ng marka ng pangkat para sa bangko upang maisagawa ang napiling listahan ng mga pagbabayad.

Sa pagtanggap ng bank statement, dapat gawin ng accountant ang mga sumusunod na aksyon.

• Sa listahan ng mga Non-cash na pagbabayad, itakda ang bank account at panahon na nakasaad para sa mga pagbabayad sa bank statement.
• I-click ang button na Hindi Naitala para sa Bangko. Tanging ang mga pagbabayad na hindi minarkahan bilang isinasagawa ng bangko ang mananatili sa listahan.
• Gamit ang Receipt and Write-off buttons, irehistro ang mga pagbabayad na iyon na kailangang ipakita sa bank statement.
• Piliin ang listahan ng lahat ng mga pagbabayad at i-click ang button na Nai-post ng Bangko.
• Sa lalabas na dialog box, itakda ang petsa para sa mga pagbabayad ng bangko at i-click ang OK.

Para sa lahat ng minarkahang pagbabayad, pipiliin ang checkbox na Nai-post ng bangko. Upang i-reconcile ang mga pagbabayad sa natanggap na bank statement, gamitin ang ulat ng Statement by Day, na tinatawag ng hyperlink mula sa listahan.

Dapat tandaan na ang programa ay nagbibigay ng kakayahang awtomatikong magrehistro ng mga pagbabayad gamit ang programa ng Bank Client. Inilunsad ang programa sa pamamagitan ng pag-click sa Exchange with bank button sa listahan ng mga Non-cash na pagbabayad.

Available din ang mixed payment. Ibig sabihin, ang bahagi ng halaga ay maaaring bayaran ng cash, at ang bahagi sa pamamagitan ng paglilipat ng mga pondo sa bank account ng supplier. Sa kasong ito, batay sa isang aplikasyon para sa paggasta ng mga pondo (o isang dokumento ng resibo), dalawang dokumento ang iginuhit: Expenditure cash order at Write-off ng mga non-cash na pondo.

Ang impormasyon tungkol sa mga pagbabayad sa mga supplier ay maaaring makuha sa Card of settlements na may ulat ng mga supplier. Ang ulat ay tinawag mula sa supplier card.

Paano magproseso ng pagbabayad sa isang supplier sa foreign currency sa pamamagitan ng paglilipat ng mga pondo sa isang foreign currency settlement account.

Ang pagpaparehistro ng naturang transaksyon ay makatuwiran lamang kung ang mga pakikipag-ayos ay ginawa sa isang dayuhang supplier. Ang pera kung saan ang mga pakikipag-ayos sa supplier ay ginawa ay tinutukoy sa kasunduan sa supplier. Kung ang mga kontrata ay hindi ginagamit, ang pera ng mutual settlements ay tinutukoy sa order ng supplier o sa resibo na dokumento kung ang order ay hindi inilagay sa supplier.

Dapat ilipat ang mga pondo mula sa foreign currency account ng enterprise patungo sa foreign currency account ng supplier.

Isinasagawa ang operasyong ito gamit ang dokumentong Write-off ng non-cash DS na may kasunod na pagpaparehistro ng pagbabayad (pagsuri sa Posted by bank checkbox) pagkatapos irehistro ang bank statement. Ang isang kasalukuyang account ay pinili sa dokumento. Dapat itong ipahiwatig ang pera kung saan kailangang ilipat ang mga pondo sa bank account ng supplier. Ang pera ng kasalukuyang account ay maaaring hindi tumutugma sa pera kung saan ang mga dokumento sa supplier ay iginuhit (kasunduan ng supplier, order ng supplier, dokumento ng paghahatid). Halimbawa, ang mga mutual settlement sa isang supplier ay isinasagawa sa euro, at ang mga pondo ay inililipat sa dolyar. Matapos makumpleto ang mga naturang transaksyon, kinakailangan na gawing pormal ang muling pagsusuri ng mga pondo ng pera. Awtomatikong nagagawa ang isang dokumento sa muling pagsusuri kapag nagsagawa ka ng pagpoproseso ng Pagsasara ng Buwan (Seksyon ng Pananalapi). Ang programa mismo ang tumutukoy kung kailangang isagawa ang muling pagsusuri, awtomatikong muling susuriin ang mga pagbabayad sa mga supplier, kinakalkula ang mga pagkakaiba sa halaga ng palitan at itinalaga ang mga ito sa ibang kita (o mga gastos).