Jump to content
Latest News: (loading..)
wHiTeHaT

Beat me to death, This one i cannot figure out.

Recommended Posts

Posted (edited)

Type:
-*.json
$key = 'price';
(now it comes)
Read out the string in a format of a currency.
***preferable NOT ALLOW cents.
The problems...........
if .json uploader provide a WRONG format..................
Set price to 0 (that can be covered)
Means add-on is for free.
If is not in a good format..........
Warn the uploader (is covered)
------------------------------------------------------
The problem is when uploader enters a string like:
99999999999999
There is no decimal, no comma (even if it is not preferred).

How much "checks" that value has to gone true to "hopefully" come to an accurate price-format.
It actual give me a headache.

Rules are allowed.... if not follow a rule...
A warning to the uploader is given something like:
"The price format is not between the allowed parameters.Please provide a value to the according parameters"
 

Edited by wHiTeHaT

Share this post


Link to post
Share on other sites

Does the price have to be in the json file? Why not a field on the Add an App form?


Let's make things easier for new osCommerce users http://forums.oscommerce.com/topic/402638-discussion-about-hard-coded-database-tables/?p=1718900  Getting there with osCommerce 2.4! :thumbsup:

Share this post


Link to post
Share on other sites

Not wanna be harsh...........
But the current add-on section is full with add-ons that are a complete mess.
As a developer point of view i would say..... trow these people in a shredder (just to let it stop)... it is just an expression... of course i do not mean it like that..... (it does not have to be a shredder).

It is better to deal with a certain level. Just a little obstakel for the ones who are still learning.
They need to know what they are doing.
Eventual the provided *.zip will also be read out to check if it not overwrite "core" files.
Yet............ i plan to allow "add code to end of files" (should work 100% for language files and the current functions.php and general.php............ might even some classes).
Another challenge will be to replace functions/methods inside a file.... i have to digg-in more to that part.

The main problem for these is simply the current code-base 2.3.4.1, either default or the BS version.
I have a certain vision where there can be a step-by-step, regardless how far each step goes, these users can come close to 2.4.
Behold........... it will not be the 2.4 as is.
I just use 2.4 as there is nothing else available for the moment.
Just like there came a community version for 2.3.4.1, same can be done for the 2.4 version.
Behold, 2.4 might never become a reality.
YET, when we put our heads together, we can go beyond current 2.4.

For that to become a reality i HAD TO made the market add-on i am working on.
When that market add-on becomes fully promoted by the current active users (same as done to promote the BS version).

Eventually, regardless if user installed first official 2.3.4.1
Regardless if user installed 2.3.4.1BS
The market add-on can cover it.
It can detect "where you are".
And from that point it can anticipate where you wanna go.

Better said.
When actively put our heads together, yes the developers AND the current "Ambassadors" , the ones who "felt" a connection to osCommerce, and for that feeling became an Ambassador.
We can achieve BIG things. 

I know what i am talk about.
You can sit in the Wagon and be pulled ahead.
Or you step out and start pulling.

It is only 2 choices. But once your out.... YOUR OUT.

Share this post


Link to post
Share on other sites
1 hour ago, frankl said:

Does the price have to be in the json file? Why not a field on the Add an App form?

i already took out the category out of the json.
Perhaps i should do same for the price formatting.
For that i have to provide form that calculates the price based on "tax".
The market will go run on a dutch tax based currency what is 21%.
The commission for a payed add-on will be 30%. (per buy)
Based on the set price given by the uploader, 70% of what rests, the uploader pays tax to his government.
Now it comes.
The market details are clear.
The uploaders tax commission is based on HIS/HERS country (as market, it is not the markets problem what is done with the earned 70% commission).
What matter is, the buyer.
is he out of EU or not?
What tax rules would apply?

to situate the dilemma in short:
Market wants 30% based from the origin "sellers" add-on price.
Market wants seller to handle the "law" as preference with no obligations.
Market only thinks in their favor, it wants to handle/maintain the price as it was sold by a "dutch" citizen.

What would be the steps the market should take in this matter?
It is not a stupid question.
There are many markets selling software "mostly in their advance", alreasy handling above.
Perhaps they figured it out in a legal way.
 

Share this post


Link to post
Share on other sites
4 minutes ago, wHiTeHaT said:

