#18 Open Source Point of Sale Version 2.2 Unofficial - Released

[Parq]

---

Open Source Point of Sale Version 2.2 Unofficial - Released

  ---   THIS IS NOT AN OFFICIAL RELEASE   ---

This release is based on version 2.1.3 and provides new features, include some patches and fix some bugs. No changes have been made to the database, which make it easier to upgrade.

In this release

• New 'Price with tax included' option. This option allow you to use price to customers with all taxes included, and show how much each taxes is.
• More languages! All labels were checked for all the languages. Some translation is needed, always!
• Management for deleted items. A deleted item can be recovered and modified, and also, if it's deleted, it can't be sold.

Patches included

• Patch 8 - Dutch language
• Patch 9 - New report for specific discounts
• Patch 10 / 11 - Spurious session logout fix
• Patch 15 - Language Chinese (zh-TW)
• Patch 16 - Language Pack
• Patch 17 - Expand/Collapse all control for all reports

Bugs

• Language az removed (it's not a translation)
• Bug 22 Deleted items management
• Fix Bug 23 some html errors
• Correct language label 'desciption' to 'description'. Affects 'giftcards_allow_alt_desciption', and 'items_allow_alt_desciption'. Also $data['allow_alt_descrption_choices']
• Fix Bug 26 Language files are loaded twice

UPGRADE from version 2.1.3

There's no database modifications. You can replace the old files with this release.
WARNING: Always is a good idea to do a backup previous to an upgrade. This is not an exception.

1. Backup your database.
2. Backup your OS-POS files. (normally at web server place)
3. Backup your OS-POS/application/config/database.php file.
4. Remove all your OS-POS files (do not remove nor modify database data!!!)
5. Extract the files for version 2.2 Unofficial.
6. Move the files to your web server place.
7. Restore your OS-POS/application/config/database.php file.
8. Log in and use!

[jekkos]

Nice to see that someone made some effort to merge those patches into a release zip. Any idea when the official svn commits are coming?

regards

[jekkos]

Maybe you can consider to include patch #12 as well in this release? I added some comments as the first reaction of pappastech was due to an unclear explanation of the patch design.

[Parq]

jekkos,

I don't know if this unofficial version should be approved as official. I hope so... :)

Related to patch #12, I haven't prove it. As you say, the unclear explanation about jquery version was a little confuse. I'm thinking about to update codeigniter and jquery and then apply the patch #12. If everything fix ok, then all the patches will be have been applied!!!

Regards,

[pappastech]

I'm reviewing this unofficial version 2.2 now. I've already found a few things that needed changed, but it looks good so far. I'll post back here when everything has been approved and committed to SVN.

Tom

[pappastech]

You've made a modification to the database and haven't included the modification in your unofficial release. What's the field type for 'tax_included' in the config table?

Tom

Nevermind...my mind was stuck on the last project I was working on. I'll add this value to the table so that it's in the default database.sql file.

Tom

[pappastech]

Please provide a description of the purpose of the 'Tax Included' field. I need to understand what you're trying to do with this.

Tom

[pappastech]

I've made some corrections to the code and I think it's ready to commit to SVN, but I need the explanation for the tax included field before I commit that.

Tom

[jekkos]

I think this means that the unit_price 's are now tax inclusive. eg. in Belgium prices are always handled like this, customers pay for products with tax inclusive, so shop keepers also enter their prices tax included. Haven't reviewed this functionality yet but it sounds promising (I have my own implementation of doing this, but it needs rework in order to be contributed to the open source version here)

[Anonymous]

please jekkos do it fast its an essential feature.
and please inform me for this patch at amit@gmail.com

[pappastech]

Ok...but the current implementation then also requires that the shop keeper keep track of the taxes outside of OSPOS rather than OSPOS keeping track of it for them. This is a usable band-aid, but not what I would call an implementation that I'm comfortable committing as a long term feature addition.

If you guys want this in SVN, I'll commit it for now, but I'll need to get the feature updated so that OSPOS still tracks the taxes, but doesn't show them as a separate item on the sales page and receipt. This should be the implementation that is desired.

If I'm way off base, let me know; but at this point I'll follow this path.

Thanks for the great work overall Parq and jekkos.

Tom

[Parq]

The system is still tracking all the taxes, but the total price is calculated only with the price of the product besides price + taxes. All the data are stored as usual.

Reports can be more or less be easy modified to show the correct values, because some queries are doing calculations inside the query.

Regards,

[jekkos]

Ok, I understand this concern, but even then the tax rate can still be entered per product basis. The only difference is that you enter the prices with tax included into the system, so that they will be listed tax included on the tickets as well.

Actually I'm planning to review this functionality as I'm interested how it differs from the way I did it in my custom version, will give some feedback on this asap.

[Parq]

New Features

Tax Included

Store Config > Tax Included

This setting allow to manage all the prices as final prices to end customer, with all the taxes included. At the same time, the taxes are informed when the sale is done, in order to let the customer know how much is paying for.

This setting has to be done at the initial store configuration.

WARNING: Nowadays some reports aren't using the global calculations and the use of this feature can make that those reports show erroneous calculations. The problem is on the report and not in the data stored. This is going to be fixed soon.

This feature was previously requested in the forum (https://sourceforge.net/p/opensourcepos/discussion/1778704/thread/abdbea40/)

Manage deleted items

Items > Search Options > Deleted

This feature add a new search option, in order to view the deleted items. When an item is mark as deleted, the item is no longer available for the system.

To undelete an item, after the search you can edit the item and uncheck the 'Deleted' attribute.

[jekkos]

Ok I reviewed the changs in this release and merged them with my current codebase in github (https://github.com/jekkos/opensourcepos). I left out the tax part as I think this functionality is not completely done yet. One should also take into account that the subtotals are tax exclusive while totals tax inclusive, and calculations go the other way around than they do normally. I implemented this but need to find some time to backport it to the oss project here.

In attachment I added the patch of Parq's changes in comparison with my codebase having all the posted patches applied. Could be useful to get the svn up to date, or otherwise, (maybe easier), we take my github repo as a starting point as it is more uptodate as the svn here now.

[pappastech]

jekkos,

I won't have the time to review this and get it implemented in the near future due to a lot of project work that just came in this week. I've given you subversion access here, please update the code after you've reviewed and believe it's ready for inclusion. If the community wants the features, I support adding them so long as they've been tested.

Tom

[Anonymous]

Can the logout patch be implemented in older versions of ospos?

We are running 2.0.2

I don't see an easy way to import all our sales / product info from 2.0.2 to a newer version of ospos

What's the easiest way to fix this???

Thanks in advance.

[Anonymous]

tax included in working. i think when we tick this option its calculate given tax rate percentage(%) on wholesale price not on retail price. please update it as soon as possible.

[Anonymous]

Hi there,
as this discussion is not old, I may provide my 5 cents about the european tax included thing.

Other than my previous writer I doubt that is taking the retail price, it is actually coming from the wrong angle.

While you may think "tax included" means that you can still work out the tax value as in a "net" system like:
tax_amount = rate * (tax_percent / 100)

This is not quite right. The tax included means that the rate amount is effectively 100% + tax percentage. This means that the tax amount wold need to be calculated as follows:
tax_amount_correct = rate * tax_percent / (100 + tax_percent) and as well for the net value: net_rate = rate * (100) / (100 + tax_percent).

Having a quick look into the code, I believe hat the proble is that get_taxes() inside of the sales_lib has not been adjusted to accomodate this.

Pening further testing and as well verifying rounding on the invoices, I guess this methode would need to look like this:
// get_taxes from libaries/Sales_lib.php
function get_taxes()
{
$customer_id = $this->get_customer();
$customer = $this->CI->Customer->get_info($customer_id);
$tax_included = $this->CI->config->config['tax_included'];

    //Do not charge sales tax if we have a customer that is not taxable
    if (!$customer->taxable and $customer_id!=-1)
    {
       return array();
    }

    $taxes = array();
    foreach($this->get_cart() as $line=>$item)
    {
        $tax_info = $this->CI->Item_taxes->get_info($item['item_id']);

        foreach($tax_info as $tax)
        {
            $name = $tax['percent'].'% ' . $tax['name'];

            if ( $tax_included )
            {
                $tax_amount=($item['price']*$item['quantity']-$item['price']*$item['quantity']*$item['discount']/100)*($tax['percent'])/(($tax['percent']+100));
            }
            else
            {
                $tax_amount=($item['price']*$item['quantity']-$item['price']*$item['quantity']*$item['discount']/100)*(($tax['percent'])/100);
            }

            if (!isset($taxes[$name]))
            {
                $taxes[$name] = 0;
            }
            $taxes[$name] += $tax_amount;
        }
    }

    return $taxes;
}

I hope this helps getting the project on the right track in this regards.
Cheers

[jekkos]

Ok I think this might indeed fix the problem for the sales part only. One should just keep in mind that the prices entered by the user are always tax inclusive, and that the tax should indeed be calculated by substracting the tax amount from the original entered price.

Only remaining problem is that you're doing arithmetic on a floating point variables, which could yield rounding errors. PHP has a more precise way of dealing with this by using the bcadd, bcdiv methods.

This patch should be duplicated for the tax calculations in the receiving lib. Could you perhaps create a new ticket for this in the patches section so I can keep track of this issue? Thanks.

[jekkos]

followup issue created at https://sourceforge.net/p/opensourcepos/patches/23/

[jekkos]

Ok I commit a patch to my github for this feature.. Could someone give this a try and provide some feedback??

latest version can be found at https://github.com/jekkos/opensourcepos

just check tax inclusive pricing in the configuration and then all entered prices will be tax inclusive (no added taxes upon checkout).