I program billing systems, and even account reconciliation systems for payment processes. It's not a nightmare, it just take a greater understand of accounting. If you want to be an engineer that works on financial systems, take the first year of classes that accounts have to take and pay attention.
Billing systems are a nightmare for engineers
271–280 of 372 posts
Re: Billing systems are a nightmare for engineers
#272> Another option is to rely on existing billing platforms, built by specialized teams. If you’re considering choosing one or switching, and you think I can help, please reach out!
To note, this option only absolve of _some_ of the complexity and burden. You still have to understand:
- what problems the billing platforms is solving for you, how they're solving it (does it match the process you need ? -> you also need to know how it should work) and what to provide them to make it work.
- what problems they are _not_ solving, and you need to deal with on your end
A good service provider will help you at least on the first part, and educate on the parts you need to be aware of, but there's always dark corners that easily get overlooked if the business owner didn't do their homework.
Re: Billing systems are a nightmare for engineers
#273Basically everything about enterprise is a nightmare for engineers. What amazes me (after having worked at some of the most profitable companies in the world) is just how little intelligence the leadership has about their own revenue or costs, beyond "wow huge amounts of money is coming in or going out". And how many critical processes are implemented manually, by individuals, with personal spreadsheets, on their lap…
Yep, I'm about ready to start implementing one of those very spreadsheets just to start trying to categorize Azure costs.
Re: Billing systems are a nightmare for engineers
#274Earlier quoted context omitted.
By "temporal model" do you mean relational tables of "customer X used Y amount of this resource at price Z from timestamp A to timestamp B" or ... ?
In field metering situations you can have the timeline of each meter, when it records data points, and then you have the different timeline of the backend service, when it actually _receives_ data points. Bonus points if the meters can send data out of order.
I did a tender for aggregating events and emitting notifications from a fleet of transport vehicles that reported metrics over LTE.
When connected they would emit events as they happened, but when there was poor service or disconnection they would buffer them and send them as a burst once they reconnected... in reverse order.
I forget the finer details, but the service I was writing was supposed to notify of trucks entering and leaving geofences, inactivity etc. anything you can think of where the order of events is important.
Re: Billing systems are a nightmare for engineers
#275(1 of 2) In the 00's, I was part of an effort to get the State of Oregon to consider open source software. A 40 million billing system debacle was part of what drove this effort. The details are not important, save to say the ASA paid big to stall the legislation and that worked. It was stalled, and word got out that future bills would be toxic. So, that's over, but a great idea remains! I am putting it here, because…
(2 of 2 --> I got "comment too long!) Now, this won't be popular with a lot of us here, myself included, as doing stuff like this will displace some revenue streams companies and people depend on. However, a longer view looks considerably more attractive. The jobs created are needed. Tie this stuff into education, and it's a perfect "farm" training ground for up and coming developers to work on important projects and…
[deleted]
Re: Billing systems are a nightmare for engineers
#276Wait until you get into the complexities of taxation. If you think you know them, pay attention to https://twitter.com/aotearoa_ben/status/1526786701750050817 . That's a law that changes the tax rate if 1. The purchase happens in Texas. 2. The payment cleared in a specific 2 day period. 3. The item cost Seriously, calling out just one example, https://comptroller.texas.gov/taxes/publications/98-490/scho... points out…
I used to work at a company that managed the systems for back of house in fast food chains. We moved customers from excel to an online system. Omg when it came to doing labouring in the US. It’s scary.
If a person clocks in at 9:52M. The company only has to pay them from 10am. But in other states they must pay from 9:45am. There’s so much complexity in the us due to all states being different.
Re: Billing systems are a nightmare for engineers
#277Wait until you get into the complexities of taxation. If you think you know them, pay attention to https://twitter.com/aotearoa_ben/status/1526786701750050817 . That's a law that changes the tax rate if 1. The purchase happens in Texas. 2. The payment cleared in a specific 2 day period. 3. The item cost Seriously, calling out just one example, https://comptroller.texas.gov/taxes/publications/98-490/scho... points out…
We should demand governments to maintain and provide an API for their tax codes. Let them have skin in the game. If the taxes are incorrect, businesses can point out that it’s the government API’s fault.
Completely developed in the open, and with full test coverage.
This should be required to collect taxes. No API? No taxes. API down? Tax waived.
Re: Billing systems are a nightmare for engineers
#278Wait until you get into the complexities of taxation. If you think you know them, pay attention to https://twitter.com/aotearoa_ben/status/1526786701750050817 . That's a law that changes the tax rate if 1. The purchase happens in Texas. 2. The payment cleared in a specific 2 day period. 3. The item cost Seriously, calling out just one example, https://comptroller.texas.gov/taxes/publications/98-490/scho... points out…
We should demand governments to maintain and provide an API for their tax codes. Let them have skin in the game. If the taxes are incorrect, businesses can point out that it’s the government API’s fault. Completely developed in the open, and with full test coverage. This should be required to collect taxes. No API? No taxes. API down? Tax waived.
Why would you do that when you could just lobby the government to make the tax code even more complex, then sell a service to handle that complexity for you under the threat of jail time if you get it wrong?
Re: Billing systems are a nightmare for engineers
#279Wait until you get into the complexities of taxation. If you think you know them, pay attention to https://twitter.com/aotearoa_ben/status/1526786701750050817 . That's a law that changes the tax rate if 1. The purchase happens in Texas. 2. The payment cleared in a specific 2 day period. 3. The item cost Seriously, calling out just one example, https://comptroller.texas.gov/taxes/publications/98-490/scho... points out…
We should demand governments to maintain and provide an API for their tax codes. Let them have skin in the game. If the taxes are incorrect, businesses can point out that it’s the government API’s fault. Completely developed in the open, and with full test coverage. This should be required to collect taxes. No API? No taxes. API down? Tax waived.
“We” the engineers (working for the government) still have to develop those APIs and the backends that power them.
The only way to reduce the pain instead of just shifting it around would be to massively simplify the source of truth - tax codes and laws.
Re: Billing systems are a nightmare for engineers
#280Earlier quoted context omitted.
>they simply cannot pay you. Do people ever stop and wonder WHY in nations like Portugal the informal economy is roughly DOUBLE of say the US? When every invoice must be available to the government, what actually ends up happening is non-conforming invoices either get made up by the customer or the money magically flows out under some other auspice. Making it literally illegal to accept an invoice that is legal in th…
Quoted post unavailable.
> it's against your freedumbs
You don't even know what freedom is or how fundamental an issue it is to the United States.