mimic-iii数据库_财务会计应用程序数据库III：完成基础结构

mimic-iii数据库

介绍 (Introduction)

In the previous article , we discussed and implemented core accounting infrastructure design: general ledger, chart of accounts, (source) documents and financial statements structure.

在上一篇文章中 ，我们讨论并实现了核心会计基础结构设计：总帐，会计科目表，(原始)单据和财务报表结构。

This article will be dedicated to the finalization of accounting infrastructure design: company profile, person profiles, costs centres and all the other entities that are used across all of the specialized accounting documents.

本文将致力于会计基础结构设计的最终确定：公司资料，人员资料，成本中心以及所有专用会计凭证中使用的所有其他实体。

会计应用本地化 (Localization in Accounting Application)

Localization is usually defined as customization of an application for specific cultures or regions. Localization consists primarily of translating the user interface. However, in the financial accounting domain, we handle not only numbers and codes but also some amount of textual information. Fortunately, the amount of textual information is very limited. In addition, not nearly all of the textual information requires localization. E.g., there is no point in localizing data that is only meant for internal use like descriptions of documents, fixed assets, internal comments etc. Only the information that is (potentially) visible externally needs to be localized.

本地化通常定义为针对特定文化或地区的应用程序定制。 本地化主要包括翻译用户界面。 但是，在财务会计领域，我们不仅处理数字和代码，还处理一些文本信息。 幸运的是，文本信息的数量非常有限。 此外，并非几乎所有文本信息都需要本地化。 例如，对仅用于内部使用的数据进行本地化是没有意义的，例如文档说明，固定资产，内部注释等。仅需要对(可能)在外部可见的信息进行本地化。

Notably, there is a legal requirement for financial accounting that all of the accounting records and documents shall be kept in national language. (I believe it’s true for pretty much all of the jurisdictions) The common exceptions to the rule are the (source) documents issued by persons in other countries, e.g., you don’t need to translate an invoice issued by some German company. Which brings us to the requirement that all of the textual data should always exist in the national language of the company’s registration country. The localization of textual data in the financial accounting domain means providing extra textual data translated into the native/understandable language of the person that the data is meant for, i.e., you need to keep such data both in the national language and in the language required by the person involved.

值得注意的是，对于财务会计有一项法律要求，即所有会计记录和文件均应以本国语言保存。 (我相信几乎所有司法管辖区都是如此)。该规则的常见例外是其他国家/地区的人签发的(原始)文件，例如，您无需翻译某些德国公司签发的发票。 这使我们要求所有文本数据应始终以公司注册国的本国语言存在。 文本数据在财务会计领域中的本地化意味着提供额外的文本数据，将其翻译成该数据所针对的人的母语/可理解的语言，即，您需要以本国语言和要求的语言来保留此类数据由有关人员。

Having in mind the scope of the application we develop, localization will be required for the following documents:

考虑到我们开发的应用程序的范围，以下文件将需要本地化：

• Invoices made
  发票
• Pro forma invoice made
  备考发票
• Cash receipt
  现金收据

The document specific textual data and its regionalization will be handled by the documents themselves, i.e., within the tables that extend document table for specific document type. However, there is one common data piece for all of the documents – company’s data. Therefore, the company’s profile should be localizable, i.e., there should be:

文档特定的文本数据及其区域化将由文档本身处理，即在扩展文档表以用于特定文档类型的表中。 但是，所有文档只有一个通用数据-公司数据。 因此，公司的资料应该是可本地化的，即应该有：

• A common company’s profile that contains language agnostic data (company’s official name, various codes, id’s, emails, defaults, policies, etc.)
  包含语言不可知数据(公司的正式名称，各种代码，ID，电子邮件，默认值，策略等)的常见公司资料。
• A localized company’s profile for each language that the company uses (address, contact info, CEO title, etc.)
  公司使用的每种语言的本地化公司资料(地址，联系信息，首席执行官职位等)

Another common data piece for all of the localizable documents is person (profile). However, as you will soon see, there are no textual data within person profile that could reasonable require localization. Official names cannot be translated. Hardly anybody would require translating an original address in a foreign country. The rest of the person data is about various codes, ids and defaults that are not subject to translation. Therefore, there is no need to implement localization for a person profile.

所有可本地化文档的另一个通用数据是个人(个人资料)。 但是，正如您将很快看到的那样，个人资料中没有可以合理要求本地化的文本数据。 官方名称无法翻译。 几乎没有人需要在国外翻译原始地址。 其余人员数据涉及无需翻译的各种代码，ID和默认值。 因此，无需对人员资料进行本地化。

Actually, most of the companies use some billing or CRM systems to issue invoices as well as cash receipts. The data from such systems is then automatically transferred to the accounting system, typically via REST service. In such cases, localization of an accounting system is not required at all trivially because the international data is handled by other applications and an accountant only require textual data in the national language. However, we are also targeting a small business that at least to some extent uses accounting system for billing. Therefore – localization.

实际上，大多数公司都使用某些计费或CRM系统来开具发票和现金收据。 然后，通常通过REST服务将来自此类系统的数据自动传输到记帐系统。 在这种情况下，完全不需要琐碎的会计系统本地化，因为国际数据是由其他应用程序处理的，而会计只需要使用本国语言的文本数据即可。 但是，我们还针对至少在某种程度上使用会计系统进行计费的小型企业。 因此-本地化。

会计应用程序中的版本控制 (Versioning in Accounting Application)

In theory, every time a (source) document is received (or is issued) by an accountant, he shall record it and never change or delete it. In real life, typos happen all the time and accountants are not willing to do corrections in the right way by issuing adjustment documents like a credit note. This is especially true for small and medium business. So, the UD part of CRUD is technically illegal, but is a must for the target user group. For the very same reason, there is no such thing as document version in the accounting domain. If a particular company wants to use detailed audit trail, it can use extra solutions for it as discussed in the first article in this series (SQL server binary log, custom log with serialized documents, etc.). Most of the companies that we target will not want or need such a functionality. Notably, law rarely requires detailed audit trail. As we definitely do not target banks, insurance companies and other highly specific sectors, the solution with full CRUD and no (extensive) audit trail is perfectly acceptable for the target group (small to medium companies and their accountants).

从理论上讲，每当会计师收到(或发出)(原始)文件时，他应记录该文件，并且决不对其进行更改或删除。 在现实生活中，打字错误经常发生，会计人员不愿意通过发行调整文件(如贷方通知单)来正确地进行更正。 对于中小型企业尤其如此。 因此，CRUD的UD部分在技术上是非法的，但对于目标用户组是必须的。 出于同样的原因，在会计域中没有诸如文档版本之类的东西。 如果特定公司希望使用详细的审计跟踪，则可以使用本系列第一篇文章中讨论的其他解决方案(SQL Server二进制日志，带有序列化文档的自定义日志等)。 我们所针对的大多数公司都将不需要或不需要这样的功能。 值得注意的是，法律很少要求详细的审计线索。 由于我们绝对不针对银行，保险公司和其他高度特定的行业，因此具有完整CRUD功能且没有(广泛的)审计追踪的解决方案对于目标群体(中小型公司及其会计师)是完全可以接受的。

On the other hand, accounting domain does require some versioning let alone not exactly traditional. The reason is the relational model we use. Even though the documents data are self-sufficient, provides full details for a particular document. They do reference common model objects – persons’ and company’s profile. E.g., an invoice document model does not store full company’s profile data and persons (buyers) profile data, only reference the data in the common infrastructure tables. However, any document when printed or otherwise exported shall include the data that was relevant as of the date of the document. It could be achieved in two ways:

另一方面，会计域确实需要某些版本控制，更不用说不是完全传统的了。 原因是我们使用的关系模型。 即使文档数据是自给自足的，也可以提供特定文档的完整详细信息。 他们确实引用了常见的模型对象-人员和公司的个人资料。 例如，发票单据模型不存储完整的公司资料数据和人员(买方)资料数据，而仅引用公共基础结构表中的数据。 但是，任何文档在打印或以其他方式导出时，都应包含截至文档日期的相关数据。 它可以通过两种方式实现：

• By storing the common state in some serialized way within the document itself (snapshot) or
  通过以某种序列化的方式将公共状态存储在文档本身(快照)中，或者
• By providing different common state versions for all the periods
  通过为所有期间提供不同的通用状态版本

The first method has problems with the real world use cases. E.g., an accountant issued an invoice for some company and later got to know that the company’s name was already different/changed at the invoice date. If he changes the relevant person data in the common model, the changes will not be reflected in the document of the interest as it holds old common state snapshot. Therefore, we will need to provide some method to reset the snapshot or to require an accountant to delete the document and then enter it anew. In both cases, the implementation is going to be non-intuitive or/and inconvenient, which is not good.

