1с погодження заявки на витрачання коштів. Як оформити оплату постачальнику за куплені товари та надані додаткові послуги? Кейс – виробничий холдинг

1. Вступ

Планування коштів - одне з основних завдань управлінського обліку на відміну обліку бухгалтерського.

Звичайно, між УУ та БО є й інші суттєві відмінності (різні вимоги до аналітики, оцінки та переоцінки активів/зобов'язань, необхідність створення резервів тощо), але необхідність вирішувати завдання планування – це найскладніша з них.
Складність планування полягає не тільки у підготовці плану (його розрахунку, формуванню за різними сценаріями), але необхідно ще:

• Виконувати перепланування;
• Актуалізувати плани, переносити коригування на такі періоди;
• Проводити план – фактний аналіз.

Слід визнати, що у більшості підприємств (що використовують автоматизації «1С») планування у програмі не ведеться.
«Нам би облік налагодити..» - так багато хто міркує.

Облік потрібно налагодити, так, але не на шкоду плануванню.
Звичайно ж, планування все одно займаються (але не в «1С», а XLS). І найперше, основне завдання (яке і намагаються вирішити) – це планування коштів.

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

І якщо бюджетування (звісно, ​​при підході до планування «зверху-вниз»), можна здійснювати за допомогою XLS, то виконувати оперативне планування – не можна.
Суть у тому, що з таблицями бюджетів найчастіше працюють мінімум користувачів (1-2 особи). Для більшості підприємств кількість статей бюджетування та ін. Аналітик – їх не так багато. Тобто все можна обробити "ручками" у XLS.

А от щодо оперативного планування д/c, то тут ситуація інша. Тобто часто буває велика кількість рахунків на оплату, багато регулярних платежів, очікуваних сплат на замовлення клієнтів і т.д.

І до того ж, все це може «зав'язано» на велику кількість первинних документів, з якими працюють різні користувачі програми, коригуються документи, ситуація змінюється і т.д.

Ще важливою відмінністю оперативного планування від бюджетування є те, що воно найчастіше йде «з низу – вгору». Тобто від «Заявок на витрату д/c», які постійно оформляють працівники підрозділів.

І ці заявки, відповідно, потрібно вчасно обробляти, приймати/відхиляти, «ставити в план» та оплачувати.

Разом:оперативне планування д/с - це найперша із завдань планування, яка має бути автоматизована в «1С» у будь-якого підприємства.

І в результаті планування фінансовий департамент / казначейство повинні «бачити» в системі:

• Коли, кому, з якого розрахункового рахунку/каси, яку суму потрібно оплатить;
• Який залишок д/c буде на таку-то дату з урахуванням поточних залишків, запланованих витрат і надходжень д/c. Потрібно уникати т.зв. "касових розривів".

  Тобто виникає потреба працювати з платіжним календарем.

• Яка заборгованість із контрагентами буде на зазначені дати, враховуючи заплановані платежі, надходження та поточне сальдо взаєморозрахунків.

  Тобто виникає потреба працювати з календарем розрахунків.

Мета цієї статті - Розповісти про можливості автоматизації оперативного планування д/c. При цьому буде проведено порівняльний аналіз 3-х різних тиражних конфігурацій (дві - типові від «1С», одна - спеціалізована від компанії wiseadvice).

Кожну з конфігурацій можна застосовувати для вирішення завдань оперативного планування д/c, проте виважений вибір слід приймати, виходячи з рамок та масштабів вашого проекту.

2. Можливості УВП 1.3

На даний момент фірма «1С» ще не випустила довгоочікувану нову редакцію УПП (ред 2). І тому, будемо орієнтуватися на те, що доступно - відповідні підсистеми УПП 1.3:

Слід скасувати, що підсистема «Заявки На Витрата Грошових Засобів» оновлювалася у конфігурації відносно недавно (2011 р). І як наслідок, в режимі керованого інтерфейсу в панелі розділів з'явився пункт «Заявки на витрати д/с/».

Якщо спробувати в типовій конфігурації, у файловому режимі, відкрити форму документа «Заявка на витрату д/с» (вона ж, ЗРДС), то відразу виникає помилка по змінній «загальніЗначення» із загального модуля «РоботаЗмінними Змінними».

Такі помилки можна буде виправити, однак, як то кажуть: «осад залишився». Тобто «шорсткості» у підсистемі ЗРДС УПП – вистачає.
Можливість через WEB-браузер оформити документ ЗРДС є корисною, але при цьому на практиці доведеться добре задуматися над спрощенням та ергономікою типової форми документа. Особливо це буде важливим для мобільних пристроїв.

А от щодо платіжного календаря, то в режимі тонкого клієнта, віддалено через WEB-браузер і т.д. скористатися не вийде. Причина в тому, що підсистема «Управління грошима» давно не оновлювалася і, зокрема, звіт «Платіжний календар» побудовано не на системі компонування даних. А отже, цей звіт не має можливості використання в тонких клієнтах, не має можливості створювати для нього довільні налаштування.

Працюючи з ЗРДС важливе місце займає регламент узгодження і затвердження заявок. Залежно від організаційної структури підприємства та інших особливостей бізнесу, внутрішній порядок узгодження заявок (регламент узгодження) може бути досить складним (багатоступінчастим, варіативним тощо). Таким чином, для автоматизації це – не просте завдання.

В УПП, підсистема узгодження та затвердження реалізована. У ній передбачені досить гнучкі налаштування.

• Погодження – це підтвердження необхідності сплатити заявку. Зазвичай узгодження має відбуватися через начальників підрозділів, керівників та інших відповідальних осіб компанії.
• Твердження – це завершальне підтвердження (з боку скарбника) того, що заявку буде сплачено. При цьому обов'язково має бути визначена дата платежу, розрахунковий рахунок/каса, з якої буде здійснено оплату. Таким чином, платіж потрапляє до оперативного плану (платіжний календар).

Слід скасувати, що низка моментів типової функціональності УПП не забезпечують те, що потрібно при реальному впровадженні підсистеми.
Про ці "моменти" я напишу пізніше, а поки розглянемо яку функціональність надає типова конфігурація.

1. Включити використання механізму погодження заявок можна окремо по кожній організації.

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

1. При цьому слід зазначити, що ієрархія у довіднику підрозділу не враховується у механізмах маршрутизації заявки.
2. Також потрібно скасувати, що узгодження та затвердження технічно побудовано без застосування механізму бізнес-процесів.

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

• До кожного підрозділу можна призначити відповідну точку маршруту узгодження. Суть у цьому така: при оформленні заявки (ЗРДС) обов'язково має бути зазначено ЦФО (підрозділ). І залежно від зазначеного підрозділу, УВП «знаходить» відповідну йому точку погодження та «надсилає» заявку на погодження в цю точку.

Також у налаштуванні маршруту погодження допустимо не вказати підрозділ. У цьому випадку така точка узгодження буде «застосовується» для всіх ЦФО, для яких конкретно не вказана відповідна точка маршруту.

1. Саме погодження виконується за допомогою спеціальної обробки «Узгодження заявок»

1. Аналіз запланованої наявності коштів, графіка платежів та відстеження касових розривів виконується у звіті «Платіжний календар».

Крім запланованої витрати д/c (ЗРДС) можна враховувати і заплановане надходження д/c. Для цього передбачено оформлення спеціального документа «Плановане надходження д/c».

Потрібно зазначити, що в документі «Плановане надходження д/c» хоч і є стану (підготовлений, узгоджений тощо), але можливість узгодити цей документ (як і ЗРДС) відсутня. Тобто зміна статусу документа можлива тільки в режимі «ручного управління».

І ще в УПП є можливість враховувати заплановане надходження д/с від покупців без оформлення документів «Плановане надходження д/с».

Тобто, якщо для покупця оформляються «Замовлення клієнтів», то в окремому звіті «Платіжний календар з урахуванням замовлень» це заплановане надходження д/c можна буде побачити.

1. Крім звіту «Платіжний календар» передбачено звіт «Аналіз доступності коштів».

При цьому передбачено можливість резервувати д/c (за заявками на витрати) або розміщувати заявки у рахунок запланованих надходжень.

Також є функціонал закриття ЗРДС і запланованих надходження д/c. Для цього в режимі «звичайного клієнта» передбачені документи «Закриття заявок на витрачання/надходження д/c».

Однак, ця функціональність також не підтримується в режимі тонкого/web-клієнта.
Тут слід розуміти, що методика «жорсткого резервування» сильно зав'язана на хронологію введення документів, і це ускладнює коригування та перепланування.

Тому функціональність залишена в УПП скоріше як «спадщина минулого», а для аналізу доступності д/c слід застосовувати платіжний календар.

Отже, функціональні можливості УПП розглянули і тепер я перерахую ті моменти типової конфігурації, які практично, на проектах, доводиться доопрацьовувати:

1. За документом «Заявка на витрачання д/c»:
   1. У документі можна зазначити «Підрозділ» (до речі, у конфігурації воно позначене як ЦФО – центр фінансової ответственности). Але цілком можлива ситуація, коли заявка оформляється від одного підрозділу (ЦФО), і при цьому витрати потрібно буде віднести/розподілити на інше/інші підрозділи (ЦФУ – центри фінансового управління).

      Можливість вказувати ЦФУ тощо. - Відсутня.

      Можливість змінювати маршрут, перенаправляти заявку на інші маршрути – відсутня.

1. Відсутня можливість запланувати переміщення д/c між розрахунковими рахунками, з рахунки в касу та інше.
1. Процес узгодження:
   1. Існує можливість узгоджувати ЗРДС, але немає можливості узгоджувати плановане надходження д/с.
   2. Насправді виникає необхідність виконувати узгодження інших працівників. При цьому в системі потрібно фіксувати ще й інформацію про те, хто і за кого виконав узгодження.

      Варіант із встановленням в одній точці узгодження кількох можливих виконавців часто не годиться, тому цей виконавець може бути зазначений і на інших етапах узгодження. В результаті це все призведе до того, що в списку заявок на погодження у співробітника з'являться одночасно і основні і непрямі завдання за погодженням. Звісно, ​​це заплутує користувача, це не зручно.

      Резюмуючи – можливість узгоджувати за іншого виконавця, можливість вказати хто та за кого має право узгоджувати – відсутня.

   3. У процесі погодження заявок, коли заявка переходить на погодження наступного маршруту, затребувана функціональність автоматичного інформування (по e-mail) наступного виконавця, а також автора заявки.
   4. Якщо автор заявки вже є відповідальним за узгодження/затвердження (на будь-якому з етапом маршруту!), то цілком логічно щоб програма автоматично «зменшувала» маршрут, переадресую заявку на найвищий, доступний рівень. Проте, в СРП це не передбачено.
   • Всі перелічені вимоги, хоч і відсутні в типовій конфігурації, проте .

1. Звіти, права доступу.
   1. Затребувана можливість обмеження доступу до заявок лише за доступними авторами/виконавцями (погодниками); за доступними користувачем підрозділами.
   2. Відсутня звітність з контролю (щодня та інтервали) фактичної та запланованої заборгованості. Це актуально і для покупців, і для постачальників.
   3. Звітність та частина функціоналу не придатні до роботи в режимі тонкого/web-клієнта.
2. Облік за регулярними угодами, договорами.
   1. Часто трапляються ситуації, коли необхідно регулярно здійснювати оплату постачальникам. Наприклад, орендні платежі тощо.

      В УПП не автоматизовано відображення у платіжному календарі тощо. цих майбутніх витрат. Тобто необхідно в режимі ручного управління відстежувати такі платежі та оформлювати заявки на платіж, що незручно та трудомістко.

   2. У договорах з покупцями, з постачальниками можуть бути прописані умови щодо відсотка передоплати, за термінами оплати тощо.

      В УПП не автоматизовано облік усієї цієї інформації та (як наслідок) автоматичне відображення її у платіжному календарі.

3. Можливості УТ 11.1

З виходом нової конфігурації «Управління торгівлею ред.11» з'явилося багато нових, корисних можливостей із завданням оперативного планування та контролю фінансів.
Мабуть, найістотніше у цій частині в УТ11 (проти УПП 1.3) – це механізм обліку графіка платежів. Цей механізм якраз «закриває» те, чого не вистачало – автоматизація планування/обліку за регулярними угодами, договорами.

Таким чином, в УТ11 можна взагалі не оформляти (якщо немає необхідності, звичайно) документи планування витрати та надходження д/c, і при цьому платіжний календар нормально формуватиметься.

Можна скасувати, що «типові налаштування» звіту «Платіжний календар» не дуже відповідають очікуванням (як такий календар не відображається), але в режимі користувача можна додати угруповання за «датою платежу» і звіт сформується у звичному вигляді.

Функціональність звіту сильно розширилася (проти УПП 1.3) з допомогою використання системи компонування даних. Тепер звіт можна формувати в тонкому/web-клієнті, зберігати в базі та призначати різним користувачам потрібні налаштування.

Крім планування витрати та надходження д/с в УТ11 з'явилася функціональність планування переміщення д/c. Для цього можна оформляти документи «Розпорядження на переміщення д/c».

Порівняно з УПП 1.3 для документа «Заявка на витрачання д/c» збільшилася кількість видів господарських операцій, що враховуються:

З'явилася можливість затверджувати документи «Заявка на витрачання д/c», так і інші розпорядження:

Для аналізу заборгованості за інтервалами/термінами передбачено звіт «Дебіторська заборгованість». За потреби можна сформувати і календар заборгованості. Для цього в режимі користувача слід додати угруповання за датами оплати.

На жаль, в УТ11 (як і раніше) не передбачено можливості аналізу календаря заборгованості за постачальниками. Проте, доопрацювати УТ11 з цього завдання.

Резюмуючи: нові методологічні рішення «1С» разом із можливостями платформи 8.2 надають хорошу базу для автоматизації завдань оперативного планування та контролю д/c.

Але разом з тим слід розуміти, що конфігурація УТ11 не є повноцінним, готовим рішенням для автоматизації казначейства та планування д/c.

• По-перше, в УТ11 у дуже спрощеному вигляді реалізовано механізм узгодження/затвердження заявок на витрату та ін. документів планування д/c. Тобто немає механізмів маршрутизації, процес затвердження заявок зведений до простої встановлення статусів.
• По-друге, в УТ11 немає підсистеми бюджетування та (як наслідок) немає функціоналу контролю заявки із запланованих бюджетів.

4. Можливості WA: Фінансист

Історично конфігурація "WA: Фінансист" була розроблена на базі продукту "Управління казначейством".

І при цьому, до нового рішення «Фінансист» від компанії WiseAdvice входять ще:

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

Розглянемо основні функціональні можливості «WA:Фінансист» у частині казначейства – від урахування умов за договорами до формування платіжного календаря.

1. У процесі затвердження заявки можна не тільки узгодити/відхилити документ (як це зроблено в УПП), але доступні інші функції: наприклад, відправити документ на доопрацювання, або запросити дод. інформацію.

   Весь цей процес автоматизовано, відповідно передбачено звітність про стан відпрацювання узгодження документа.

5. Підсумки

Висновки:

1. Для автоматизації роботи фінансових департаментів, казначейств, організацій із складною орг. структурою найбільш відповідним рішенням є «WA:Фінансист».

   Дане рішення розвивалося та еволюціонувало тривалий час, відповідно акумулювало специфіку та вимоги різних фін. департаментів та казначейств. Загальні трудовитрати на розробку рішення становили понад 5000 чол/год.

   Перевагою рішення «WA:Фінансист» є розвинена функціональність та велика кількість механізмів налаштувань програми. Таким чином, впровадження цього рішення можливе в короткий термін (т.зв. «коробкове впровадження»), без доп. розробок, програмування та ін.

   Так як у рішенні закладено механізми двостороннього обміну з усіма основними типовими конфігураціями, то інтеграція в існуючу структуру (обмін даними з базами УТ, УПП, Комплексна, Бух) буде не складною.

2. Для автоматизації фін.департаменту/казначейства у рамках проекту комплексної автоматизаціїнайкраще підійдемо рішення на базі УВП.

   При цьому потрібно розуміти, що функціональність УПП вимагатиме доробок.

   Специфіка, вимоги фін. Департаментів, казначейств закладені в УПП не так глибоко, як це зроблено в окремих, спеціалізованих рішеннях.

   Таким чином, запровадження УПП за цими завданнями слід виконувати лише у рамках проекту автоматизації.

3. Для великих організацій, для автоматизації департаменту казначейства УТ11не підходить.

   У цьому рішенні, по-перше, відсутні механізми узгодження/затвердження документів планування.

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

   Однак, УТ11 відмінно підійде дляавтоматизації (в т.ч. оперативного планування д/c) невеликих фін. відділів компаній.

Надіслати цю статтю на мою пошту

У бухгалтерському обліку Рахунок на оплату в 1С є документом, який організація пред'являє покупцю за поставлений товар або надану послугу з метою інформування про необхідність внесення коштів.

У 1С представлено два варіанти роботи з рахунками на оплату в 1С:

Як документ, що зберігається в базі та відповідна йому друкована форма. Він призначений для контролю взаєморозрахунків з покупцями у системі та виведення відповідної інформації на паперовий носій.

Друкована форма Рахунки на оплату, що формується із замовлення клієнта чи документа реалізації та потрібна для відправки покупцю. Роздрукувати її можна у будь-який момент часу, а так само виведену на екран форму можна зберегти на свій ПК у будь-якому форматі.

Який із вищеперелічених варіантів застосовуватиметься залежить від значення константи Використовувати рахунки на оплату клієнтам і встановлюється воно у розділі НДІ та Адміністрація → Продаж → Оптовий продаж → Рахунок на оплату.

Документ Рахунок на оплату 1С 8.3

Створення рахунку в 1с 8.3 можливе шляхом введення нового з Реєстру торгових документів, а також введенням на підставі, за дотримання деяких умов

За замовленням клієнта, якщо:

У ньому обрано договір із порядком взаємодії За замовленнями;

У ньому договір не потрібен, але в угоді вказано порядок розрахунків на замовлення.

Рахунок на оплату в 1С створюється на підставі реалізації товарів та послуг якщо:

Використовується договір, у якому визначено порядок за накладними;

Договір не потрібен, але в угоді прописані правила розрахунків за накладними.

Рахунок 1С 8.3 може бути створений на підставі будь-якого з вищезгаданих документів, за умови, що правила взаєморозрахунків з клієнтом за договорами.

При створенні рахунок на оплату 1С 8.3, за даними будь-якого із зазначених об'єктів, призначене робоче місце «Створення рахунків на оплату», відкривається воно у списку за командою Створити на підставі.

Тут представлено дві робочі закладки: Етапи та оплати та Рахунки на оплату. Кожна передбачає свої реквізити та виконує певні функції.

На першій відображаються всі заплановані платежі, передбачені за графіком оплати.

Пояснимо, про який графік йдеться. В угоді з клієнтом, чи вона індивідуальна чи типова, можна встановити графік платежів, відповідно до якого необхідно фіксувати в інформаційній системі надходження коштів.

Для графіка оплати вказується найменування та заповнюється список етапів. Для кожного етапу графіка оплати визначається варіант оплати (аванс, передоплата чи кредит), оплата (безготівкова чи готівкова), відсоток від загальної суми (всього всіх рядків має дорівнювати 100%), відстрочка (зсув у днях від дати продажу).

Наведемо приклад. Для клієнта встановлено умови взаємодії: для відвантаження продукції за заявкою покупець повинен внести передоплату у розмірі 50% від суми цієї заявки, решта має бути оплачена протягом 5 днів після відвантаження. Усі платежі здійснюються через касу.

Заповнення даних виглядає так:

Деталізація: На замовлення;

Форма оплати: Готівкова;

Варіанти оплати: передоплата (до відвантаження) 50% та кредит (після відвантаження) 5днів 50%

Згідно з графіком, встановленим в угоді, автоматично розраховуються етапи оплати в самому документі (Замовлення клієнта або Реалізація товарів та послуг). За потреби їх можна скоригувати вручну за посиланням у полі Оплата та перенести до документа, не змінюючи даних у довіднику.

Прапори в першій колонці закладки встановлюються автоматично у рядків, за якими треба оформити рахунок на оплату. Якщо плату по рядку вже здійснено (внесено до бази платіжних документів), то рядок стає не активним і в колонці «Оплачено» відображається сума, що вже надійшла. Створюється рахунок натисканням кнопки однойменної кнопки. При цьому буде створено новий проведений рахунок, інформацію в якому буде заповнено відповідно до даних документа підстави та суми, що підлягає оплаті. Він відобразиться у списку рахунків на наступній вкладці «Рахунки на оплату» у стані Виставлений.

Новий рахунок у 1С містить таку інформацію:

У шапці: на підставі чого виставлено, коли, кому та від кого;

В Етапах оплати відображаються форма оплати, банківський рахунок та/або каса та графік оплати;

Додатково вказуються менеджер, керівник, головний бухгалтер, заповнюється призначення платежу та за необхідності вноситься додатковий текст для виведення до друкованого бланку;

У Коментар можна ввести інший довільний текст для зручності роботи користувача.

Усі створені рахунки на оплату 1С 8.3 доступні у списку рахунків у розділі «Продажі». Переглянути всі виставлені рахунки по об'єкту розрахунків можна за допомогою звіту «Пов'язані документи», і відкрити їх безпосередньо зі звіту, натиснувши на відповідні рядки звіту.

Вивести друковану форму за проведеним рахунком у 1С можна у будь-який момент за допомогою команди «Друк», так само можливе групове виведення кількох виділених рахунків.

Друкована форма Рахунок на оплату 1С 8.3

Формування тільки друкованої форми Рахунок на 1С 8.3 без зберігання її в базі, доступне з наведених нижче об'єктів системи:

Із замовлення клієнта, при дотриманні наступних умов:

У ньому використовується договір з деталізацією розрахунків на замовлення;

Договір не потрібен, але в угоді варіант розрахунків на замовлення.

З реалізації товарів та послуг у разі якщо:

Використовується договір, у якому взаєморозрахунки здійснюються за накладними;

Договір не потрібен, але в угоді вказується деталізація за накладними.

Рахунок 1с 8.3 може бути сформований за даними будь-якого з наведених вище документів, якщо в них застосовується порядок розрахунків За договорами.

Так само для рахунків у 1С реалізовано можливість виведення рахунку з факсиміле. Для цього в картці організації в налаштуваннях друку має бути доданий факсимільний друк (методика додавання доступна за посиланням «Як створити факсиміле?»). Роздрук такого рахунку на оплату в 1С здійснюється за командою Друк вибором відповідного пункту меню.

Бізнес-процес «Узгодження та затвердження заявок на витрачання коштів»

В умовах стабільного фінансового стану підприємство здатне повністю і вчасно виконувати свої зобов'язання - у такому разі, підприємство не потребує оптимізації витрачання коштів. В даний час, в умовах фінансової кризи, механізм розподілу дефіцитних коштів за зобов'язаннями підприємства є особливо актуальним.

Процес складається із шести послідовних етапів:

1. Представник підрозділу (менеджери, інженери, тощо) оформляє заявку на витрачання коштів за зобов'язаннями - авансами за договорами та погашення заборгованості за розрахунковими документами.

2. Керівник підрозділу за допомогою зручних інструментів перевіряє заявки на коректність та, за необхідності, коригує їх.

3. Відповідальний представник фінансової служби (фінансовий директор, заступник фінансового директора або керівник організації) визначає, з яких розрахункових рахунків, кому та в якому обсязі мають бути перераховані кошти.

4. Керівник підрозділу розподіляє дозволені для оплати суми за конкретними заявками (фактично за зобов'язаннями - замовленнями, рахунками, розрахунковими документами).

5. Бухгалтерія підприємства на підставі затверджених та розподілених на зобов'язання заявок створює вихідні платіжні доручення.

6. Платіжні доручення автоматично вивантажуються у клієнт-банк.

Оформлення заявок на витрачання коштів

Оформлення операцій із витрачання коштів із розрахункових рахунків завжди починається з планування витрати коштів - тобто оформлення заявок на витрачання всіма задіяними у процесі підрозділами підприємства.

Кожна служба підприємства оформляє заявку на витрачання коштів залежно від призначення витрати (кожному призначенню витрати відповідає певний вид операції у документі «Заявка на витрачання коштів»). Як призначення витрати, у разі авансових платежів, може бути вказано замовлення постачальнику, а разі погашення боргу - розрахунковий документ.

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

Формування заявки на витрачання коштів здійснюється за допомогою документа "Заявка на витрачання коштів".

Рис.1.

Перевірка підготовлених заявок

Керівник підрозділу перевіряє список оформлених підлеглими заявок на витрачання коштів, коригує та відправляє на затвердження до фінансової служби. Для затвердження заявки на витрачання коштів оформляється документ «Твердження заявок», до якого підбираються невиконані документи «Заявка на витрачання коштів».

Рис.2.

У результаті після перевірки та коригування керівник підрозділу підтверджує, що оформлені заявки узгоджені та готові до розгляду фінансовою службою.

Рис.3.

Затвердження заявок фінансовою службою

Після того, як кожна служба підготувала - оформила в системі - заявку на витрачання коштів, фінансовий директор або призначений їм відповідальний приймає рішення про їхню оплату (повну або часткову) у цей день. При цьому рішення може прийматися як за кожною окремою заявкою, так і за сукупністю їх за певною ознакою - наприклад, щодо оплати певному контрагенту (або за певним договором контрагента), або погоджується бюджет на заявки служби цілком.

Рис.4

При прийнятті рішення про витрати коштів необхідно вказати з якого розрахункового рахунку їх відправити. При розгляді заявок фінансовий директор бачить залишки коштів за розрахунковими рахунками (з урахуванням планованих надходжень та раніше затверджених платежів) на закладці «Залишки за рахунками». Проводячи документ, фінансовий директор затверджує обсяги коштів, які можна розподілити на заявки на витрачання коштів по службі.

Рис.5.

Розподіл затверджених платежів за заявками на витрачання коштів.

Керівник підрозділу з допомогою документа «Розподіл заявок» розносить затверджені загалом службі чи безпосередньо по контрагентам суми на підібрані ним заявки на витрачання коштів.

Рис.6

Якщо затверджений обсяг за заявкою менш ніж планувався, то на залишкову суму автоматично створюється заявка на витрачання коштів, яка може бути подана керівником підрозділу для затвердження фінансовою службою в інший день.

За допомогою набору аналітичних звітів, співробітники підрозділу можуть аналізувати запланований, затверджений і виконаний обсяг сплат і зобов'язань підрозділу, що залишилися, перед контрагентами.

Оформлення операцій із фактичному витраті коштів.

Після того, як заявки на витрачання коштів пройшли процес узгодження з фінансовим директором, фінансовий відділ бухгалтерії на підставі затверджених заявок, вводить документ «Платіжне доручення вихідне». При цьому у документі «Платіжне доручення вихідне» всі необхідні поля заповнюються автоматично, бухгалтер вказує призначення платежу (для друкованої форми платіжки) та проводить документ «Платіжне доручення вихідне» без позначки «Оплачено».

Створені та проведені платіжні доручення із 1С імпортуються до системи «Клієнт-банк».

На другий день у міру надходження виписки з банку про скоєні операції бухгалтер у кожному платіжному дорученні вказує позначку «Оплачено», а також вводить в систему операції з витрат коштів, які банк списав з розрахункового рахунку в безакцептному порядку - оформляє документи «Платіжний ордер: списання коштів» та «Платіжна вимога отримана». У разі, якщо у безакцептному порядку списано кошти на користь контрагентів, відповідним службам необхідно підібрати той розрахунковий документ контрагента, за яким здійснено оплату та виконати закриття заявки на витрачання, якщо вона була раніше оформлена.

Звірити оформлені операції з витрат грошових коштів протягом дня з випискою можна з допомогою типової обробки «Виписка банку». У типовій обробці «Виписка банку» фахівець може проконтролювати, залишок початку, прихід, витрата, залишок кінець дня у кожному банківському рахунку організації у межах документів. Якщо з друку видно, що документ був оплачений частково, то користувач може прямо з обробки оформити часткову оплату.

Тільки після проведення документів щодо витрати коштів з ознакою «Оплачено» у системі проводиться списання коштів з рахунків та змінюється стан розрахунків із контрагентами.

Варіанти конфігурацій

Рішення призначене для програмних продуктів «1С: Управління виробничим підприємством 8» та «1С: Управління торгівлею 8».

Вартість робіт

Визначається індивідуально з особливостей конфігурації Замовника.

Документ "Заявка на платіж" є основним інструментом підсистеми керування заявками на платежі. Цей документ дозволяє реєструвати у програмі потребу перерахування готівкових чи безготівкових коштів постачальникам, співробітникам, податковим органам та іншим контрагентам. Крім цього, функціоналом документа забезпечується процедура погодження та затвердження кожної зареєстрованої заявки на платіж.

Робота з документом ведеться у журналі заявок на платежі. Доступ до журналу здійснюється через пункт головного меню "Заявки на платежі" "Журнал заявок на платежі", а також через пункти панелі керування робочих столів програми.

Опис форми документа "Заявка на платіж"

Форма документа "Заявка на платіж" містить характеристики (реквізити), які розкривають призначення платежу, що реєструється. У верхній частині форми розташовується блок основних реквізитів, що визначають організацію, ЦФО, вид коштів та інші обов'язкові характеристики заявки. Закладка "Призначення платежу" містить список реквізитів, які дозволяють вказати суму та детально охарактеризувати призначення платежу. Крім цього існують три закладки, що містять додаткову інформацію про планований платеж: "Супровідні документи", "Платежі" та "Проходження заявки".

Форма документа "Заявка на платіж"

Основні реквізити

Перелік основних реквізитів:

• Термін оплати - крайня дата, до якої необхідно сплатити заявку;
• Операція - платіжна операція, що визначає вид розрахунків із контрагентом. Реквізит є обов'язковим для заповнення;
• Стаття ДДС - , що класифікує реєстровану заявку на платіж відповідно до прийнятого в організації класифікатора статей. Реквізит є обов'язковим для заповнення;
• Організація - компанія, у якій зареєстровано заявку. При введенні нового документа реквізит автоматично набуває значення «Основної організації» з персональних налаштувань користувача (вказується у формі елемента довідника «Користувачі»). Реквізит є обов'язковим для заповнення;
• ЦФО - структурна одиниця підприємства (відділ, підрозділ, департамент), відповідальна за взаєморозрахунки з контрагентом – одержувачем коштів;
• Ініціатор – фізична особа, яка є ініціатором угоди, що реєструється на оплату. Реквізит є додатковою характеристикою заявки та використовується як критерій відбору в журналах та звітах підсистеми;
• Спосіб оплати - визначає пріоритетний спосіб оплати заявки (готівка або безготівка). При введенні нового документа реквізит набуває значення «Безготівкові»;
• Коментар – рядок довільно коментаря до заявки, що реєструється, на платіж;
• Відповідальний користувач, який зареєстрував документ заявки у програмі. Реквізит заповнюється автоматично та недоступний для редагування.

Закладка "Призначення платежу"

Під час реєстрації документа на закладці «Призначення платежів» необхідно заповнити такі реквізити:

• Контрагент – юридична або фізична особа, яка є одержувачем коштів, заповнюється із довідника "Контрагенти". Реквізит є обов'язковим для заповнення;
• Договір - договір з контрагентом, у межах якого необхідно перерахувати кошти;
• Сума платежу;
• Ставка ПДВ;
• Сума ПДВ, що входить до суми платежу;
• Валюта коштів;
• Призначення платежу– рядок призначення платежу, визначальна предмет угоди, тобто. внаслідок чого потрібно перераховувати кошти. Призначення платежу може бути сформоване автоматично;
• Номер документа заснування- номер документа, що є підставою для заявки (наприклад, номер рахунку на оплату, номер накладної тощо);
• Дата документу заснування- дата документа, що є основою заявки;
• Документ підстава- Рядок інформації, що характеризує первинний документ, отриманий від контрагента і є підставою для перерахування коштів. Якщо основою платежу є рахунок на оплату, характеристики документа заповнюються вручну. Автоматичне заповнення цього реквізиту відбувається під час введення заявки виходячи з документа постачальника (накладної, акта виконаних робіт та інших первинних документів, зареєстрованих у 1С:Бухгалтерії);

Закладка "Супровідні документи"

Закладка "Супровідні документи" містить табличне поле, призначене для прикріплення до заявки на платіж усіх необхідних супровідних документів, наприклад договорів, додаткових угод, рахунків на оплату, сертифікатів, специфікацій тощо. Документи, що прикріплюються, повинні являти собою електронні документи довільного формату. При записі заявки всі зазначені на закладці документи зберігаються в інформаційній базі, що забезпечує збереження цих документів та можливість швидкого доступу до них безпосередньо з форми заявки.

Заявка на платіж: закладка "Супровідні документи"

Список доступних реквізитів:

• Найменування документа- найменування документа, що прикріплюється. При додаванні файлу документа в поле автоматично підставляється ім'я файлу. За потреби користувач може змінити вказане значення;
• Тип документа – тип прикріпленого документа. Це поле недоступне для редагування і автоматично заповнюється при виборі файлу;

Можливість вести платіжний календар у 1С 8.3 та 8.2 є у кількох типових конфігураціях:

• 1С Бухгалтерія підприємства 8.3 (3.0)
• 1С Управління виробничим підприємством
• 1С ERP Управління підприємством 2.0
• 1С Комплексна автоматизація
• 1С Управління торгівлею 11 та 10.3
• 1С Управління невеликою фірмою

Платіжний календар реалізовано як звіту (рис.1).

У звіт виводяться дані про планові надходження, витрати і залишки ДС. Інформацію можна деталізувати до первинних документів (рис.2).

Приклад роботи з платіжним календарем у 1С Управління торгівлею

Розглянемо приклад для конфігурації 1С Управління торгівлею 11 та нові можливості, які з'явилися в останніх версіях.

Насамперед необхідно виконати налаштування. Для цього розділ «Адміністрування — Організації та кошти» включає прапорець «Заявки на витрачання коштів» (рис.3). В інших версіях цей прапорець можна знайти в розділі "Казначейство".

У цьому розділі можна налаштувати контроль лімітів з організації загалом чи кожному підрозділу.

Після налаштувань у розділі «Фінанси» з'являється розділ «Планування коштів» (рис.4). В інших версіях може бути розділ «Казначейство».

Введемо кілька заявок на витрати. Цей документ є ключовим в організацію оперативного контролю руху ДС. Розглянемо його докладніше (рис.5).

Отримайте 267 відеоуроків з 1С безкоштовно:

Насамперед, необхідно вибрати операцію документа. У прикладі це «Перерахування податку». Від обраної операції залежить. Програма підкаже користувачеві, яку статтю можна використовувати у тому чи іншому випадку (список статей буде відфільтровано залежно від операції).

Оскільки в установках включено контроль лімітів, програма заблокувала проведення документа. Щоб затвердити таку заявку, потрібно або включити прапорець «Над лімітом», або збільшити ліміт за цією статтею.

Ліміти задаються у документі «Ліміти витрати коштів» (рис.6). Період задається не на момент формування заявки, а на момент запланованої оплати. У прикладі заявка проводиться липнем, але ліміт встановлюється на серпень.

Документ «Заявка на витрати ДС» має декілька статусів:

• Не погоджено
• Узгоджено
• До оплати
• Відхилено.

Усі неузгоджені заявки можна побачити у журналі «Заявки на витрачання ДС до погодження» (Мал.7). Затверджувати заявки зручно прямо із цього списку.

Тепер сформуємо платіжний календар та оцінимо ситуацію.

На рис.8 подано звіт на серпень 2016 року. У ньому червоним відзначено касові розриви. За заявкою №ТДЦУ-000003 04.08.2016 потрібно сплатити придбання основного засобу, але грошей на цю дату не вистачає.

На відміну від платіжного календаря ранніх версій (рис.1), зараз з'явилася можливість прямо зі звіту сформувати документи переміщення або планових надходжень ДС.

На рис.9 бачимо документ «Очікуване надходження ДС», сформований за кнопкою «Надходження» прямо з платіжного календаря. Щоб закрити касовий розрив, необхідно правильно вибрати статтю ДДС та планову дату надходження.