×
Показано с 1 по 3 из 3
  1. #1

    Обновление правленной бухгалтерии 454 релиза

    Проблема №1.
    В бух.базу за несколько лет из внешнего источника загружались проводки по субсчетам 19 счета.
    В компании до 2009 года велся учет по НДС и ЕНВД, причем ЕНВД выделить юридически было нельзя (торговые залы работали по ЕНВД, но юридически относились к подразделению с НДС). Известно было процентное соотношение закупок и продаж в рамках подразделения на торговый зал и основную деятельность. Для выделения ЕНВДшной части и последующего переброса сумм,попадавших на 19-й счет по ЕНВД, на 41 счет, счета 19.1, 19.2, 19.3 были сделаны группами и введены субсчета 19.1.1 - НДС, 19.1.2 - ЕНВД, 19.2.1,19.2.2, 19.3.1, 19.3.2 аналогично.
    Соответственно, НДСные субсчета обрабатывались как положено, а с ЕНВДшных все тупо сливалось назад (насколько я поняла).
    С 2009 года ЕНВД в компании нет, и учет НДС ведется на 19.1.1,19.2.1,19.3.1 - ну и дальше по субсчетам 19.4 и т.д., которые в данной ситуации не важны.
    Вопрос: возможно ли и, если да, то как грамотнее и проще избавиться от ненужной ступеньки и вернуться на 19.1,19.2,19.3?
    Варианты есть, но нет достаточной бухгалтерской подготовки, чтобы понять, какие будут наименее болезненны.
    Обрезать на начало 2009 года с переносом данных на промежуточный счет и удалением ненужных субсчетов и пересозданием 19.1,19.2,19.3,19.4 как обычных субсчетов (не групп)? Боюсь - времени в обрез до закрытия квартала, база древняя, может умереть при обновлении.
    Оставить как есть, откорректировав везде обращение к субсчетам 19 как к 19.1.1,19.2.1,19.3.1? Единственное безболезненое решение,какое вижу - но оно увеличивает время на очередные обновления базы, там и так много правок. При таком раскладе обрезка, если без нее не обойтись, пойдет в конце года из современного релиза, времени на нее будет побольше.
    Не пытаться обновлять существующую полусбойную базу, а перекачать из нее все данные в чистую базу нового релиза с учетом правильных субсчетов? Точно знаю, что будут сбойные документы, которые не перекачаются, где-нибудь за 2005-2006 годы (база живет с 2003 года).
    Есть ли еще какие-то варианты решений?
    Заранее благодарна за подсказку...!)
    Поделиться с друзьями

  2. #2
    Клерк Аватар для Dinchik
    Регистрация
    14.11.2008
    Сообщений
    3,360
    Не пытаться обновлять существующую полусбойную базу, а перекачать из нее все данные в чистую базу нового релиза с учетом правильных субсчетов? Точно знаю, что будут сбойные документы, которые не перекачаются, где-нибудь за 2005-2006 годы (база живет с 2003 года).
    Если перекачать в чистую для Вас не проблема, то качайте в чистую сразу остатки на начало года и документы только этого года, с учетом новых субсчетов 19.1, 19.2 и т.д.

  3. #3
    Во-первых, спасибо за реакцию и хорошего Вам дня!) Но... Это решение было бы самым простым и очевидным, не требуй бухи сохранить базу целиком...
    Похоже, единственно, что я сейчас смогу - тупо по всему коду отследить эти счета + еще пару вилок, в т.ч. по 41 счету, дать им возможность работать с существующими субсчетами, обновиться до текущего релиза, в конце года все же дожать их до нормальной обрезки, и тогда уже перекачать все на нормальные счета...
    Хорошо хоть, что после Нового Года шеф, как выяснилось, делал выгрузку-загрузку (база SQL-я), так хоть глюки мне грозят в меньшем объеме...

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)