第一种方法在实际使用案例中存在问题。 例如，一位会计师为某家公司开具了发票，后来又知道该公司的名称在发票日期已经不同/已更改。 如果他更改了通用模型中的相关人员数据，则该更改将不会反映在感兴趣的文档中，因为它包含旧的通用状态快照。 因此，我们将需要提供一些方法来重置快照或要求会计师删除文档然后重新输入。 在两种情况下，实现都将是非直觉的和/或不便的，这是不好的。

The second method perfectly meets the expectations of an accountant. If some data for some period is changed, an accountant can be sure that all the documents for the relevant period will catch up. Therefore, we’re going to use it. (For further discussion, see Best way to design a database and table to keep records of changes).

第二种方法完全可以满足会计师的期望。 如果某个时期的某些数据发生更改，会计可以确保相关时期的所有单据都将赶上。 因此，我们将使用它。 (有关进一步的讨论，请参阅设计数据库和表以保留更改记录的最佳方法 )。

The versioning method required is non-traditional in a way that any of the versions can be modified by an accountant whenever required (when an accountant gets to know about some changes). Conceptual winforms GUI could look something like that (for visualization only, fields are not actually well distributed as explained further!!!):

所需的版本控制方法是非传统的，因此会计可以在需要时修改任何版本(会计需要了解某些更改时)。 概念上的winforms GUI可能看起来像这样( 仅用于可视化，字段实际上分布不佳，如进一步说明！！！ )：

Actual version data will only be needed when a document is either printed or otherwise exported. So the business object implementing a document that requires versioning will require a method PrepareForPrint or similar to fetch (update) the versioned data. The SQL queries for that purpose will be as trivial as:

仅在打印或以其他方式导出文档时才需要实际版本数据。 因此，实现需要版本控制的文档的业务对象将需要使用PrepareForPrint或类似方法来获取(更新)版本控制的数据。 用于此目的SQL查询将很简单：

SELECT * FROM company_profile_versions v WHERE v. effective_date <= [document date] 
ORDER BY v.effective_date DESC LIMIT 1.

Company profile version data could be cached, as the data amount will be small. Person profile version data is more problematic. Expected amount of persons could be as large as several dozen thousands. If you add three versions on average per person that could add up to quite a large memory footprint. Though, those implementation details are not particularly relevant at this development stage. For now, it’s enough to define that each company or person profile shall have a list of versioned data with effective dates specified.

公司简介版本数据可能会被缓存，因为数据量很小。 人员配置文件版本数据存在更多问题。 预期人数可能多达数十万人。 如果您平均每人添加三个版本，这可能会占用相当大的内存。 但是，这些实现细节在此开发阶段并不特别相关。 到目前为止，只需定义每个公司或个人资料都应具有已指定生效日期的版本控制数据列表即可。

地址 (Addresses)

There are two issues about addresses that should be discussed:

有关地址的两个问题应加以讨论：

我们如何构造地址字段？ (How Do We Structure Address Fields?)

You can find various address structurizations on web. Most of them are country specific, e.g., US postal office defines those address fields: Street Number, Predirectional, Street Name, Street Suffix, Postdirectional, Secondary Unit Indicator, Secondary Number, PO Box Number, City, State, ZIP Code, ZIP+4 Code. Using a country specific address structurization for an accounting application is not a particularly good idea, as a significant part of the companies have vendors and clients in foreign countries, which have their own addressing schema. There are no international standards for address structure. In such cases, it’s not a bad idea to rely on the guys who have the largest dataset to test the ideas on, i.e., Google. Google for Android uses those address fields: label, street, PO Box, neighbourhood, city, region, postcode and country. Definitely, it looks better than trying to fit US address schema for Lithuania.

您可以在网上找到各种地址结构。 它们中的大多数是特定于国家/地区的，例如， 美国邮政局定义了以下地址字段：街道编号，预定向，街道名称，街道后缀，定向，二级单位指示符，二级编号，邮政信箱编号，城市，州，邮政编码，ZIP + 4个代码。 在会计应用程序中使用特定于国家/地区的地址结构并不是一个特别好的主意，因为这些公司中有很大一部分在国外拥有自己的地址架构的供应商和客户。 地址结构没有国际标准。 在这种情况下，依靠拥有最大数据集的人(例如Google)来测试想法并不是一个坏主意。 Google Android版会使用以下地址字段：标签，街道，邮政信箱，邻里，城市，地区，邮政编码和国家/地区。 无疑，它看起来比尝试适合立陶宛的美国地址方案更好。

However, our data hunger shall not outshine the expectations of our users – accountants. An accountant will be unable and unwilling to structure addresses in foreign countries (try for yourself to structure address like this: “ 65 moo.7 T. Ao-nang, Muang, Krabi (Phi Phi Don), 81210 Phi Phi Don, Thailand ”). Therefore, we cannot impose a burden of address structuring on an accountant. It could only exist as an option for addresses within the application home country. To sum it all up, we shall provide only optional address structurization and only specific to the home country of the application. In my case – Lithuania. Which brings us to the requirement to have a field for unstructured address, a country and a few optional country specific fields (in my case – for Lithuania): municipality, city, street and house number. One more thing, that could enchase analytics these days, is geo coordinates. It’s easy to plug into gmaps and let an accountant validate unstructured address as well as pick the address from a map. Therefore, why not add two decimal fields for longitude and latitude.

但是，我们的数据需求绝不会超出用户(会计师)的期望。 会计师将无法也不愿意在国外构造地址(尝试自己构造地址，例如：“ 65 moo.7 T. Ao-nang，Muang，Krabi(Phi Phi Don)，81210 Phi Phi Don，Thailand ” )。 因此，我们不能给会计师增加地址结构的负担。 它只能作为应用程序所在国家/地区内地址的选项存在。 综上所述，我们将仅提供可选的地址结构化，并且仅针对应用程序的母国。 就我而言–立陶宛。 这使我们要求拥有一个非结构化地址字段，一个国家和一些可选的国家/地区专用字段(在我的情况下–立陶宛)：市政，城市，街道和门牌号码。 如今，可以进行分析的另一件事是地理坐标。 插入gmap并让会计师验证非结构化地址以及从地图中选择地址很容易。 因此，为什么不为经度和纬度添加两个十进制字段。

Keep in mind that we are doing the address structurization not out of having nothing else to do. The value of structured addresses is analytics. We definitely won’t do any analytics with the company’s self-addresses. Therefore, fields for unstructured addresses will be sufficient for the company’s profile.

请记住，我们正在做地址结构化的工作并非没有其他事情要做。 结构化地址的价值在于分析。 我们绝对不会对公司的自我地址进行任何分析。 因此，非结构化地址的字段足以满足公司的要求。

每人需要多少个地址？ (How Many Addresses per Person Are Required?)

There are two types of addresses of an accountant’s interest – billing address and shipping address. Actually, the latter is often handled by CRM, warehouse or billing applications and not so often of interest for an accounting.

会计师感兴趣的地址有两种类型：帐单地址和送货地址。 实际上，后者通常是由CRM，仓库或开票应用程序处理的，而对于会计而言却不是那么重要。

The billing address is the one that is displayed on an invoice next to the client’s name. It can change, but it happens rarely. As we discussed in the section about versioning, it can be conveniently handled by the versions of a person profile. If the billing address changes at some moment, it shall and will affect the invoices, which dates are later than the change. E.g., if an accountant issued an invoice and then noticed that the billing address has changed, he can update person’s profile version and that will also update the invoice billing address, which is exactly what an accountant expects. The billing address is a legal field and might have some tax related implications. However, nothing really happens at the billing address. Therefore, its change in case of a mistake will still be reconcilable with the real world facts.

帐单地址是发票上显示在客户名称旁边的地址。 它可以改变，但很少发生。 正如我们在有关版本控制的部分中讨论的那样，人员个人档案的版本可以方便地处理它。 如果帐单地址在某一时刻发生更改，它将并且将影响发票，该日期晚于更改。 例如，如果会计师发出发票，然后发现帐单地址已更改，则他可以更新人员的个人资料版本，这也将更新发票帐单地址，这正是会计师期望的。 帐单邮寄地址是一个法律字段，可能会涉及一些与税收相关的问题。 但是，帐单地址上并没有真正发生任何事情。 因此，在发生错误的情况下进行更改仍然可以与现实世界相吻合。

