План счетов устанавливается государством или над-государственными органами. Его структура проста:
1. Номер счёта;
2. Наименование счёта.
3. Номер основного счёта (только для субсчетов)
Можно добавить поле для комментариев.
Предприятие может, следуя рекомендациям, вводить свои субсчета.

Аналогично, государство устанавливает корреспонденцию счетов:
1. Дебет-счёт;
2. Кредит-счёт.
Может быть добавлено поле для комментариев.
Предприятие может добавить свои проводки для субсчетов и ограничить использование установленных государством корреспондирующих счетов. Поэтому, можно добавить логическое поле, как флаг допускающий/запрещающий конкретный вид проводок на данном предприятии. Можно поступить иначе, введя дополнительную таблицу допустимых видов проводок для данного предприятия, эта таблица будет простым подмножеством корреспонденций, плюс проводки по субсчетам.

Далее, есть типы документов, которые подлежат бухгалтерскому/налоговому учёту. Перечень этих типов документов может меняться.
Есть документы, подлежащие учёту, и позиции этих документов.

Типы документов:
1. Обозначение типа документа;
2. Название типа документа.

Документы:
1. Идентификатор документа:
2. Тип документа
3. Номер документа;
4. Дата документа;
5. Организация источник документа;
6. Основание документа;
7. Сумма по документу;
8. Сумма с учётом налогов;
9. ...

Позиции документов:
1. Идентификатор позиции;
2. Ссылка на документ;
3. Номер позиции в документе;
4. Содержание позиции (например, наименование материалов);
5. Количество;
6. Цена;
7. Сумма;
8. Общая сумма с учётом налогов;
9. ...

Далее необходимо учитывать налоги, которых может быть много, и ставки которых меняются со временем. Какие-то налоги могут отменять, какие-то вводить.
Виды налогов:
1. Идентификатор налога;
2. Обозначение налога;
3. Название налога;
4. Дата введения;
5. Дата отмены;
6. Описание.

Ставки по налогам:
1. Идентификатор ставки;
2. Ссылка на вид налога:
3. Размер ставки в %;
4. Размер ставки (номинальный);
5. Описание.

Налоги по документам:
1. Ссылка на документ;
2. Ссылка на ставку налога;
3. Сумма налога;
4. Обоснование.

Налоги по позиции документов:
1. Ссылка на позицию;
2. Ссылка на ставку налога;
3. Сумма налога;
4. Обоснование.

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


Проводки
id date accd analitcoded1 analitvalued1 analitcoded2 analitvalued2 analitcoded3 analitvalued3 ... acck analitcodek1 analitvaluek1 analitcodek2 analitvaluek2 analitcodek3 analitvaluek3 ...566765 05.07.2021 123123 1 org_id 2 contr_id 3 doc_id ...
Для ускорения работы делают денормализацию и хранят № счетов в проводках, чтобы можно было делать запросы like '60.1%'
Не надо делать денормализацию... Это плохо сказывается в последствии, IMHO.

Самое главное, как всегда... забыл :)

Таблица проводок:
1. Дебетовый счёт;
2. Кредитовый счёт;
3. Ссылка на позицию документа;
4. Сумма проводки;
5. Исполнитель проводки;
6. Дата и время проводки.

Дебетовый и кредитовый счета - это ссылка на таблицу корреспонденции счетов.
Первичный (уникальный) ключ составляют первые три поля.

Почему? Установка партии?

А если подумать?... Можно сделать любое количество проводок, по разным парам дебет-кредит. А вот по одной и той же паре, сделать более одной проводки позиции документа на самом деле нельзя. Это ограничение придумано не мной.

Так это весьма удобно и информативно. К тому же я указал, что можно не первичный ключ, если религия запрещает, но ограничение уникальности всё равно делать надо. Плодить или не плодить ограничения - выбор каждого. Споры о суррогатных ключах - давняя история, и каждый волен решать для себя сам, что использовать.

Во-первых, потребность в JOIN резко сокращается, во-вторых, есть USING.

Смех без причины...

