Comments (5)
Hi @lgrkvst ! Thanks for the interest you show to our ledger !
That's a good question, the ledger does support accounts going negative. It used to allow it by setting a mapping, that would allow specific accounts to go into negative (let's say overdrafts accounts for example). Currently, we recommend using our no-code solution numscript, which allows you to specify on a transaction level that you allow an account to go negative up to a certain amount.
All of this is checked at the transaction level, the engine does not perform "cron like" processes !
I like the idea of a limit attribute, it might allow for a more thorough distinction between the accounts, i'll discuss it with the team to know wether an account wide solution might be needed (be it alongside or instead of the transaction wide) in the short term !
I can provide you with some examples or documentation if you need :)
from ledger.
I think credits are not related to accounting in any way.
@lgrkvst Here is my idea how you can do it:
In contract of spending money from account, create overdraft
directive with amount of credit limit for your transaction:
send [COIN 100] (
source = @user allowing overdraft up to 500 // or 'allowing unbounded overdraft'
destination = @store
)
Then, (@jdupas22 @flemzord @altitude correct me guys if i'm wrong please), ledger sending notifications about transactions via message queue. If you got a notification, that @user
's balance is negative, create a "credit agreement" with user, that they need to pay X coins per X months, to cover their credit using scheduled payment. For example:
send [COIN 100] (
source = @user:pending
destination = @your_bank
)
set_tx_meta("payday", "2022-12-20")
Or something like this.
To be honest: i'm really newbie here, so i suck in writing contracts, but definitely what i can say that you can do this credits mechanics by yourself, ledger is already too complex as i can see in the source code, and currency conversions (really important feature) can't fit in existed system (because, like credit system, it is also such a complex shit)
@flemzord @altitude correct my answer and thought about credit feature, please, maybe i'm wrong about both of these parts
P.S. If this idea sounds good for you, you can add this guide in usecase library if you want, but credit me in this guide please
from ledger.
@quenbyako: Surely you could solve any use-case without the notion of negative balances. Depending on what you want to solve, the downside might be that the system becomes overly complex.
At the end of the day it's down to what product you're aiming to build, and that may be the issue at hand: I cannot picture a real-world use case where it makes sense to dictate overdraft at the tx level, nor an example where the account holder (sender) gets to choose whether to overdraft or not. On the contrary it introduces the kind of complexity that you're solving above by entering account holders into credit agreements after the fact that their account has already been overdrafted.
Credit should be an attribute at the account level.
@jdupas22: I agree checking should be done at tx time. Cron jobs are better suited for interest calculations.
Having that said, both FX and interest calculations are at least to me way beyond the scope of a ledger microservice.
from ledger.
Hey @quenbyako ! You're kind of right :) But usually i you'll want to use a specific pattern of numscript file for transaction that are "allowed" to generate overdrafts. So the solution would be like you said, listen to the ledger events and taking actions when some accounts go in negative. I think the "slippery slope" here is that this starts to be a bit too deep in the user's logic. The ledger in itself aims to be a generic but customizable solution.
We can imagine a rule to subscribe to specific events (like creation of overdrafts) in the future though ! I'd be very interested in seeing this unfold. I'll discuss it with the team !
@lgrkvst Exactly, there is a lot of ways to solve most problems in the ledger currently, the flexibility of accounts makes it so that most can be solved simply by adding some steps to the payment flow, and sometimes a bit of backend actions for the user.
However, i agree that the "credit" attribute should be set at the account level. That's something we're working on. We were not really happy about the design solution of the mapping we had at account level, so it's going to be iterated on in the near future. Obviously, the Numscript solution to define the overdraft at the transaction level is not perfect either, but it allows us to solve more immediate problems for some of our users, and to find the time to implements a better solution soon :)
Don't hesitate if you have any other question ! I'm also tagging @altitude here in case he has something to add !
from ledger.
Hey guys ! I'm going to close this issue since it seems not to be active anymore ! Don't hesitate to come talk with us at https://formance.com/slack if you have any question about it (or something else) !
I'll try to ping both of you once we have a better solution making its way into a PR ! :)
from ledger.
Related Issues (20)
- Balances aggregation HOT 1
- First class support for transactions relations
- Filter transactions by metadata
- Filter transactions by metadata HOT 1
- This kind of code is duplicate 3 times. HOT 1
- Numscript: set_tx_meta not accepting string vars values HOT 1
- bug: Can't run example HOT 2
- initializing ledger store: open migrates\\0-init-schema: file does not exist HOT 1
- Support for back dated transactions HOT 6
- Negative values for account balance HOT 3
- Ledger creates a segment connection / client even when Segment is disabled. HOT 3
- Usage of a different stream HOT 2
- Connection pooling? HOT 1
- Duplicate key violation on id when handling concurrent requests HOT 10
- Bug: with --telemetry-enabled=false flag numary still sends data to twilio HOT 3
- Allowing unbounded overdraft does not work correctly HOT 2
- Colour of Money
- Integrate pull request preview environments
- Ledger Container with latest version that is v1.19.1 does not work HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ledger.