Gremmer – Desktop Bookkeeping

Software
Inhoud
Chapter 1. Front-End Developers: Getting started with WPF (Windows Presentation Foundation) ...... 3
Chapter 2. Front-End And Back-End Developers: Sockets and the Client-Server Architecture ............ 4
Chapter 3. Front-End And Back-End Developers: Onion Architecture and Model-View-ViewModel
pattern ...................................................................................................................................................... 5
Chapter 4. Back-End Developers: Repository Pattern and Dapper ......................................................... 6
Chapter 5. BackEnd Developers: Unit Testing ....................................................................................... 6
Chapter 6. BackEnd Developers: Accounting Logic............................................................................... 7
Chapter 7. FrontEnd and BackEnd Developers: Debtors and Creditors, Debit and Credit ..................... 8
Chapter 8. FrontEnd and BackEnd Developers: Invoice Center ............................................................. 9
Tasks (Round 1) .................................................................................................................................... 12
Chapter 1. Front-End Developers: Getting started with WPF
(Windows Presentation Foundation)

This chapter is only required for developers working on the front end of the application.

WPF (Windows Presentation Foundation) is a UI framework for desktop client applications and is a
subset of the .NET Framework. WPF is comparable with Java’s JavaFX which is written in FXML.
Similarly, WPF works with XAML: eXtensible Application Markup Language. XAML is based on
XML.

We will be applying the MVVM pattern (Chapter 3).

We will not implement UI tests.

Note: WPF components could not contain more than 1 component as a child component. To achieve
this behavior, we use grids.

Required study material for front-end developers:

https://www.youtube.com/watch?v=gSfMNjWNoX0 (Length: 70 minutes)
Chapter 2. Front-End And Back-End Developers: Sockets and the
Client-Server Architecture

The application will be split into a client and a server. A client requests a service or resource from the
server. Only the server knows about a database and it is the server that sends the results from the
database back to the client. This communication is done through sockets. This message is in essence
just a bunch of bytes. Therefore, the developers who will be responsible for the socket communication
must have a great understanding of the variable types in C# and its corresponding bytes/bits where
byte = 8 * bit. And integer is 32 bits (4 bytes).
The Client-Server Architecture must be applied to ensure that a user is not able to decompile our code
and access the database. The client should only contain UI and Client logic, such as printing.
Processes (which converse client input into server output) are only to be found in the server and thus
not accessible when the client is decompiled.

Required Material:
https://searchnetworking.techtarget.com/definition/client-server (Read)

http://csharp.net-informations.com/communications/csharp-socket-programming.htm (Read and

navigate for more)

https://www.tutorialsteacher.com/csharp/csharp-data-types (Read)
Chapter 3. Front-End And Back-End Developers: Onion Architecture
and Model-View-ViewModel pattern

The Onion Architecture is a design choice to provide a way to build applications in perspective of
better testability, maintainability, and dependability. Although there are multiple models for the onion
architecture, the concept is similar. I define 4 layers (but some models define more or less):
1. Domain Layer or Business Logic Layer
2. Repository or Database Layer
3. Services Layer
4. UI Layer
The first two layers are the inner most layers whereas the last layer is the outer most layer. The service
layer is used to communicate between the UI layer and the database layer. The onion architecture
dictates that inner layers should not know about outer layers. There is a one-directional
communication. Taking Chapter 2 as well as the principles of the Onion Architecture into
consideration, we must define multiple projects in our solution to ensure independency of the
business logic as well as multiple solutions to define the difference between the server and the client.

The two solutions are simply named Client and Server. The client consists of at least the project
Presentation (containing the outer most layers for UI). Client logic however, could be implemented in
a new solution. The Server contains at least one solution to define the business logic. We could
however, implement more projects, or even solutions whenever we notice clear differences between
parts.
The MVVM (Model-View-ViewModel) pattern is an architectural pattern which dictates how the UI
should be decoupled from the database and back-end logic. The View is the XAML code in this case.
It binds its components to the ViewModel. Changes to the component or to the code are notified.
Hence, it is a two-directional communication. The ViewModel communicates with the Models which
have direct access to the repositories (which access the database).