The shipping address is the one where some goods or equipment are actually shipped. It only has meaning if something is physically shipped. It also describes a real world fact, i.e., it’s not just a legal field like the billing address. Therefore, it is always a part of an invoice factual description and consequently is stored within the invoice schema (for further discussion, see Storing a Shipping Address Best Practice ). Of course, it is convenient for an accountant to be able to pick a shipping address from a lookup instead of entering it manually for each invoice. However, the lookup values (addresses) in this case are only defaults. Once an invoice is saved, the value is copied to the invoice because it becomes a real world fact (while you cannot change real world facts by changing a profile). Therefore, shipping addresses do not require versioning.

送货地址是实际运送某些货物或设备的地址 。 它只有在实际运输某些东西时才有意义。 它还描述了一个现实世界的事实，即，它不仅是诸如帐单地址之类的合法字段。 因此，它始终是发票事实描述的一部分，因此存储在发票架构中(有关更多讨论，请参见存储送货地址最佳实践 )。 当然，对于会计人员来说，能够从查找中选择送货地址，而不是为每个发票手动输入送货地址，是很方便的。 但是，在这种情况下，查找值(地址)仅为默认值。 保存发票后，该值将被复制到发票，因为它成为真实世界的事实(而您无法通过更改配置文件来更改真实世界的事实)。 因此，收货地址不需要版本控制。

A company by itself (as a legal entity) always has only one billing address. As changing fact that is required to be presented in multiple languages, it belongs to a version of company’s regional profile.

一家公司本身(作为法人实体)始终只有一个帐单地址。 由于需要用多种语言显示的不断变化的事实，它属于公司区域概况的一个版本。

A company by itself could have multiple shipping addresses, i.e., it can ship goods from various locations. However, this concept is closely related to the warehouse concept for inventory operations. Therefore, we will deal with it in some later article about inventory operations.

一个公司本身可以有多个送货地址，即它可以从各个位置运送货物。 但是，此概念与用于库存操作的仓库概念紧密相关。 因此，我们将在以后的有关库存操作的文章中进行处理。

公司简介 (Company Profile)

To summarize the requirements for localization and versioning, we will need a total of four tables (entities) for company and person profiles:

总结本地化和版本控制的要求，我们将需要总共四个表(实体)用于公司和个人资料：

• company_regional_profiles – to store localized company data that does not require versioning, e.g., default values that are only used to prefill document fields with default values. The table will contain one row per language (at least one row for the base language).

  company_regional_profiles –用于存储不需要版本控制的本地化公司数据，例如，仅用于使用默认值预填充文档字段的默认值。 该表将包含每种语言的一行(基本语言至少一行)。

• company_regional_profile_versions – to store localized company data that does require versioning, e.g. company address

  company_regional_profile_versions –存储需要版本控制的本地化公司数据，例如公司地址

• company_profile – to store company data that does not require either localization or versioning, e.g., default values that are only used to prefill document fields with default values. The table will always contain only one row. (P.S. national ID as non-versioned field was a bad example, it can change although very rarely)

  company_profile –存储不需要本地化或版本控制的公司数据，例如，仅用于使用默认值预填充文档字段的默认值。 该表将始终仅包含一行。 (PS国家ID作为非版本字段是一个不好的例子，尽管很少更改，但可以更改)

• company_profile_versions – to store company data that does not require localization but does require versioning, e.g., company name, email, phone no, CEO name, etc.

  company_profile_versions –存储不需要本地化但需要版本控制的公司数据，例如公司名称，电子邮件，电话号码，CEO名称等。

We will also need two more helper entities (tables) that logically belong to the company profile:

我们还将需要另外两个逻辑上属于公司资料的帮助实体(表)：

• default_accounts – As discussed in the previous article, some business functionality, e.g., balance sheet presentation requires knowledge about some (default) company accounts that the company uses for specific purposes, e.g., retained revenues account. The list of such default accounts depends heavily on the business layer implementation and is likely to change. Therefore, it’s not a good idea to provide a separate field for each default account type. Besides, we also have to support the application extensions, which are likely to require their own default accounts. For these reasons, the default account types are defined as an enumeration with an extension point like we previously did for (source) document types. As I didn’t foresee the requirement for default account type extensibility in the first article in the series, we will implement it now.

  default_accounts –如上一篇文章所述 ，某些业务功能(例如资产负债表表示)需要了解公司用于特定目的的一些(默认)公司帐户，例如保留收入帐户。 此类默认帐户的列表在很大程度上取决于业务层的实现，并且可能会发生变化。 因此，为每种默认帐户类型提供单独的字段不是一个好主意。 此外，我们还必须支持应用程序扩展，这些扩展可能需要其自己的默认帐户。 由于这些原因，默认帐户类型被定义为带有扩展点的枚举，就像我们之前对(源)文档类型所做的那样。 由于我没有预见该系列第一篇文章中对默认帐户类型可扩展性的要求，因此我们现在将其实现。

• company_regional_templates – one of the localization objects is a template that the company uses for its “external” documents, e.g., an invoice template. Specific template format depends on the reporting engine the application uses. However, it is not of importance from the database point of view, as a template is always a file, i.e., BLOB. The extra table requirement is due to the data type and for extensibility. The BLOB fields for templates could be added to the company_regional_profile_versions table, but such approach would complicate the database. First of all, templates do not change as frequently as other localizable data. Whenever we add a new version of localizable data, we duplicate the fields that do not actually change. It’s ok for small fields taking into account that there won’t be many entries in company_regional_profile_versions table. But the templates can be as large as 100 – 500 kB each. We definitely do not want to duplicate that much data when the company’s address got changed. Another reason to use a separate table is extensibility. It’s likely that some application extension could have its own documents that are meant for external users, e.g., a specific kind of invoice, and therefore require localization. As I didn’t foresee the requirement for template type extensibility in the first article in the series, we will also implement it now.

  company_regional_templates –本地化对象之一是公司用于其“外部”文档的模板，例如发票模板。 特定的模板格式取决于应用程序使用的报告引擎。 但是，从数据库的角度来看，它并不重要，因为模板始终是文件，即BLOB。 额外的表要求是由于数据类型和可扩展性。 模板的BLOB字段可以添加到company_regional_profile_versions表中，但是这种方法会使数据库复杂化。 首先，模板不像其他本地化数据那样频繁地更改。 每当我们添加可本地化数据的新版本时，我们都会复制实际上未更改的字段。 考虑到在company_regional_profile_versions表中不会有太多条目的小字段也可以。 但是每个模板的大小可以高达100 – 500 kB。 我们绝对不希望在公司地址更改后重复那么多数据。 使用单独的表的另一个原因是可扩展性。 某些应用程序扩展可能具有自己的文档(例如，特定类型的发票)供外部用户使用，因此需要本地化。 由于我在本系列的第一篇文章中没有预见到模板类型可扩展性的要求，因此我们现在也将实现它。

Now we can summarize all of the requirements and my personal experience about the commonly used profile fields with the following company profile schemas (relevant portions per profile type):

现在，我们可以使用以下公司配置文件模式(每种配置文件类型的相关部分)来总结关于常用配置文件字段的所有要求和我的个人经验：

表company_profile详细信息 (Table company_profile Details)

Fields	Description
base_country	An ISO 3166 code of the country that the company is a resident for. Should not be changed after the company is created because companies cannot move to another jurisdiction by themselves. It’s a foreign key for the country_codes table and restricts updates and deletes of this country code. Actually, the restriction is the main purpose of this field, as it’s not very feasible that an accounting application could support many jurisdictions without major impact on usability. If a particular RDBMS does not support tables without primary keys, the field could also be used as a primary key.
base_currency	An ISO 4217 code of the base currency that is used for accounting. Should not be changed after the company is created because this kind of change brings us to the situation when there are two base currencies within a single database. Which is extremely difficult to calculate and support. The recommended method on such a rare occasions (e.g., introducing EUR) is to create a new company database and only move converted balances. While the old database is left for historic reference. It’s a foreign key for the currency_codes table and restricts updates and deletes of this currency code.
base_language	An ISO 639-2 code for the base language that is used in the accounting. Should not be changed after the company is created because that wouldn’t translate the old textual data by itself. The recommended method on such a rare occasions (I cannot even imagine such) is to create a new company database and only move balances. While the old database is left for historic reference.
establishment_date	A date that the company was established on. Obviously, cannot change (unless a typo).
default_description_invoice_made, default_description_invoice_received	A default descriptions of an invoice. The descriptions are only used to autofill the description field (as defaults), which is only for internal use. Therefore, its change has no impact for any old invoices. The reason why they are used instead of a separate table with default descriptions per document type is that in real life use cases, they are the only ones that do not require customized description (at least in my experience supporting an accounting application).
default_measure_unit_invoice_received	A default measure unit in an invoice received. It is only used to autofill the measure unit field (as a default), which is only for internal use. Therefore, its change has no impact for any old invoices.
default_sales_vat_schema_id, default_purchases_vat_schema_id	Default VAT schemas applied for new invoices. They are only applied as defaults. Therefore, their change has no impact for any old invoices. The VAT schemas will be discussed in the future articles in the series. For now, those are just reference fields for future use.
inserted_at, inserted_by, updated_at, updated_by	Standard audit trail fields as described in the first article in this series . Obviously, the company profile is a root entity.

