Регістр накопичення або регістр бухгалтерії?

1. Питання паралельності роботи системи
2. Питання швидкості роботи
3. Порівняння часу виконання рухів по регістрах різного виду (Реєстр бухгалтерії, регістр накопичення...
4. Порівняння часу виконання запитів по регістрах різного виду (Реєстр бухгалтерії і регістр накопичення...
5. Порівняння часу виконання запитів по регістрах іншого виду (Реєстр бухгалтерії і регістр накопичення...
6. загальні висновки

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

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

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

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

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

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

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

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

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

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

Питання паралельності роботи системи

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

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

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

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

Питання швидкості роботи

Для порівняння часу, що витрачається платформою 1С на роботу з регістрами різних типів, були проведені експерименти.

Для проведення описуваного тесту був створений спеціальний документ «Документ для контролю часу рухів регістрів» і розроблений функціонал, який записує в окремий регістр час виконання системою дій, що вимагають контролю. Тест проводився на основі типової конфігурації «1С: Бухгалтерія 8 КОРП» версії 2.0.8.2, на платформі 1С 8.1.15.14,, використовувався клієнт-серверний варіант (64-розрядний сервер 1С, СУБД - Microsoft SQL Server 2008).

Тест складався з 3 частин:

• Порівняння часу виконання рухів по регістрах різного виду (реєстр бухгалтерії, регістр накопичення виду «обороти», регістр накопичення виду «залишки»);
• Порівняння часу виконання запитів по регістрах різного виду (реєстр бухгалтерії і регістр накопичення виду «обороти»);
• Порівняння часу виконання запитів по регістрах іншого виду (реєстр бухгалтерії і регістр накопичення виду «залишки»).

Порівняння часу виконання рухів по регістрах різного виду
(Реєстр бухгалтерії, регістр накопичення виду «обороти», регістр накопичення виду «залишки»)

Документ для контролю часу рухів регістрів при проведенні по черзі формував записи в регістри трьох різних типів:

• Регістр бухгалтерії Госпрозрахунковий Дт 62.01 Кт 90.01.1, вся аналітика заповнена;
• Типовий оборотний регістр накопичення ПДВ Продажі (назва в метаданих - НДСЗапісіКнігіПродаж);
• Спеціально створений реєстр ПДВ Продажі_Остаткі (назва в метаданих - НДСЗапісіКнігіПродажОстаткі), ідентичний типовому регістру НДСПродажі за складом вимірювань і ресурсів, але він має тип «Залишки».

Регістр ПДВ продажу обраний, тому що за даними досить добре відповідає кореспонденції Дт 62.01 Кт 90.01.1 (виручка від продажу послуг).

Перед контрольним виміром документи були перепроведени по 2 рази.

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

Загальна кількість записів в регістрах на момент тестування - Госпрозрахунковий і ПДВ Продажі - по 270 000, ПДВ Продажі_Остаткі - 250 000.

Документ проводився оператором вручну.

Показники виконання:

Документ Процедура Показати # в документі Час виконання, з Документ для контролю часу рухів регістрів 1 Проведення по регістру
НДСПродажі 0,016 Проведення по регістру
НДСПродажі Залишки 0,015 Проведення по регістру
Госпрозрахунковий 0,046 РАЗОМ 1 0,077 Документ для контролю часу рухів регістрів 10000 Проведення по регістру
НДСПродажі 4,899 Проведення по регістру
НДСПродажі Залишки 4,743 Проведення по регістру
Госпрозрахунковий 48,703 РАЗОМ 10000 58,345 Документ для контролю часу рухів регістрів 20000 Проведення по регістру
НДСПродажі 8,331 Проведення по регістру
НДСПродажі Залишки 8,253 Проведення по регістру
Госпрозрахунковий 68,499 РАЗОМ 20000 85,083

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

Порівняння часу виконання запитів по регістрах різного виду
(Реєстр бухгалтерії і регістр накопичення виду «обороти»)

Документ для контролю часу рухів регістрів, проведений заздалегідь, по черзі запрошував дані про своїх власних рухах по регістрах:

• Регістр бухгалтерії Госпрозрахунковий, заповнений тільки даними, необхідними для тестування;
• Типовий оборотний регістр накопичення ПДВ Продажі.

Тексти запитів:

Загальна кількість записів в регістрах на момент тестування - Госпрозрахунковий і ПДВ Продажі - по 270 000.

З форми документів (Документ для контролю часу рухів регістрів), оператором послідовно викликалися 4 описаних вище запиту.

Показники виконання:

Документ Процедура Показати # в документі Час виконання, з Документ для контролю часу рухів регістрів 1 Запит по регістру
ПДВ продажу 0,141 Запит по регістру
ПДВ продажу
Віртуальна таблиця Обороти 1,450 Запит по регістру
госпрозрахунковий 0,141 Запит по регістру
госпрозрахунковий
Віртуальна таблиця Обороти 0,234 РАЗОМ 1 1,966 Документ для контролю часу рухів регістрів 10000 Запит по регістру
ПДВ продажу 0,468 Запит по регістру
ПДВ продажу
Віртуальна таблиця обороти 0,468 Запит по регістру
госпрозрахунковий 0,390 Запит по регістру
госпрозрахунковий
Віртуальна таблиця Обороти 2,824 РАЗОМ 10000 4,150 Документ для контролю часу рухів регістрів 20000 Запит по регістру
ПДВ продажу 0,936 Запит по регістру
ПДВ продажу
Віртуальна таблиця обороти 0,874 Запит по регістру
госпрозрахунковий 0,765 Запит по регістру
госпрозрахунковий
Віртуальна таблиця Обороти 5,523 РАЗОМ 20000 8,098

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

Порівняння часу виконання запитів по регістрах іншого виду
(Реєстр бухгалтерії і регістр накопичення виду «залишки»)

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

• Регістр бухгалтерії Госпрозрахунковий, заповнений тільки даними, необхідними для тестування;
• Спеціально створений регістр накопичення ПДВ Продажі Залишки, за даними відповідний аналітиці кореспонденції Дт 62.01 Кт 90.01.1 (виручка від продажу послуг).

Тексти запитів:

Загальна кількість записів в регістрах на момент тестування - Госпрозрахунковий і ПДВ Продажі Залишки - по 250 000.

З форми документів (Документ для контролю часу рухів регістрів), оператором послідовно викликалися 6 описаних вище запитів.

Показники виконання:

Документ Процедура Час виконання, з Документ для контролю часу
рухів регістрів Запит по регістру
ПДВ продажу _ Залишки 0,202 Запит по регістру
ПДВ продажу _ Залишки
таблиця Залишки 8,986 Запит по регістру
ПДВ продажу _ Залишки
таблиця Залишки і обороти 11,466 Запит по регістру
госпрозрахунковий 0,390 Запит по регістру
госпрозрахунковий
таблиця Залишки 13,557 Запит по регістру
госпрозрахунковий
таблиця Залишки і Обороти 35,193 РАЗОМ 69,794

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

загальні висновки

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

ГК Трейд Софт, Москва
Автор: Філіппов О.В.
Дата публікації: 07.12.2010 р