Subject: Re: Public LLPS web site
From: "Mike" <[email-masked]>
To: "Andi Kuhn" <[email-masked]>
Date: Fri, 14 Sep 2007 14:07:25 -0400

I understand.  I just got off the phone with Amber.  I will be speaking with Mike Grove.  I will be in contact with you and Amber to discuss further direction.
Thank you,
Mike - LLPS

  ----- Original Message ----- 
  From: Andi Kuhn 
  To: Mike 
  Cc: Amber Morris 
  Sent: Friday, September 14, 2007 1:54 PM
  Subject: Re: Public LLPS web site

  Do we need it?  No.  But it's already built - I'm just trying to save the client money in redevelopment.  All that is in the 'separate' database is the website page content - unimportant to any of your internal systems - and we've already built the content management system and administration processes.  It's all just text and copy that they want to be able to update.

  ANDI KUHN / Director, Interactive & Emerging Media / v. 813.258.8858 / f. 813.258.8859 / [email-masked]
  MUELLER/BAISDEN ADVERTISING / www.muellerbaisden.com / 3508 S. Manhattan Ave., Tampa, Florida 33629

  On Sep 14, 2007, at 1:51 PM, Mike wrote:

    Andi,
    Do we need to have a separate database?  I was hoping we could keep everything together.
    Mike - LLPS

      ----- Original Message -----
      From: Andi Kuhn
      To: [email-masked]
      Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked]
      Sent: Friday, September 14, 2007 1:38 PM
      Subject: Re: Public LLPS web site

      Actually, we'd be linking directly to the existing database for all of those things  - the external database would then only contain the CONTENT of the external site (what is on each page) - none of the ordering, processing, shipping, or customer information . . .  

      Andi

      ANDI KUHN / Director, Interactive & Emerging Media / v. 813.258.8858 / f. 813.258.8859 / [email-masked]
      MUELLER/BAISDEN ADVERTISING / www.muellerbaisden.com / 3508 S. Manhattan Ave., Tampa, Florida 33629

      On Sep 14, 2007, at 1:30 PM, Mike Grove wrote:

        The only problem with option 1 is that products, pricing, shipping rates, and discounts would all have to be manually syncronized as changes are made.  If someone is willing to accept that task I do not see a problem with this option.

        Mike Grove

------------------------------------------------------------------------
        From: Andi Kuhn <[email-masked]>
        Subject: Re: Public LLPS web site
        Date: Fri, 14 Sep 2007 12:23:11 -0400
        To: [email-masked]

        Hey Mike,

        We have a couple options: 

        1. We can interface with their existing internal sales database, and also use their credit card processing account.  In this scenario, we'd continue with the system we've built, employ the current database in use with the site, and then hook up to the sales database for storing the sales information.   This would require the most minimal amount of change and would make sense anyway because the database we're currently working with for LLPS contains all of the information specific to the website such as labor laws for each state, federal labor laws and things like that.  It would require no synchronization since all we're doing with the external database is inserting rows containing the sale information.     Also, it's already set up so that  LaborLawPostingService.com is on a separate hosting plan.   The two sites are completely separate, yet we are able to connect to the "internal" sales database to add sales records as well as use their CC processing gateway.

        2.  We can develop the external application in ASP.NET.   The two applications will both connect to the existing database.  Based on what we've been talking about, it seems that the two applications themselves do not need to communicate with each other, they both just need to be able to communicate with a common database and use the same processing system.

        Let me know what you think -
        Andi

        ANDI KUHN / Director, Interactive & Emerging Media / v. 813.258.8858 / f. 813.258.8859 / [email-masked]
        MUELLER/BAISDEN ADVERTISING / www.muellerbaisden.com / 3508 S. Manhattan Ave., Tampa, Florida 33629

        On Sep 14, 2007, at 11:19 AM, Mike Grove wrote:

          It is written in ColdFusion MX 7 with a SQL Server 2000 database.  It is running on Windows 2003 Server.

          Yes, I developed their application.  It has been in use for about three years now.

          Mike Grove

----------------------------------------------------------------------

          From: Andi Kuhn <[email-masked]>
          Subject: Re: Public LLPS web site
          Date: Fri, 14 Sep 2007 11:08:18 -0400
          To: [email-masked]

          Mike - 

          what language is your internal application written in, and did you develop it?  

          :) Andi

          ANDI KUHN / Director, Interactive & Emerging Media / v. 813.258.8858 / f. 813.258.8859 / [email-masked]
          MUELLER/BAISDEN ADVERTISING / www.muellerbaisden.com / 3508 S. Manhattan Ave., Tampa, Florida 33629

          On Sep 14, 2007, at 10:49 AM, Mike Grove wrote:

            There are some decisions that need to be made dealing with the the internal sales web site and the customer web site (external).

            Option 1: Each site has its own database
            * No way for the reporting function on the internal site to track any sales that happen on the customer site.
            * All customer information on the external site will be independent of the internal site, so sales people internally will not be able to look at any order information for an external customer.
            * The product, pricing, shipping, and discount rules will need to be maintained in both places.
            * All orders that come in through the external web site will not go through the standard internal shipping process, and will have to use its own process.
            * No easy way to migrate a customer from one database to the other

            Option 2: Both sites share access to the internal database
            * This requires both sites to be run on the same server (which should allow them to share a credit card processing logic)
            * Eliminates all of the syncronization problems
            * Probably requires a significant re-write to the customer web site

            This is just a short list of the implications.  I am sure there are more that will surface as this project moves forward.

            Michael Grove

            Mike wrote: 
            > Mike, 
            > I have just been informed myself. I have not been consulted on this at all. This was being handled by the guys. You might want to talk to Steve Tingiris. I was under the impression Steve and Joe Fata at least initially spoke to him but that Baisden was doing the designing. I just started getting questions asked of me regarding the processing. We are in the process of having PayPal take over the actual processing. I am just waiting for the new contract. There will not be really any changes as far as our system is concerned. They are just going to change the direction out of the "gateway" to which processor we will be connecting to. I was told it should be seamless and would not involve probably any change on your part. The reason I had them contact you was that they kept asking me questions about the processing and even wanted to open a new processing account. I told Amber that there was no need creating something that was already existing. That's when I asked her to call you. I am not sure what needs to be done now. Again, maybe follow up with Steve Tingiris. After you talk with him, let me know what the plan is. I will help you anyway I can. 
            > Thanks, 
            > Mike - LLPS 
            > 
            > 
            > ----- Original Message ----- 
            > From: Mike Grove 
            > To: [email-masked] 
            > Cc: [email-masked] 
            > Sent: Thursday, September 13, 2007 11:30 AM 
            > Subject: Public LLPS web site 
            > 
            > I just got a call from the person that is managing the development of your public customer oriented web site. It appears that they had no idea that they were going to be required to make their site communicate with our internal database, so they have written the entire system to use their own database. This is a huge issue not only because they have put in a lot of work that will need to be rewritten, but also because no rules have been established as to how these systems will communicate. Things are further complicated because their system is written in a different language than the internal application, which makes interoperability that much more difficult. They are looking to me for the answers to these questions, but it is difficult to design a plan to deal with these issues after the system has been completely written. 
            > 
            > All of us need to have a meeting to discuss what direction we need to take on this and if we even want to try to make these systems work together. 
            > 
            > Michael Grove 
            >