Building- > Entrance -> Appartement -> Contract
The business is about providing accountancy services to the owners of large buildings or organizations that take care of the building when each apartment is owned by a different person.
The first thing to add is a building, it's entrances (each entrance has a different address) and the apartments in the building.
ApartmentAttributes are properties of the apartment such as bodycount (how many people live in the apartment at the time) which can change every now and then. !!!Attention!!! -> Each change is represented by a new ApartmentAttributeValue.
Then we need to add the contracts - who owns and who lives in each apartment.
When adding a new building, most of the data about apartments, contracts and people are loaded from an external database or an import file.
Next we need to tell the system what fees should the people pay and how to calculate the exact amounts (since they can differ each month but can be calculated). This is represented by the FeeRecipe entity.
Each contract usually has around 5-10 FeeRecipes.
there is a FinancialAccount entity between Contract and FeeRecipe. Most often each contract only has one FinancialAccount but in some edge cases there can be more. This is required because the Fees on different FinancialAccounts are treated a bit differently in some cases based on the attributes of the FinancialAccount but the details are unimportant.
Next looking from the other side of the diagram there is an AccountingOrganization. In most cases an AccountingOrganizations is 1:1 with Building but there are exceptions with one AccountingOrganization handling multiple buildings and also exceptions with one building being split to multiple AccountingOrganizations. Therefore we made them completely independent. +1
Finally the ContactCard represents a Person or Company and can be referenced pretty much anywhere in the system. It can be an employee of our company, an owner of an apartment, an organization managing a building, a contractor our company cooperates with etc.
Maybe this context and FeeCalculating belong to the same core context?
These people need to pay some fees every months which is where our company comes in - to help determine what fees they should pay and observe if they are indeed paying them.
At the end of each month an automated process takes each (still active) FeeRecipe and generates a new Fee for it for that month. The calculation requires the formula from the FeeRecipe and the current ApartmentAttributeValues on the related Appartment.
FinancialAccountGroup is actually a brand new entity we came up with just this morning after discovering some serious problems in our PaymentAllocations process. Basically it's a group of FinancialAccounts that holds some options how should the Payments be allocated to Fees. FinancialAccountGroup is actually the scope for the PaymentAllocations process - take all not-fully-allocated Payments and FeeItems related to the FinancialAccountGroup and do the process described in the previous issue.
PaymentPreference holds a reference number that we can use to match a given payment from the import to a specific person and FinancialAccountGroup. The process of matching imported payments to people converts UnassignedPayment to Payment.
This is one of the reasons why I created the issue. I don't know what is correct here.
On one side Fees and Payments are totally independent:
But then the final goal for both payments and fees is to allocate them to each other. Of course this can only happen after fees are generated and all payments for certain time period imported and assigned to clients.
So yeah, this is one of the cases where I'm really unsure if they should be in one BC or not. What do you think? And more importantly why?
Note: I didn't have time to go through the resources you linked yet. I'll do that asap.
In FeeCalculating you have a "Needs Clarification" note. What should I clarify?