Вимоги до проведення документів

Див. також

1. Документи призначені для введення первинної інформації, пов’язаної з реєстрацією подій, що впливають на показники, які обліковуються в системі. Наприклад, під час автоматизації фінансово-господарської діяльності підприємства – це облік різних господарських операцій; у системах управління виробничими процесами – реєстрація виробничих операцій тощо.

2.1. Реєстрація події в системі (тобто відображення її в обліку) виконується за допомогою проведення документа. Більшість документів мають проводитися (властивість Проведення встановлено у значення Дозволити).

Логічно, непроведений документ відрізняється від проведеного тим, що непроведений документ є «чернеткою», не відображеною в обліку. Такі документи можуть бути збережені в системі, навіть якщо вони не повністю або взагалі не заповнені; до них не застосовуються жодні перевірки та обмеження бізнес-логіки (перевірки заповнення, дат заборони зміни тощо). Дані таких документів не відображаються в обліку (не виводяться у звітах тощо)

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

2.2. Якщо життєвий цикл документа складається з кількох етапів, які відповідають етапам певного процесу, то для опису цих етапів у документа можуть бути введені додаткові статуси. Наприклад, документ «Замовлення клієнта» може мати статуси: «не погоджено», «до забезпечення», «закрито»; документ «Видатковий касовий ордер» – спочатку зареєстрований у журналі реєстрації касових ордерів (КО-3), потім підписаний головним бухгалтером (керівником), переданий до каси, потім зареєстрований у Касовій книзі, підписаний головним бухгалтером (керівником).

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

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

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

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

2.3. Виняток із цього правила («більшість документів мають проводитися») становлять

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

Такі документи не проводяться.

2.4. У разі якщо користувач має виконувати реєстрацію події в системі та відображення її в обліку за одну дію, необхідно записувати новий документ у режимі проведення.

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

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

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

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

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

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

3.3. Непроведені та позначені на видалення документи не повинні мати активних рухів.

3.4. Навіть якщо документ не формує рухів, він має проводитися, щоб логічно відрізнятися від «чернетки».

4. Для більшості подій відображення в обліку може бути оборотним. У такому разі для цього слід використовувати механізм скасування проведення документів.

Див. також

• Імена об’єктів метаданих у конфігураціях
• Порядок запису рухів документів
• Самодостатність регістрів