Payment manager done preliminarily.
Well, it has been a few days, but work has been hell (well, not in a bad sort of way, just busy). On vacation now, and took a bit of time to work at the project today. Won't really dive deep into until Monday or Tuesday so I can have a bit of a weekend.
I'm too lazy to re-read my blog posts, but I think I left off pretty much right after I finished work order entry. I had debated talking about my "active history grid", which I suppose I will give a quick dive into. Basically, it is just another data grid in terms of appearance, but I have created a basic object format which provides a means of specifying an event to trigger on double clicks. For orders it bring up the order editor, for customers it brings up the customer grid, pre-filtered, etc... After some debate with Veronica on what it should look like, it now has a slightly better look.
But that was the small battle. As I said in my last post, it was more conceptually cool and fun than it was difficult since everything I wanted worked in the first try, and most of the hard work had already been in creating the more complex screens they triggered.
The larger battle, was behemoth number 2. Handling payments and check outs of orders... I may split this into 2 functions eventually. I will throw it at my parents and brother first and let them decide. For the most part, everything is still hideous. I have put no effort into design except going far enough to give an idea of what things can and/or are intended to do.
Payments is a bit of a nightmare as well simply because the work orders were a nightmare. It wasn't AS bad, but it was close. With special orders tied in I have scenarios where stock may not actually be affected at all because they weren't manually received. Same with payments for them. So on completion of the order, it first completes any unfinished special orders, then removes the remaining stock from inventory and then sets the order to completed. From there (or even before then) the user can apply payments which need to be tracked for accounting purposes. I'm tracking in multiple places, I have a log and an entry with the order for the payments. At the end of the day... the log will probably be the place to go with the records as back up. Reason being something I hit in Veronica's software... not all transactions are tied to orders, things like variances in the till at the end of the day, or buying coffee. Since those activities have nothing to do with orders, I can't throw those transactions in there which makes life hard. Having a table dedicated to these things makes that easier, but it also means I need to track changes in 2 places to keep the books balanced.
I'm going to hate myself when I start building in functionality to change orders and payments. Well... actually for payments I'm copping out. Forcing the user to enter negative entries instead. I suppose that COULD be enough data.
Oh well. This screen is even uglier than my order entry screen so I won't subject anyone to screen shots. I think my parents will respect how I was able to keep to their requests on the order entry screen, so despite the ugly, I can live with that one.
Now. Time for hot chocolate.
I'm too lazy to re-read my blog posts, but I think I left off pretty much right after I finished work order entry. I had debated talking about my "active history grid", which I suppose I will give a quick dive into. Basically, it is just another data grid in terms of appearance, but I have created a basic object format which provides a means of specifying an event to trigger on double clicks. For orders it bring up the order editor, for customers it brings up the customer grid, pre-filtered, etc... After some debate with Veronica on what it should look like, it now has a slightly better look.
But that was the small battle. As I said in my last post, it was more conceptually cool and fun than it was difficult since everything I wanted worked in the first try, and most of the hard work had already been in creating the more complex screens they triggered.
The larger battle, was behemoth number 2. Handling payments and check outs of orders... I may split this into 2 functions eventually. I will throw it at my parents and brother first and let them decide. For the most part, everything is still hideous. I have put no effort into design except going far enough to give an idea of what things can and/or are intended to do.
Payments is a bit of a nightmare as well simply because the work orders were a nightmare. It wasn't AS bad, but it was close. With special orders tied in I have scenarios where stock may not actually be affected at all because they weren't manually received. Same with payments for them. So on completion of the order, it first completes any unfinished special orders, then removes the remaining stock from inventory and then sets the order to completed. From there (or even before then) the user can apply payments which need to be tracked for accounting purposes. I'm tracking in multiple places, I have a log and an entry with the order for the payments. At the end of the day... the log will probably be the place to go with the records as back up. Reason being something I hit in Veronica's software... not all transactions are tied to orders, things like variances in the till at the end of the day, or buying coffee. Since those activities have nothing to do with orders, I can't throw those transactions in there which makes life hard. Having a table dedicated to these things makes that easier, but it also means I need to track changes in 2 places to keep the books balanced.
I'm going to hate myself when I start building in functionality to change orders and payments. Well... actually for payments I'm copping out. Forcing the user to enter negative entries instead. I suppose that COULD be enough data.
Oh well. This screen is even uglier than my order entry screen so I won't subject anyone to screen shots. I think my parents will respect how I was able to keep to their requests on the order entry screen, so despite the ugly, I can live with that one.
Now. Time for hot chocolate.
Comments
Post a Comment