-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Company card #101
Company card #101
Conversation
Initial fields for company-card
</div> | ||
<div className="form-message"> | ||
<Text> | ||
Verbruik achter de meter. Inclusief verbruik van eigen opwek. Exclusief verbruik van laadpalen. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GillisHommen is dit correct als toelichting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ja dit is correct idd, wbt verbruik achter de meter. En ook wbt laadpalen, maar dat doet me eigenlijk denken dat we die 'laadpalen' optie voor nu ook beter kunnen weglaten; het verbruik daarvan zit namelijk al in het brutoverbruik.
Alternatief zou nog kunnen zijn dat we 'levering' laten invullen ipv bruto verbruik. Maakt voor de laadpalen op zich niet uit, maar levering is een getal dat ze van een factuur kunnen aflezen, bruto verbruik niet.
Nog een variant is om totale levering en totale teruglevering te laten invullen, samen met geïnstalleerd vermogen PV... Met het 'risico' dat men inconsistende getallen kan invullen. (een combinatie van drie getallen die niet echt mogelijk/feasible is)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Voor nu laadpalen uitgecomment. Als we tot een beter inzicht komen kunnen we het aanpassen.
Reminder client.jar hercompileren |
Part of #12
misschien dan ook in de comment van het brutoverbruik niet meer de laadpaal noemen [edit] Nevermind, zie dat je dat al gedaan hebt (Y) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments but looks good to merge.
@@ -58,12 +58,21 @@ data class Pilot( | |||
} | |||
|
|||
// Extension function for List replacement | |||
private fun <AssetType> List<AssetType>.replaceAt(index: Int, newAsset: AssetType): List<AssetType> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can it be renamed more generic as "SimulationElementType" to keep it strong typed? So the company can be included.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought there was a bug but I was mistaken. I shouldn't have done this change together.
AFAIK the code is still as type-safe as it was before.
I don't see the point of putting all the Pilot properties in the same type hierarchy.
No description provided.