Jaymes

Hi,

I started a course in the UK on VB 6 but left to move to Cyprus before I started on any heavy duty stuff (variables, database applications, etc).

At my current work, my boss has told me that I have 1 year (starting from 13.05.2005) to create a simple commission payroll system. I have one already on excel, but it is not even 30% error proof as I go on to explain. As I am 10% familiar with VB 6, I thought the best place to start would be VB.NET, which brought me to you guys.

Here is what I have to create:

A program that allows a user/s to enter bookings, and from those bookings, calculate the commission to be given to the sales reps. It should also allow me to print and view reports via pdf.

Stage one: Enter Bookings:

I already have this system on my excel spreadsheets, but it is very error prone. I have a worksheet for every rep and then have the following fields:

Client's Surname & Initial,
Booking Number,
Tickets,
Booking Amount (seperated into 3 different columns as some bookings are made in £GBP, $USD or EURO),
Payment Method,
Payment Number,
Booking Date, &
Comments.


The problem with this system is that when admin hand me down the commission sheets, they sometimes make mistakes and so put a booking onto two or three reps at the same time. If I had a proper system, the system would let me know if the same booking number was on another reps commission as each booking number is unique.


I know I am asking a lot, but can anyone guide me or direct me in how I should start?


Best Regards


Jaymes

LOI Kratong

I sort of posted in the other one you started before reading this, so if you've already started VB then ignore what i said...

__________________
www.heldtogether.co.uk

Bharathi

Hi,

Split the project into small problems and post it

Regards
Bhar
Books for programmers
http://www.vkinfotek.com

Wraith Daquell

I would definitely break it down into small segments, each encapsulated in its own class. This helps immensly in debugging.
My preference is a diconnect of information:

GUI front end - communicates with
Class Data - holds data to be formatted by
Class Formatter - sends formatted data to
Class Print - or
Class PDF

However you do it, you should probably use a relational database (not an object database). That means getting your hands into SQL, which is fun and productive anyway. With a good database (I recommend MySQL) and some SQL, you're double-booking could disappear in lieu of some warnings.

For formatting you should probably look into GDI+. This would make it extremely easy to print to a PDF or plain paper. Another great option would be to buy a PDF library for .NET; the advantage being assurance of the PDF quality.

The GUI front-end I would design last, as data seems to change and wreck the original design (my products go through major face-lifts...). It should optimally be completely disconnected from the other classes except for references. This way, you can port the classes to other projects and debug them (not that your code would ever contain any bugs ) easier. Also, if you have password protection, a disconnect of the GUI from the Data would make it infinitly easier to secure.

Just my two cents here.

__________________
The meek will inherit the earth.

-WDaquell

Dameon

Perhaps you should switch to C# right now Don't make the same mistake that I have! I got sucked into VB .Net. Great language! But the party is at C#, so good luck finding (interesting) jobs with VB. Anyway, it is true that you should encapsulate many things into classes, but I wouldn't take the given examples (which are very good, I might add) too rigidly. It really depends on what you are personally shooting for. Something to watch out for, though. Whatever data backend you have, be it an SQL, Access, Oracle, text file, whatever, you should definitely encapsulate that in a class. What you want is a MustInherit base class that is inherited for the different storage. Perhaps an SqlBackend, Xmlbackend? You will have a variable somewhere declared as the base type, but will be set to an instance of whatever database you are using. So if the company switches to a different database, you charge a hefty sum but simply create a new class for it. In this particular case, I would have the base class contain such functions as AddSalesRep, UpdateBooking, etc. In the vast, vast majority of cases, that is bad design. You don't want unrelated classes dependant on each other in that way. However, in this case, the data storage is abstracted in such a way that it wouldn't make sense to have a method like AddRow...how would you do that in XML?

Best of luck to you. I'm free to answer in quick language questions. Its a helluva switch.