领域	描述
base_country	公司所在国家/地区的ISO 3166代码。 公司成立后不应更改，因为公司无法自行转移到另一个司法管辖区。 它是country_codes表的外键，并限制此国家/地区代码的更新和删除。 实际上，限制是该领域的主要目的，因为会计应用程序可以在不对可用性造成重大影响的情况下支持许多司法管辖区并不可行。 如果特定的RDBMS不支持没有主键的表，则该字段也可以用作主键。
base_currency	用于记帐的基础货币的ISO 4217代码。 创建公司后不应更改，因为这种更改会使我们陷入一个数据库中有两种基本货币的情况。 这是很难计算和支持的。 在这种罕见的情况下(例如引入欧元)，推荐的方法是创建一个新的公司数据库，并且仅移动转换后的余额。 旧的数据库留作历史参考。 这是currency_codes表的外键，并限制此货币代码的更新和删除。
base_language	记帐中使用的基本语言的ISO 639-2代码。 公司成立后不应更改，因为那样就不会自动转换旧的文本数据。 在这种罕见的情况下(我什至无法想象的)，推荐的方法是创建一个新的公司数据库，仅移动余额。 旧的数据库留作历史参考。
establishment_date	公司成立的日期。 显然，不能更改(除非输入错误)。
default_description_invoice_made, default_description_invoice_received	发票的默认描述。 说明仅用于自动填充说明字段(默认情况下)，仅供内部使用。 因此，它的更改对任何旧发票都没有影响。 之所以使用它们，而不是使用每个文档类型具有默认描述的单独表，是因为在现实生活中的用例中，它们是唯一不需要自定义描述的(至少以我支持会计应用程序的经验而言)。
default_measure_unit_invoice_received	收到的发票中的默认度量单位。 它仅用于自动填充度量单位字段(默认情况下)，仅供内部使用。 因此，它的更改对任何旧发票都没有影响。
default_sales_vat_schema_id, default_purchases_vat_schema_id	适用于新发票的默认增值税方案。 它们仅作为默认值应用。 因此，它们的更改对任何旧发票都没有影响。 增值税方案将在本系列的后续文章中进行讨论。 目前，这些只是供将来使用的参考字段。
inserted_at, inserted_by, updated_at, updated_by	标准审计跟踪字段，如本系列第一篇文章中所述。 显然，公司简介是一个根实体。

表company_profile_versions详细信息 (Table company_profile_versions Details)

Fields	Description
id	A synthetic key. I prefer to use it for consistency. Though, in this case, field effective_date is also a great candidate as primary key.
effective_date	A date that the profile data is effective from.
national_id_no, social_security_no, vat_no	Codes that identify the company within state registries. Could be jurisdiction specific, but in most jurisdiction should be pretty much the same. If you think that they cannot change, think again. National registry reforms happen. Not to mention that a company could be (de)registered as VAT payer multiple times. Obviously, the codes are not localizable.
company_name	An official name of the company. Obviously, can change. Not localizable.
ceo_name, accountants_name	Names of the CEO and accountant. Obviously, can change. Not localizable.
vat_deduction_percentage	Applicable VAT deduction percent. Will be discussed in detail in the future articles. For now, just a field reserved for future use.
ceo_signature_facsimile, accountants_signature_facsimile	In some jurisdictions, invoices could be “signed” with a CEO’s signature facsimile (scanned signature). Not applicable for Lithuania anymore and, as far as I’m concerned, the rest of the EU. If it’s applicable for your jurisdiction, it’s a good place for the fields. Even though they are of BLOB type, their size is small by definition (1-5 kB). Therefore, no significant impact for duplication.

领域	描述
id	合成密钥。 我更喜欢使用它来保持一致性。 但是，在这种情况下，字段effective_date也是主键的最佳选择。
effective_date	配置文件数据生效的日期。
national_id_no, social_security_no, vat_no	在州注册表中标识公司的代码。 可能是特定于管辖区的，但在大多数管辖区中应该几乎相同。 如果您认为它们无法更改，请再考虑一下。 国家注册管理机构改革正在进行。 更不用说一家公司可以多次(注销)注册为增值税支付方。 显然，代码不可本地化。
company_name	公司的正式名称。 显然，可以改变。 不可本地化。
ceo_name, accountants_name	首席执行官和会计师的姓名。 显然，可以改变。 不可本地化。
vat_deduction_percentage	适用的增值税抵扣百分比。 在以后的文章中将详细讨论。 目前，仅保留一个字段供将来使用。
ceo_signature_facsimile, accountants_signature_facsimile	在某些辖区，可以用首席执行官的签名传真(扫描签名)对发票进行“签名”。 不再适用于立陶宛，就我而言，不适用于欧盟其他地区。 如果它适用于您所在的管辖区，那么它是适合这些领域的好地方。 即使它们是BLOB类型，从定义上看它们的大小也很小(1-5 kB)。 因此，对复制没有重大影响。

Table extended_default_account_types is implemented using the same method as the other type extensions (see the first article of the series for details). The only substantial difference is the absence of fallback type. In this case, the extended default account type has no meaning without the extension itself. Therefore, if the extension is uninstalled, the default account types owned by the extension can be safely dropped. Table fields:

表extended_default_account_types是使用与其他类型扩展相同的方法实现的(有关详细信息，请参阅本系列的第一篇文章 )。 唯一的实质区别是没有后备类型。 在这种情况下，扩展名默认帐户类型没有扩展名本身就没有任何意义。 因此，如果卸载了该扩展程序，则可以安全地删除该扩展程序拥有的默认帐户类型。 表格栏位：

Fields	Description
id	A GUID of the extended type that is assigned (generated) by the extension developer.
extension_id	An ID of the extension that the extended operation type belongs to (foreign key to table extensions)
type_name	A name (short description) of the extended default account type – for the (obvious) data debugging purposes.

领域	描述
id	由扩展开发人员分配(生成)的扩展类型的GUID。
extension_id	扩展操作类型所属的扩展的ID(表扩展的外键)
type_name	扩展默认帐户类型的名称(简短描述)–用于(显而易见的)数据调试目的。

表default_accounts详细信息 (Table default_accounts Details)

Fields	Description
id	A standard synthetic key. A combination of default_account_type and extended_default_account_type_id could also be used as a clustered primary key. However, the extended_default_account_type_id field could be null (if it’s not defined by an extension). Which might cause problems in some RDBMS. Therefore, I opt for standard synthetic key.
default_account_type	An application defined enumeration of the default account types that a handled by the base application functionality. It might change. Therefore, ENUM type cannot be used. For the data integrity purpose (to prevent illegal/non-existent types), a technical lookup table might be used. But I am undecided about it yet.
extended_default_account_type_id	A default account type defined by an extension of the application (if the default account type belongs to an application extension). It’s a foreign key for the extended_default_account_types table with ON DELETE CASCADE option. So that the entry is automatically deleted if the extension is uninstalled.
account_id	An account that is set as the default of the particular type. It’s a foreign key for the accounts table with ON DELETE CASCADE option. So that the entry is automatically deleted if the account is deleted.

领域	描述
id	标准合成密钥。 default_account_type和extended_default_account_type_id组合也可以用作群集主键。 但是， extended_default_account_type_id字段可以为null (如果扩展名未定义)。 这可能会在某些RDBMS中引起问题。 因此，我选择标准的合成密钥。
default_account_type	应用程序定义了基本应用程序功能处理的默认帐户类型的枚举。 它可能会改变。 因此，不能使用ENUM类型。 为了数据完整性(防止非法/不存在的类型)，可以使用技术查询表。 但是我还没有决定。
extended_default_account_type_id	由应用程序扩展名定义的默认帐户类型(如果默认帐户类型属于应用程序扩展名)。 它是带有ON DELETE CASCADE选项的extended_default_account_types表的外键。 因此，如果扩展名被卸载，该条目将被自动删除。
account_id	设置为特定类型默认值的帐户。 它是带有ON DELETE CASCADE选项的帐户表的外键。 这样，如果删除帐户，该条目将自动删除。

