ocBase (concept) - justification

An overview of the existing solutions target platforms:

1. Оpencart and its modifications.
What we all are working. Has a database based on the ID of heading, where, under the trade position is taken the model.
Has the form DB: ID, Model, SKU, or other identifiers, data models, series models, category models, model attributes, model options etc

Main advantages:
- Solves the need for creating THEM where 1 model = 1 SKU (one product, one page) without options (there are attributes).
- Solves the need for creating 1 where the model has no SKU, but with options (such as pizza and its supplements)

Cons:
- No users using it in its business processes SKU, since there is no possibility to account for different SKUs of the same model.
No easy import/export data for different SKUs of the same model.
- Options available placing value SKU in options such as Advanced options, Related options, and Automatic processing of the price list, work on different algorithms, without having a single standard. So for example "coherent option 2.0" almost solve the problem and unload only data related options, omitting others which have no SKU in the options, because the work with different database tables (options and additional extended tables and related options. And the most popular CSV imoprt/export also has the ability to download only data 1 model by ID and all of its options on one line.

2. Bitrix (1C) and the like. I haven't seen, don't know how it works inside, but I would venture to guess that the DB looks like this:
SKU and other IDs (ID1, ID2, UPC, QRкод etc), model ID, series 1, series 2 (class), SKU attributes, options, no.

The rationale and definition:
ocBase (concept) - cms opencart.
Has a database based on the ID+the SKU commodity item, where the product SKU is accepted.
View the database (base opencart unchanged, but with the extension tables are placed where the values of the SKU that goes beyond the existing values of options):
ID, Model, models, series, categories, models, model attributes, the value of the SKU (based on options) + additional tables (by selecting color, size, and other; other and any other identifiers (ID1, ID2, UPC, QRкод, etc.); availability A, b, C.....)
Pros:
- solves tasks satisfying the requirements imposed by modern business processes based on SKU.
- attraction of new users are small, medium and large businesses.
- unlimited possibilities of expansion and creation of modules based on the SKU (e.g., as a display product availability in stores).
- Exchange data with any platform of any kind.
Cons:
- Lack of modules using the option values and ID (except ID and model).
- While the lack of modules is able to upload and download data on ID with a condition checking the value of option where you place the value of the SKU.

Conclusion:
Not even having nothing in your Arsenal to filter THEM and search you will be able to solve problems previously only available Betrixaban and the like.
Since this is a new branch of development with unlimited possibilities for extension Programmers also receive full and informed enrichment, at the expense of new clients of high level, able to pay for something that you do now at least by a factor of x2.

p.s
It only the concept, I urge you to do something.
ask not to unsubscribe generalities, if you have something to add or correct - write. If you have something to refute it with arguments.

>> I urge you to do something. <<

Why don't you do it ? It's probably the only chance, to get it done, because you cannot really expect the Fellows in Charge to change an existing Version Concept, just, because one possibly feels, it could be done better.

Sure, it could, much better, i.E., by starting up as a simple single-whatever Shop, without any Mod's, and nothing, not really used in daily default action. My personal View. And for most, it's probably all they really look for anyway, as long as it looks great and shiny, and works swell. But others expect much more, or different, some of them already tried, over the Years, to create their own Type of Software, based on some Version of OC.

But within a Main Version Development, there is little Room for fundamental Code Changes, especially, as long as every new Sub-Test-Release is 'handled' by Users/Downloaders as already professionally usable Software, even capable to still handle all old Mod's, ever bought. Despite of the Fact, that this place is already filled up with ever the same repeating Error-Help-Demands. It's similar to the Windows-Story, some always want to belong to the first, (to run into Problems,) probably, just to have a better feeling, or something...

But if you really believe to have/know a better way, to do something, you should prepare at least a working sample software, to demonstrate your Ideas and Knowledge, then, you will be taken seriously, I assume. But otherways, take, what you get, and accept, that you so have every right, to ask, but none to demand, or urge, our Masters of OC, to accept your proposals, regardless of their possible Value.

Still, V2 is not really 1.0 yet, and 2.5 won't make your dreams come thru, either, so, I guess, V3 would/could possibly be made in your Favour. Therefore, take time, and use it, to convince the Boss, to, at least, have a well done Bases to think about it...

Good Luck, just to reply in some decent way...
Ernie
Nothing personal, I did not understand a word, honestly, as UN- Programmer!

I already posted in the relevant support topics modules:
Advanced and related options, Automatic processing of the price list.
this picture https://yadi.sk/i/uLXVo3twkwxhA
Task: take a single standard value for the SKU.
This will allow you to:
1. To refuse to determine SKU and other IDs in the item data.
2. Ask models that do not have variants, SKUs and other identifiers specifying them in the options.
3. To take the Model of the product, as "product Model" for the convenience of data exchange with the supplier to call, as anything but advanced.
4. To set the value for the SKU in manually with the help of Advanced modules and Related options, and automatically check and load and unload data only on the value of the SKU, after appropriate modifications, using the Automatic handler of the price list.
5. When loading data using the Automatic handler of the price list and in the preparation of the price list, in any case you have to manually set the value of the model, code or by its name. It is difficult, but it is possible and in 1000 times increases the efficiency of further updates only on the value of the SKU.
Conclusion: we teach a single standard SKU is equal to the value of related options and just the SKU value in the options. This solves the problem of choosing create in the store a separate card or products with variants and models based on the values of any number and of any type.
This solution works, don't change the engine "oc", don't be offended, but it's "crooked", because it goes through a bunch of options and article options, and the SKU is a value in our case: any IDs, attribute values, and options, and the options are nothing like attributes distinguish the model from each other.
That decision was not "crooked", you need to replace the concept of "options" to "SKU", but it probably will be possible in future versions 2.0 and above, or if who will undertake the revision 1.5.

Following this logic, it is necessary to replace the concept of "categories" to "series". Standard opencart allows you to create categories and use advanced filter solutions to select for a series of categories and series for the producer, but he does not specify their values. There are some extensions such as: Collection, Series, brand Line, Model series + 1.8 Menu it already offers alternatives and sets up the values of the series. A step into the future, together with standard SKU, it will allow to make import from XML.

I'm not a programmer.
These concepts do not make changes to an existing opencart engine, that's right they extend, what is already there, but extensions now there is we use different SKU values like the picture. Developers need only to approve the standard SKU for additions, I'll be very happy if it will be in version 2.5 or 3.0

Your Words in the Lord's Ears..., as we would say, I cannot judge, unfortunately,
if I could, I would write some Code, possibly, to make tests. Just about as I always do,
by use of existing 'Knowledge', created by someone, who knew...

But, possibly, you should get a hold of someone like linked below, to get their opinion,
in private, at least...

http://www.opencart.com/index.php?route ... e=JNeuhoff
http://www.opencart.com/index.php?route ... me=JAY6390

Good Luck
Ernie

https://yadi.sk/i/xOs1rt7qm6xuC
Hi Ernie! I am very grateful that you have guided me in the right direction. You are one of the few who heard! Alternative solution based on the module "Related options". Only need to create module for processing of values that uses "Related options" and we will receive a module which runs a full-fledged virtual warehouse. In theory this could be a multi warehouse. Here is an approximate functionality of the module:

Requires the creation of a module, based on values created by the module "Related options" - "RO".

In the module field must be present:
1. No column in the price list code with "RO"
2. No column in the price list "model" (item code) (item - data)
3. No column in the price list with the price "RO"
3. No column in the price list with quantity "RO"
4. No column in the price list containing the alternate identifier "UPC" "RO" - the barcode

The module must contain a function and a checkbox:
- Output the report to a file on the updated number of "articles" "RO".
- Display a report containing data from the item card not changed about "the Articles" "RO". The report should contain: the product model (as product code), Manufacturer, Category

Objectives of the module:
- processing value "RO": imports the "price" and "Quantity" by checking the "article""RO".
- processing value "RO": imports the "price" and "Quantity", checking the "UPC""RO".
- If the price has no value to the article (and it may be, if the item card there are no options), the module must take "code" and substitute in "code"
- If the Related options are some of the products with different options and one article "RO", then test them and update them data the price and quantity
- scan and display a report on the item card does not contain code from the price.