После разделения баз я вычищаю дебиторов и кредиторов, которых уже давно не существует. База меньшего размера работает быстрее.
Не хочу делить базы -не делю, никто не заставляет.

Юля, тут разговор о том, что именно заставляют. По другому прога просто не работает.

Не понимаю, почему прога заставляет? Каким образом это происходит? И в какой момент? Надеюсь не 31 декабря в 24:00?

Я вообще против насильственных действий со стороны программы

Про момент спроси тех, кто на таких прогах работает.... А визуально это выглядит, как куча иконок на рабочем столе. Одна иконка-один год..

Фантазия слабовата.

Ерунда это всё:
Главное в программе - наличие покупателей.
Есть покупатели - есть программа.
Нет покупателей - нет программы.
Лучшая программа - текстовый редактор (начиная, по-моему, с Edit) и электронные таблицы (начиная с Lotus). Всё остальное - от лукавого.
Главное в любом продукте - спрос.
Жалко, на VGK пропал перечень программ. Их было более десятка.

p.s. Лучшая программа - забыл про самое главное: фантазия бухгалтера.

Привет, девчёнки! Я вернулся!..

Основываясь на своем тыщелетнем опыте работы по внедрению бух.программ ответственно заявляю в связи с сабжем следующее - разделение баз данных не нужно и бесполезно. При условии, что пользователь не меняет кардинально методику учета и нет необходимости для чего-то скрыть старую информацию (кривые данные, например). Среди моих клиентов на предыдущем месте работы большинство не прибегало к разделению ни разу, многие хранят данные за 10-12 лет. Думаю, что будут хранить еще столько же.

Обосновываю.

1. Скорость. Размер базы, конечно, влияет на скорость обрабокти данных. Но при правильно спроектированной структуре, это влияние совсем не линейно. Например, при 100 документах некий часто востребованный отчет считается пару миллисекунд, при 100000 это уже десять секунд, при 1000000 будет, допустим, 13 секунд. То есть за год или за 10 у тебя данные - отчеты считаются в приемлемое веря. Цифры иллюстративные.

2. "Старая" аналитика. Нет разницы в том, что пользователь не видит старые записи в аналитике или их физически нет в базе данных. Кроме того, даже если некий клиент существует в списке и виден и с ним не было операций десять лет, это никак не влияет на поиск актуальных клиентов.

3. Удобство. Это банально удобно, когда легко доступны старые года и возможна отчетность за несколько лет "на одном экране".

4. Переход на Евро. А вот тут не могу стопроцентно ничего утверждать о бесполезности открытия новой пустой базы с 2014 года. Поясню. Арифметически переход на евро достаточно тривиален - нужно просто пересчитать все движение к новой учетной единице по курсу на 31.12.2013 и куда-то засунуть разницу округлений.

То есть теоритически достаточно скопировать базу со всей историей и поменять цифры. Но, к сожалению, народное творчество нашего СГД никто не отменит и я боюсь представить, какие будут указания по переходу на евро - все мертвые математики начнут ворочаться в гробах, А живые рвать волосы на соседях, не говоря о программистах...

Соглашусь с Макссофт, что городить огород, чтобы система умела динамически менять учетную единицу ради одного случая за 20 лет не имеет смысла, хотя и интересно с академической точки зрения. Наверное, я это сделаю у себя, вдруг пригодится

Этого делать нельзя IMHO, предыдущий период до евро должен быть актуальным и привязанным к лату. Поменять цифры нужно только во входящих остатках на 2014 год. От СГД не будет указаний, нечего указывать, тоже IMHO.

База данных в латах останется доступной. Тогда как вся информация в евро доступна в рабочей БД за всю историю. Конечно, уровень головной боли у пользователей немного повысится.

Да, неправильно это как-то. Вообще, с точки зрения пользователя должно быть так:
1. Никаких перекодировок быз данных и дополнительных архивов.
2. Никаких ошибок округления быть не должно.
3. Хочу - смотрю в евро, хочу в латах, причем программа автоматически устанавливает отчетную валюту , основываясь на дате окончания периода для каждого конкретного отчета.

Это достаточно сложно в реализации. У меня оценка работы для реализации этого функционала примерно 70-90 часов. Не уверен, что окупится, принимая во внимание изначальную нехватку этих самых часов... Хотя...

Зачем? Вся история до 2014 года никогда не была в евро, а Вы её хотите сделать? Я считаю, что каждый период должен быть актуальным, это значит до 2014 года основная валюта - лат, после 2014 - евро. Выдумывать ничего не нужно.
Если Вы хотите какие-либо сравнительные аналитические отчёты последующих и предыдущих периодов, то это к бухучёту не имеет никакого отношения.

История была в учетной денежной единице, такой и остается.

Ой, не мне, новичку, Вас учить, что этим бухгалтера и занимаются, и еще миллионом дел, не имеющим прямого отношения к бухучету. Вообще бух.программы, имеющие отношение только к бух-учету не особенно и интересны

Кроме того, например. "А когда это мы последний раз платили тому-то и такому-то и сколько вообще заплатили за всю жизнь?" Вопрос не имеющий прямого отношения к бухучету, но требующий ответа, желательно только движением мышки. (правда, часто на этот вопрос бухгалтера отвечают вообще без движениями чем либо, а просто по памяти. Всегда восхищался!)

Ответ на приведённый Вами в пример вопрос имеет отношение к бухучёту IMHO, добывается движением мышки, но не имеет никакого отношения к "проблеме перехода на евро".

Латы + евро = непоймичто. Или я тоже не понимаю, как может быть, что данный отчет НЕ имеет НИкакого отношения к переходу на €.

не делайте " непоймичто", делайте правильные отчёты, если не знаете как, учитесь