| |
New York wrote:Have you seen 2.8? Attribute Combinations now have:
Stock quantity:
Allow out of stock:
Sku:
Manufacturer part number:
GTIN:
Thanks for the info, I have not had a chance to look at 2.8 yet I'll probably get to that next week.
Are you saying that info has been stored in the ProductVarient_ProductAttribute_Mapping Table (or an additional table related to that tbl) if so then we're all cool.
What about pricing is it also now down at that level?
Reason I ask is that in say the furniture ind different fabrics used on say a lounge can have a different costs & therefore rrp, so as I said the pricing structure also has to come down to this level as well.
Cheers
Posted:
3 months ago
|
daveb wrote:
Of course it is possible.
No disrespect intended but as of 4 months ago when I last looked NO it was not possible.
You might like to read my (and others) post here http://www.nopcommerce.com/boards/t/19794/product-variant-confusion.aspx and the link to the work item in the post above.
Re your comment on coding around the interface my comment would be NOOOOOOOO, what is there now is beautiful it does exactly what is needed and most importantly its user friendly. I have retail clients here in Aust that would kill for a POS system that does it the way NOP does, hence my interest in extending the functionality of NOP to turn it into a POS system.
BTW I would code this myself but in all honesty as it is a Core function in NOP its ramifications are too great.
Maybe the NOP team might like to give some guidance, do we create a fork, what would be the process of bringing those forked changes back into the core app, because it would affect not only master tables but transaction tables as well would the team like a doc with detailed analyse for them to work from.
Bottom line guys this change is urgently, with it I know that there is a potential market of 300000+ (MYOB has some 500000 odd users here in aust & NZ) NOP users just here in Aust & NZ alone, the current options available are for magento, OS commerce, prestashop and Virtuemart, etc. they are all sub std and both end users and MYOB partners are screaming for a better option which I know can be delivered with NOP.
Cheers
Posted:
3 months ago
|
Hi,
At the present integration with a POS system is not possible because you can not get the 1 for 1 product matching outcome you need for products with multiple colours & sizes.
The NOP guys did try and address this a couple of months ago but because they did not put the Barcode, SKU's (unique product identifiers) far enough down in the product attribute table structure it is still (as of V2.7) not correct. I have not looked to see if there were changes in V2.80/90 to fix the problem so I might stand to be corrected.
The other problem that this creates is that until its done you cannot use NOP for stock control.
To help & with out going too far into it if you go to a fashion shop selling say dresses you'll find when you look at the products on the rack and in particular the barcode/GS1 numbers it will go something like this;
Barcode Product name
9123456987654 Small Red XYZ dress
9123456325648 Med Red XYZ dress
9123456443259 Large Red XYZ dress
9123456548917 Small Blue XYZ dress
9123456487929 Med Blue XYZ dress
9123456643217 Large Blue XYZ dress
9123456111444 Small Green XYZ dress
9123456558791 Med Green XYZ dress
9123456999999 Large Green XYZ dress
FYI on a 13 digit GS1 barcode the 1 number represents the product country, the next 6 digits are the product suppliers unique identifier and finally the last 6 digits are the actual product identifier. Bottom line when a supplier joins GS1 they purchase the Supplier code & a range of product identifiers from say 100001 -200000. Those numbers dished out in sequential order as the supplier ads products to their range and as such the product identifier part of the code cannot be used to identify the products attributes.
I am actually hanging on the guys fixing this so I can get on with writing the integration with the MYOB Accounting & POS (Retail Manager) products - Aust, NZ & SEA only and the MS Dynamics POS systems in both cases they will be real time 2 way integrations.
LOL because the MYOB accounting system re-write has been a $90M+ disaster (god wouldn't we love a budget like that) I will only be doing the link for V19.8 of MYOB accounting.
Cheers
Posted:
3 months ago
|
Buddy you should take a trip into the PHP/MYSQL/Java OS land compared to pretty well every single one of them the NOP community is the best by far the most supportive.
Bottom line it only took a few days to learn NOP (from a site admin perspective) & if you can't do that on your own without a manual then you are obviously out of your depth and need to find yourself a professional who you will have to PAY to get the benifit of an expertiese you clearly do not have.
REMEMBER THE OS RULE OF THUMB IS THAT BASIC SOFTWARE IS FREE BUT SUPPORT AND CUSTOMISED DEV WORK IS CHARGABLE.
On the real chance that you are a OS freak skript kiddy with NFI; Take your BS somewhere else, not taking money for their work is the reason 99.9999% of OS projects FAIL. If your not happy for NOP people to charge you then its easy GO SOMEWHERE ELSE, there are HUNDREDS of Ecomm OS projects out there (none as good as NOP) so go and anoy the people there.
Cheers
Posted:
6 months ago
|
higgsy wrote:Hi all,
We've been using Nop for a while now (1.9, 2.20 and 2.40). I'd like to start by saying what an awesome product we think it is!
It seems that with every Nop project we work on, we always feel slightly uncomfortable with the way Nop deals with product variants. I'll use our most recent project as an example. It is a clothing shop and therefore sells all the usual items, dresses, shirts, shoes etc.
Al
Hi Al,
Agree entirely NOP is an awesome product. I've been involved in ERP/POS (BTW eCommerce is just another name a Point of Sale and some parts of an ERP system) design & development for 30 yrs, I've also worked with more OS products than I care to mantion and IMO the quality of the work the NOP guys produce is second to none in not just the OS world but also in the commercial world.
LOL make no mistake and as my comments in the following links demonstratrate I'm not backward in coming forward in critisizing software co's that screw up with their product dev or use their market position to screw their customers over.
http://community.myob.com/t5/Upgrading-to-AccountRight-2011/Too-slow-solution-found/m-p/142856#M5613
http://community.myob.com/t5/Upgrading-to-AccountRight-2011/Windows-8-RP-Release-Preview-and-AR2011/m-p/142588#M5605
Look for the Gaz nic.
Soz for the political statement but the MYOB story serves as a warning to all and sundry in the US that Mit Romney & his Ilk must never be alowed to become the US president. Bottom line a fool that payed $1.2Bn for a co that at best (based on EBIT) was worth $180M, and the unscrupulous way they have begun to extort money from its client base says it all.
I digress.
That said I also agree that the product varience aspects of the system are confusing and not quite right from a usability POV or from a stock managemet/Sales entry POV.
The stock management aspects atm make it all but impossible to link NOP to 99% of ERP & POS systems, and more signifficantly make it very difficult to sell NOP as a viable replacement for the traditional in store POS system.
While not exhaustive, from my analysis the table structures are almost correct in that the field needed are already in the DB but just not in the the right tables.
For example ATM the product SKU, manufacturers & GTIN numbers, stock levels and pricing level info is stored in or has a relationship to the Product Varient Table. For the system to work properly the relationships need to be built around the ProductVarient_ProductAttribute_Mapping Table.
The other things that need to be looked at if NOP is going to achieve its full potential in the market is that it needs to cater for the fact that a product can be manufactured by different manufacturers who will of course have different manufacturers, GTIN's and in many cases pricing attributes for the same product.
The other concept that is fundamental and that is needed is the introduction of a product supplier because in the vast majority of cases a retailer needs to know about the manufacturer but does not buy from the manufacturer directly because they only deal with a wholesale suppler who in turn deals with the retailer.
An example of that would be say HP, yes they are a manufacturer but how many here actually buy from HP, if the rest of the world is like Australia then the vast majority of us will be forced to deal with a Wholesale supplier not HP directly.
The introduction of a supplier & the ability to process purchases into NOP would be a fabulous addition IMO.
The other thing that is an imperative is that these changes MUST be introduced first if NOP is going to eventually impliment a multi store capability.
Lets not copy the incorrect multi store capabilities that other eCommerce systems have implimented due to their poor domain knowledge, lets step outside the box & impliment a structure thats been designed by a true domain expert.
If its of any assistance I have done some analysis on the table structure changes that I believe would be required to impliment the above functionality including the multi store requirements, I would be happy to impliment the changes in an NOP DB and submit that to the NOP team for scrutiny & possible inclusion in a future release of NOP.
With respect the usability aspects related to adding products with multiple attributes, this could be achieved with what is known in the POS world as a "Colour, Style, Size Matrix" again I have done some analysis on how this could be implimented in NOP and believe that if the changes I've suggested above are implimented then an NOP "Attribute Matrix" structure could be easily added to the product creation interface to vastly improve the current multi attribute product addition functionality.
Look forward to the feedback.
Cheers
Garry
Posted:
8 months ago
|