toeb / accounting Goto Github PK

Ich als Kassenwart möchte Konten Kategorien zuweisen können um bspw. zwischen Personen, Sachkonten oder Zulieferern unterscheiden zu können.

Akzeptanzkriterium:

• Visuelle Darstellung der Kategorien
• Konto der Kategorie A darf nicht Unter-/Oberkonto der Kategorie B sein

Notizen:
Für später kann man sich noch überlegen ob man Kategorien Regeln zuordnen kann wie bspw. Warnung wenn Kontostände der Kategorie A über einen bestimmten Betrag sind.

Ich als Kassenwart möchte einzelne Budgetpläne zusammengefasst angezeigt bekommen um zu wissen wie korrekt die Planung war.

Akzeptanzkriterium:

• Übersichtliche Anzeige der Budgets
• Bugetplan herunterladbar

• I added a context.SaveChanges() call after every repository method. however it should probably only be saved once for every request?

Current Account Model is a bit bloated with Id-like properties.

We have Meta.Id, Account.Number and Account.ShortName. As I see, both, Number and ShortName have the same intention, so we should remove one soon, to avoid confusion.

Hi, I would like to make this project public. So I can use appveyor.

Is there a reason to keep it private except schame?

The fronted needs a create account view

• using a directive with service would be advisable
• The account name should be validated before creating it(display an error if the name is taken)
• same for accoutn number
• account list should be displayed when selecting parent account
• account category list shoudl be display for selecting category.

It seems for an empty list of children, the property is currently null instead of empty list.

Is this the intended behavior? It means a lot of extra checking in other application layers, so I would prefer an empty list behavior if possible.

Ich als Kassenwart möchte Konten schließen können um sie bei Suchen oder Anzeigen zu verbergen und Buchungen auf sie zu verbieten.

Akzeptanzkriterium:

• Nur ausgeglichene Konten dürfen geschlossen werden
• Seperate Anzeigeoption für geschlossene/alle Konten

We need a comprehensive example that uses the whole of the accounting System

It should contain realistic Actions and execution orders

Story

• A user has created a Transaction which he wants to cancel
• The transaction has to be copied and the amounts inverted
• a cancelled transaction cannot be cancelled again.

Story:

• dev wants to test functionality of website through a browser
• dev wants access to database before, during and after browsing the website
• dev wants to test website on different browsers
• dev wants to look at internal state of web app during a browser request

Using Selenium (PhantomJS,Chrome,IE,FireFox) and Owin SelfHost it should be possible to allow for real End to end testing of the web frontend and the backend. TO create simple unit tests a base class is necessary which incorporates all the functionality fives the dev access to a Browser object (IWebDriver)

Ich als Kassenwart möchte Konten Budgets zuweisen um erarbeitete Budgetpläne direkt abbilden zu können und zu sehen wie weit ein Budgetposten ausgeschöpft ist.

Akzeptanzkriterium:

• Anzeige bei Konten die Budget haben mit Betrag
• Budgetpläne mit Gültigkeitszeitraum (z.B. Jahresbudget, Semesterbudget, ...)

Story

• User wants to create a Transaction
• He should be able to create an arbitrary amount of partialtransaction which
• the transaction has to be balanced when inserted into the database
• A Receipt is necessary for to perform a transaction
• A Receipt Date is necessary
• The Transaction Date of the partial transactions should be stored
• A Transaction needs to consist of at least 2 partial trasnactions

Die aktuelle Lösung, in der eine einzige Klasse (z.B. AccountingFacade) die Implementierung mehrerer Commands enthält, führt aus meiner Sicht zu vermeidbaren Designproblemen.

Folgender Plan für ein CommandHandler Interface:

public interface ICommandValidator<TCommand>
{
    bool Validate(TCommand command, out IEnumerable<ValidationException> ValidationErrors);
}
public  interface ICommandHandler<TCommand> : ICommandValidator<TCommand>
{
    void Handle(TCommand command);
}

Jedes Command lässt sich so unabhängig implementieren, die Validierung wird vom Handling getrennt.

Anstelle von AccountingFacade könnte eine Factory Klasse stehen, die die einzelnen CommandHandler Implementierungen zurückgibt und sich um Dinge kümmern kann wie z.B., dass Validate immer vor Handle aufgerufen wird.

public class AccountingFactory
{
    protected ICommandHandler<TCommand> DecorateHandler<TCommand>(ICommandHandler<TCommand> handler)
    {
        return new ValidatingHandlerDecorator<TCommand>(handler);
    }
    public ICommandHandler<OpenAccountCommand> OpenAccountCommandHandler()
    {
        return DecorateHandler(new OpenAccountCommandHandler());
    }
}

Hierbei ist OpenAccountCommandHandler die eigentliche Implementierung und ValidatingHandlerDecorator ein Wrapper, der dafür sorgt, dass Validate IMMER vor Handle aufgerufen wird. Auf ähnliche Weise lassen sich dann auch andere Querschnittaufgaben per Decorator einpflegen - z.B. die UnitOfWork Injection.

Story

• user has an existing account which he wants to modify
• user should only be able to modify select fields
• afterwards the account should exist in the modified version in the database

Ich als Kassenwart möchte Aufgaben erstellen um wichtige Aufgaben (z.B. Aktivenbeitrag) nicht zu vergessen und sie direkt im Kassenprogramm zu sehen.

Akzeptanzkriterium:

• Anzeige aller Aufgaben
• Optionales Fälligkeitsdatum
• Wiederholungsrythmus einstellbar (z.B. alle 3 Monate)

