How we can update custom field after entry is done about medici

[Uzlopak]

tldr; You dont

Your question seems odd. In classical accounting the ledger is not mutable. You should never manipulate the entry in the ledger after it is written. Imagine you have a physical book for classical double accounting. There you can only write with permanent ink into the T-Tables. There is no erasing or manipulating of entries in the ledger. At the moment you start to manipulate the entries in the ledger, you can not trust it anymore.

In accounting it is important that you can always determine the balance of any relevant accounts. There is no semi state of an entry. So if I ask you how much credit a customer has, than you can not say based on the entries, that it is 100 € and after 2 minutes, after you manipulated the entries, tell me it is 200 €. I repeat: If your entries show me at 12 oclock pm that the customer has 100€ then you can not say at 12:02 oclock pm that it is 200 €, because some pending transaction finalized, even though the amount of entries did not change. Imagine you want to file your taxes. You can not say, hey my fiscal year starts in january and I wrote the invoices for january on 31st December 2022 so all my income in january is part of my previous fiscal year, even though my customers transfer the money on 1st January 2023. At the moment you have the actual power of disposition of the money it is relevant for the ledger. So yeah, I can found a company and write invoices with a value of 1 billion Euro, but that doesnt mean, that I have 1 billion euro in my pocket and can do with the money as I please.

Transactions are not Schroedingers Cat.

So if you can not manipulate the ledger entry, this means that you have to use a different approach. And this means using of more T-Tables or using of more Entries. What does this mean?

Incoming Money/Assets:
Customer A sends you money via Bitcoin. You register the incoming bitcoin transaction from the rpc channel from bitcoind. You write the transaction into CustomerA:pending so you can already show the customer on your website that you see the transaction. Then you wait till the bitcoin transaction is over the treshold of necessary confirmations and you accept it as written into the blockchain and then transfer the pending amount from CustomerA:pending to CustomerA:account. But if the bitcoin transactions fails e.g. because of double spending, then you transfer the pending amount to CustomerA:failed or somewhere else.. But for detemining the balance you only use CustomerA:account, as it is the single point of truth for the balance of the customer. So thats why you dont directly transfer the pending transaction to CustomerA:account.
In classical banking you would say, that the unconfirmed bitcoin transaction is an avis/Remittance advice and the confirmed bitcoin transaction is the finalized banking transaction. And only finalized transactions are relevant in booking.

Outgoing Money/Assets:
Customer A wants to withdraw/refund from his account. You transfer money from customerA:account to customerA:pending if it is someting like bitcoin. Or you immediatly deduce the money from the account and say, the money is gone. Doesnt matter if you put it on pending or immediatly set it as succeeeded, as the customer will complain if the money did not transfer on his account. Then you need anyway to look into it. But if it is a bank transaction you just know that you sent the money, so it is just necessary to keep the bank transaction id in your ledger entry to keep it traceable.

If in any case a transaction fails, you can make a Storno which is basically the void method of an LedgerEntry in medici.

And always keep in mind, that the ledger is YOUR single point of truth. Meaning: You first write the entry into the ledger and then you trigger the relevant process. E.g. You sell gold online. The process is: Customer orders x amount of gold, you check if the customer has enough credit in his account by atomically reducing the amount of money for the order and then if it is sucessfully written into the ledger, you trigger the following process which ends with you sending out the gold. This means, that if the ledger has an issue and/or you fail at writing into the ledger (e.g. not enough balance), you just throw an error and dont send the gold out.
Imagine the bad alternative: Customer orders Gold, you check that the customer as enough money, prepare the Gold for sending and ship it away, and in the last step you write into your ledger. This would mean, that if your ledger has some issue, your customer gets anyway the x amount of gold but your ledger does not reflect that because of the error. The customer has still "enough" money in his account as the amount was never reduced from the account of the customer. So he can order again x amount of gold. Resulting in you losing the money by basically gifting the gold to the customer. Again: YOUR ledger is YOUR single point of truth. It doesnt mean, that it is perfect, nor does it mean that it is even correct. You can have accounting errors. But!: An accounting error should be never to your disadvantage and in best case not to the disadvantage of the customer. A customer will complain about accounting errors to his disadvantage, but never to his advantage.

So e.g. customer sends money and it never shows in his account. That doesnt mean, that he lies or that he wants to defraud you. You will check the claim of the custome and validate if he really sent money to you. You see it is in the bank account. You check your ledger and see that you missed his money transfer. Then you add manually the transaction to your ledger as you determine that it is the truth. Again: It is YOUR single point of truth.

So be always really conservative when doing accounting related operations.

Looking foward for your feedback

[prathameshv5]

hey @Uzlopak , this exactly what I wanted to do. your suggestion really helped. thanks a lot!!

[koresar]

Transactions are not Schroedingers Cat.

👏