Required Material:
https://www.codeguru.com/csharp/csharp/cs_misc/designtechniques/understanding-onion-
architecture.html (Read Onion Architecture)

https://www.youtube.com/watch?v=fo6rvTP9kkc (MVVM)

https://www.youtube.com/watch?v=srSNOKZds48 (Optional: Onion Architecture, 16:36)

Chapter 4. Back-End Developers: Repository Pattern and Dapper

The repository pattern allows us to switch to another type of database without many changes.
The repository however, should not have the semantics of a database. It’s not updating or saving, it is
simply a collection of objects in memory. These changes are made to the database via a Unit of Work.
A Unit of Work is referred to as a single transaction that involves multiple operations of
insert/update/delete. It is – similar to the ViewModel in the MVVM pattern – a middleman between
the entity controller and the database context.

Required Material:
https://www.youtube.com/watch?v=rtXpYpZdOzM (26 min)

https://www.c-sharpcorner.com/UploadFile/b1df45/unit-of-work-in-repository-pattern/ (Read)

https://www.youtube.com/watch?v=eKkh5Xm0OlU (Dapper)

Chapter 5. BackEnd Developers: Unit Testing

Not only do developers write their code, they also ensure that there is a minimum amount of bugs in
the system. They do so by writing tests. Tests do not ensure that there won’t be bugs of any kind.
Properly written tests (tests that take edge cases into account) only try to minimize the amount of bugs.
In simple words a test is nothing more than a method that checks whether or not the code returns the
expected output. In more technical words this means that we isolate a section of code to verify its
correctness. Decoupled code goes hand in hand with testing. Therefore, writing to interfaces will
become a requirement in our project. An example is given below.

public class Account{

Instead of creating an Account as shown above, we create an interface called IAccount and implement
it. Interfaces can be automatically generated after you have written your class, so do not worry too
much about it when writing your classes.
public class Account : IAccount {

}
However, when creating an instance of a class, you should write to interfaces. This means that instead
we will be writing IAccount account = new Account(); rather than Account account = new Account();
We do not use the keyword var in this case either. Let’s say we create a new class because apparently
there is a different kind of account, let’s say DifferentAccount. We now only have to:
1) Write the class;
2) Change the second part of the assignment. IAccount account = new DifferentAccount(); The rest
of the code will stay the same because using IAccount dictates you to be limited to what IAccount
contains (the methods).

Required material:
https://www.youtube.com/watch?v=HYrXogLj7vg (Unit Testing 44:55)

If you are not familiar with interfaces:

https://www.youtube.com/watch?v=A7qwuFnyIpM&t=455s (Interfaces 48:30)

Chapter 6. BackEnd Developers: Accounting Logic

To sketch the intended architecture, I will explain it from Top to Bottom.

 - Financial Reports: the financial reports such as the Balance Sheet are all based on
ledgers.
- Ledgers consist of accounts which could be one of the following 3 types: assets, liability,
stockholder’s equity. An account has a unique number which often follow the same
pattern and - much like old programming languages – these numbers have gaps of 100 to
be able to add accounts when needed in a logical order.
- The ledger contains the total amounts of those accounts, whereas the daybooks consist
of daybookpages (with a specific name and a corresponding total for that page), which
consists of sheets (with a specific name and also a corresponding total for that sheet),
which consists of journal entries. These journal entries are linked to an account, could be
linked to a document (e.g. an invoice) or to a Company (debtor/creditor), have a
description, a total amount, a vat percentage and the like. Often daybooks are also linked
to accounts such as bank. However, this is not a necessity.

Journal entries can be linked to debtors and creditors, which are companies.

The main specification of our application will be:

➔ Table with all debtors, ability to create new debtors and delete, send reminders for open
invoices
➔ Table with all creditors, ability to create new debtors and delete
➔ Recording Invoices
➔ Creating and sending Invoices
➔ Posting new journal entries in the correct daybooksheet.
➔ Automating the posting processes via bank standard and the like
➔ Automating depreciation and other posts
➔ Downloading trial financial reports
➔ Having multiple businesses (in case of a holding) and thus multiple administrations
➔ Ending the bookkeeping year

Chapter 7. FrontEnd and BackEnd Developers: Debtors and Creditors,

