Бухгалтерський та оперативний облік в різних базах

За рік в середньому виходить мінімум 3-5 оновлень. При оновленні конфігурації, всі раніше внесені правки затираються, потім їх треба відновлювати вручну.

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

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

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

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

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

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

В оперативному обліку ситуацій, коли треба перепровести минулий період купа, особливо при розробці нового функціоналу.

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

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

Багато одночасно працюючих користувачів в одній базі - це не дуже классно. З часом це призведе до блокувань і сповільнить роботу системи.

Розмір бази буде зростати і вона буде ставати повільнішою. В залежності від кількості документів її потрібно буде раз в 3-5 років різати, переносити залишки і починати вести облік з чистого аркушу в новій базі. Отримати аналітику за 5 років буде неможливо.

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

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

Якщо вести облік в 2-х базах, в регістрах бух. обліку в оперативній базі теоретично можна в майбутньому організувати управлінський фін. облік.

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

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