Now we can summarize all of the requirements and my personal experience about the commonly used localizable profile fields with the following company regional profile schemas (relevant portion):

现在，我们可以使用以下公司区域配置文件架构(相关部分)来总结关于常用的可本地化配置文件字段的所有要求和我的个人经验：

表company_regional_profiles详细信息 (Table company_regional_profiles Details)

Fields	Description
id	An ISO 639-2 code for the language that the regional profile is for. There should be at least one regional profile for the base language of the company.
default_extra_info_in_invoice	A default region specific text that is added to invoices. The text is only used to autofill a localized document/invoice comments field (as a default value). Therefore, its change has no impact for any old invoices.
default_invoice_measure_units	A default measure unit in an invoice made. It is only used to autofill the localized measure unit field as a default value. Therefore, its change has no impact for any old invoices.
inserted_at, inserted_by, updated_at, updated_by	Standard audit trail fields as described in the first article in this series. Obviously, the company regional profile for a particular language is a root entity.

领域	描述
id	区域概要文件所用语言的ISO 639-2代码。 公司的基本语言至少应有一个区域性资料。
default_extra_info_in_invoice	添加到发票的默认区域特定文本。 文本仅用于自动填充本地化的文档/发票注释字段(作为默认值)。 因此，它的更改对任何旧发票都没有影响。
default_invoice_measure_units	发票中的默认度量单位。 它仅用于自动填充本地化的度量单位字段作为默认值。 因此，它的更改对任何旧发票都没有影响。
inserted_at, inserted_by, updated_at, updated_by	标准审计跟踪字段，如本系列第一篇文章中所述。 显然，特定语言的公司区域资料是一个根实体。

表company_regional_profile_versions详细信息 (Table company_regional_profile_versions Details)

Fields	Description
id	A standard synthetic key. I prefer to use it for consistency. Though, in this case, fields effective_date and regional_profile_id could also be used as a clustered primary key.
regional_profile_id	An id of the regional profile that the version entry belongs to.
effective_date	A date that the profile data is effective from.
registered_address, office_address	A registered and actual address of the company. The registered address is an official address within the relevant companies’ registry. It is common that actual address is different from the official.
phone_no, email, contact_details	Contact details that are used in the documents for a specific language. Even though phone number and email are not localizable by nature (cannot be translated), it’s common to display different contact details for different languages. There are employees behind those contacts and not every employee may speak the relevant language.
ceo_title	A title of the CEO, e.g., director, president, chairman, CEO, etc.

领域	描述
id	标准合成密钥。 我更喜欢使用它来保持一致性。 不过，在这种情况下，字段effective_date和regional_profile_id ID也可以用作群集主键。
regional_profile_id	版本条目所属的区域配置文件的ID。
effective_date	配置文件数据生效的日期。
registered_address, office_address	公司的注册地址和实际地址。 注册地址是相关公司注册表中的正式地址。 实际地址与官方地址不同是很常见的。
phone_no, email, contact_details	文档中使用的特定语言的联系方式。 即使电话号码和电子邮件本质上无法本地化(无法翻译)，但通常会针对不同的语言显示不同的联系方式。 这些联系人背后有员工，并不是每个员工都可以说相关的语言。
ceo_title	CEO的头衔，例如董事，总裁，董事长，CEO等。

Table extended_regional_template_types is implemented using the same method as the other type extensions (see the first article of the series for details). The only substantial difference is the absence of fallback type. In this case, the extended template type has no meaning without the extension itself. Therefore, if the extension is uninstalled, its templates can be safely dropped. Table fields:

表extended_regional_template_types是使用与其他类型扩展相同的方法实现的(有关详细信息，请参阅本系列的第一篇文章 )。 唯一的实质区别是没有后备类型。 在这种情况下，扩展模板类型没有扩展本身就没有任何意义。 因此，如果扩展名已卸载，则可以安全地删除其模板。 表格栏位：

Fields	Description
id	A GUID of the extended type that is assigned (generated) by the extension developer.
extension_id	An ID of the extension that the extended template type belongs to (foreign key to table extensions)
type_name	A name (short description) of the extended template type – for the (obvious) data debugging purposes.

领域	描述
id	由扩展开发人员分配(生成)的扩展类型的GUID。
extension_id	扩展模板类型所属的扩展的ID(表扩展的外键)
type_name	扩展模板类型的名称(简短描述)–用于(显而易见的)数据调试目的。

表company_regional_templates详细信息 (Table company_regional_templates Details)

Fields	Description
id	A standard synthetic key. A combination of regional_profile_id, effective_date, regional_template_type and extended_regional_template_type_id could also be used as a clustered primary key. However, such a large clustered index doesn’t look very appealing. Therefore, I opt for standard synthetic key.
regional_profile_id	An id of the regional profile that the template version entry belongs to.
effective_date	A date that the template is effective from.
regional_template_type	An application defined enumeration of the template types that a handled by the base application functionality. It might change. Therefore, ENUM type cannot be used. For the data integrity purpose (to prevent illegal/non-existent types), a technical lookup table might be used. But I am undecided about it yet.
extended_regional_template_type_id	A template type defined by an extension of the application. (if the template type belongs to an application extension) It’s a foreign key for the extended_regional_template_types table with ON DELETE CASCADE option. So that the entry is automatically deleted if the extension is uninstalled.
template_body	A template file.

领域	描述
id	标准合成密钥。 也可以将regional_profile_id ， effective_date ， regional_template_type和extended_regional_template_type_id的组合用作集群主键。 但是，这么大的聚集索引看起来并不吸引人。 因此，我选择标准的合成密钥。
regional_profile_id	模板版本条目所属的区域概要文件的ID。
effective_date	模板生效的日期。
regional_template_type	应用程序定义了由基本应用程序功能处理的模板类型的枚举。 它可能会改变。 因此，不能使用ENUM类型。 为了数据完整性(防止非法/不存在的类型)，可以使用技术查询表。 但是我还没有决定。
extended_regional_template_type_id	由应用程序扩展定义的模板类型。 (如果模板类型属于应用程序扩展)，它是带有ON DELETE CASCADE选项的extended_regional_template_types表的外键。 因此，如果扩展名被卸载，该条目将被自动删除。
template_body	模板文件。

Now that we have full company profile schema in place, we can define a sequence of actions required to initialize a new database for a company:

现在我们已经有了完整的公司资料架构，我们可以定义一系列初始化公司新数据库所需的动作：

1. Add entries for the relevant extensions as described in the first article in the series

   如本系列的第一篇文章所述，为相关扩展添加条目

2. Add entry to the table country_codes for the base state of the company

   将条目添加到表country_codes以获取公司的基本状态

3. Add entry to the table currency_codes for the base currency of the company

   在表currency_codes添加公司基本货币的条目

4. Add entry to the table company_profile for the non-localized company profile

   将条目添加到未本地化公司资料的表company_profile中

5. Add entry to the table company_profile_versions for the non-localized company profile initial data version

   将条目添加到表company_profile_versions以获取未本地化的公司资料的初始数据版本

6. Add entry to the table company_regional_profiles for the localized company profile in base language

   以基本语言将条目添加到表company_regional_profiles ，以获取本地化的公司资料

7. Add entry to the table company_regional_profile_versions for the localized company profile in base language initial data version

   在基本语言初始数据版本中，将条目添加到表company_regional_profile_versions中以本地化的公司资料

That’s a minimal required initialization. Of course, you should also consider using extra wizard for some typical financial statements and chart of accounts setup.

这是最小的必需初始化。 当然，您还应该考虑对某些典型的财务报表和会计科目表设置使用额外的向导。

个人资料 (Person Profiles)

To summarize the requirements for localization, versioning and addresses we will need a total of three tables (entities) for person profiles:

为了总结本地化，版本控制和地址的要求，我们将总共需要三个表(实体)用于个人资料：

• person_profiles – to store person data that does not require versioning, e.g., default values that are only used to prefill document fields

  person_profiles –存储不需要版本控制的人员数据，例如，仅用于person_profiles文档字段的默认值

• person_profile_versions – to store person data that does require versioning, e.g., person name, address, etc.

  person_profile_versions –存储确实需要版本控制的人员数据，例如，人员姓名，地址等。

• shipping_addresses - to store shipping addreses for a person

  shipping_addresses存储一个人的运送地址

