Jump to content

GemRock

Members
  • Content count

    2,020
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by GemRock

  1. GemRock

    [CONTRIBUTION] CCGV (trad)

    Hi Voland, No I am not here to argue anything. I simply think that may make things better and some people could benefit from it. I found what she said did not match what I saw in my tests and thought maybe I did not test it properly? I do not use the discount part of CCGV (trad) so I can not make any comment on it but I believe the principle would still apply, i.e., no tick no use - a matter of consistency. Note that Ager did use the word 'Gift Voucher', not 'discount voucher'. Also note that the fix does not apply to discount code, as Phocea clearly states in the fix, so you do need to think about/test it if you want to use it on the Discount feature of CCGV (trad). Ken
  2. GemRock

    [CONTRIBUTION] CCGV (trad)

    Ager I am not here to ask, or let alone to force, you to include the 'fix'. But I honestly do not follow what you say above and am seriously thinking of me missing something on my own tests? 1. ...doubles back and it gets unregistered and then proceeds without noticing that they are no longer using their Gift Voucher... The user can not proceed without selecting at least one payment method, either use the gift voucher or pay by card or something else. Instead there will be a pop up error box informing the user of this, which is by design as far as osCom & CCGV (trad) are concerned. 2. ...if they don't notice at all and end up paying more than they intended to... There is no way the user would end up paying more: if both 'use gift voucher' and other payment method are clicked, the gift voucher option, if there's enough amount, would automatically be the default payment method. This behaviour is also by design of CCGV (trad). On my tests, I backed & forwarded 10 times and found no possibility of over-payment, well, at least not on my implementation. I actually have a working test site (see my home page, pls ignore the layout, background etc) that connects to Protx test server. Anyone could use fictitious details to buy anything albeit there?s no delivery! :P The above is based on the tests on my test site. Ken
  3. GemRock

    [CONTRIBUTION] CCGV (trad)

    Ager Thank you for your pointer to the other posts, but unfortunately I could not find any good explanation other than agree that it is a matter of choices of how one may think their implementation should work/behave, and everyone should have the full right to make their own decision. Well, maybe it does not fully qualify for a ?bug?, in fact, when I first tested CCGV (trad) and found this ?bit? the word ?bug? did not actually come into my mind, but thought that was ?something? that could be improved upon. Based on my many years of application software programming/testing experience, I?ve got into the habit of trying out all the scenario to ensure that every line of code is run through and is correct as intended. It is also my humble opinion that, as a developer, I?d not dictate how a user may think or do. OK, let?s forget about the word ?bug?, and have a look at how CCGV (trad) works or intends to work: Say, you have some money in your gift voucher account. You now arrive at the check out payment page. There?s ?Tick to use Gift Voucher account balance? check box, and you check it, then click Continue to go to the next confirmation page. There there?s the ?Payment Method (Edit)? option, and you think you still have some money in your Paypal account and you want to use it, or you have been offered 1 yr zero interest on purchase on your credit card and you want to take advantage of this, or whatever, then you click the edit (payment method) link but only to find that you can not actually ?edit? the payment method despite the ?Tick to use Gift Voucher account balance? being shown unchecked and you having clicked the other payment option! Now, the ?logic? here it seems to me either you do not allow the user to ?edit? payment method by not showing this option at all (albeit the user may still try to press the Back button on keyboard to return to the previous page), or you genuinely allow the user to edit the payment method by, e.g., adding the two extra lines of code. Shoppers frustration is the last thing any shop owner wants. Whatever, CCGV (trad), as many have said, remains a great contribution. Ken
  4. GemRock

    [CONTRIBUTION] CCGV (trad)

    For everyone's benefit, I think this bug fix should be mentioned here as it can only be found on the CCGV 5.16 pages, but the bug also exists in CCGV (trad) (once you check the 'use Gift Voucher account balance' check box you have no way to chnage your mind) and my test shows the fix works as well on CCGV (trad). It is a bug fix posted by Phocea, so full credit goes to Phocea. Below is the full text posted by Phocea: ***************************** Text by Phocea Starts ****************************** Hello just thought I would post a bug fix for a small problem which occurs if a customer decide to change his mind and NOT use his gift voucher balance after all. Basically once the box is ticked, even if you go back to checkout_payment and leave the box unticked, the balance is still used. Even if you log off and back in, its still registered with the session ! Anyway here is the line that need to be added to get rid of this bug: In checkout_payment.php After: if(tep_session_is_registered('credit_covers')) tep_session_unregister('credit_covers'); //CCG Add: if(tep_session_is_registered('cot_gv')) tep_session_unregister('cot_gv'); //CCGV And we might as well clean this up in logoff.php also After tep_session_unregister('gv_id'); Add: tep_session_unregister('cot_gv'); Note that this problem does not apply to Discount codes, only the gift vouchers. ***************************** Text by Phocea Ends ****************************** Hope the next CCGV (trad) update includes this bug fix. Ken
  5. GemRock

    [CONTRIBUTION] CCGV (trad)

    I suspected you had got at least some parts of the sql scripts run otherwise you'd not say it 'up&running like a treat'. I suppose while you are in phpMyAdmin, open the table called configuration to see what's there and what may somehow be missing with regard to CCGV(trad). If you run all the 'insert into' sql scripts a second time, it'd probably duplicate these records, which may confuse the system. Pleaes note, as suggested by Vger, do read & follow the instructions carefully. Ken
  6. GemRock

    [CONTRIBUTION] CCGV (trad)

    I have found a fix to the above problem, which is similar to that suggested by Simon (http://forums.oscommerce.com/lofiversion/index.php/t140211.html). I check the validity of the "DeliveryAddress", rather than the product type. Ideally, the problem should be fixed at Protx, but it is not easy to get guys at Protx to listen and to move around, I believe. Ken
  7. GemRock

    [CONTRIBUTION] CCGV (trad)

    Hi there, CCGV (trad) is a much simpler and working version to implement. Wonder why people would make other CCGV versions so complicate and even not working any more in the past several months. I am testing on CCGV(trad) with a version of PWA and my initial testing shows they can work together without problem. The only issue at the moment I come across with my installation is that CCGV seems to have a problem with Protx Form (protx_form.php). Normally, or as design, CCGV would by pass the Delivery information page and goes straight to Billing Information page, resulting in there being no delivery address. In protx_form.php, both delivery & billing addresses are passed to Protx server, which, stupidly, would insist both addresses must have a post code even the delivery address is an empty string :angry: . Since it 'fails' the post code test, Protx server returns an error msg complaining 'post code is missing', and the process won't go any further. IMHO, the billing address is what is required to check against that registered with the credit/debit card used for the transecting. I contact protx support but they did not seem interested, and gave me a 'big stick style' answer, saying one only got that error msg when theres no post code in the address :angry: I am still working on a solution. Anyone got the same problem? Or is there a solution out there already, which I may be missing? I do not think it has anything to do with PWA. In my set up, PWA is not available when a gift voucher is purchased. Many thanks, Ken
  8. GemRock

    [CONTRIBUTION] CCGV (trad)

    Sorry, I meant especially that part of sql script as shown below: INSERT INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, last_modified, date_added, use_function, set_function) VALUES ('Welcome Gift Voucher Amount', 'NEW_SIGNUP_GIFT_VOUCHER_AMOUNT', '0', 'Welcome Gift Voucher Amount: If you do not wish to send a Gift Voucher in your create account email put 0 for no amount else if you do place the amount here i.e. 10.00 or 50.00 no currency signs', 1, 31, NULL, '2003-12-05 05:01:41', NULL, NULL); Ken
  9. GemRock

    [CONTRIBUTION] CCGV (trad)

    Have you run the sql script? Ken
×