Коллега пишет, что при обновлении проводки Главной Книги разорвалось соединение с интернетом и часть проводки попала в Главную книгу, а часть осталась в дневном журнале и проводка в нём теперь не балансируется. Знакомая проблема? Нет, нет, нет, мы не будем сейчас обсуждать, что по-хорошему, программа должна была использовать транзакции SQL сервера и тогда такого бы не произошло. Будем исходить из того, что есть.
Первое, что я делаю в такой ситуации, сверяю сумму по той части проводки, которая уже попала в Главную Книгу (за исключением статистических счетов, конечно же) с суммой того, что не попала. Они должны совпадать, только знаки у них должны быть противоположными. В моём случае они не совпали: одна строка уже попала в ГК, но из журнала не удалилась. Значит это нужно сделать «вручную».
Второе: завожу «подставной» бухгалтерский счёт (балансовый):
Он мне нужен для того, чтобы забалансировать «порванную» проводку, оставшуюся в журнале.
Балансирую этим счётом «порванную» проводку так, чтобы её сумма стала равна нулю.
Проводку отправляю в Главную Книгу.
Нахожу в Главной Книге (в таблице GL06) строку проводки с «подставным» счётом. Удаляю эту строку.
Нахожу в таблице сальдо (GL52) запись с «подставным счётом». Удаляю эту запись.
Удаляю карточку «подставного» счёта.
Вот так, без всяких там вульгарных выкриков типа: «кошелёк или жизнь» добиваемся того, что требуется.
Можно, конечно, пойти другим путём, но там больше всяких но. Например, если использовать системную утилиту «реконструкция сальдо», то это нужно всех «выгонять» из системы…
Кстати, если у Вас включена непрерывная консолидация, то в принимающей компании после отправки «порванной» проводки в Главную книгу в журнале Главной книги надо найти строку с «подставным» счётом и тоже её удалить
А вы как поступали, если вдруг такое когда-то случалось? :)))
