4 ms·
I also had a previous job doing exactly that... but it was an billing / accounting system at a print company. Certain large customers (a bank, an airline) had
by tacostakohashi 8y ago
I also had a previous job doing exactly that... but it was an billing / accounting system at a print company.
Certain large customers (a bank, an airline) had contracts where they would order large batches of printed forms, luggage tickets, sick bags, etc, at some negotiated quantity / price (taking into account the size of the print run, our capacity at the time, etc.). We (the print company) would then print it and warehouse it, and ship it directly to their individual locations in smaller batches as they ordered it.
The billing was done on some cost + shipping basis, so at the end of the month you'd have to look at everything that was shipped, work out which original batches going into inventory that came from on a FIFO basis, and then use that as a basis for the cost plus billing.
It was a horrible messy old codebase, and it was sometimes difficult to explain the results.
Anyway, I just thought I'd share this as an example use-case for a sufficiently generic / flexible / reliable implementation of your potential side project.
- jerry40 8y agoIt is the interesting idea to make this tool as generic as possible! Like a framework for matching different types of events based on some rules + a visual explanation for any chain of matched events. Perhaps I should think about this idea. Thanks!
- tacostakohashi 8y agoYeah, and the visual explaination part is actually just as important as getting the right results. For any complex system with financial impact there will always be people claiming that the output is wrong, so you need to be able to quickly and easily justify everything.
- jerry40 8y agoYes, I agree. Sometimes there were so tricky cases that it was impossible to explain why that tool matched those deals.