Вырученный остаток на счете за сохраненный остаток на счете для простого банковского счета?

Ответ 1

Предисловие

Аудиторские требования являются объективной истиной для систем бухгалтерского учета. Кроме того, при работе с государственными средствами существует законодательство, которое необходимо соблюдать.

Вам не нужно полностью выполнять требования бухгалтерского учета, вы можете реализовать только те части, которые вам нужны.

И наоборот, было бы нецелесообразно внедрять что-либо, кроме стандартных требований бухгалтерского учета (их частей), потому что это гарантирует, что, когда количество ошибок или нагрузка превысит некоторый порог, или система расширится, вам придется повторно внедрить, Стоимость, которую можно и, следовательно, следует избегать.

Также необходимо указать: не нанимайте неквалифицированного, не аккредитованного "аудитора". Последствия будут такими же, как если бы вы наняли неквалифицированного разработчика. Может быть и хуже, если налоговая инспекция оштрафует вас.

метод

Стандартный метод учета в не очень примитивных странах заключается в следующем. "Лучшая практика", если хотите, в других.

Этот метод применяется к любой системе, которая имеет аналогичные операции; потребностей; исторические месячные данные против требований текущего месяца, таких как контроль запасов и т.д.

рассмотрение

Во-первых, соображения.

1. Никогда не дублируйте данные. Если текущий баланс может быть получен (и здесь он прост), не дублируйте его с итоговым столбцом. Такой столбец является дублированием данных. Это нарушает правила нормализации. Кроме того, он создает аномалию обновления, которая в противном случае не существует.

2. Если вы используете итоговый столбец, то при каждом обновлении Транзакций (как при изменении, а не при вставке новой Транзакции) значение итогового столбца становится устаревшим, поэтому в любом случае его необходимо обновлять все время. Это является следствием Аномалии Обновления. Что исключает ценность его наличия.

3. Внешняя публикация. Если баланс публикуется, как в ежемесячной банковской выписке, такие документы обычно имеют юридические ограничения и последствия, поэтому опубликованное значение CurrentBalance не должно изменяться после публикации.

   • Любое изменение, после даты публикации, в базе данных, фигуры, которая публикуется извне, является свидетельством нечестного поведения, мошенничества и т.д.

     • Такой акт, пытающийся изменить опубликованную историю, является отличительной чертой новичка. Новички и психически больные будут настаивать на том, что история может быть изменена. Но, как все должны знать, незнание закона не является действительной защитой.

   • Вы бы не хотели, чтобы ваш банк в апреле 2015 года изменил текущий баланс, который он опубликовал в своей выписке по счету от декабря 2014 года.

   • Эта цифра должна рассматриваться как показатель аудита, опубликованная и не подлежащая изменению.

4. Любые необходимые исправления или корректировки вносятся как новые транзакции в текущем месяце, даже если они применяются к предыдущему месяцу. Это потому, что соответствующий месяц закрыт и опубликован, потому что нельзя изменить историю после того, как это произошло и было записано. Единственный действующий месяц - текущий.

   • Для процентных систем и т.д. В не очень примитивных странах, когда обнаружена ошибка, которая имеет исторический эффект (например, в апреле 2015 года вы обнаружили, что проценты, рассчитанные по ценной бумаге, были неверными, так как с декабря 2014), значение скорректированного платежа/вычета процентов рассчитывается сегодня для количества ошибочных дней, и сумма вставляется как транзакция в текущем месяце. Опять же, единственный эффективный месяц - текущий.

     И, конечно же, необходимо скорректировать процентную ставку по ценной бумаге, чтобы ошибка не повторялась.

   • Если вы обнаружили ошибку в расчете процентов в банке на вашем Сберегательном (процентном) счете и исправили его, вы получите один депозит, который составляет всю корректировочную стоимость, в текущем месяце. Это транзакция в текущем месяце.

     Банк не: меняет историю; применять проценты за каждый из исторических месяцев; вспомнить исторические банковские выписки; переиздать исторические банковские выписки. Нет. Возможно, за исключением стран типа Иди Амин.

   • Те же принципы применяются к системам управления запасами. Это поддерживает здравомыслие.

