Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Subject: Re: python first project
Date: Sat, 11 Jan 2014 17:10:20 -0500
Organization: IISS Elusive Unicorn
References: <ae47738d-b16a-4567-bdd9-07d18db5fc77@googlegroups.com> <mailman.5335.1389460629.18130.python-list@python.org> <a25f12fa-d524-45d7-918b-8b36af4dc7aa@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5340.1389478218.18130.python-list@python.org>
Lines: 74
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:63727

On Sat, 11 Jan 2014 09:55:57 -0800 (PST), ngangsia akumbo
<ngangsia@gmail.com> declaimed the following:

> 
>I have a paper with the instructions that was given to me, these guys just want something very simple. The CEO in concern want that every day he get in to the office , it does not matter the time. He should be able to see a record of all the transaction for that day from his desktop 
>
	Very vague level... It's defining basically one report (or set of
reports) but overlooks all the effort to enter that data. Even ignoring the
warehouse and personnel records you may be looking at a rather large
system. 

	Even a single user/single account check register will require:
1	Some persistent data storage (at one end is a fixed width formatted
record [fixed width makes it easier to jump around by record number], at
the other end is a table in a relational database)
2	Forms for entering transactions (checks/deposits), possibly forms
allowing for updates/corrections (with logic to confirm changes to cleared
transactions)
3	Forms/processes for reconciling the register with bank statements
4	Reports of cleared/uncleared transactions
 
	All that is, as I say, for a single user with a single account.

	If you are tracking customer billing, you are talking multiple
accounts, and quite likely double-entry bookkeeping. In double-entry
bookkeeping, every credit in one account has to be matched with a debit in
another account (when a customer pays, you reduce the amount owed on his
account while adding the amount to company operating account). For safety,
you have to ensure that a computer crash can't, say, reduce the customer
amount but fail to add the amount to the company account -- this is where a
database with transaction support comes into play).

http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system

>yeah just a client billing app
>

	Even if not using a full-up double-entry system, you are still looking
at multiple accounts (one account per customer) showing purchases/payments
(and other possible transactions)... A database table just for customer
fixed information (name, address, account #, limits on purchases), a second
database table for transactions (shared by all customer accounts -- the
account # is a foreign key linking to the customer) -- this table will
probably have entries just for payments and purchase summaries (the items
in a purchase will be a third table linked to the summary record, and maybe
linked to the inventory system by part # and quantity). It gets more
complex if you need to track overdue amounts for penalties as you'll need a
way to flag which purchase summaries have been paid and which have open
amounts.

>Just salary, employee record, etc
>
	Still a separate application that should be restricted to certain
users.
 
>What i need to do is simple, design an app for employees, finance sector, purchase, billing, bookkeeping etc. Ok there is not IT infrastructure in this firm, they have a group of workers just doing the manual input of data. so the ceo wants this data to interact with a program that can keep track of what is going in the company.
>

	Is any part of the system already computerized? If not, and everything
is being done on paper forms, the first step might be to replicate the
manual procedures using the computer -- replace each paper form with an
equivalent screen form and backing data store (files/database) {A purchase
order would likely access many tables: customer, summary record, line item
records, inventory...}. A better path would be to do systems analysis (use
cases) to find out if there may be steps that aren't really needed, or
others that can be improved.

	Producing fancy reports for the CEO may be the last thing you
implement, as it relies upon having a stable database design, business
logic, and data entry.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/