The Model is created, However the EntityFramework model has to be created via the OnModelCreating method .

I thought of an easy way to implement authorization logic.

Create a injected service (ISecurityService) which has a method IsAuthorizedFor(object) at the beginning of every command handler you call securityService.IsAuthorizedFor(cmd) . it throws a security exception if not. The first implementation just lets it pass through (dummy implementation)

Discuss!

Story

• the developer wants to create a test easily for an interface
• the database should be initialized accordingly (empty database)
• sensible utility and helper functions should be added

Instead of accessing the Repositories (datalayer) directly the frontend should also use a command to query the business layer which queries the data layer

this allows implementing privileges for views / not showing inactive accounts, etc

• The accounts should be listed
• selecting an account should display its details
• in Details view an edit action should be possible

Ich als Kassenwart möchte Buchungen zwischen mehreren Konten durchführen um Rechnungen und Zahlungswege abzubilden.

Akzeptanzkriterium:

• Warnung bei gleicher Buchungsnummer
• Nur ausgeglichene Buchungen werden zugelassen (Soll = Haben)
• Buchungen können angezeigt werden
• Kontostand wird korrekt angezeigt

Notizen:
Attribute: ReceiptNumber, ReceiptDate, Text

Ich als Kassenwart möchte Konten anlegen um Buchungen zwischen Konten durchführen zu können.

Akzeptanzkriterium:

• Keine Konten mit gleichen Nummern
• Erstellte Konten können angezeigt werden

Notizen:
Attribute: Name, Number, ShortName

I think IUnitOfWork should use Db transactions to work. The problem did not occur yet but while developing I noticed that I often query and then modify&delete entities however these entities could already be deleted. therefore the concurrency management would have to be implemented(probably once per unit of work)

thoughts?

Ich als Kassenwart möchte nach Konten suchen können um nicht die komplette Liste durchgehen zu müssen.

Akzeptanzkriterium:

• Perfomante Suche
• Suche nach verschiedenen Attributen

Ich als Kassenwart möchte nach Buchungen suchen können um nicht die komplette Liste durchgehen zu müssen.

Akzeptanzkriterium:

• Perfomante Suche
• Suche nach verschiedenen Attributen

Ich als Kassenwart möchte Rechnungen verschicken an Kunden um zu Zahlungen auffordern zu können.

Akzeptanzkriterium:

• Rechnung enthält alle Buchungen ab eingestellten Datum
• Buchungen vor eingestellten Datum werden als Saldovortrag zusammengefasst
• Rechnung über E-Mail mit Template Text (Konto worauf man es überweist usw) und Rechnung als PDF Anhang

Notizen:
Wenn Kunden ihren Kontostand online selber nachschauen können, kann man auf die Rechnung noch einen Link zum Konto einfügen.

Ich als Kassenwart möchte Buchungen stornieren um Fehlbuchungen zu korrigieren.

Akzeptanzkriterium:

• Buchungstext der Stornierung macht klar welche Buchung storniert wurde
• Stornierung hebt Fehlbuchung korrekt auf

Story

• User has an existing (open) Account
• User wants to close account
• account can only be closed if it is balanced
• account should only be marked as closed and not removed
• the closure date should be marked

Is it more usefull to throw an exception if a command is invalid or would it be better if the command gets a list of messages (info, warning, error) which the gui can then display

example.

when creating a transaction many things can go wrong, from argument null to invalid transaction balance.

I think it would be usefull if the command would get all information about why it is wrong so this could be displayed in the user interface?

A solution would be creating a command base class which contains a list of validation messages, possibly using a validation framework.

Ich als Kunde möchte meinen Kontostand abrufen um zu wissen ob ich Guthaben/Schulden habe.

Akzeptanzkriterium:

• Authentifizierung um Kontostand zu sehen
• Anzeige aller Buchungen auf meinem Konto
• Herunterladen der Rechnung als PDF

Notizen:
Eventuell für später Interessant, da wir eh eine Web-App Architektur haben. Die reine App um Kontostand anzuschauen kann auch eine seperate Web-App sein.

I would suggest creating a single page web application (from scratch)
using OWIN / WepApi or SignalR / angularjs

Story

• Necessary Account Categories should be created by business layer on intialization
• It needs to be clear wether the end user may create categories or not.

Ich als Kassenwart möchte Konten bearbeiten um Informationen zu korrigieren und zu aktualisieren.

Akzeptanzkriterium:

• Geänderte Informationen werden angezeigt
• Kontonummer muss die selbe bleiben
• LastModified muss übereinstimmen mit Änderungsdatum

Ich als Kassenwart möchte Konten in Baumstrukturen (ein Konto mit mehreren Kindern) anordnen können um Familien an Konten zu schaffen welche logisch zusammen gehören und Überkonten alle Buchungen der Unterkonten zusammenfässt.

Akzeptanzkriterium:

• Gesamtübersicht aller Konten in Baumstruktur
• Detailansicht des Kontos zeigt Oberkonto und alle Unterkonten an
• Buchungen/Kontostand wird korrekt zusammengefasst

• Webdeployment for single click publishing
• accounting.greenno.de

Story

• A user initializes the Accounting System and wants to Create the standard Accounts
• The Facade should provide a method to initialize the Account System if the database is Empty

Story

• user needs a new account
• user at least enters account name and number
• name and number must be unique
• name and number may not be empty
• category is optional - default category is used
• account parent is optional - possibly a default is used

To facilitate test driven developement and correct versions every commit to master should be automatically tested.