5. Все реальные системы бухгалтерского учета (т.е. Те, которые аккредитованы Аудиторским органом в соответствующей стране, в отличие от множества "пакетов" Микки Мауса), используют систему двойного ввода для транзакций именно потому, что она предотвращает массу ошибок, наиболее важным из которых является то, что средства не теряются. Это требует простой Главной книги.

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

6. Основные проблемы, влияющие на производительность, выходят за рамки этого вопроса, они касаются того, реализуете ли вы подлинную реляционную базу данных или нет (система хранения записей в контейнере базы данных SQL, типизированная идентификаторами).

   • Использование подлинных реляционных ключей и т.д. Будет поддерживать высокую производительность независимо от количества таблиц.

   • И наоборот, RFS будет работать плохо, они просто не могут работать. "Масштаб", когда он используется в контексте RFS, является мошенническим термином: он скрывает причину и стремится устранить все, кроме причины.

Реализация

1. Для каждой Учетной записи будет таблица ClosingBalance в таблице AccountStatement (одна строка на Учетную запись в месяц) вместе с StatementDate и другими деталями выписки.

   • Это не дубликат, потому что это требуется для целей аудита и здравомыслия.

     Для инвентаризации - столбец QuantityOnHand в таблице PartAudit (одна строка на деталь в месяц)

   • У него есть дополнительное значение, так как оно ограничивает объем строк транзакций, которые необходимо запрашивать в текущем месяце.

     • Опять же, если ваша таблица реляционная, первичным ключом для AccountTransaction будет (AccountCode, TransactionDateTime), который будет извлекать транзакции с точностью до миллисекунд.

     • Принимая во внимание, что для системы регистрации записей "первичным ключом" будет (TransactionID), и вы будете получать текущий месяц по TransactionDate, который может или не может быть проиндексирован правильно, а необходимые строки будут распределены по файлу. В любом случае, при гораздо меньшей скорости, чем ClusteredIndex, и там, где много извлеченных строк, выполняется сканирование таблицы.

2. Таблица транзакций остается простой (реальная концепция транзакции по банковскому счету проста). Имеет один положительный столбец Сумма.

3. Текущий баланс для каждой учетной записи:

   • Выписка. Баланс за предыдущий месяц

     (для инвентаря, PartAudit.QuantityOnHand)

   • плюс сумма Transaction.Amounts в текущем месяце, где TransactionType указывает депозит

     (для инвентаря Transaction.QuantityActed)

   • минус сумма Transaction.Amounts в текущем месяце, где TransactionType указывает на снятие

4. В этом методе только транзакции в текущем месяце находятся в состоянии изменения, поэтому они должны быть получены. Все предыдущие месяцы публикуются и закрываются, поэтому необходимо использовать показатель аудита.

5. Старые строки в таблице транзакций можно удалить. Старше десяти лет за государственные деньги, пять лет иначе, один год для систем хобби-клубов.

6. Конечно, важно, чтобы любой код, относящийся к учетным системам, использовал подлинные стандарты OLTP и подлинные транзакции SQL ACID.

7. Этот дизайн включает в себя все соображения производительности на уровне области (если это не очевидно, пожалуйста, попросите расширение). Масштабирование не является проблемой, теперь проблемы масштабирования находятся за пределами базы данных.

Корректирующий Совет

