Electronic Billing question

galitska has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks, thank you for your replays. My inner balance is coming back. Let me be more specific with the goal of my quest. Let's say, one wendor needs to see the Client's name as First-Comma-Last-Comma-Middle Initial Another - only Last Name-Space-First Name Third - Last-Comma-First and requires that length of Last and First Names were not longer than 15 characters each Or one client wants billed amount to be positive and discount - negative Another - both amount and discount - positive Due to the fact that I also supply Total as (Amount munus Discount) - the result sometimes is not in clients favor If you can suggest the possible approach on those two problems - I will figure out the rest (I hope so, may be, possible). Your humble disciple.

Comment on Electronic Billing question - where to start

Replies are listed 'Best First'.
Re: Electronic Billing question - where to start by radiantmatrix (Parson) on Nov 01, 2004 at 18:20 UTC
galitska, your question is not very complete. Perhaps you could describe it in greater detail, provide links to reference materials, &c. The article How do I post a question effectively? has some excellent advice on posting complete questions that are likely to get good answers. Your question seems interesting on the surface, and I look forward to your reformulation of it! radiantmatrix `require General::Disclaimer;` "Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy	[reply]
Re: Electronic Billing question - where to start by davido (Cardinal) on Nov 01, 2004 at 19:49 UTC
I am not familiar with your particular needs, and the question doesn't exactly define them. But a good startingpoint with this type of problem is to factor all the stuff that doesn't change into a base class (or module), and then sub-class it to add on the layers that tweak it to work with varying needs. The sub-classes should use a uniform interface, so that one sub-class can be a drop-in replacement for another. That way, when you get a new client, with a new need, you simply subclass the base class providing the individual functionality that the new client needs, without wrecking everything else. This is one of those things that object oriented programming is for. Dave	[reply]
Re: Electronic Billing question - where to start by talexb (Chancellor) on Nov 01, 2004 at 21:11 UTC
This question is rather vague, so the answer cannot be precise, but I can suggest that you rewrite your billing application so that the output for each client is defined by a configuration file specific for each client. Thus, every time a client wants something different, you haul out your configuration file and start tinkering. After a while you'll have a variety of formats and you can start with a solution that's close to the one your client wants, and go from there. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply]
Re: Electronic Billing question - where to start by perlcapt (Pilgrim) on Nov 01, 2004 at 19:54 UTC
We must identify what key can be used to determine which version client program is making the request. In the client request stream is there something that is unique to each version? If there is something unique, then it would not be hard for a perl-based server to intercept the request and reformat into some standard (most recent) version of the actual billing server. The Perl-based front-end would act like a request broker, many-to-one. Is this sort of what you need? An example of the differences would help clarify your needs. perlcapt -ben	[reply]
Re: Electronic Billing question - where to start by Mutant (Priest) on Nov 01, 2004 at 21:51 UTC
As already stated, you have two main options - customised configuration for each client, or customised classes for each client. The option you choose will depend on whether the customisation will be mainly different data (configuration) or different code (sub-classes). I'm sure you would get a better answer if you provided more specifics about your problem.	[reply]