Debit and Credit
Debtors owe the company money: they have the liability to pay. The company on the other hand, has a
liability to pay its creditors. The IFRS, an international standard for accounting, states that expenses
should be recognized in the same period as the revenues to which they relate (expenses are always
made in order to gain revenue). It is not recognized when incurred. In not so technical words:
whenever the company receives an invoice from a creditor, it must recognize it by posting a journal
entry for the expenses (expenses payable when those expenses are unpaid). Liabilities and equity are
by default credited when increasing, and debited when decreasing, whereas assets are by default
debited when increasing, and credited when decreasing. There are, however, some accounts that do
not follow these rules. Those accounts are expenses (this has nothing to do with expenses payable),
which are debited when increasing and credited when decreasing, and depreciation, which is credited
when increasing and debited when increasing. In fact the reason for this, is that expenses are reducing
the net income balance and depreciation reducing the asset balance.
When developing the software, we not necessarily need to know about credit and debit. In fact, we
could choose to skip all of it because we are only concerned about the amount of an account which
will result in a balance. It is the user that will give meaning to those accounts and interpret it.
However, unless someone proves me wrong, I do suggest to add a property of enum BalanceType to
the Account. It might be required later on to form financial reports, although I am aware of the fact
that this could be interpreted by our own code by simply checking the position of the accounttype in
the balance sheet. Last but not least, it offers the possibility to recognize those “anti-accounts” such as
depreciation and expenses (I don’t know the proper word for this type of accounts in English), since in
this case Account as well as AccountType (which is the name in the balance sheet and should also be
a new struct or class) would contain a property BalanceType. If BalanceType of Account !=
BalancyType of AccountType, then Account is such an anti-account. AccountType might actually be
the same as a Ledger name.
Our application will contain a page which allows the user to:

- View debtors and all their information

- View total open, how often it is reminded
- Send reminders

Another page to:

- View creditors and all their information

- View total to be paid, how many days open
- View if there are any reasons why it is not paid yet (which is done in the Invoice Center,
discussed in Chapter 8)

Chapter 8. FrontEnd and BackEnd Developers: Invoice Center

The Invoice Center has two functions:

 - Recording invoices (from creditors)
- Creating invoices (and sending to debtors though mail)

Invoices are split into two categories: outgoing invoices and incoming invoices. Incoming invoices are
linked to a creditor, whereas outgoing invoices are linked to a debtor.

An incoming invoice class contains a creditor number, invoice number, invoice date, maturity date,
total amount, total vat, amount paid and all invoice lines. An invoice line contains the total for that
line, a description, an accounttype, vat.

We will add a few more properties to the incoming and outgoing invoices. The incoming invoices will
go through a set of processes before it will be recorded as an expense payable in the bookkeeping. It
must be approved by peers, which are mostly financial directors. Invoices won’t be eligible for
payment unless they have approved it. Therefore, we will set up an Invoice Center. When an
employee records an invoice there must be:

➔ An invoice number
➔ Invoice date
➔ Maturity date (there must be a setting so it will automatically be x amount of days after the
invoice date, because many companies do not internally use the maturity date noted on the
invoice as they have their own rules)
➔ Creditor (if not exist -> create one, must also be possible in the center itself)
➔ Total amount
➔ Vat percentage

Optionally, they also provide a file containing the actual invoice. This is mostly a pdf. At my work
their invoice center (called Document Center of visma.net) works by dragging all pdf files to the
program, and then it is in a waiting room so to speak, waiting to be filled in completely with all
information. It also has some sort of OCR, but I don’t know how hard it would be for us to implement
this.

It is also possible to choose which peers are eligible to accept the invoice (because some invoices
must be accepted by someone else, for example the HR director must accept the HR invoices,
because the financial director doesn’t know about the invoice). Of course, we should allow to have
default peers. After you filled in everything, you process it. The peers can now see their invoices to
accept. If something is not filled in correctly, they can send it back to the invoice center of the
employees and they must fill it in correctly (so without losing the pdf and information). If there are
other issues that must be discussed, they can create a discussion with other peers (managers mostly)
about this document. It will be placed in a Rejected page. Therefore, in Java my class had the
following properties for the incoming invoices.
Outgoing invoices do have an additional property, in most bookkeeping software called Rmd which
stands for Remindercount. It indicates how many times an invoice has been reminded. Based on this,
the reminder would look different (different message).

