A Phoca Cart size can be a purchasing attribute with option values, a descriptive specification or a filter parameter. Its selected stock mode determines whether quantity belongs to the whole Product, a variation or a combination. When Phoca Cart is the prospective Target Platform, those relationships sit inside Joomla’s own user, language and route model; copying the same “Size” label cannot reproduce them all.
Phoca Cart is a Joomla-native commerce component with its own Product, Category, Customer, Order, pricing, tax, stock, and benefit structures. Joomla still supplies users, access levels, menus, modules, templates, language context, routing, and the wider extension environment. Migration must therefore translate both the commerce records and the Joomla relationships that make those records discoverable and usable.
Phoca Cart also separates several concepts that source platforms often combine: Product options, attributes, specifications, customer-group prices, discounts, coupons, reward points, tax rates, currencies, stock statuses, and downloadable access. A field name is not enough to choose the destination. The destination should follow how the value affects buying, administration, and historical interpretation.
Product Identity and Catalog Relationships
A Phoca Cart Product can connect to Categories, manufacturers, images, attributes, options, specifications, related Products, downloads, stock, prices, discounts, taxes, reviews, language content, and customer-group rules. The Product row is therefore only the center of a relationship network.
| Source meaning | Possible Phoca Cart owner | Relationship to preserve |
|---|---|---|
| Core Product identity | Product record | Name, alias, code/SKU, descriptions, publication state, and language |
| Catalog placement | Phoca Cart Categories | Product-to-Category assignments and intended hierarchy |
| Brand identity | Manufacturer record, Category, or external key | Product-to-manufacturer and any browsing or integration use |
| Product media | Product images, downloadable files, or content assets | Role, ordering, visibility, and access |
| Shopper choice | Purchasing attribute with its option values or inputs | Selected value connects to its price, configured stock, media and Order-line meaning |
| Descriptive data | Specification, parameter or identified content/custom field | Display, comparison, filtering or administration purpose remains distinct from a purchased choice |
| Buyer-specific benefit | Customer group, price, discount, coupon, or reward record | Customer eligibility to the commercial result |
A source child SKU needs the destination stock unit and commercial identity that represents it. Phoca Cart’s Main Product stock mode shares a quantity; Product Variations track variation quantities; Advanced Stock tracks option combinations. Treating a variation as an individual stock unit does not by itself give it a separate native Product row. A separate Product relationship is appropriate only when the actual catalog design and supported representation require that identity.
Native Product IDs, attribute/option keys and combination-stock references identify different records. Codes, SKUs and external identifiers help match business items across systems, but a copied source child key does not automatically reuse a native Product ID or rebuild its selected stock relationship.
Options, Attributes, Specifications, and Parameters
The most important Phoca Cart catalog distinction is the function of Product detail values.
- Attributes define purchasing choices such as size or color and can affect price.
- Options provide the attribute’s available values or inputs and connect the selected choice to the purchase.
- Specifications describe and compare Products without changing their price.
- Parameters provide another structured way to filter Products; custom values need their identified field or extension owner.
A source field such as “size” illustrates the problem. It can be a selectable clothing size, a package dimension, a filter value, or internal warehouse data. Those meanings need different target owners.
| Source behavior | Target interpretation | Meaning to retain |
|---|---|---|
| Choice changes stock or Product code | Attribute/option relationship in the selected stock mode, or a separately identified Product where required | Stock-unit, code and Order-line identity remain connected without assuming each variation is a new Product row |
| Choice changes price only | Option value with price relationship | Selected value and price adjustment |
| Shopper enters text | Input-oriented field or extension record | Entered value attached to the correct Order item |
| Technical specification | Specification and its Product value | Label, value, group, ordering and comparison use; no specification-driven price change |
| Search/filter facet | Eligible attribute, specification or parameter relationship used by the selected filter | Normalized value and filter membership retain their definition and Product assignment |
| Internal operational value | Custom field or external-system record | Administrative ownership without accidental storefront display |
Definitions and Product assignments should remain separate. A specification group, attribute definition, or option definition can be reused across many Products, while the Product-specific value or allowed selection belongs to the individual Product relationship.
Prices, Stock, Discounts, Coupons, and Rewards
Phoca Cart can express more than one kind of commercial value. Base price, customer-group price, Product discount, cart discount, coupon, reward points, tax, currency, and stock status are separate concepts. Combining them into one “price” field removes the rule that explains when and for whom the value applies.
| Source commercial rule | Phoca Cart relationship | Translation question |
|---|---|---|
| Wholesale or member price | Customer group plus Product price | Which Customers belong to the group and which Products use the price? |
| Product-specific sale | Product discount and effective conditions | Is the discount a stored amount, percentage, or timed rule? |
| Cart promotion | Cart discount or coupon | Which cart conditions and usage limits define eligibility? |
| Loyalty balance | Customer reward-point record | Is the balance authoritative in Phoca Cart or another system? |
| Stock availability | Main Product, Product Variations or Advanced Stock mode, plus stock-status rules | Does quantity belong to the shared Product, an individual variation or an option combination? |
| Multicurrency value | Currency and price/display relationship | Which amount is stored and which is converted for display? |
Historical Order totals should retain the price, discount, coupon, reward, tax, shipping, payment, and currency evidence recorded at purchase time. Those snapshots are not substitutes for active target rules. New carts use the current Phoca Cart configuration and plugin logic.
Reward points need explicit ownership. A Customer balance, points earned by an Order, points spent, and the rule that converts points into value are related but different records. Migrating only the balance can leave the history and eligibility logic unexplained.
Categories, Manufacturers, Search, and Joomla Navigation
Phoca Cart Categories and manufacturers belong to the commerce catalog. Joomla menus and modules expose selected Product, Category, manufacturer, search, filter, comparison, or other views to shoppers. A source navigation structure may therefore translate into several target relationships rather than one Category tree.
| Source structure | Possible destination | Meaning to preserve |
|---|---|---|
| Product Category | Phoca Cart Category and Product assignments | Catalog hierarchy and buyer grouping |
| Brand page | Manufacturer record plus menu or module destination | Brand identity, browsing, and filtering |
| Dynamic collection | Filter, search rule, module query, Category, or custom logic | Membership rule rather than only current Product IDs |
| Featured or latest block | Joomla module configuration | Query, ordering, audience, and placement |
| Comparison or wish list | Phoca Cart Customer/session records and modules | Product relationships and account ownership where persistent |
| Restricted catalog | Joomla access level, Customer group, or extension | Who can see or buy the Products |
Joomla Categories and Phoca Cart Categories are not automatically the same taxonomy. Joomla Categories organize records inside Joomla components; Phoca Cart maintains its commerce Category model. A migration should not merge them merely because the labels match.
Search and filtering depend on normalized Product values. If source attributes contain inconsistent spelling, units, or value formats, the target can retain every string while still losing useful filter behavior. The relationship between Product, attribute/specification definition, and normalized value is the relevant data model.
Customers, Joomla Users, Groups, and Addresses
A registered Phoca Cart Customer may link to a Joomla user. Customer groups can influence prices and benefits, while Joomla access levels can control site visibility. Addresses, tax details, company data, reward points, wish lists, and Orders may belong to different parts of the Customer relationship.
| Customer value | Appropriate owner | Reason |
|---|---|---|
| Login identity and enabled state | Joomla user | Controls authentication |
| Site access role | Joomla user group/access level | Controls content and component visibility |
| Commercial segment | Phoca Cart Customer group | Can affect prices, discounts, or benefits |
| Reusable billing/shipping address | Phoca Cart Customer/address record | Belongs to the Customer lifecycle |
| Guest address | Historical Order | Belongs to one transaction |
| Reward balance | Phoca Cart reward records or external loyalty system | Requires an authoritative ledger |
| Tax or company identifier | Customer, address, Order, or external system | Ownership depends on reuse and legal purpose |
Joomla user groups can control permissions, and access levels control what users can view. Phoca Cart Customer groups govern commerce treatment such as prices or displayed purchasing controls. A selected configuration, plugin or custom rule can connect these classifications, but that connection has its own owner; matching group names do not make membership, permissions and prices interchangeable.
A linked Joomla account also does not establish usable credential continuity. The exact Source-to-Target path determines whether the original verification can be preserved or whether reset or another access flow is required. Customer identity, Joomla user state, addresses and historical Orders can remain meaningful independently of that authentication result.
Guest Customers should remain distinguishable from registered accounts. An Order email does not prove that a persistent Joomla user existed, and generating accounts from all guest history can create duplicate identities.
Orders, Invoices, Payments, and Shipping Evidence
Phoca Cart Orders can include Product and option details, addresses, Customer context, prices, discounts, coupons, reward points, taxes, shipping, payment, currency, status, notes, and invoice references. The Order should preserve a snapshot of the transaction rather than relying only on the current Product or Customer record.
| Order relationship | Meaning to preserve |
|---|---|
| Order to Customer or guest | Identity used at purchase time |
| Order line to Product and option values | Exact purchased configuration |
| Order line to price and discount | Historical amount formation |
| Order to coupon or reward use | Benefit applied to the transaction |
| Order to tax, shipping, and payment | Historical financial and fulfillment context |
| Order to status and timestamps | Operational progression |
| Order to invoice or receipt reference | Document continuity where required |
| Order to external ID | ERP, POS, accounting, carrier, or marketplace continuity |
Where POS or invoicing is used, its enabled configuration and related records determine document numbers, cashier/location context and stock activity. Online and offline transactions can share catalog or Customer identities while retaining different operational records. An Order row alone cannot explain those additional relationships, and retaining old activity does not instruct the destination to repeat its stock or document effects.
Payment and shipping plugins have separate historical and active roles. A past Order can retain method names, amounts, tracking and provider references. New transactions use the destination’s configured plugin and authorization; a historical token or reference does not itself permit a charge, refund or shipment action.
Content, Language, URLs, and Storefront Presentation
Phoca Cart operates inside Joomla, so Product and Category records are only part of the customer-facing result. Joomla menus, modules, templates, language assignments, access levels, routing, and content pages shape discovery and presentation.
A source store may combine Product data with buying guides, comparison pages, manufacturer pages, Blog Posts, landing pages, and downloadable resources. These should be assigned to the target record that owns their lifecycle:
- Product-specific selling content can belong to Product fields;
- Category introductions can belong to Category content;
- broader editorial material can use Joomla Articles with their Category/menu relationships, or an identified editorial extension;
- module-driven Product blocks remain Joomla presentation configuration;
- downloadable assets can belong to Product access or CMS content depending on purpose.
Translated content also has more than one storage model. Joomla’s default multilingual approach can use separate Product records per language, connected through associations. An installed translation layer such as FaLang or the supported Multilanguage CK approach can organize translations differently. The selected implementation determines whether language values share a logical Product or use associated native records, and how their stock ownership relates. Interface INI strings remain separate from translated Product or Category content.
Language labels alone cannot settle Product identity. Separate associated records need their native IDs and language links preserved; a translation layer needs its own value ownership. Treating every translation as an independent sellable item can duplicate stock, while forcing associated records into one row can lose language and route relationships.
URL ownership is shared. Product and Category aliases provide commerce identity, while Joomla menu context and routing can determine the visible path. The target should identify canonical destinations and relate redirects to them rather than treating the full source URL as one Product field.
Plugins, Modules, Imports, POS, and External Systems
Phoca Cart is modular. Payment and shipping plugins, search and filter modules, PDF generation, newsletters, Open Graph integration, import/export workflows, POS functions, template overrides, and custom Joomla extensions can create or consume data outside the standard Product-Customer-Order structures.
| Dependency | Additional data or assumptions | Destination question |
|---|---|---|
| Import/export workflow | Column mappings, external IDs, schedules, transformed values | Will Phoca Cart or an external process remain authoritative? |
| POS workflow | Offline Orders, stock updates, document numbering, cashier or location context | Which records are shared with online commerce? |
| Search/filter module | Indexed values, parameter definitions, query configuration | Which Product relationships drive discovery? |
| Payment/shipping plugin | Provider references, tracking, method metadata, custom statuses | What is historical evidence and what is active configuration? |
| PDF or invoice extension | Document templates, numbering, generated files | Which identifiers and files require continuity? |
| ERP, accounting, marketplace, or feed integration | Stable Product, Customer, Order, tax, and stock keys | Which system owns each identifier? |
| Template override | Expected fields, module positions, route assumptions | Which translated records must remain addressable? |
The presence of an extension should lead to a data-ownership question, not an assumption that all its records belong in a generic custom field. Some values belong to Phoca Cart, some to Joomla, and some to the external system that created them.
How Phoca Cart Differences Change Migration Scope
Phoca Cart scope should distinguish these treatments:
| Treatment | Typical examples | Scope consequence |
|---|---|---|
| Direct record translation | Products, Categories, manufacturers, Customers, Orders, media | Map supported fields and identifiers |
| Relationship reconstruction | Options, attributes, specifications, Customer groups, reward records, Order benefits | Rebuild definitions, assignments, and ownership links |
| Joomla presentation structure | Menus, modules, templates, routes, access, language context | Assign to target site implementation |
| Plugin or workflow data | POS, invoices, imports, payment/shipping metadata, search indexes | Define a current destination or historical archive |
| External-system continuity | ERP, accounting, marketplace, loyalty, carrier, feed IDs | Preserve durable keys and named ownership |
| Intentional retirement | Obsolete modules, unused parameters, duplicate routes, abandoned integrations | Exclude with a recorded reason |
A coherent target model lets staff trace a Product through its Category, option, specification, price, stock, Customer-group rule, Order line, Joomla route, and external identifier without guessing which system owns the value.
Conclusion
Phoca Cart data model differences come from the combination of a rich commerce component and the Joomla site around it. Products can depend on Categories, manufacturers, options, attributes, specifications, prices, stock, benefits, taxes, plugins, and multilingual content. Customers can span Joomla users, access levels, Phoca Cart groups, addresses, rewards, and Orders. Storefront routes and presentation remain Joomla relationships.
A reliable migration translates each value by function. Shopper choices stay connected to the correct Product and Order line; descriptive values remain useful for display and filtering; historical totals remain separate from active rules; and plugin or external-system data receives a clear owner. That approach preserves how the store works rather than only how its tables were named.
Common Questions
What is the practical difference between a Phoca Cart option and a specification?
An option is a value or input within a purchasing attribute, such as a chosen size or color. A specification describes or compares the Product without changing price. The same label can represent either meaning in the source, but its definition and Product assignment must follow whether it changes the purchase or describes the existing item.
Should Joomla Categories and Phoca Cart Categories be merged?
Not automatically. They belong to different Joomla components and can serve different purposes. Phoca Cart Categories organize commerce records, while Joomla Categories organize records inside the CMS component that owns them.
How should Customer groups and Joomla user groups be translated?
Keep Joomla user groups, access levels and Phoca Cart Customer groups as distinct relationships. Joomla permissions and visibility differ from commerce prices or purchasing controls. A selected configuration, plugin or custom rule can connect membership or treatment, but that link must be represented explicitly; copying a group name does not reproduce it.
Do reward points belong only to the Customer balance?
No. The balance, points earned, points spent, the related Orders, and the conversion rules can be separate records. The target needs an authoritative owner for the complete loyalty relationship.
Can historical tax, payment, and shipping data use the same records as active checkout rules?
Historical Orders should preserve the amounts, labels, and references recorded at purchase time. Active target rules and plugins govern new transactions and remain a separate configuration layer.
How should POS or import/export data be handled?
Identify the Products, selected stock units, Customers, Orders, document numbers and external keys shared by the actual workflow. POS, invoice generation and import/export configuration can have additional owners. Historical activity and retained references explain past operations; they do not by themselves recreate schedules, repeat stock effects or authorize new document or payment actions.
Does translated Phoca Cart Product content always have a separate Product ID?
No. Joomla’s default multilingual content approach can use separate associated Product records for each language, while an installed translation layer can store translations differently. The selected implementation determines native record identity, language associations and the stock owner. Translated text alone does not prove either one shared Product row or an independently stocked Product for every language.