We will also need two more helper entities (tables) that logically belongs to the person profile: person_groups and person_group_assignments. The requirement is determined by typical use cases – sometimes accountants need to group persons by some common business specific criteria. Person groups are trivial entities – just a name (to display in a lookup controls) and a description. One person could be assigned to multiple groups and vice versa. Hence, we also need a standard many-to-many relationship table – person_group_assignments. As those tables are trivial, no further details are needed.

我们还将需要另外两个逻辑上属于人员资料的帮助者实体(表)： person_groups和person_group_assignments 。 需求由典型的用例确定-有时会计师需要按照一些特定于业务的通用标准对人员进行分组。 人员组是琐碎的实体–只是名称(显示在查找控件中)和描述。 一个人可以被分配到多个小组， 反之亦然 。 因此，我们还需要一个标准的多对多关系表– person_group_assignments 。 由于这些表很琐碎，因此不需要更多详细信息。

Now we can summarize all of the requirements and my personal experience about the commonly used localizable profile fields with the following company regional profile schemas (relevant portion):

现在，我们可以使用以下公司区域配置文件架构(相关部分)来总结关于常用的可本地化配置文件字段的所有要求和我的个人经验：

表person_profiles详细信息 (Table person_profiles Details)

Fields	Description
id	A standard synthetic primary key. A person doesn’t have any field or even a combination of fields that could be used as a natural key.
default_currency_id	An ISO 4217 code of the currency to use as a default when invoicing the person. As a default value, it could be changed without any effect for old invoices. It’s a nullable foreign key for table currency_codes with option ON DELETE SET NULL, because the null value can be safely treated as company’s base currency while there is no reason to block currency delete only because it’s assigned as a default for a person. (as long as the currency was not used in a document)
default_regional_profile_id	An id of the company’s regional profile (language) to use as a default when creating some localizable documents for person (e.g., invoice). As a default value, it could be changed without any effect for the old documents. It’s a nullable foreign key for table company_regional_profiles with option ON DELETE SET NULL, because the null value can be safely treated as company’s base language profile while there is no reason to block regional profile delete only because it’s assigned as a default for a person (as long as the regional profile was not used in a document).
default_accounts_receivable_id, default_accounts_payable_id	Default accounts to use in documents for the person. As a default value, it could be changed without any effect for the old documents. It’s a nullable foreign key for table accounts with option ON DELETE SET NULL, because the values are optional while there are no reasons to block account delete only because it’s assigned as a default for a person (as long as the account was not used in a document).
date_of_birth	A date of birth of a natural person (if the person is a natural person and chose to use date of birth instead of other ids). Obviously, cannot change (unless a typo).
contact_details, comments	The fields are only for internal use by an accountant. No benefits in keeping their versions.
is_client, is_natural_person, is_employee, is_supplier	Most common person categories. Typically used to filter lookup lists.
is_archived	A standard field for marking a person as no longer in active use as described in the first article in this series .
inserted_at, inserted_by, updated_at, updated_by	Standard audit trail fields as described in the first article in this series. Obviously, the person profile is a root entity.

领域	描述
id	标准的合成主键。 一个人没有可以用作自然键的任何字段，甚至没有字段的组合。
default_currency_id	开具发票给人的默认ISO 4217货币代码。 作为默认值，可以更改它，而对旧发票不起作用。 它是表currency_codes的可空外键，带有选项ON DELETE SET NULL ，因为可以将null值安全地视为公司的基础货币，而没有理由仅因为将其分配为人的默认值而阻止货币删除。 (只要未在文档中使用该货币)
default_regional_profile_id	创建个人的一些可本地化文档(例如发票)时，默认使用的公司区域资料的ID(语言)。 作为默认值，可以更改它而对旧文档没有任何影响。 它是带有选项ON DELETE SET NULL表company_regional_profiles的可为空的外键，因为可以将null值安全地视为公司的基本语言配置文件，而没有理由阻止区域配置文件删除仅是因为它被指定为一个人的默认值(例如(只要文档中未使用区域配置文件)。
default_accounts_receivable_id, default_accounts_payable_id	该人在文档中使用的默认帐户。 作为默认值，可以更改它而对旧文档没有任何影响。 对于带有选项ON DELETE SET NULL表帐户，它是可为空的外键，因为这些值是可选的，而没有理由阻止帐户删除，仅是因为它被指定为个人的默认值(只要未在帐户中使用该帐户)文件)。
date_of_birth	自然人的出生日期(如果该人是自然人，并且选择使用出生日期代替其他身份证)。 显然，不能更改(除非输入错误)。
contact_details, comments	这些字段仅供会计师内部使用。 保留其版本没有任何好处。
is_client, is_natural_person, is_employee, is_supplier	最普通的人类别。 通常用于过滤查找列表。
is_archived	本系列的第一篇文章中描述的用于标记某人不再活跃的标准字段。
inserted_at, inserted_by, updated_at, updated_by	标准审计跟踪字段，如本系列第一篇文章中所述。 显然，个人档案是根实体。

表person_profile_versions详细信息 (Table person_profile_versions Details)

Fields	Description
id	A synthetic key. I prefer to use it for consistency. Though, in this case, fields effective_date and person_id could also be used as a clustered primary key.
person_id	An id of the person (profile) that the data version is for
effective_date	A date that the profile data is effective from
person_name	A name of the person. Obviously, can change.
address, municipality, city, street, house_number, longitude, latitude	An address of the person (unstructured and, optionally, structured). Obviously, can change.
country_id	A state of the person residence. Not so obvious, but still can change. E.g., if a company becomes a state resident for tax purposes it is considered a state resident even if it has no subsidiaries in that country.
national_id_no, vat_no, social_security_no, business_certificate_no, individual_activity_certificate_no	Codes that identify the person (company) within state registries. Could be jurisdiction specific, but in most jurisdiction should be pretty much the same. If you think that they cannot change, think again. National registry reforms happen. Not to mention that a company could be (de)registered as VAT payer multiple times. Obviously, the codes are not localizable.
internal_id	An id of the person that the company uses internally, e.g., some customer id. It is typically displayed on invoices. Therefore, subject to versioning.
bank_account_no, bank_name	A bank account of the person. Obviously, can change. Could also be implemented as a separate table for person’s bank accounts to support multiple bank accounts per person. However, never been asked for such a functionality by any accountant and prefer to keep it as simple as possible.
email	An email of the person. It could be displayed on invoices. Therefore, subject to versioning (though, in this case it’s questionable).

领域	描述
id	合成密钥。 我更喜欢使用它来保持一致性。 不过，在这种情况下，字段effective_date和人员person_id也可以用作群集主键。
person_id	数据版本所针对的人(个人资料)的ID
effective_date	配置文件数据生效的日期
person_name	人名。 显然，可以改变。
address, municipality, city, street, house_number, longitude, latitude	人员的地址(非结构化和(可选)结构化)。 显然，可以改变。
country_id	人居住地的状态。 不太明显，但仍然可以改变。 例如，如果一家公司出于税收目的成为州居民，即使该公司在该国没有子公司，也被视为州居民。
national_id_no, vat_no, social_security_no, business_certificate_no, individual_activity_certificate_no	在州注册表中标识个人(公司)的代码。 可能是特定于管辖区的，但在大多数管辖区中应该几乎相同。 如果您认为它们无法更改，请再考虑一下。 国家注册管理机构改革正在进行。 更不用说一家公司可以多次(注销)注册为增值税支付方。 显然，代码不可本地化。
internal_id	公司内部使用的人员的ID，例如某些客户ID。 通常显示在发票上。 因此，应进行版本控制。
bank_account_no, bank_name	该人的银行帐户。 显然，可以改变。 也可以实现为个人银行帐户的单独表格，以支持每个人多个银行帐户。 但是，从来没有任何会计师要求提供这样的功能，而是希望使其尽可能简单。
email	该人的电子邮件。 它可以显示在发票上。 因此，受版本控制(尽管在这种情况下，这是有问题的)。

The last table within person profile infrastructure shipping_addressesis trivial – just an unstructured and, optionally, structured address plus standard bit flag is_archived. The latter might seem redundant, as the shipping address shall be cloned to the invoice. I only leave it as a means for an accountant to temporary hide it in lookup controls.

人员配置文件基础结构shipping_addresses的最后一张表很简单–只是一个非结构化(可选)的结构化地址以及标准位标志is_archived 。 后者似乎是多余的，因为送货地址应复制到发票上。 我仅将其保留为会计师将其暂时隐藏在查找控件中的一种方法。

