Web Analytics Made Easy -
StatCounter allow a visitor to enjoy upgrade before billing process - CodingForum

Announcement

Collapse
No announcement yet.

allow a visitor to enjoy upgrade before billing process

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • allow a visitor to enjoy upgrade before billing process

    thank you
    Last edited by mktc; Feb 12, 2004, 03:41 PM.

  • #2
    Welcome here!

    I don't quite see the problem + i don't understand your question about the commands to look into, because this is a question about a functionality, which can be realised through multiple ways.
    I suppose that the acceslevel is registered inside the userstable. So a simple admin-page where you can update the usertable (or only that field) would be enough to instantly give them another acceslevel. Inside your application, you chould just check on the level of that client for your screenflow.
    The 'billing'a argument is a business argument and not a technical argument. But i don't understand why it would be a problem either because you just need to choose how you will deal with such mid-term upgrades
    --> bill them for the highest level they had in that month
    --> record the upgradeday and then compute how many days he was in level1, how many in level2 and multiply that with the fee per day for each of the levels and agregate that
    --> or if they pay at the beginning of the month, compute the delta between the new levels dayly price and the old levels daily price and multiply that with the days in the new level
    --> or maybe even something else
    These are also fairly easy computations, but they require that you don't only store the acceslevelinside the usertable, but that you also keep a acceslevel-history table, where you insert a record on each level-change (one when the account is created for the original level, and from there on for each change) Maybe the problem is that they just run a select at the beginning of the month where they simply join the usertable with the level-fee table. Which instantly returns the required fee for the next term, without any computing or logic needed.
    To allow mid-term changes, you need to
    - set up this level-history table
    - set up a script to an algorithme to check if
    --> the client had an account last month
    --> check if the clients acceslevel was changed last moth
    --> compute the daily price for each level + the delta between them
    --> multiply delta with number of days in new level
    --> compute the fee for the next term
    --> add the result of the multiplification to the next fee.

    Or, you could compute the extra required fee for the remainder of the current term when they want to change their level, and only change it when they payed.

    Either way, if you want accurate billing with this sort of flexability, then this can envolve quite some modifications to your db-design and some extra scripting.
    If i was the coder, and this feature was not included in the agreed analysis, then i would surely bill you for it.

    <edit> Your addition question
    <<<<Couldn't a batch process on say a 15 minute cycle be used to upgrade the account info?>>>>
    No need for. Just do it real-time by updating the usertable (and if required, on the fly computing of the additional required fee for the remainder of the started term)
    <<<<Its a very large site and will be on a server farm so power is not an issue.>>>>
    Power is always an issue I suppose you/your friend don't have a clue about the unnescecary cost you now have. But used CPU and bandwith should be some of your biggest concerns. Wount be long before host will charge you per used CPU seconds ...
    <<<<I want him to be able to call his guys and tell them which direction to go in, because I think they might be screwing him.>>>>
    Realy ... I don't know their arangements, but if you require such an additional change, after implementation, then this can cause some serious rework. Well, if they are smart, they would have forseen this and it would be included from the start on. Or there would have decided against it from the start on.
    If they did not look into this while making there functional design, then they are just bad analysts and then your friend should have taken his business elsewhere, where they might have charged him a bit/a lott more, but where they would have made a more thorough analysis or where they would have set up a more modular framework that would allow easy integration of such features. But everything comes with a price ...
    But it's to easy to put the blame on the inflexible - incompetent coder if you don't know what sore of arangeent they had and what the application-requirements were.
    </edit>
    Last edited by raf; Feb 12, 2004, 04:35 AM.
    Posting guidelines I use to see if I will spend time to answer your question : http://www.catb.org/~esr/faqs/smart-questions.html

    Comment


    • #3
      Thank you very much for your response. You cleared it up for me. I dont have a clue about the cost because I'm not involved in the project. The servers are owned and on site.This is a very large site with lots of money behind it. Its not some mom and pop operation. I was asked because I work in info-sec and what I dont know, I know how to get the answers, so he asked for some help.He decided he wanted this and asked if it could be done. They said no. In my business what the boss says goes and an explanation is due if it cant be done. I'm grateful for your response.

      m
      Last edited by mktc; Feb 12, 2004, 03:47 PM.

      Comment


      • #4
        Since this issue seems to be closed, I'll kindly ask that you post any new issues you run into in a new thread, to avoid confusion.
        Former ASP Forum Moderator - I'm back!

        If you can teach yourself how to learn, you can learn anything. ;)

        Comment

        Working...
        X