#21 Managing stock feature

[padungsak]

Here is a patch of Managing stock and Thai language adding
Manageing stock feature detail:
Items module

* Item is seperated into 2 stock type
    1. Warehouse: back store
    2. Sale stock: font store
* When create new item, user has to put "Unit quantity" and "Related item number" which are                 
    new label
* Add Stock type in search option

Report module

* Add requisition report

Receiving module

* In Receiving mode: The received item will be in wholesale
* I have introduced a requisition mode which is a stock movement

Sale module

* Seperate sale into 2 mode
    1. Sale retail: sale an item in the Sale stock
    2. Sale wholesale: sale an item in warehouse

Note: This patch is created by TortoiseSVN. You can check diff by copy OSPos.patch in the attached to your program directory then Right click->Apply patch..

Note2: There are some bugs which have to be fix but I hope you to merge this patch first. Then it will be easy to get code form git and fix the bug without worry about merging process.
What do you think?

[padungsak]

Note3: This patch is created based on version 2.2.1
Note4: Due to the database is chenged, To test the feature please backup you old one and apply the new one in database folder.
Related discussion topic
https://sourceforge.net/p/opensourcepos/discussion/1778703/thread/d5078b1a/

[jekkos]

ok nice thanks for the patch. I will look into the changes today or maybe tomorrow. I will let you know when I reviewed it so maybe we can have a skype session. My nick is jekkos85 if I'm not mistaken (or perhpas jekkos not sure will check).

[jekkos]

ok I applied the patch now. got everything working. I also saw that default language was changed to thai. Will need to change that tho.

Will need to do some further testing and review and I will come back to y for the merge

[padungsak]

Thanks for your review. Please list all defect you found, I will fix it as soon as possible

[Anonymous]

Ok One remark I found, when opening the requisite receiving report, when you click the link to view the receipt, I get a 404.

I gave it a shot and tried to correct this but didn't get it working thoroughly yet.

things to do here are the following

• create separate requisite_receipt method in receivings controller
• this method will call the model to query for info using the given id
• then the cart variable in receiving_lib can be loaded with that data
• requisite_receipt view can be loaded (with all data set)
• receiving_lib state should be cleared in the end

this way a requisite receipt can be displayed using it's own url at all time.

Will need to do some deeper testing later today and will give some feedback on it.

thanks

[padungsak]

A big thank for your test result adn solution.
I think I will fix this after this patch is merge to the trunk package.
Because I don't want to do a patch which could be confilct with the previous patch

Jekkos,
Whant do you think?

[jekkos]

ok I will push my current changes to github first. I still need to fix one thing in the receipt, there is one field not showing up correctly. Will need to look into fixing that (or maybe you can have a look at the branch).

[jekkos]

Dear,

I merged your changes in a new feature branch, which is available now on my github (github.com/jekkos/opensourcepos).

I do have a couple of points regarding the multi location item implemtation that we might need to adapt to make it better

• currently only two locations are supported. I'm convinced that some users might have a need to support more than 2 and in this case we should make the implementation more generic
• provide an option to specify item locations in the app config
• all the code depending on this feature can access the configured list of locations and loop through on every location involving these locations

• sale_types can be generated in a generic way

• another remark is that your patch duplicates item entries when an item is moved to another location.

• my idea here is that we should use the inventory table to keep track of the quantities of every item in a specific location. Inventory tracking information would better be stored in the inventory table instead of in the item table itself. This has the following consequences:
  => requisitions don't need separate tables anymore (ospos_requisition), instead we can just add a column to ospos_inventory specifying the location or sale_type if you will

=> the item_unit table is not really needed. All of the quantities are stored in the inventory table for every location.
=> in the inventory trackin dialog we should get an overview of the available quantities for each single item in every location. This can be done easily by adding an extra location parameter to the queries

I think overall this idea will make the patch simpler and will give the end users more flexbility in using ospos. What do you think?

[jekkos]

If you want I can give you access to the github repo so we can collaborate more quickly, currently your changes are on

https://github.com/jekkos/opensourcepos/tree/merge/padungsak

let me know.

[padungsak]

Please give me the access to the branche

[jekkos]

OK I granted you access.

[Anonymous]

Dear Jekkos,
Sorry for late reply and thanks for your comment, I agree with your idea about keepping all item movement in inventory tracking. But I confuse about the database design. As you mentioned that item_unit is not need, But in my design item_unit describe a number of item in a pack eg 1 pack of beer is 12 buttol of beer.

Colud you please explain me more about the design or we can have a skype session to ensure that I understand all correctly before coding?