Once we have the person profile schema in place, we can fetch the effectual profile fields with a query:

一旦有了人员个人档案架构，就可以通过查询获取有效的个人档案字段：

SELECT p.id, p.default_currency_id, p.default_regional_profile_id, _
p.default_accounts_receivable_id,
p.default_accounts_payable_id, p.date_of_birth, p.contact_details, p.comments, p.is_client,
p.is_supplier, p.is_natural_person, p.is_employee, p.is_archived,
v.person_name, v.address, v.state_of_residence_id, v.national_id_no, v.vat_no, _
v.social_security_no,
v.business_certificate_no, v.individual_activity_certificate_no, v.internal_id,
v.bank_account_no, v.bank_name, v.email
FROM person_profiles p
LEFT JOIN person_profile_versions v ON v.person_profile_id = p.id AND v.effective_date =
(SELECT MAX(q.effective_date) FROM person_profile_versions q WHERE q.person_profile_id=p.id)

成本中心 (Cost Centres)

A cost centre is typically defined as a department within a business to which costs can be allocated. It’s a part of management accounting. (See wiki) We will implement cost centre in a bit more generic and simple way – as an extra dimension for analytics that is not strictly related namely to costs. Simply define a loose set of simple cost centre entities with an option of grouping that could be assigned to documents and ledger entries and consequently enables filtering of reports. Such a straightforward implementation will allow an accountant to use it not only as a classical cost centre but also as a project tracker or budgeting line.

成本中心通常定义为企业中可以分配成本的部门。 这是管理会计的一部分。 (请参阅Wiki )我们将以更通用和更简单的方式实现成本中心-作为与成本不严格相关的分析的额外维度。 只需定义一组松散的简单成本中心实体，即可选择可以分组到文档和分类帐条目的分组选项，从而启用报表过滤功能。 这种简单明了的实现方式将使会计师不仅可以将其用作经典的成本中心，还可以用作项目跟踪器或预算线。

The schema for cost centres is trivial and hardly requires any further comments:

成本中心的架构很简单，几乎不需要任何其他注释：

将人员和成本中心绑定到文档 (Binding Persons and Cost Centres to Documents)

As it was already discussed in the second article in the series, the first point to add the persons and costs centres at is the general ledger. We have already left two fields for that purpose. So now, the full schema looks like that (the relevant portion):

正如本系列第二篇文章中已经讨论过的那样，添加人员和成本中心的第一点是总帐。 我们已经为此保留了两个字段。 因此，现在，完整架构如下所示(相关部分)：

However, that’s not the only point where the foreign keys to the person and cost centre should be added. Again, as discussed in the second article, not every document has a general ledger transaction (e.g., time sheet or a labour contract do not). Moreover, some documents might have both persons related an unrelated through a general ledger entry (e.g., an invoice with a guarantee). Therefore, we shall also add a foreign key reference at the document level. Even though the related persons might overlap (and in most case will overlap), it doesn’t break normalization as the reference has a different context. The link to a document is definitely a broader concept than a link to a ledger entry. On the other hand, we cannot streamline relation to a document to a relation to a particular ledger entry. Which brings us to conclusion that both references are required by the business logic of the domain.

但是，这不是应该添加人员和成本中心的外键的唯一点。 再次，如第二篇文章所述，并非每个文档都具有总帐事务(例如，时间表或劳动合同没有)。 此外，某些文件可能通过总分类帐条目(例如，带担保的发票)使两个人之间没有关联。 因此，我们还将在文档级别添加外键引用。 即使相关人员可能重叠(并且在大多数情况下会重叠)，但由于引用具有不同的上下文，因此不会破坏规范化。 与到分类帐条目的链接相比，文档的链接绝对是一个更广泛的概念。 另一方面，我们无法将与单据的关系简化为与特定分类帐条目的关系。 这使我们得出结论，领域的业务逻辑需要两个引用。

Obviously, a (source) document might have both multiple persons and cost centres related. Which brings us to requirement of standard many-to-many tables. Therefore, the final schema for document to persons and costs centres relations looks like that (a relevant portion):

显然，(原始)文档可能同时具有多个人员和成本中心。 这使我们达到了标准的多对多表的要求。 因此，文件与人员和成本中心关系的最终方案如下所示(相关部分)：

It should also be noted that the application that will make use of the schema shall not ignore the persons and costs centres that has already been assigned to ledger entries. Those shall also fall into the document relations. Otherwise, a trivial select filtered by a person (or a costs centre) would also hit the “heavy” ledger entries table. This is only the most pragmatic reason. There are also a theoretic one. As described above, the relation document-person is different from the relation ledger entry – person as per domain business logic. Therefore, the relation to a person by a ledger entry and a document have a different business meaning per domain and both of them shall be kept in order to correctly describe both aspects. The convention (as you cannot guarantee it at the database level) also has benefits for the extensions. As every extended document shall use the document infrastructure, all of the documents (both for base functionality and extended) will be available by a single “interface”, i.e., we can have a single filterable registry for all of the documents.

还应注意，将使用该模式的应用程序不应忽略已经分配给分类帐条目的人员和成本中心。 这些也应属于文档关系。 否则，由人员(或成本中心)筛选的琐碎选择也会打入“沉重”分类帐条目表。 这只是最务实的原因。 还有一个理论上的。 如上所述，关系文档人员与关系分类帐条目不同-根据域业务逻辑的人员。 因此，分类帐分录和单据与人的关系在每个域中具有不同的业务含义，因此应保留它们两者以正确描述这两个方面。 约定(因为您不能在数据库级别上保证它)对于扩展也有好处。 由于每个扩展文档都将使用文档基础结构，因此所有文档(用于基本功能和扩展文档)都将通过单个“接口”提供，即，我们可以为所有文档提供一个可过滤的注册表。

通用文档编号方案 (Common Document Numeration Schema)

The last but not the least handy thing to implement in the common documents interface is the numeration schema. The documents that an accountant receives have numbers that they have. Meaning, the accountant just records a fact. However, the company itself issues some documents. And, at least for small companies, those are issued using the accounting software, i.e. our application. Therefore, the application should be able to handle the numeration of such documents. It might be culture specific, but as far as I’m concerned, the ways the document numbers are generated are:

在通用文档界面中要实现的最后但并非最不方便的事情是计数模式。 会计师收到的文件具有其编号。 意思是，会计师只记录一个事实。 但是，公司本身会发布一些文件。 而且，至少对于小公司而言，这些是使用会计软件(即我们的应用程序)发行的。 因此，应用程序应该能够处理此类文档的数量。 它可能是特定于文化的，但是就我而言，文档编号的生成方式是：

• There is some document serial, that consists mostly of some letters, sometimes other characters and numbers; might also be an empty string;
  有一些文档序列，主要由一些字母，有时还包括其他字符和数字组成； 也可能是一个空字符串；
• There is a base (running) number (integer) that is reset subject to the company policy: never, once a year, once a month or every day.
  有一个根据公司政策重设的基本(运行)数字(​​整数)：永远，每年一次，每月一次或每天一次。
• There is a formatted full document number that consists of: a serial (as a prefix), a date of the document (or part of the date, e.g., year only, or the date might be disregarded at all) and the base number.
  有一个格式化的完整文档编号，包括：序列号(作为前缀)，文档日期(或日期的一部分，例如仅年份，或者日期可能根本不被考虑)和基数。

To sum it all up, the document number template using .NET format string (only for demonstration, any other could be used instead) could be described by the fields:

总而言之，使用.NET格式字符串的文档编号模板(仅用于演示，可以使用其他任何格式)可以由以下字段描述：

• Serial – pretty much any string provided by the user; for sanity check, presumably max 20 characters;
  串行–用户提供的几乎所有字符串； 进行健全性检查，大概最多20个字符；
• A numbering policy enumeration, i.e., reset running number: never, once a year, once a month or every day;
  编号策略枚举，即重置运行编号：从不，每年一次，每月一次或每天一次；

• A full number format string, e.g. “{0:yyyyMMdd}-{1:D6}” which for a document at 2019-12-31 with running number 1 would produce “20191231-000001”, or “{1}”, which for the same document would produce “1” (serial always goes as prefix, no need to include in the format string).

  完整的数字格式字符串，例如“ {0：yyyyMMdd}-{1：D6} ”，对于运行编号为1的2019-12-31的文档，它将产生“ 20191231-000001 ”或“ {1} ”，因为同一文档将产生“ 1 ”(序列始终作为前缀，不需要在格式字符串中包含)。