Эти пункты должны быть изложены только потому, что в SO Ответах были предоставлены неправильные советы (и за них проголосовали массы, конечно же, демократически), а в интернете полно неправильных советов (любители любят публиковать свои субъективные "истины" "):

1. Очевидно, некоторые люди не понимают, что я дал метод в технических терминах. Как таковой, это не псевдокод для конкретного приложения в конкретной стране. Метод предназначен для способных разработчиков, он недостаточно подробен для тех, кого нужно вести рукой.

   • Они также не понимают, что период сокращения в месяце является примером: если ваше сокращение для целей Налогового управления является ежеквартальным, то во всех случаях используйте квартальное сокращение; если единственное юридическое требование, которое у вас есть, это ежегодное, используйте ежегодное

   • Даже если ваше сокращение производится ежеквартально для внешних целей или в целях обеспечения соответствия, компания вполне может выбрать ежемесячное сокращение для целей внутреннего аудита и санитарии (т.е. Чтобы свести к минимуму продолжительность периода состояния потока),

     Например. в Австралии налоговая инспекция отключает предприятия ежеквартально, но более крупные компании ежемесячно прекращают контроль над запасами (это избавляет от необходимости выслеживать ошибки в течение длительного периода).

     Например. банки предъявляют требования о соответствии законодательству ежемесячно, поэтому они проводят внутренний аудит по показателям и закрывают бухгалтерские книги ежемесячно.

   • В примитивных странах и государствах-изгоях банки держат период своего состояния максимума в очевидных гнусных целях. Некоторые из них делают свои отчеты о соответствии ежегодно. Это одна из причин, почему банки в Австралии не терпят крах.

2. В таблице транзакций не используйте отрицательный/положительный в столбце Сумма. Деньги всегда имеют положительную ценность, нет такой вещи, как отрицательные двадцать долларов (или то, что вы должны мне минус пятьдесят долларов, а затем решаете, что двойные отрицания означают что-то еще).

3. Направление движения или то, что вы собираетесь делать с фондами, является отдельным и дискретным фактом (для Transaction.Amount). Для чего требуется отдельный столбец (два факта в одном элементе данных нарушают правила нормализации, вследствие чего он вносит сложность в код).

   • Реализуйте столбец TransactionType, который является (D, W) для ввода/вывода в качестве отправной точки. По мере роста системы просто добавьте (A, R, w, M) для корректировки, возврата, ATM_Withdrawal, Management_Fee и т.д.

   • Никаких изменений кода не требуется.

4. В некоторых примитивных странах судебные требования гласят, что в любом отчете, в котором перечислены транзакции, в каждой строке должен быть указан промежуточный итог. (Обратите внимание, что это не требование Аудита, потому что они превосходят [Метод выше] по сравнению с требованием суда; Аудиторы несколько менее глупы, чем юристы и т.д.)

   Очевидно, я бы не стал спорить с требованием суда. Проблема в том, что примитивные кодеры переводят это в: о, мы должны реализовать столбец Transaction.CurrentBalance. Они не понимают, что:

   • требование печатать столбец в отчете не является обязательным для сохранения значения в базе данных

   • Итоговый итог любого вида является производным значением, и его легко закодировать (напишите вопрос, если вам нелегко). Просто внедрите необходимый код в отчете.

   • реализация промежуточного итога, например. Transaction.CurrentBalance как столбец вызывает ужасные проблемы:

     • вводит дублированный столбец, потому что он выводим. Перерывы Нормализация. Вводит аномалию обновления.

     • Аномалия обновления: всякий раз, когда транзакция вставляется исторически или когда Transaction.Amount изменяется, все Transaction.CurrentBalances с этой даты по настоящее время должны пересчитываться и обновляться.

   • в вышеупомянутом случае отчет, который был подан для использования в суде, теперь устарел (каждый отчет онлайн-данных устарел с момента их печати). То есть. Распечатать; обзор; изменить транзакцию; Повторная печать; Пересмотрите, пока вы не будете счастливы. Это бессмысленно в любом случае.

   • вот почему в менее примитивных странах суды не принимают какую-либо старую печатную бумагу, они принимают только опубликованные данные, например. Банковские выписки, на которые уже распространяются требования аудита (см. Метод выше), и которые не могут быть отозваны или изменены и перепечатаны.

Ответ 2

Это довольно субъективно. Я бы посоветовал подумать:

• Сколько учетных записей существует в настоящее время?
• Сколько учетных записей вы ожидаете иметь в будущем?
• Какую ценность вы придаете масштабируемости?
• Насколько сложно обновить базу данных и код, чтобы отслеживать баланс как собственное поле?
• Есть ли более серьезные проблемы, связанные с развитием, к которым необходимо прибегать?

С точки зрения достоинств предложенных двух подходов суммирование значений транзакций по запросу, вероятно, будет более простым и быстрым в реализации подхода.

Однако он не будет масштабироваться, а также поддерживать баланс текущего счета в качестве поля в базе данных и обновлять его по мере поступления. И это несколько увеличивает время обработки транзакций, так как каждая транзакция должна запускать запрос для вычисления баланса текущего счета до его продолжения. На практике это могут быть небольшие проблемы, если у вас не очень большое количество счетов/транзакций или ожидается в самом ближайшем будущем.

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

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