Note: I can not find you in skype
My skype name is padungsak

[padungsak]

Dear Jekkos,

Sorry for late reply and thanks for your comment. I agree with you that all item movement should be in inventory tracking.
But I confuse on your database design. As you mentioned that item_unit is not need so where can I put the unit of each item.
item_unit in my design is a unit quantitie of item in a pack eg. 1 pack of beer has 12 bottles of beer.

Could you please explain me more about the DB design?
Or we can have a skype session to ensure that I understand the design correctly before coding.

Note: I cannot find your skype account
My skype account name is padungsak
My location is in Thailand

[jekkos]

Dear,

I think the concept you mention here is the one of the item kits. This gives you the ability to bundle a quantity of different items together as a whole for sale. When you enter the item kit name at the register, the defined number of items will be substracted from the stock, so in this case the item_unit kan be replaced by just using item kits.

The only change we could do is to move the location field from the item table to the inventory. We could create a small table with key and name item_locations, and link foreign keys of these location to the inventory table. One should then indeed extend the dropdown in the register and receivings as you did, and keep the requisitions part to move stock from one location to another (in this case stock movement +1 for one location and -1 for another) but generate it dynamcally based on the entries in item_location, so you can sell items from any stock location. This would be a good solution to the multi warehouse feature that has been requested here for a long time.

I will have some time to skype with you when I get back from work, I think this will be around 20pm gmt+1, not sure if that suits you?
Other wise in the weekend I will be available earlier.

[padungsak]

Dear,

I still not clear on your qoute above. Let me explain my understanding

• In user view
• User should add locations in config page
• When add new item in items/item kits page, user can specify the item quantity for each location
• In 'Inventory Count Details' dialog there should be a dropdown list of location,for example, to let user choose to view inventory tracking for each location.
• In Receiving page requisition still be there. To move the stock, user choose item to move. Then in the cart there should be a dropdown list to select the source and destination location to move

• In Sale page the dropdown should be extend by the location configed in the config page.

• Database

• There should be one table contain item_id, location, quantity in each location
• quantity column in the items table should be removed

Could you please correct me?

[padungsak]

What do you think?

[jekkos]

1. agree
2. initial quantities should be specified when adding new items indeed. Normally stock corrections can be done through the inventory link in the items overview
3. good idea, we could provide a dropdown to filter per location, or just show both initially (and then user could use a dropdown to filter?)
4. good idea. there should be checks on the available quantity for the source location to see if the desired amount is available.. of course negative result can be obtained as with the sales now, but this will yield a warning on top (is already in there)
5. good idea, should iterate the item_locations table and list every entry in the dropdown? We could eventually use a flag to eg. disallow direct sales from certain location in item_location, if you think this is useful. (first ned to do requisition in that case)
6. database
7. I think you are right about the extra table for maintaining quantities, could be called item_quantities. they will need to relate the current number quantity for an item for a specific location id
8. I think we need to add one more column to inventory for linkiing in the location_id

ok that's it think we agree on the implementation, thanks for setting this out already!!

[padungsak]

1. initial quantities should be specified when adding new items. this means for example. if user put 2 stock position in the config page. In the New Item dialog there should be 2 input box for entering 2 items quantity available in each stock.

Am I correct?

[jekkos]

Well yes this would be a nice option, we could generate the field according to the number of present locations in the config. Adapting these quantities afterwards will yield a new entry in inventory (substract or add), as is currently.

[padungsak]

Dear Jekkos,

I want to discuss with you on item kit concept. after investigate on it's workflow, I cannot see how can I adapt it with stock movement.

Can I have a skype session with you on Sunday 9-10 am your time?

[jekkos]

Ok could be possible that the item kit itself is not tracked in the inventory.. I think that the current implementation just allows you to select the item kit in the register and this will add all of the included items to the receipt. There is indeed no tracking of inventory on the item kit itself, it's merely a container for items, if that is what you were after?

[padungsak]

Dear Jekkos,

There need a lot of change to do muti stock location. Can I have a skype session with you?

[jekkos]

ok fine, my skypename is jekos85. I will be available this evening around 18pm gmt+1

let me know if that suits you.

[padungsak]

That's fine for me.
Can we have it on Wednesday 6 pm(gmt+1)?

Honestly I cannot find your skypename. Could you please add me?
My email is suntonpon@hotmail.com
Please use my email search on the skype directory

[jekkos]

ok I reinstalled skype I added u to my list.
tomorrow should be ok I hope I will put a reminder.
thanks.