The outgoing invoices do not have a similar system because the company doesn’t care if they
unfortunately sent a wrong invoice because an employee fucked up. That doesn’t matter, or at least,
it is not worth it to invest more time and money on that. Invoices therefore, are automatically sent to
the customer (unless this setting is switched off) and the invoice should be able to be printed and
saved in a lot of formats (min. requirement XML, XLS, XLSX, PDF, WORD).
Tasks (Round 1)

UI MainWindow & UI Menu

The UI main window will basically be the main container. It will be filled with other components,
called usercontrols. The main window will contain nothing but a logout button and the like. It is very
important however, because it determines how the rest will be presented as. You choose where which
component would be: Where would we place the user information? What about a part in the UI that
will sum up what you still have to do? You will write documentation on how you think it should look
like and support your idea with a drawing, like paint. You will create the XAML file as well as the
viewmodel and the models.
The UI Menu is a usercontrol. You will also add the menu and its corresponding viewmodel. In this
case there is no model related to the menu view. Note: the event handlers may be empty yet, that is no
big deal. Just make sure that it exists.
(https://www.wpf-tutorial.com/usercontrols-and-customcontrols/creating-using-a-usercontrol/)

UI Debtor Table
The debtor table view shows all debtors, allows the user to sort on a debtor (on the name, the address,
the amount open, etc.), to search a debtor on name, or simply show all debtors with a specific regex.
Note that this table does not show all invoices of the debtor, but only the total amount open. Make sure
that this amount can be negative. Think about edge cases. Create the view as well as the viewmodel
and the models. The model for the table is to be found (indirectly) in the logic chapters.
UI Creditor Table
Read Debtor Table but then for creditors
Setting Up Socket Communication
You will be setting up the socket communication for the client as well as the server. It must be open
for extension.
Setting up the main databases with Dapper
You will be setting up the core databases. It will include a table for outgoing and incoming invoices,
debtors and creditors, daybooks, pages, sheets, journal entries, and companies and users (which are
part of the company). Companies contain
Creating invoices (BackEnd)
You will be responsible for creating the invoices dynamically in any format. The user must be able to
design their own invoice. You will be dictating how the UI part would work and therefore, the UI part
cannot be done before you have finished your task.
Printing utilities
You will be creating the utility to print any fileformat possible. You will also create the settings entity
with Dapper for those utilities: standard printer, standard format, etc.
UI Invoice Center Main Windows
You will be responsible for the mainpage of the invoice center. The main page will be used to drag
and drop invoices in (also to choose them obv.), An example of a real life application:

As you can see, it contains a table with all invoices. Those invoces are being interpreted, which we
probably can’t do because that’s quite sophisticated. Instead, the user will fill it in (so when clicking a
button you will open a new window to fill that in). Those invoices that are being processed are to be
found in this table. Anything that is successfully brought to the discussion board (where it must be
accepted), will not be found here! This is just a placeholder for if something goes wrong. The invoice
will start with no information being filled, then they fill it and if they for some reason didn’t accept it
to go to the discussionboard, then it will be hanging out there. Employees often do this when their
habit is to throw everything at once to the discussionboard. That is being done by selecting all
invoices in the table and clicking on a button. When selecting one invoice, the invoice will be shown
in the pdf viewer.
This window where the invoice information will be filled will contain a pdf viewer too. It will also
take into account all requirements for the invoice (see the chapters about logic)
This task is meant to be done by multiple people.
Task Description Credits Deadline
To Earn*
UI MainWindow & Menu 2 Not yet determined
UI Debtor Table 2 Not yet determined
Setting Up Socket 2 Not yet determined
Communication

Setting up the main 3 Not yet determined

databases with Dapper

Creating invoices 3 Not yet determined

(BackEnd)

Printing Utilities 1 Not yet determined

UI Invoice Center Main 5 Not yet determined
Windows

*Credits to earn will be counted per member and divided by the total amount of credits given. That
will be your %share of this project.
**You are allowed to do tasks with multiple members, but you will be sharing the credits. Max
amount of members per task is equal to the amount of credits to be earned.