• A bit flag indicating that the full number is provided by an external system, i.e. whether the full number shall be “calculated” using running number and format string or a user (e.g., a CRM) should be allowed to enter the full number manually.
  指示完整数字由外部系统提供的位标志，即应允许使用运行编号和格式字符串“计算”完整数字，还是允许用户(例如CRM)手动输入完整数字。

If you know of a real life use case that wouldn’t fit the template, please let me know.

如果您知道不适合该模板的现实用例，请告诉我。

Obviously, a change in template (company’s numbering policy for some type of document) cannot affect numbers of the documents that has already been issued. Which brings us to the following options:

显然，模板的更改(公司对某种类型的文档的编号策略)不会影响已经发行的文档的编号。 这为我们带来了以下选择：

• Make the template read-only if it has been used by a document
  如果模板已被文档使用，则将其设为只读
• Copy template fields to the (complex) document number fields
  将模板字段复制到(复杂)文档编号字段
• Anything in between the previous solutions
  先前解决方案之间的任何情况

Actually, I don’t see any serious cons for all of the options. My choice is based on the way most accountants see/understand the document-numbering concept. And they tend to associate the numbering schema with the serial part, i.e., when they choose a serial from a lookup accountants (most of them) expect a valid (next) number to be assigned to the document. And otherwise, accountants are not used to a field “numbering policy” as well as seeing multiple “numbering policies” with the same serial, which makes it non-intuitive. To make the numbering function as intuitive as I can, I chose the following mixed solution:

实际上，我看不到所有选项的严重弊端。 我的选择基于大多数会计师对文件编号概念的理解/理解。 而且，他们倾向于将编号模式与序列号相关联，即，当他们从查询会计师中选择序列号时(大多数)，他们希望将有效(下一个)编号分配给文档。 否则，会计师将不会习惯于“编号策略”字段，也不会看到具有相同序列号的多个“编号策略”，这使其变得不直观。 为了使编号功能尽可能直观，我选择了以下混合解决方案：

• The serial part of a template is unique per document type and identifies the template (at least from the accountant’s point of view).
  模板的序列部分对于每种文档类型都是唯一的，并且可以标识模板(至少从会计师的角度而言)。
• The serial part of a template is made read-only the moment a document uses the template.
  当文档使用模板时，模板的串行部分将变为只读状态。
• The rest of the template fields remain editable but their values are copied to the document, i.e., change does not affect previous documents.
  其余模板字段保持可编辑状态，但是它们的值已复制到文档中，即，更改不会影响以前的文档。

There are two ways to implement this solution: plainly copy numbering policy, external system flag and format string to the document or keep a separate “numbering policy versions” table that holds the same fields and gets a new row whenever a policy changes. The first option will cost extra ~60 MB for one million document database. The second option will save the space and (maybe?) will be more normalized but somehow more complex. As the disk space costs are quite negligible, I opt for the more simple solution – three field copy. The resulting schema will be the following (the relevant portion):

有两种方法可以实现此解决方案：将编号策略，外部系统标志和格式字符串简单地复制到文档中，或保留一个单独的“编号策略版本”表，该表包含相同的字段并在策略更改时获得新的一行。 对于一百万个文档数据库，第一个选项将花费额外的〜60 MB。 第二个选项将节省空间，并且(也许？)将被更规范化，但是以某种方式更加复杂。 由于磁盘空间成本可以忽略不计，因此我选择了更简单的解决方案-三字段复制。 结果模式如下(相关部分)：

表格complex_numbers的详细信息 (Details for the table complex_numbers)

Fields	Description
document_id	An id of the document that the number is of. As we have 0..1 relation here, it’s both a primary key and a foreign key.
template_id	An id of the template that defines the numbering rules.
reset_policy	A numbering policy, i.e., periods when the running number shall be reset. Copied from template.
format_string	A format string used to produce a full number by the document date and running number. Copied from template.
has_external_provider	A bit flag indicating that the full number is created and formatted by a third party (e.g. a CRM), i.e., format_string and running_no shall not be used. Copied from template.
running_no	A running (sequence) number of the document within the reset period.
full_no	A full (formatted) number of the document.

领域	描述
document_id	该编号所属的文档的ID。 因为这里有0..1关系，所以它既是主键又是外键。
template_id	定义编号规则的模板的ID。
reset_policy	编号策略，即运行编号应重置的时间段。 从模板复制。
format_string	格式字符串，用于按凭证日期和运行编号产生完整的数字。 从模板复制。
has_external_provider	指示完整号码由第三方(例如CRM)创建并设置格式的位标记，即format_string和running_no不应使用。 从模板复制。
running_no	重置期间内文档的运行(序列)编号。
full_no	文件的完整(格式)数。

表格complex_number_templates的详细信息 (Details for the table complex_number_templates)

Fields	Description
id	An id of the complex number template. A standard surrogate primary key
document_type	A base (source) document type that the template is meant for.
extended_document_type_id	An extended (source) document type that the template is meant for.
serial	A serial of a document, i.e. an arbitrary string (including an empty one) to prefix the full number of a document. Should be unique per document_type and extended_document_type_id. Shall not be changes after the template is used for a document.
reset_policy	A numbering policy, i.e., periods when the running number shall be reset.
format_string	A format string used to produce a full number by the document date and running number.
has_external_provider	A bit flag indicating that the full number is created and formatted by a third party (e.g., a CRM), i.e. format_string shall not be used.
is_archived	A standard bit flag indicating that the template is no longer in use and is kept only as a historical record. (as the template used in a document cannot be deleted)
comments	Accountant’s comments regarding the template. For internal use only.
inserted_at, inserted_by, updated_at, updated_by	Standard audit trail fields as described in the first article in this series . Obviously, the complex number template is a root entity.

领域	描述
id	复数模板的ID。 标准代理主键
document_type	模板所针对的基本(源)文档类型。
extended_document_type_id	模板所针对的扩展(源)文档类型。
serial	文档的序列号，即以字符串开头的任意字符串(包括一个空字符串)。 每个document_type和extended_document_type_id应该唯一。 模板用于文档后不得更改。
reset_policy	编号策略，即运行编号应重置的时间段。
format_string	格式字符串，用于按凭证日期和运行编号产生完整的数字。
has_external_provider	指示完整号码由第三方(例如CRM)创建并设置格式的位标记，即format_string不应使用。
is_archived	一个标准位标志，指示该模板不再使用，仅保留为历史记录。 (因为无法删除文档中使用的模板)
comments	会计师对模板的评论。 仅限内部使用。
inserted_at, inserted_by, updated_at, updated_by	标准审计跟踪字段，如本系列第一篇文章中所述。 显然，复数模板是一个根实体。

Having the schema in place, we can now fetch a next number for an arbitrary complex number schema with an id=123 and a document dated 2019-05-26 in a generic way:

有了模式之后，我们现在可以以通用方式为id=123和日期为2019-05-26的任意复数模式获取下一个数字：

SELECT MAX(c.running_no) + 1 AS NextRunningNo
FROM documents d
LEFT JOIN complex_numbers c ON c.document_id = d.id
WHERE c.template_id = 123 AND (c.reset_policy = 'never' OR
(c.reset_policy = 'day' AND d.document_date = '2019-05-26')
OR
(c.reset_policy = 'month' AND YEAR(d.document_date) = YEAR('2019-05-26')
AND MONTH(d.document_date) = MONTH('2019-05-26'))
OR
(c.reset_policy = 'quarter' AND YEAR(d.document_date) = YEAR('2019-05-26')
AND QUARTER(d.document_date) = QUARTER('2019-05-26'))
OR
(c.reset_policy = 'halfyear' AND YEAR(d.document_date) = YEAR('2019-05-26')
AND ((MONTH(d.document_date) < 7 AND MONTH('2019-05-26') < 7) OR
(MONTH(d.document_date) > 6 AND MONTH('2019-05-26') > 6)))
OR
(c.reset_policy = 'year' AND YEAR(d.document_date) = YEAR('2019-05-26')));

结论 (Conclusion)

In this article, we have finished developing database schema for the core accounting infrastructure: company profile, person profiles, generic document numbering policy.

在本文中，我们已经完成了针对核心会计基础结构的数据库架构的开发：公司资料，人员资料，通用文档编号策略。

Future articles will be dedicated to concrete types of (source) documents and accounting operations. At the moment, I haven’t made up my mind where to start from.

以后的文章将专门讨论(源)单据和会计操作的具体类型。 目前，我还没有决定从哪里开始。

翻译自: https://www.codeproject.com/Articles/5164951/Database-for-Financial-Accounting-Application-III

mimic-iii数据库