# New BV Flow

For the new BV flow, we have tried to build a middlewear that translate from regular parameters (JSON structure comming from frontend app) to FormBuilder Format(FBF).
After working for a few days on this, we have realised the amount of cases we have in this questionnaire is considerable big.

#### Issues found

* Variables are not descriptive enough
* Many variables in Dutch language
* Many conditional cases

#### Idea

An idea to solve this mapping issue with FBF would be to avoid it completely.

**How?**
Now we have our frontend app. It will manage all the logic of the questionnaire by itself. Giving us more flexibility inside the questionnaire.
Basically, we will receive now a set of variables (JSON) with the values the user has specified during the questionnaire. Using those variables, we should be able to generate the documents.

In order to complete the flow we should find a way to map the variables coming from the frontend app to FBF. This way the documents will be generated using the same variables as always. This mapping is really complex to implement due to the amount of logic involved. Also, worth to mention that if any of the variables is changed, the mapper will need to be changed too.

We can skip FBF and generate the documents using our variables (the ones coming from the frontedn app) and this way, we get rid of FBF for the Dutch BV Incorporation flow. We can skip the huge logic to get those values out of FBF and pass it directly to the document generator.

**Incovenients?**
We will need to replace the variables in the 7 documents of the Dutch BV incorporation for the new ones.

#### Technical Details

A `Notary Product Type` (the template with the variables) will have a JSON configuration column to store all the possible keys for each `Notary Product Type`. This configuration will be used as a template for the future types generated. (This is the same we do right now)
The `Notary Product` will have another column to store the JSON config with the values especified. Those values will be provided by the frontend app as mentioned before.
Then, once we have every value provided for the end user we need to generate the documents.
Document generation is based on `MailMerge`. This mean we can provide the variables and the values. The values will be replaced in the document keeping the format.
This will be possible only after replacing the document with the new variables. Otherwise, we won't have anything to replace.

Right now, we have a huge logic to convert FBF to a hash with variables and values that are valid for the document generator. Those are the values we pass to the document generator and each questionnaire has its own.

The idea would be to use a new JSON format, we need to define it but it should look similar to this one:

{
  "company_name": "whatever picture bather B.V.",
  "address": "Some place in the Netherlands"
  ...
  "shareholders": [
    {
      "p1": {
        "is_natural_person": true,
        "is_new_company": false,
        "is_existing_company": false,
        "natural_person": {
          "address": "Another far far away place"
          "first_name": "John",
          "last_name": "Doe"
        },
        "new_company": {
          "headquarters": "A place far far away"
        },
        "existing_company": {
          "headquarters": "A place far far away"
        },
        ...
      },
      "p2": {
        "natural_person": false,
        "new_company": true,
        "existing_company": false
        ...
      },
      "p3": {
        ...
      }
    }
  ]
}

#### Advantages

* More readable format
* Easy to understand
* Conditions can be managed in frontend app giving more flexibility.