Market only thinks in their favor, it wants to handle/maintain the price as it was sold by a "dutch" citizen.

perhaps above is not possible and regardless of the commission, still need to take in account the buyer is not an Dutch or EU citizen.
Regardless if that "citizen" find a way to bypass EU law and pay less as possible Tax for his purchase.

Share this post


Link to post
Share on other sites

The market is not the seller, it is merely handling the payments on behalf of the seller. The market is earning a commission, and that commission would be income and be subject to relevant Dutch income tax laws.

The 70% balance is remitted to the seller and they are responsible for their own taxes etc unless they are in the Netherlands, in which case you will need to consult Dutch law as to whether you need to withhold tax before you remit that payment.

As far as the sale goes, I've had a quick skim of this https://ec.europa.eu/taxation_customs/sites/taxation/files/resources/documents/taxation/vat/how_vat_works/telecom/explanatory_notes_2015_en.pdf and it appears Dutch citizens would need to pay VAT on their purchase, whereas citizens of other countries would not. However, if I were you I would consult a tax lawyer.


Let's make things easier for new osCommerce users http://forums.oscommerce.com/topic/402638-discussion-about-hard-coded-database-tables/?p=1718900  Getting there with osCommerce 2.4! :thumbsup:

Share this post


Link to post
Share on other sites

Shouldn't the data spec be provided so all the uploader would need to do is to verify that the price is_numeric or by FILTER_VALIDATE_FLOAT or etc? And any incorrect format would just be rejected?

 

7 hours ago, wHiTeHaT said:

How much "checks" that value has to gone true to "hopefully" come to an accurate price-format.
It actual give me a headache.

 

Share this post


Link to post
Share on other sites
Posted (edited)
11 hours ago, wHiTeHaT said:

The problem is when uploader enters a string like:
99999999999999
There is no decimal, no comma (even if it is not preferred).
 

Price should be set to $99999999999999.00 in this case.

Where is the problem?

So long as you check that the input here is a number, you are good to go;

filter_var($input, FILTER_VALIDATE_FLOAT)

Note that this is good for "0" prices as well, and should also allow fractional prices;  9.99

You maybe allowing fractional prices as it is much easier to spend 9.99 than it is to spend 10 (mentally).

Edited by burt

This is a signature that appears on all my posts.  
IF YOU MAKE A POST REQUESTING HELP...please state the exact version
of osCommerce that you are using. THANKS

 
Get the latest current code (community-supported responsive 2.3.4.1BS Edge) here

 

Share this post


Link to post
Share on other sites
Posted (edited)

i solved it

 

    if(!empty($val)){
        $sql_main_array['products_price'] = (float)HTML::sanitize($val);
    }else{
        $error = true;
        $messageStack->add_session('market_upload', 'Price: <strong>' . basename($val) . '</strong> is not within the correct parameters. Only float is allowed', 'error');
    }

 

Edited by wHiTeHaT

Share this post


Link to post
Share on other sites
Posted (edited)

Hmmm...what happens when $val = 'abc'?

 

1 hour ago, wHiTeHaT said:

 


    if(!empty($val)){
        $sql_main_array['products_price'] = (float)HTML::sanitize($val);
    }else{
        $error = true;
        $messageStack->add_session('market_upload', 'Price: <strong>' . $val . '</strong> is not within the correct parameters. Only float is allowed', 'error');
    }

 

 

Edited by wHiTeHaT

Share this post


Link to post
Share on other sites

Sounds like the client and/or app will have the logic to handle this, and I thought the json was a file like a composer.json that was provided by the app dev.

0.0 may actually get an error instead of being stored as 0.0000....

 

The following values are considered to be empty:

"" (an empty string)
0 (0 as an integer)
0.0 (0 as a float)
"0" (0 as a string)
NULL
FALSE
array() (an empty array)

 

7 minutes ago, wHiTeHaT said:

The uploader get's list of his uploaded apps in his account section ;)

 

Share this post


Link to post
Share on other sites
5 hours ago, clustersolutions said:

The following values are considered to be empty:

"" (an empty string)
0 (0 as an integer)
0.0 (0 as a float)
"0" (0 as a string)
NULL
FALSE
array() (an empty array)

 

Good catch... changed to

if(isset($val) && is_numeric($val)){
    $sql_main_array['products_price'] = (float)HTML::sanitize($val);
....

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×