За счёт того, что не надо соединяться с первичными таблицами, чтобы разыменовывать каждое поле внешнего ключа.
Ну, представьте, что нам нужно сформировать "главную книгу" или "книгу продаж"... В предложенной модели, мы просто проходим по таблице проводок и всё, никаких соединений делать не надо. Если же таблицы имеют суррогатные ключи, то надо соединяться с таблицей Счетов, чтобы выбирать только те счета, которые нужны. По ID счёта невозможно сказать, какой счёт за ним стоит, да, и про сам ID, пользователи ничего не знают. И это касается практически всей бухгалтерской аналитики.

У меня диаметрально противоположный опыт. Работать с базами данных на естественных ключах, намного удобнее, в том числе и при написании запросов. Очень известный человек в области БД Joe Celko написал работу: «Data & Databases: Concepts in Practice», The Morgann Kaufman Series in Data Management Systems (ISBN 978-1-55860-432-2 ). Он имеет огромный практический опыт, вел колонки в известных журналах посвященных БД, где разбирал самые разные примеры и давал ценные практические советы. Был активным участником авторских коллективов разработчиков SQL-89 & SQL-92. Он и в своей книге и во множестве прочитанных им лекций детально разбирал мифы, связанные с использованием суррогатных ключей. Если есть желание, то можете почитать. Вести же религиозные споры просто не имею желания. Я привёл модель бухгалтерской системы, по запросу автора топика, а использовать её или нет, какие ключи ему использовать, путь он решает сам. Вести дальнейшее обсуждение темы СК vs. ЕК я не хочу.

Нет, я привел модель, а потом мне начали "не советовать", как мне делать не надо.

А пальчиком ткнуть можно?

Нет, здесь всё правильно, ссылка именно на корреспонденцию. На план счетов ссылаться нельзя, поскольку тогда могут заводить любые, в том числе, и недопустимые проводки. А так внешний ключ из двух полей позволяет ссылаться только на то, что разрешено законом/нормативами.
Нет, "клинить" не будет, работает очень шустро, проверено десятками лет, на разных предприятиях под разными версиями Firebird. Индекса только два (дебет-кредит и позиция документа). Иногда добавляют индексы по дате-времени, реже по исполнителю. Вообще, схема очень компактная по размерам.

Забыто...

Про отсутствие головы на плечах, я ничего не говорил. Есть предметная область, её надо исследовать, до того как, а не апосля.

Пример приведён выше. Любые комментарии приветствуются.

Что такое "бюджетная классификация"?

Вы пытаетесь выдать свои представления, которые "внезапно" оказались неверными за знание предметной области. Классификаторы, действующие на территории Российской Федерации, входят в Единую систему классификации и кодирования (ЕСКК), созданной по постановлению Правительства в 1970-х годах. Это целиком относится и к бухгалтерскому учёту, к правилам кодирования счетов. Написанием бухгалтерских систем, я впервые занялся в 80-х годах. Отчётные формы меняются достаточно часто, например, с 01.07.2021 г. в очередной раз изменились счёт-фактура и УПД, но структура системы остаётся неизменной. И если проектирование БД делалось не со слов "тёти Маши", то... никаких "внезапно" не происходит.

Так обращайтесь к этому разработчику. Ещё раз спрашиваю, к представленной модели вопросы, замечания, комментарии есть? Обсуждать тему ключей я не имею желания.

Это поле строковое (VARCHAR(15)). Дело в следующем, субсчета могут иметь символьные обозначения (не запрещено); а также, когда проектировалась бухгалтерия, был явный тренд по переходу на МФО, где нечисловые символы применяются широко.

Вы не поверите, номера счетов во всех бухгалтериях одни и те же :)

Уважаемы оппоненты, религиозные войны, вещь занятная и весьма затратная. Всё, что вы пишите сегодня и помыслите написать завтра уже давно и многократно подробно рассмотрено, принято или опровергнуто. Многие очень неглупые люди и профессиональные разработчики, как сторонники, так и противники любой точки зрения, рассмотрели любые проблемы и предложили их решения. Кому интересно, может покопаться в интернете и найти ответы на свои вопросы. Сказать что-то новое в этой теме практически невозможно. Давайте не будем отнимать время друг друга пустой болтовнёй.