Drupal Commerce de A a Z

Aprende a usar o Drupal nos teus projectos ecommerce passo a passo
0.0 (0 ratings) Instead of using a simple lifetime average, Udemy calculates a
course's star rating by considering a number of different factors
such as the number of ratings, the age of ratings, and the
likelihood of fraudulent ratings.
1 student enrolled
$50
Take This Course
  • Lectures 137
  • Contents Video: 13 hours
    Other: 1 hour
  • Skill Level Intermediate Level
  • Languages Portuguese
  • Includes Lifetime access
    30 day money back guarantee!
    Available on iOS and Android
    Certificate of Completion
Wishlisted Wishlist

How taking a course works

Discover

Find online courses made by experts from around the world.

Learn

Take your courses with you and learn anywhere, anytime.

Master

Learn and practice real-world skills and achieve your goals.

About This Course

Published 6/2014 Portuguese

Course Description

Gostarias de criar a tua loja online como um resultado profissional?

Ouviste falar do potencial da framework Drupal Commerce, mas não sabes por onde começar?

Se a resposta é afirmativa a uma das questões, este curso é para ti.

O objectivo é permitir que a qualquer pessoa familiarizada com o Drupal ou que deseje criar um negócio online possa criar uma loja de raiz.

O curso desenrola-se em etapas com exercícios práticos e explicação passo a passo e cobrem:

  • configuração básica da loja,
  • princípios de funcionamento,
  • criação de produtos e displays flexíveis,
  • utilização da API para modificar o comportamento default de um componente,
  • implementação de sistema de pesquisa facetada, relatórios...

Ao contrário de outras soluções ecommerce, demasiado rígidas e convencionais, o Drupal Commerce é muito flexível e poderoso.

Depois desta introdução, ficas apto a utilizar Drupal Commerce em projectos com diferentes requisitos e perfis.

What are the requirements?

  • Conhecimentos básicos do funcionamento do Drupal
  • Alguma experiência com Views e Rules (preferencial)

What am I going to get from this course?

  • Conhecer origens do Drupal Commerce (DC)
  • Instalar DC
  • Explorar a arquitectura e API do DC
  • Criar produtos e display para esses produtos
  • Definir regras de pricing, taxing, shipping e payment
  • Integrar no workflow os vários displays do cart
  • Modificar views
  • Melhorar backoffice de gestão de produtos, encomendas, clientes
  • Editar as permissões para DC
  • Implementar sistema de pesquisa com Search API

What is the target audience?

  • Utilizadores familiarizados com Drupal 7 e que querem utilizar o Drupal em lojas online.
  • Qualquer pessoa que esteja disposta a aprender a trabalhar com uma solução de ecommerce robusta, versátil e open source.

What you get with this course?

Not for you? No problem.
30 day money back guarantee.

Forever yours.
Lifetime access.

Learn on the go.
Desktop, iOS and Android.

Get rewarded.
Certificate of completion.

Curriculum

Section 1: Introdução
07:52

Drupal Commerce (daqui em diante, também DC) é um projeto muito versátil e transforma o Drupal numa plataforma de e-Commerce para uso de lojas e developers.

Lidar com o DC pressupõe familiaridade com a administração e a configuração do D7. Acresce ainda o à vontade com Views e Rules.

Nesta fase de arranque, impõe-se algumas notas relativamente ao Drupal Commerce e à opção de instalação utilizada nesta formação.

Article

Algumas curiosidades sobre processo de arranque e desenvolvimento deste projecto pela Comunidade Drupal.

04:54

O Ubercart era uma solução pronta a usar, mas em sacrifício do core e multilanguage. Estava como que encapsulado e divorciado do código em que se alojava. Era pouco customizado e extensível.

O facto do DC estar tão bem integrado com o D7 e ter adotado módulos nucleares e transversais, torna-o uma escolha interessante para desenvolver projetos e-Commerce de qualquer perfil.

Além de reunir as vantagens óbvias de qualquer instalação Drupal - suporte de comunidade dinâmica, inovação contínua, somam-se outras vantagens como se depreende pela lista de características abaixo.

Características
  • Adaptável - Adapta-se a qualquer modelo de negócio, tanto na lógica como no aspeto, com a simples configuração dos módulos e temas.
  • Multilingual e Multi-currency
  • Mobile ready
  • Assistência
  • Preparado para integrar com terceiros graças a API para pagamentos, social networks, import/ export. Existe API de: cart, customer information, items, payment, pricing, taxes.
  • Gestão de conteúdo - DC implementa as suas próprias entidades e campos: products, line items, customer profiles, payment trasnactions
  • Regras de negócio flexíveis - Rules está omnipresente porque vai permitir configurar e estabelecer regras adaptadas ao que se pretende em cada projeto em todas as áreas: preço de produtos, shopping cart, checkout, pagamento
  • Products flexíveis - mais do que tomar os produtos como items físicos, o DC perspetiva-os de várias formas e a mesma base pode ser reutilizada para vendas, deals, ficheiros, conteúdo. Os clientes podem também personalizar os produtos antes de efetivar a compra
  • Extensão com módulos contrib - stock, reviews, coupons, downloads, etc.
Framework ou modelo de e-Commerce?
Article
05:49

DRUPAL COMMERCE OU COMMERCE KICKSTART?

Quem já tenha pesquisado sobre e-Commerce no Drupal e especificamente sobre o Drupal Commerce ter-se-á apercebido da existência de uma distribuição alternativa à instalação standalone do Drupal Commerce.

Escolher entre um tipo de instalação e configuração e outra depende do background, do que se pretende fazer e alcançar, bem como do tempo disponível.

CK é bom para projecto de raiz. Dá boas sugestões para escolha de módulos.

DC é bom para adicionar loja a site existente.

É perfeitamente possível desenvolver um projeto com Commerce Kickstart, que atalha em muitos aspetos, mas para um processo formativo, optámos por escolher o Drupal Commerce numa instalação Drupal por se tornar mais fácil decompor os elementos e perceber claramente o que faz o quê no conjunto da aplicação. Contudo, as referências e os paralelismos com o Commerce Kickstart serão uma realidade sempre que oportuno.

Encontras mais detalhes sobre as diferenças de instalação na Section 3 e Anexos.

Section 2: Website a criar
Planificar o website
Article
03:24

ALGUNS PRESSUPOSTOS DESTE WEBSITE MODELO

A formação que está prestes a começar foi concebida para aprender o Drupal Commerce, centrando-se em tudo o que lhe diz respeito, sem se preocupar com componentes secundárias, mas fundamentais para dar a sensação de estar a trabalhar num projeto e-commerce.

Tudo o que está relacionado com site building e theming do projeto e que não tem diretamente que ver com a aprendizagem do Drupal Commerce foi realizado e configurado previamente. Desta forma, é possível centrarmo-nos no Drupal Commerce e focar apenas as questões de site building e theming dos componentes específicas.

Section 3: Instalar Commerce
Opções de instalação
Preview
Article
09:41

Neste vídeo mostramos como instalar o profile para Drupal Commerce que procura acelerar a configuração e o desenvolvimento de um negócio e dar uma antevisão do que é possível realizar com o Drupal Commerce.

06:55

MAPADE INTERDEPENDÊNCIAS DO DC

No mapa em anexo e no vídeo, podemos verificar a integração e interdependência dos componentes do Drupal Commerce. A instalação parece uma cascata de dependências como destacado e os elementos child herdam as dependências dos parent e em última instância do Drupal Commerce.

À medida que formos explorando o que faz cada “secção” e que elementos necessita para executar a sua tarefa para o resultado final, vamos perceber melhor este jogo de módulos instalados em cascata.

Para já, ativamos as dependências do Drupal Commerce e ativamos todos os módulos que fazem parte da suite do Commerce.

Não vamos configurar todos de uma vez, mas a seu tempo, todos os componentes vão ter a nossa atenção. Grosso modo, cada componente terá uma entrada no nosso manual.

Section 4: Arquitectura do Commerce
08:59

Perceber a arquitetura do Drupal Commerce e implementá-la corretamente pressupõe ter claro o plano da loja e esclarecidos todos os detalhes, pois dessas especificidades decorrem as opções de configuração e seleção de módulos.

Sendo impossível cobrir todas as possibilidades dadas pelo Drupal Commerce, estabeleceu-se o máximo de requisitos da loja para demonstrar e ver em funcionamento diferentes aspetos do Drupal Commerce em ação.

O DC baseia-se inteiramente nas entidades e Field API do core, pelo que cria e lida com entidades próprias.

COMMERCE ENTITES

  • Product - que via product reference se articula com qualquer node type, permitindo esta funcionalidade que um mesmo product tenha n displays e variações. Existe um único campo Price por product, mas o nº de nodes associados é ilimitado, via product reference.
  • Line item - está associado a cada product reference e é único. Tem ligação a Price, suportando várias instâncias.
  • Order - está lidgado a um Line item refernce campo, a outro campo price e ao Customer profile via Customer profle reference. Neste caso aceita ligação a mais que um customer profile reference, eplo que numa order é possível listar vários customer profiles, embora a order depois fique associada a um único

COMMERCE FIELDS

Price - campo obrigatório de qualquer produt type

COMMERCE ENTITIES REFERENCE

  • Product reference - liga Produt e (Node) numa relação de 1 -> muitos
  • Line item reference - liga a Order numa relação de 1 -> 1
  • Customer profile reference - liga Order e Customer profile numa relação de 1 -> 1
Section 5: Products
Configuração básica: product
Article
10:38

PRODUCT ENTITY: TYPE DEFAULT "PRODUCT"

O product type é o “core” do DC. Como está ligado ao display e ao line item, todos os seus valores ficam disponíveis de forma flexível.

A proposta de product type default é product, mas podemos ignorá-la e criar os nossos product type, mas também podemos moficiar o product para o nosos fim.

Ao falarmos de type aplicado a product, lembramos a lógica dos content types. Ora o que se passa aqui é precisamente o mesmo: temos a entidade product e podemos criar n types dessa entidade, também conhecidos por bundles.

PRODUCT TYPE: 3 custom types

Foi o que fizemos ao criar 3 novos product type: bouquet, bonsai, garden.

À semelhança do que acontece com os content type, e aliás qualquer entidade, vamos ter disponível uma secção Manage fields e outra Manage display.

PRODUCT TYPE: CAMPOS COMUNS E ATRIBUTOS
Por serem todos derivados da mesma entidade, partilham alguns campos default e required: sku, title, commerce_price e status.

O SKU é o código do produto, funcionando como um identificador único no sistema. Pode ser editado manualmente, mas existem processos automáticos de criação, algo muito parecidos com automatic title.

O title, claro está, required e também pode ser automatizado. Quando se usa o AUtoSKu para gerar SKU automático, o title é também automatizado.

O price é parte essencial, porque contém o valor unit price com base no qual todos os cálculos e regras de preços vão depender.

Status indica se o produto está ativo ou não. Quando marcado como inativo, deixa de poder ser adicionado e fazer parte de line itens. Existem aplicações próprias para gerir o stock e disponibilidade do product, mas o uso básico desta funcionalidade pode servir esse propósito de forma muito elementar.

PRODUCT TYPE: CAMPOS PERSONALIZADOS

Em relação aos custom fields ou fields adicionados especificamente por nós para os nossos product types, embora existam algumas diferenças, existe co-ocorrência de campos. O que fizemos, e devemos fazer nos casos em que o comportamento de um determinado campo seja comum, é reutilizar os campos, na linha do que se faz também na criação dos node types.

O campo imagem foi reutilizado em todos os três product types.

Muitos perguntar-se-ão porquê optar por colocar a imagem no product type e não no content type. Para termos o efeito de uma imagem por cada variação de produto - cor, tamanho, é fundamental posicionar este campo no product, pois permite fazer upload de imagem por SKU e não por node id que pode agrupar vários SKU de um mesmo produto. Pretende-se que, na visualização de um node de luvas de jardinagem, seja possível ver o mesmo modelo de luvas na cor azul, branca ou caki.

A esta variação de produtos chama o DC o atributo do produto. Sempre que a caraterística de um produto não for comum a todos os produtos do tipo, mas represente um fator de escolha no ato da compra, ela deve figurar como campo no product type.

Relativamente à escolha do tipo de campo e à sua configuração, no caso da imagem é óbvia, mas os outros campos já merecem um comentário.

No DC existem dois tipos de campo para seleção de opção: as lists e o term reference com vocabulário associado. Ambos funcionam, mas, no caso da color, optámos por term reference para ser possível trabalhar este atributo com um módulo contrib de seleção de cor: o commerce fancy attributes que espera um term reference para funcionar.

A configuração de atributos de um product que entendemos como variações e queremos dar a possibilidade ao cliente de escolher no momento de selecionar para o cesto têm de ter ativa a opção Attribute field settings. Esta opção diz ao Add to cart para tomar conta daqueles fields e disponibilizá-los juntamente com o botão Add to cart e preço.

08:51

PRODUCT TYPE: MANAGE DISPLAY

Como já referido, qualquer entity tem a parte de gestão da aparência dos campos que a compõem.

Este display controla a visualização do product em si, mas também reflecte-se nas partes do product type que estiverem a ser utilizadas (embebidas) no product display. Estes campos aparecem no node manage display como “Product: Price”, “Product: Image” com a indicação de que o controlo da aparência se faz em product type.

Os view modes facultados pelo DC são Default, Teaser e Node: teaser.

Novos view modes podem ser adicionados (veremos o caso do Commerce Add to cart confirmation) ou criados com Display Suite, por exemplo.

Configuração básica: product display
Article
10:44
ENTITY NODE: MANAGE FIELDS

Temos o obrigatório title, o title que vai servir de chapéu a todas as variações de um produto, e o title a exibir aos clientes. Temos um campo descritivo e dois campos de taxonomia, um referente ao catálogo, outro à família de produtos dentro de uma categoria do catálogo, o que poderia ter sido também opção um catálogo de 2 níveis. Mais explicações sobre a construção do catálogo seguem à frente.

A colocação dos campos de taxonomia no content type em vez do product type têm duas explicações muito lógicas:

  • primeira, as categorias do produto não são individuais, mas aplicam-se a conjuntos de produtos, pelo que faz sentido estar no nível do conten ttype que agrupa
  • segunda, as páginas de termos de taxonomia default do Drupal funcionam com nodes e não com products. Mais uma vez verifica-se aquela máxima de que o product não é para exibir, mas para criar a lógica de funcionamento e gestão da loja.

Se quiserem experimentar, tentem colocar um campo taxonomy term no product, façam o seu display e tentem que funcione.

De todos os campos aqui listados, aquele que permite toda a magia é o campo a que demos o nome de variations. É um campo do tipo Product reference que associa um node a um ou mais products. Ativamos um widget fabuloso de que daremos mais detalhes a seguir - o Inline entity form, que economiza muitos passos no processo e criação.

ENTITY NODE: MANAGE DISPLAY

No view mode Default, devemos mostrar os campos abaixo:

  • Product: Image (configurado no product type)
  • Category catalog
  • Description (default)
  • Product: Price (configurado no product type)
  • Variations (Add to cart)

Não é preciso mostrar campos como size ou color, porque foram adicionados ao Add to cart settings e ele mostra-os antes do Add to cart com todas as opções.

Já para o view mode Teaser, mostramos apenas:

  • Product: Image (configurado no product type)
  • Description (summay)
  • Product: Price (configurado no product type)
Configuração básica: line item type
Article
06:33

Para qualquer dos product type, vamos precisar de dois campos no Line item type com que vão funcionar:

gift: yes/no (campo boolean)

message (campo texto longo sem sumário)

Como lidamos mais uma vez com uma entity, dispomos obviamente de manage fields e manage display.

Em manage fields adicionamos os dois campos acima e, ao ativar conditional fields, fazemos depender a visibilidade de Message de acordo com o campo Gift estar ou não checked. esta configuração faz-se em Manage dependencies.

Nota - Rectificação ao vídeo em relação à configuração do campo conditional fields em Manage dependencies

Indica-se no vídeo a relação de dependência usando has value..., mas deve ser a a relação is checked. Isto para garantir que a condição funciona só quando é selecionado valor de checked no campo gift.

Substituir a configuração:

Dependent - Message (field_message)

Dependee - Gift (field_gift)

Description - Message is visible when Gift has value 1.

Pela configuração:

Dependent - Message (field_message)

Dependee - Gift (field_gift)

Description - Message is visible when Gift is checked.

Line item - manage display

Nesta parte controlamos sobretudo a ordem dos campos e etiquetas.

Uma chamada de atenção para uma especificidade do Line item type e aliás qualquer entity do Drupal Commerce.

Se criarem um line item type, fizerem alguns testes com Add to cart de produtos no carrinho, voltarão ao interface de configuração do Line itens types e verão que não é possível eliminar.

A opção delete só fica disponível se não houver nenhum produto com essa line item type em cart ou order. Esta issue dá conta disso mesmo: https://drupal.org/node/1940254

10:12

INLINE ENTITY FORM: CRIAÇÃO DE PRODUCT E PRODUCT DISPLAY NUM SÓ

Nesta sequência de vídeos de módulos contrib da área de products, damos conta de módulos contrib que exploramos para melhorar o resultado final e o funcionamento da nossa loja.

Começamos pelo IEF que disponibiliza um formatter extra em campos de entity reference ou similares - product reference, no nosso caso.

Quando temos dois items que queremos relacionar, a relação só é possível depois de ambos estarem criados. Ora este formatter, permite que na criação de um item se possa criar o outro com que se pretende relacionar e no final ter os dois items criados e corretamente associados.

Não fora o IEF, teríamos de criar os products todos e depois criar os displays de product em que iríamos fazer a mera associação. Este processo em duas etapas e pouco transparente para o utilizador final fica simplificado no com o IEF já que no momento de criar um product display permite gerar criar os products.

Este formatter tem duas opções: multiple e single. Este último sé seria aplicável se tivéssemos um único product display para todos os product type. Como optámos por criar um display para cada product type, devemos usar o multiple que permite escolher o type de product pretendido.

Quando o product display está configurado para aceitar mais que um product (será a situação mais comum), aparece a opção "Add another item".

07:07

AUTOMATIZAR A CRIAÇÃO DOS SKU (CÓDIGOS)

Esta opção é uma bênção quando começamos a criar produtos e temos de pensar na lógica para gerar os códigos de produtos.

Se os produtos já têm um código, referência, simplesmente usamos esse código, introduzindo-o no campo SKU.

Quando os produtos não têm um código ou queremos gerá-lo automaticamente, podemos usar o AutoSKU para criar placeholder. Este módulo usa os tokens e temos vários à escolha como data com possibilidade de ser modificada para ano/ mês [current-date:custom:?] e todos os fields que fazem parte do product type.

A configuração é muito simples, sendo toda ela realizada na secção "Editar" de cada product type. Uma vez ativado o módulo, aparece uma nova opção Automatically Generate SKU com disponibilização da já habitual lista de tokens prontos a usar e a combinar.

Numa secção mais abixo, ainda temos outras opções interessantes relacionadas:

  • Always regenerate SKU - esta opção permite fazer o bluk de items já existentes ou deixá-los e fazer só daí para a frente. Dependendo da lógica de criação e importação de items, pode ser uma opção a considerar.
  • Hide SKU Field - esconde o campo, evitando o ruído e tornando a edição mais limpa.
  • SKU Case - permite aplicar uppercase ou lowercase, uniformizando o aspeto dos códigos de produto.
06:27

COMMERCE FANCY ATTRIBUTES PARA CAMPOS DE OPÇÃO

Este módulo proporciona uma experiência ao utilizador mais interessante quando seleciona a cor. Em vez duma simples lista ou radio buttons monótonos, temos as cores que o cliente pode clicar.

O requisito do Fancy Attributes é um vocabulário, pois ele espera um campo do tipo texto com o valor da cor no formato HEX que ele processa.

Depois de criar o vocabulário e criar alguns termos com o campo de texto no qual é inserido o valor da cor, é preciso selecionar o widget de renderização correto - Add to cart attribute tem de ser o color widget para o módulo funcionar.

Basicamente, rejeitamos o widget habitual e selecionamos o widget ptoporcionado pelo Fancy attributes.

Ao visitar um product que use o campo color, vamos verificar que na visualização do node nos aparece a nova opção de seleção.

Pode ser necessário limpar a chache várias vezes.

Seguem alguns valores HEX utilizados neste exercício:

  • Green - #688C24
  • Lilas - #7B7399
  • Orange - #EDA746
  • Red - #8C2E2E
  • Rose - #FF7878
  • White - #FFFFFF
  • Yellow - #FFC619
06:33

PODER CRIAR VÁRIOS LINE ITEM TYPES

Tal como dito anteriormente, o Line item type default do Commerce permite aplicar Line item type a todos os product type, sem particularizar o tipo de product.

Se pretendermos restringir esse Line item type a um só tipo de product, é necessário recorrer a este módulo.

A sua instalação segue o procedimento habitual. Depois de limpar a cache, verificamos que na secção das Line item types nos é facultada agora a possibilidade de adicionar novo tipo de line item.

Trata-se de uma nova entity em tudo igual a outra entity. Podemos criar por cada line item type um field ou uma série de fields de tipologia variada.

Uma vez terminada a operação, só temos de ir ao product display (content type) onde pretendemos exibir a nova Line item type e em Manage display do campo Add to cart escolher o Add to Cart line item type da lista de disponíveis, em princípio o default Product e o nosso line item type custom.

Visitando um product com Product no item line type e outro product com o Line item type custom, confirmamos que os campos mostrados são diferentes e percebemos quão simples é customizar esta parte do sistema.

Section 6: Catálogo de produtos
05:16

Nesta parte vamos dar conta das movimentações que têm de ocorrer paralelamente no website, nomeadamente na área da taxonomia importante para definir a organização dos produtos e ainda o trabalho com Views para reflectir essa lógica.

Para criar o catálogo de produtos, a equipa do DC propõe a taxonomia.

Escusado será dizer que o catálogo é um elemento decisivo na exploração e navegação pelos produtos.

O vocabulário a criar pode ter um ou mais níveis, mas devemos sobretudo pensar na simplicidade e pensar sempre na experiência do utilizador.

VOCABULÁRIO: CATALOG

  1. Criamos os termos: Bouquets, Bonsai, Garden tools
  2. Aplicamos esse vocabulário aos content types: bouquet_display, bonsai_display, garden_display, adicionando um campo Term reference nos content type relacionados com os products.
  3. O passo seguinte foi criar um menu Catalog com os mesmos items da Taxonomia.
  4. Por fim, posicionámos o bloco na region pretendida.

Quando os catálogos de produtos são mais complexos, com vários níveis de categoria/ subcategoria, é preciso avaliar se não é melhor desdobrar em dois menus de navegação/ exploração.

No caso de a hierarquia ser um must, é recomendável usar o Menu Block que faz display de várias secções de um mesmo menu. https://drupal.org/project/menu_block

Gerar o menu a partir da taxonomia vai dar imenso jeito se o vocabulário for extenso. Ver o módulo Taxonomy Menu https://drupal.org/project/taxonomy_menu

Nesta fase do trabalho, ainda foi preciso criar o Vocabulário Color para o field_color do product type garden.

VOCABULÁRIO: COLOR

  • Termos: Red, Orange, ...
  • Aplicado a product type: garden
  • Field custom: color hex (text field)
  • Manage display: add to cart attribute (color widget)

A novidade na construção deste vocabulário está no facto de criarmos um field do tipo texto que vai guardar a informação da cor no formato hexagonal para o módulo contrib Commerce Fancy Attributes processar (ver Lecture 21).

10:27

CRIAR VIEW DE CATÁLOGO

Começa o trabalho com o Views e iniciamos pela construção da view que vai listar todos os produtos para os clientes, sem olhar às categorias.

View page - All products

Trata-se de uma view com display page, formato html list e a mostrar teaser dos node product display que no filtro Content:type limitamos aos nossos 3 content types com associação à loja.

O path a dar à page é /products e criamos um item de menu Normal no Main menu.

O CSS do tema encarrega-se de lidar com a apresentação em 3 colunas dos produtos de forma responsive, por isso no pager limitamos o nº a 12 items.

VIEW MODES USADOS NA VIEW DO CATÁLOGO

Vamos editar a aparência dos produtos do catálogo, tanto na forma resumida (teaser) como full (página individual).

Teaser

No teaser optamos por exibir os dados pela ordem: Product: Image (thumbnail), Description (trimmed), Product: Price. Os dois campos “Product” são configurados no Product type e não no Content type.

Full content/ Default

No view mode Full content (ativado), demos um arranjo em duas colunas usando simplesmente o Fieldgroup na secção manage display, com dois grupos: Column left (group_left) e Column right (group_right).

Na coluna da esquerda posicionamos o Product: Image e os restantes campos na coluna da direita: Product: SKU, Category catalog, Category family, Product: Price, Description (default), Variations (add to cart).

Devemos retirar da visualização todos os campos atributo do product que associamos ao Add to cart, caso contrário esses campos ficam repetidos no display. Caso de color, size.

Section 7: Gerir produtos
08:17

A secção da administração ou backoffice é muito importante numa loja em que centenas ou milhares de produtos têm de ser geridos e atualizados pela equipa, bem como todas as operações associadas.

Não é por acaso que o DC propõe cerca de 10 ecrãs de administração e para isto muito contribui o Views, um dos módulos requeridos pelo Drupal Commerce.

VIEWS ADMINISTRAÇÃO: COMPARATIVO DC E CK

Para termos a noção de como é perfeitamente possível estender essa base, propomos uma avaliação comparativa das views no Drupal Commerce (DC) e Commerce Kickstart (CK).

O DC apresenta ao todo, na versão standard, 9 views prontas a usar, e melhor ainda, prontas a serem modificadas caso se justifique. Essa é uma das belezas do DC, dar em modo de edição o acesso a todas as views que controlam o display, sejam eles para backoffice ou frontoffice.

  • Cart - 3 public views
  • Line items - 1 admin view
  • Orders - 2 admin views, 1 user view
  • Products - 2 admin views

9 views (Drupal Commerce)

Na origem, o CK apresenta 11 views, a que se somam outras tantas à medida que formos adicionando módulos contrib, porque a regra é transversal - todas as visualizações ficam listadas no interface do Views.

Neste capítulo da administração e interface, o CK dá lições muito interessantes e faz propostas de arranjo dos items muito pertinentes. E para quem não andar distrído, depressa se dá conta de que muitos dos detalhes de display do CK foram incorporados e constituem linha gráfica do Drupal 8!

Ao navegar pelo CK e ao editar e criar alguns items da loja, apercebemo-nos do modo transparente para o utilizador final do seu funcionamento. Esse interface mais intuitivo deve-se ao Commerce Backoffice.

Assim, sem estar a usar o CK, podemos beneficiar de ecrãs mais limpos e de atalhos de edição muito relevantes e um aspeto mais limpo do funcionamento do workflow - cria product, associa a node, consulta product, filtra product do type A com categoria C, etc.

  • Cart - 4 public views
  • Line items - 1 admin view
  • Orders - 2 admin views, 1 user view
  • Products - 2 admin views, 1 public
  • 11 views (Commerce kickstart)
  • ---------
  • Commerce add to cart - 1 public
  • Commerce backoffice - 7 admin
  • Commerce addressbook - 1 admin
  • Commerce message - 1 admin
  • Demo content slideshow - 1 public
  • Discounts - 1 admin

23 views (Commerce kickstart)

11:05

BACKOFFICE MELHORADO COM COMMERCE BACKOFFICE E OUTROS

Para tornar o backoffice mais ágil e intuitivo, vamos implementar algumas melhorias.

Instalamos o Commerce backoffice, que requer Views Bulk Operations e Views megarow.

Ainda vamos ativar Chosen, que requer jquery_update e a respetiva library jquery para tornar os exposed filters mais interessantes.

Outro módulo contrib interessante seria o Editable Fields.

Depois de instalar o Commerce Backoffice damo-nos conta de que é uma suite com Backoffice base e variações para product, order, content. Vamos deixar para já de parte o Backoffice order e ativamos os restantes.

O efeito é imediato e temos override de alguns links e ativação de novos com mais umas tantas views editáveis por detrás.

Esses views displays são em resumo:

  • Commerce Backoffice: Content
  • Commerce Backoffice: Comments
  • Commerce Backoffice: Products - content
  • Commerce Backoffice: Product variations
  • Commerce Backoffice: All products

ANTES E DEPOIS NAS VIEWS ADMINISTRAÇÃO

Vejamos alguns comentários a propósito e ajustamentos necessários na configuração para funcionarem com os fields dos nossos product type e content types.

admin/content -> admin/content (Commerce Backoffice: Content)

Este display faz override à lista de conteúdo default do Drupal core com a possibilidade de limitarmos a visibilidade aos items de conteúdo genérico, ou seja, content types que não sejam display de product types.

Esta view é do tipo Content e já vem preparada para filtrar unicamente items que não sejam graças ao filtro: Content: Product display (No)

admin/content/comment -> admin/content/comment (Commerce Backoffice: Comments)

Override da mesma view default do core.

admin/commerce/products/list -> admin/commerce/products/(list) (Commerce Backoffice: Products - content)

Esta view é a que combina product display e product type item. Ela lista os vários displays e no interior destes, com Quick edit temos acesso à sublista de items de product type aí incluídos.

Esta é uma view do tipo Content e o formato é megarow table.

Para que a view funcione com campos específicos do projeto, é preciso garantir que o formato ativo é table megarow.

Nas Relationships pode ativar-se o campo product reference incluído em todos os content types para seleção dos itens de products da loja (Content: Referenced products) para mostrar dados extra do Commerce product como SKU e outros.

(não existente) -> (Commerce Backoffice: Product variations - commerce product)

Este display funciona em paralelo com o anterior e corresponde à sublista dos items de product type relacionados com determinado display. Este sistema usa o megarow module para criar a sublista.

Esta view é do tipo Commerce product.

Para que a view funcione com campos específicos do projeto, é preciso garantir que nas Relationships esteja o campo Commerce Product: Referencing Node com obrigatoriedade desta relação ativa.

Estender esta relation ao Contextual filter no campo Content: nid, pois é este argumento que vai interceptar as duas views.

admin/commerce/products/list -> admin/commerce/products/variations (Commerce Backoffice: All products)

Representa a lista de todos os itens simples de products types, mas reformulada em termos de endereço.

admin/commerce/products/types -> admin/commerce/config/product-variation-types

Alteração do endereço da página que aloja a lista e campos de cada product type. Em vez da área de Products, os types são empurrados para a secção de configuração da loja.

Também podemos editar os exposed filters da view Backoffice product e ativar o módulo Chosen para que a seleção de items de opção seja mais interessante e intuitiva.

11:17

VBO: OPERAÇÕES DEFAULT

Já vimos os benefícios proporcionados pelo Quick edit na visualização geral de nodes/products, mas muito mais pode ser feito com VBO.

O VBO funciona tendo como base o Views e permite realizar operações em múltiplos itenns em simultâneo. Ele foi incorporado no Commerce e até existe a versão Commerce VBO Views, totalmente adaptada ao Commerce que recria as Views admin para products, content, line items, customers, orders, etc.

Na linha do que se faz com o VBO em geral, de que o Admin VBO Views é exemplo, é possível usar operações já propostas - por exemplo, apagar items, mas também criar operações específicas para o nosso website. Em concreto, vamos ver como alterar em massa preços de produtos.

Passo 1 - Instalar

Numa situação em que não tivéssemos o Commerce já com VBO, teríamos de instalar e eventualmente o Commerce VBO Views que recria as Views default do DC já com operações dadas pelo VBO. Porém, como estamos a usar o Commerce Backoffice e todas as suas benesses vamos conservar essa situação e só acrescentar a musicalidade dada pelo VBO.

Passo 2 - Retificar views

No caso de não termos o Commerce Backoffice e usarmos na sua vez o Commerce VBO Views, é preciso repassar as Views e verificar se todo trabalho está como queremos, sobretudo se anteriormente tivermos feito algum trabalho de personalização dessas views DC default.

Passo 3 - Comparar views e avaliar ganhos

Estejamos com o Commerce Backoffice ou com o Commerce VBO Views, verificamos que na lista de fields das visualizações de administração existe um campo especial facilmente reconhecido por começar por “Bulk operations”. E falo em começar, porque podemos ter vários tipos de campos VBO, por exemplo um relativo a operações a realizar com nodes (Content) e outro com Product.

No exercício a realizar para mudar o preço, vamos precisar do Bulk operations: Product.

Podemos testar as operações propostas pelo VBO Product, que em princípio é uma única: Delete product item. Podemos fazer alguns testes e eliminar conjuntos de items de uma só vez.

Visitando a área de configuração do campo VBO, apercebemo-nos da possibilidade de ativar mais operações que estão disponíveis por defeito, mas benhuma que se assemelhe a alterar preço de produtos.

10:31

VBO: CRIAR OPERAÇÕES NOVAS

Passo 4 - Criar rule action set para mudar o preço

Adicionar uma operação ou mais à lista de ações a realizar pelo VBO implica criar uma Rule usando a opção Component, especificamente o plugin “Action set” dos plugins de componentes.

A ideia dos componentes é estabelecer os parâmetros a usar e depois chamá-los na construção da rule, que neste caso se reduz a uma action sem eventos nem condições.

As Variables correspondem ao quadro dos parâmetros que definimos no início.

A Label pode ser importante ser escrita em função do que faz sentido para o utilizador que vai introduzir ou selecionar um valor.

O Integer foi o valor escolhido pelo facto do preço ser um integer na base.

O input do valor tem sempre de ser feito com mais 2 zeros. 20€ tem de ser 2000.

Passo 5 - Criar rule action set para Enable product

Muito semelhante nos parâmetros à anterior, por estarmos a trabalhar com entity Commerce product onde queremos realizar as operações, mas desta vez o segundo parâmetro é um Truth value com seleção no ato da configuração, ou seja, dizemos que o valor há-de ser true.

Passo 6 - Criar rule action set para Disable product

Em tudo igual ao anterior, com a diferença de Truth value não estar ativo (selecionado), portanto é False.

Importar Products - Soluções
Article
18:22

PASSO 1. ATIVAR MÓDULOS

Vamos usar naturalmente o feeds, o commerce_feeds e o job_scheduler requerido pelo Feeds.

PASSO 2 . CRIAR NOVO FEED IMPORTER

Ir a admin/structure/feeds e clicar em "Add importer" admin/structure/feeds/create

PASSO 3. EDITAR O FEED IMPORTER

O nosso objetivo é criar um feed importer para product.

A configuração faz-se em vários passos e todos eles configuram uma parte do processo de importação.

Basic settings

É a secção que devemos usar quando importamos conteúdo para product display ou qualquer content type. Como queremos importar product, esta parte é praticamente ignorada.

Fetcher

É o formato do ficheiro source. No nosso caso vamos usar csv, por isso escolhemos o File upload. De acordo com a seleção, especificamos as extensões de upload e a pasta onde os ficheiros source vão ficar guardados.

Parser

É o programa que vai ler os dados e que deve estar adequado ao tipo de formato. Naturalmente, precisamos do CSV parser. Seguem-se as espeficiações do csv parser, o delimitador de campo que estiver a ser usado no nosso ficheiro csv.

Processor

Esta parte é aquela em que definimos que destino queremos dar aos dados processados. Regra geral, temos o node processor dado pelo Feeds, mas aqui encontramos outras opções asseguradas pelo Commerce Feeds: Commerce Customer Profile processor, Commerce Product processor. Como está fácil de ver, para importar products, usamos o Commerce Product processor.

A configuração prende-se com a seleção do bundle (ou type) de product. Esta é uma limitação do Commerce Feeds. Ele só permite importar products de um type por cada feed importer. Se tiver na loja 6 product type, terei que criar 6 feed importer e também criar 6 ficheiros .csv com os dados por product type.

Querendo ter um único importer e um só csv, posso sempre usar o Commerce Feeds Multitype.

Para terminar o feed importer, falta fazer o mapping que é uma operação em que se estabelece as correspondências entre source (escrito como está no ficheiro csv) e target (campos do product type selecionado).

Para a situação específica de imagens, elas devem ser primeiramente arrumadas na pasta que o field imagem do product indicar em files. No ficheiro a importar, é preciso criar a coluna Imagem e especificar o path que deve ser relativo. Ex. sites/default/files/product/my-style/myimage.jpg

PASSO 4. IMPORTAR

Visitar o link /import onde ficam listados todos os feed importer e selecionar o feed importer criado.

Ajustar o delimitador de campo e fazer upload do csv.

A importação, mesmo de centenas de items, faz-se rapidamente.

Para importar product display, é repetir a mesma operação, criando um feed importer com Node processor na configuração do processor e ajustar todas as outras secções, inclusive a escolha do node type destino.

05:30

Neste breve vídeo, mostramos o website depois de adicionados alguns itens de produtos à loja, sempre por via do Add content - bonsai, bouquet ou garden, dentro dos quais criámos os produt item de loja.

Exemplificamos ainda como dar um arranjo mais interessante às páginas de categoria dos produtos, acrescentando uma imagem associada à categoria da Taxonomia Catalog.

Esta imagem é um campo custom do tipo Image que associamos a cada categoria.

Section 8: Pricing
Price
Article
06:44

Esta parte não é específica das regras de cálculo de preço, antes faz uma breve introdução ao Rules e à sua centralidade no DC.

A escolha do Rules para parametrizar todas as variáveis na loja dá flexibilidade extraordinária à aplicação. Porém, requer alguma prática e noções de como estão estruturados os dados e como os chamar nas regras que criamos.

Uma Rule pode ter 3 secções: eventos, condições, acções.

O primeiro é o que faz disparar a rule.

O segundo são as condições que se pretende que ocorram conjuntamente ou parcelarmente para se aplicar a ação.

As ações são o conjunto de operações a realizar.

06:01

O objetivo aqui não é listar exaustivamente todos os eventos e condições das Rules, mas referir as opções específicas para Drupal Commerce.

Esta listagem de opções considera apenas os componentes básicos do Commerce. Se ativarmos mais componentes, por exemplo Payment, teremos outros eventos e outras condições.

O mesmo raciocínio vale para módulos contrib quando expõem os seus elementos ao Rules.

10:43

LINE ITEM E PRODUCT NA LÓGICA DO PRICING

O foco neste capítulo são rules associadas a pricing. Noutros capítulos, veremos rules específicas para cart, checkout, etc.

Para perceber o modo de funcionamento das Rules pricing, é preciso ter em mente alguns pressupostos, designadamente que as product pricing rules têm sempre como parâmetro um product line item.

Tendo em conta que:

  • Line item é gerada sempre que um produto é colocado no cart
  • Line item tem um Product item associado via relação commerce_product
  • Line item usa campo commerce_price do Product para calcular preço unidade do produto
  • Line item é passada pelas rules de pricing
  • Line item possui commerce_unit_price que apresenta preço unitário aplicadas já regras de pricing
  • Line item tem quantity atributo
  • Line item multiplica commerce_unit_price pela quantity
  • Line item apresenta total da quantidade de um produto via commerce_total
  • Line item tem path para aceder ao product display

É possível realizar todo o tipo de operações:

  • Add an amount to unit price
  • Convert the unit price to a different currency
  • Divide de unit price by some amount
  • Set the unit price to specific amount
  • Set the unit price's currency code
  • Subtract an amount from the unit price

Então, o que vamos ter no final é o preço base transformado em preço final de venda

ACESSO ÀS RULES PRICING

Podemos aceder à lista de regras de preços em admin/commerce/config/product-pricing , uma área da configuração da Store totalmente voltada para os preços e cálculos.

Mas as mesmas surgem listadas no painel geral das rules em admin/config/workflow/rules .

Veremos em seguida algumas boas práticas a adoptar na criação de rules e na sua organização, pois é muito fácil acumular rules que deixamos de controlar e que fazem override umas às outras.

07:26

RULE DESCONTO COM BASE NO ROLE E quantidade de produtos

Esta regra só é aplicável se satisfeitas 2 condições: uma relativa ao tipo de utilizador, outra à quantidade solicitada de um mesmo item de produto.

Aplica desconto 20% se cliente é administrador e se seleciona mais que 3X o mesmo produto.

Desconto é aplicado por line item type no item que apresenta quantidade superior a 3. Se no total do cart, o cliente tiver selecionado mais que três produtos, mas nenhum item em particular, a regra não dispara.

Para uma avaliação das mudanças e maior clareza para o utilizador, é possível optar pelo formatter "Formatted amount with components" em vez do "Formatted amount" simples. Quando feitos descontos ou aplicadas taxas, não fica claro para o cliente se não se decompuser as partes do preço.

Aplicamos só este formatter no view mode line item, mas deixamos o Formatter amount para Default e Node: teaser, porém com a opção - Displaying the original price em vez do default Display the calculated sell price for the current user.

08:42

DESCONTO COM BASE NA QUANTIDADE TOTAL PRODUTOS

Este desconto apresenta uma única condição, por isso é aplicável a qualquer cliente que satisfaça essa única condição.

Aplica desconto 20% se total de nº de produtos no cart é igual ou superior a 5, independentemente do nº da quantidade por line item. Pois aqui o que conta é a quantidade total de produtos no cart.

Satisfeita a condição, os 20% aplicam-se a todas as linhas de produto sem excepção.

05:28

DESCONTO COM BASE NO MONTANTE TOTAL DOS PRODUTOS

Este desconto apresenta uma única condição, por isso é aplicável a qualquer cliente que satisfaça essa única condição.

Aplica desconto 20% se total do montante no cart é igual ou superior a 100€, independentemente do montante por cada line item. Pois aqui o que conta é o valor total dos produtos no cart.

Satisfeita a condição, os 20% aplicam-se a todas as linhas de produto sem excepção.

07:36

DESCONTO COM BASE NA QUANTIDADE TOTAL DE UM TIPO DE PRODUTO

Este desconto apresenta o mesmo raciocínio que o anterior, com a simples diferença de limitar a um tipo de produto e ser aplicado não pelo cart, mas pelo line item.

Os 20% de desconto só acorrem se se verificar compras de 3 ou mais produtos do tipo bouquet.

Neste caso, ao testar a regra, verifica-se que o desconto se aplica somente nas item lines que tenham produto bouquet e com quantidade mínima de 3.

As outras lines ficam inalteradas e podem até apresentar 20 items de quantidade que nada muda.

NB: Se o mesmo porduto do tipo bouquet é adicionado várias vezes em diferentes line item, o desconto não se aplica.

Não foi possível salvaguardar esta limitação, porque teríamos de controlar quantidade por linha e quantidade por cart do tipo bouquet.

07:37

DESCONTO ESPECIAL PARA REVENDEDOR

Imaginemos que queríamos dar desconto de 30% em todos os produtos a utilizadores do tipo revendedor. Obviamente, esta regra só dispara funciona com utilizador registado, pois anónimos não têm role. Aplicamos desconto de 30% se se verificar a condição de que é revendedor. Naturalmente que previamente à criação da rule, é necessário criar um role "revendedor".

Por defeito, o Drupal Commerce nas operações de cálculo do preço disponibiliza os seguintes componentes: Base price, Discount, Fee. Como abaixo explicado, vamos criar novo componente type de Preço e seleccioná-lo uma vez disponível.

Podemos obviamente usar o Discount, porque é disso mesmo que se trata e surge o preço desdobrado em Base e Discount, mas se quisermos ser mais específicos e criar um componente desconto específico para revendedor, podemos fazê-lo usando simplesmente o hook_commerce_price_component_type_info()

Para isso, criamos um módulo custom. Podemos chamar o nome que quisermos, sem usar nomes usados ou reservados.

1. Criar pasta "custom" em sites/all/modules

2. Criar ficheiro custom.info com dados

name = Custom

description = Custom code

package = Commerce contrib

core = 7.x

3. Criar ficheiro custom.module com linhas

	<?php
	/**
	* Implements hook_commerce_price_component_type_info().
	*/
	function custom_commerce_price_component_type_info() {
	return array(
	'desconto_revendedor' => array(
	'title' => t('Desconto revendedor'),
	'weight' => -40,
	),
	);
	}

4. Ativar módulo na secção indicada

5. Limpar caches

6. Reeditar rule do desconto de revendedor e selecionar novo componente que passa a estar agora disponível

7. Se testarmos, nos componentes do preço vai aparecer "Desconto revendedor"

Módulos contrib: categoria price
Article
10:35

CATEGORIA RULES

Como já nos apercebemos, o Rules é fundamental no desenho da loja. Existem alguns módulos, na maior parte tentam disponibilizar em primeira mão condições frequentes prontas a usar. No entanto, tudo o que é disponibilizado pode ser acedido pleo Rules sem extras com um percurso um pouco mais laborioso.

Commerce Extra Rules Conditions

https://drupal.org/project/commerce_conditions

Disponibiliza mais conditions que se podem usar diretamente sem muito trabalho de chamar campos. Este módulo tem manutenção pouco regular.

Conditions extra:

Commerce Line item (secção só disponível normalmente nas Actions)

  • Line item product has term
  • Line item product has term

Commerce Order

  • Total product of type quantity comparison
  • Total product with term quantity comparison

Commerce Rules Extra

https://drupal.org/project/commerce_rules_extra

Fork do commerce_conditions segundo o maintainer. Pretende disponibilizar uma coleção de eventos, condições e ações para o DC.

Eventos extra:

  • Process checkout pane
  • Quantity of line item has changed

Conditions extra:

Commerce Line item

  • Line item product has term
  • Line item product has terms

Commerce Order

  • Total product with term quantity comparison
  • Total product of type quantity comparison
  • Total product of type amount comparison

Actions extra:

  • Change pane properties - por exemplo, pode mudar-se a visibilidade do pane com Billing information do cliente que pode não aparecer se a order for relativa a um product type x
  • Get the referencing node from the line item
15:02

CATEGORIA DESCONTOS

Mais uma vez, depois de explorar os módulos contrib relativos a descontos, verificamos que a função é sobretudo a de oferecer um interface mais apelativo para criar descontos, porque na base, o Commerce Discount usa o Rules. Podemos consultar as rules depois de criar um novo desconto para confirmar que nova rule é gerada e listada.

Commerce Discount

https://drupal.org/project/commerce_discount

Precisa de Entity Reference, Inline Conditions para referenciar product/ discount. Traz extensões:

  • Commerce Discount Date para parametrizar descontos por períodos de tempo com datas.
  • Commerce Discount Usage para fazer tracking do uso de descontos se precisamos de restringir desconto só para primeiras 20 compras, por exemplo.

Cria nova opção com interface exclusivo em Store > Discounts.

Na edição dos settings do discount define-se com que line item type se quer trabalhar. Ele próprio gera 2 line item type: Fixed amount discount (Machine name: commerce_discount) e Product discounted (Machine name: product_discount).

Tanto permite criar descontos como importar descontos.

Para criar um desconto, é preciso:

  • dar nome (identificação e label para clientes)
  • escolher tipo de desconto: order ou product
  • definir condições - atributos per product type, per category (taxonomia)

Existe alguma documentação básica em: https://drupal.org/node/1706132

Commerce Discount Extra

https://drupal.org/project/commerce_discount_extra

Depende do Commerce Discount e acrescenta mais duas condições de criação de desconto per order.

Módulos contrib: categoria coupons
Article
21:20

CATEGORIA CURRENCY

O DC foi pensado para lidar com múltiplas moedas e realizar conversões. Após instalação, traz o básico, mas existem módulos para circunstâncias mais complexas.

A configuração da(s) moeda(s) aceite(s) faz-se em Store > Currency settings e todos os módulos contrib alojam aí configurações mais específicas em tabs extra.

Configuração básica das moedas

  1. Ir a Store > Currency settings
  2. Determinar a moeda default
  3. Selecionar moedas com que se pretende trabalhar

Se houver já produtos criados, eles assumem a que lá estiver editado em termos de moeda default, pois a configuração de settings após items de produtos já existentes só tem impacto em novos items.

Para converter valores das moedas, usa-se o Rules.

  1. Criar rule nova com taxa de conversão fixa: Convert US to EUR
  2. Adicionar Condition: Data comparison > "commerce-line-item:commerce-unit-price:currency-code" > Equals > Default currency
  3. Adicionar Action: Multiple the unit price by some amount > Amount: 0.73, isto se considerarmos que 1$USD são 0.73€EUR
  4. Adicionar Action: Convert the unit price to a different currency > EUR

Porém, este método é manual e requer actualização da taxa de conversão periodicamente, por isso vamos ver formas de automatizar este processo no vídeo.

Commerce Currency Settings

https://drupal.org/project/commerce_currency_settings

Estende os parâmetros de edição e display das moedas via interface por cada uma das línguas ativas no sistema.

Por defeito, as definições de moeda do DC só permitem seleção de moeda. Com este módulo, todos os parâmetros inerentes à moeda e aà forma de a apresentar ficam acessíveis, desde o símbolo, nome da moeda, casas decimais, etc.

Commerce Multicurrency

http://drupal.org/project/commerce_multicurrency

Tem a grande vantagem de não obrigar a definir um preço de produto por cada item. Na verdade, existe um único preço (na moeda default) que é convertido para as outras moedas quando solicitado. Essa conversão é totalmente automática e assenta nas taxas de conversão do Banco Central Europeu, sendo possível acrescentar outros providers.

Um bloco e duas rules encartregam-se de disponibilizar um switch por moeda.

Currency Info Hooks

http://www.drupalcommerce.org/developer-guide/core-architecture/info-hooks/currency-info-hooks

A API do DC em matéria de currency disponibiliza uma série de hooks para uso se necessário personalizar para além daquilo que os módulos contrib já permitem.

Truques ao lidar com o Rules
Article
Section 9: Shopping cart
03:56

FUNÇÃO DO CART

É uma funcionalidade imprescindível nas lojas de eCommerce e traduz-se na forma visual do carrinho, cesto.

A sua função é agrupar os produtos selecionados para compra, ou seja, aqueles que o cliente (anónimo ou autenticado) quer comprar, embora não haja garantia de que é para comprar efectivamente (realizar checkout).

A ideia do cart é coligir os items adicionados, mas tem prevista a remoção de items, edição da quantidade de produtos e outras características. Pode estar associado a uma sessão ou a um user em específico.

O cart, na lógica da encomenda (Order), representa o primeiro passo ou fase.

Vamos ver neste capítulo o que é o Add to cart e como funciona nos bastidores. Também veremos como o configurar e que aspectos podemos modificar e como.

Quando falamos no sistema do Cart no Drupal Commerce estamos a falar de pelo menos 3 grandes componentes e ainda de um sem número de ações e interações nos bastidores.

Existem várias versões de Cart desenhadas para diferentes circunstâncias. Os dados exibidos dependem do que parece fazer mais sentido a cada momento. No entanto, qualquer dos forms pode ser personalizado e trabalhado de modo diferente.

É claro que os candidatos mais importantes para personalização das várias versões de cart são:

  • interface do Drupal commerce
  • rules ligadas ao cart
  • visualizações criadas especificamente pelo Views
  • modificação de código original com recurso aos hooks

De tudo isto veremos um pouco.

12:14

ADD TO CART

É a parte de leão do sistema do cart e o funcionamento é bastante complexo, porque acontecem muitas ações e interações por detrás. Também é a versão de cart que mais chama a atenção e que marca a origem de qualquer compra e seleção de produto.

Sempre que o utilizador clica no botão”Add to cart”, uma order nova é criada, mesmo quando se trate de user anónimo. Também nesta fase, se o produto expuser ao utilizador os seus atributos para escolha, os campos adicionados ao Add to cart form ficam disponíveis.

A configuração no interface faz-se a partir do Manage display do node type que é usado para mostrar um product type. Aí é possível editar opções como:

  • disponibilização ou não do widget de quantidade
  • campos de atributos de produto adicionados ao cart
  • campos da line item type adicionados ao cart

E falamos em opções, porque no limite o form do add to cart pode disponibilizar unicamente o botão submitted.

O código relativo ao Add to cart está concentrado no ficheiro commerce_cart.module, pasta do módulo cart do commerce. Aí encontramos todas as functions, mas nunca devemos modificar os ficheiros originais. Por isso, é importante ter noção de como implementar um hook e saber como consultar o repositório de hooks de projectos contrib do Drupal em http://drupalcontrib.org/api/drupal

14:03

SHOPPING CART PAGE

É o formulário que lista todos os line items da presente order.

Acede-se a este painel em primeira mão via mensagem do sistema que apresenta link para o /cart assim que item é adicionado (resultado de rule). Mas geralmente, um botão permanente ou um icon fazem a ligação a esta página com o endereço /cart.

O que temos por detrás é uma view com display page que naturalmente pode ser modificada para ir ao encontro do tipo de display mais adequado.

Os campos default visíveis são:

  • Product
  • Price
  • Quantity
  • Remove
  • Total

A esta lista podem somar-se mais campos específicos da Line item ou do Product type, desde que assegurada a relação Commerce line item: Referenced Product.

A visualização do cart por meio de um display do Views dá-lhe toda a flexibilidade de que precisa. Vamos exemplificar no vídeo com o campo message do Line item type e o campo Image do Product type.

08:12

HOOKS: ALTERAR COMPORTAMENTO DOS FORMS

Em qualquer das visualizações de cart, é possível retirar, acrescentar e modificar formatters dos campos exibidos. O segredo repousa logicamente no Views que confere a flexibilidade na hora de trabalhar displays.

Mas sempre que isso não é possível, podemos lançar mão da API e aplicar hooks. A vantagem é podermos ter um módulo custom com todos os hooks que quisermos.

Um hook é um pedaço de código em php que corresponde sempre a uma function reconhecida pelo sistema, e que pode ser do core ou de um módulo contrib, etc.

Quando usamos um hook, alojamo-lo normalmente num custom module, num custom theme ou no ficheiro template.php

Sempre que o Drupal encontra uma mesma function a ser chamada, dá prioridade à versão mais específica, fazendo override à original.

Na prática, para a function commerce_cart_add_to_cart_form() existe o hook function hook_form_FORMID_alter(). Para pôr o hook em ação devemos substituir hook por meumodulo__form_commerce_cart_add_to_cart_form_alter().

O sistema interpreta que o meumodulo__form_commerce_cart_add_to_cart_form_alter() é mais específico e dá prioridade a esse na hora de renderizar, processar, ou o que quer que seja que ocorra na function.

Nos exemplos que se seguem, utilizamos a function para modificar diferentes aspectos do form Add to cart. Devemos alojar essas functions num módulo custom a que demos o nome de “custom”.

07:58

HOOK FORM ID PARA ALTERAR TEXTO

Em relação ao button “Add to cart”, é por vezes necessário alterar o texto a mostrar.

Claro que é possível modificar o texto via Traduzir interface na configuração > Línguas, mas o acesso à string da versão original (language source) fica inacessível via tradução. Por isso é que muitas pessoas usam o módulo Stringoverrides.

O que vamos mostrar é a possibilidade de modificar esse texto via hook, restringido por product type ou aplicando a todos os produtos, independentemente do type.

O hook de que falamos é o hook_form_FORMID_alter() que é específico dos forms. Como o Add to cart é um form, só temos que indicar o ID para se lhe aplicar.

Na primeira versão do hook, temos o texto “Pay now” para o product type bouquet e Add to cart (default) para os restantes.

Na segunda versão, temos o texto “Shop now” para todas as situações.

Em ambos os casos, usamos a função t() que deixa que o texto seja traduzido noutras línguas.

05:04

HOOK FORM ID PARA ALTERAR BOTÃO

Esta function serve para colocar uma imagem no cart diferente da default.

Este trabalho pode ser feito com CSS com background-image, mas esta meia dúzia de linhas faz o mesmo eficientemente.

Mais uma vez temos o hook do form com a chamada do elemento $form[‘submit’] que representa o botão.

A imagem pode ficar alojada no próprio module custom, devendo ser indicado o path.

Se atentarmos via inspect element, verificámos que por defeito no HTML o input type é “submit” e depois de corrido o hook, o elemento passa a input type “image”:

<input type="submit" id="edit-submit" name="op" value="Add to cart">

<input type="image" id="edit-submit" name="submit" src="http://example.com/sites/all/modules/custom/img/taupe-add-to-cart.png">

08:44

HOOK FORM ID PARA ALTERAR ORDEM ELEMENTOS

Para exemplificar como alterar ordem dos elementos que fazem parte do Add to cart form temos várias opções de acordo com o tipo de elementos.

Se se tratarem de campos do product type ou da line item type, basta na secção Manage fields dispô-los pela ordem desejada.

Porém, existem situações em que certos elementos não são passíveis de serem manipulados via interface.

Veremos isso com o módulo contrib Commerce Wishlist.

Apesar de este módulo ter, na versão dev, uma opção de weight para o botão Add to wishlist, a versão estável ainda não oferece essa flexibilidade. Assim, vamos ter de recorrer ao uso de hook.

Para este exercício precisamos do módulo Devel e do module custom onde estamos a armazenar todos as nossas modificações e de saber que a ordem de elementos assenta no weight (peso).

Sabendo que o botão Add to cart tem peso 50, precisamente de dar ao botão Add to wishlist pelo menos o peso 51 para ele ficar imediatamente a seguira.

Mais uma vez o hook é o do form_alter. Abaixo verão porém que tem peso 99 para o caso de algo ser colocado entre.

Cart e users
Article
06:00

ESCONDER ADD TO CART A ANÓNIMOS

Há certos requisitos de loja em que não se quer mostrar preços a anónimos ou permitir compras.

Para esconder o Add to cart para anónimos é preciso alterar o form, já que as permissões default e especificamente o Access checkout só travam anónimo mais à frente no workflow, não na fase de adicionar produtos ao cart.

ESCONDER SHOPING CART PAGE A ANÓNIMOS

Como vimos está previsto numa rule standard a criação de uma sessão commerce de anónimo, gerando conta de user posteriormente. Se entretanto se autentica, o cart é associado àquele user.

Para esconder o Shopping cart page de anónimos, alterar o Access da view que controla o display para "user authenticated".

Para que a configuração tenha efeito, é imprescindível criar display page na view a partir do master display. Esse novo display page faz override ao anterior. Usamos na mesma o path cart, e ao configurar o Access por role, passa a ter efeito.

10:39

ESCONDER BLOCK CART A ANÓNIMOS

Outro requisito comum é esconder o cart de acordo com o tratar-se de user anónimo ou autenticado.

Visto tratar-se de um simples bloco, para impedir que anónimos vejam o cart, basta limitar a visibilidade do bloco a "user auhenticated".

14:33

ESCONDER BLOCK CART SE VAZIO

Um requisito comum é esconder o bloco se o cart estiver vazio.

Por defeito, se o bloco estiver posicionado numa region do tema ele é sempre visível, mesmo quando o cliente não selecionou nenhum produto. Nesse estado (empty) a mensagem “Your shopping cart is empty.” é mostrada.

Se visitarmos o display, verificamos tratar-se do Master display, o que significa que alguns aspetos estão a ser controlados por código e não é um display totalmente entregue ao Views.

Se criarmos um bloco custom aproveitando a funcionalidade do clonar, e posicionarmos esse bloco em vez do default Master, passamos a ter total controlo, podendo agora o Views não mostrar por defeito o bloco quando não existem items.

Porém, o Shopping cart block do master parece-nos ter um comportamento desejável na maioria dos casos das lojas, já que o bloco com a mensagem indicativa de que o cart está vazio pode funcionar como um Call to action.

Rules de cart
Article
14:48

RULE PARA CART: ADD ITEM OFERTA

Para exemplificar um casos prático de uso do Rules aplicado ao cart, criamos o seguinte cenário.

Em vésperas de Natal, a Nature Style oferece 5 postais de Natal da Unicef aos seus clientes. Porém, isso só pode ocorrer 1 vez por cada cart ID e é importante que a oferta esteja restringida ao período de compras entre 1 e 24 de Dezembro.

Neste exercício, temos de lidar com as datas e temos de nos certificar de que o a data do cart modificado ocorrer no período de tempo da promoção. Usamos a data do cart modificada/ update e não a data de criação, porque pode dar-se o caso de um cart já ter sido criado há muito tempo e atualizado no período de promoção.

Outro aspecto a ter em conta é a validação do cart como candidato à promoção, pois aqueles cart que já tenham na sua lista de items a oferta, não devem gozar do bónus sempre que é adicionado novo produto.

Importante chamada de atenção é a do SKU do produto de oferta que consta na Rule. Esta rule pressupõe que haja no sistema o product type “offer” e que haja pelo menos um item desse type com o SKU: Christmas2013. Para testar a rule sem esta operação, basta editar na secção do SKU para aí adicionar um código válido do sistema em que se estiver a testar.

06:29

COMMERCE WISHLIST

São vários os contributos dentro do âmbito do shopping cart. Vamos passar revista algumas opções, sublinhando o que de interessante oferecem.

Comecemos pela Wishlist, cujo módulo já referimos a propósito do peso dos elementos no form add to cart e como reordená-los, mas ainda não falamos das suas funcionalidades.

Além de permitir criar listas em vez da adição imediata de produtos ao cart, dá a possibilidade de remover elementos, diferencia produtos pelas suas variantes, e, muito importante, transfere produtos da wishlist para o cart.

No espírito da flexibilidade de display do Views, proporciona 2 tipos de visualização - um bloco e uma page com o path /whishlist.

07:24

COMMERCE ADD TO CART CONFIRMATION

Trata-se de uma alternativa bem mais sofisticada e agradável ao simples “Display an Add to Cart message” do Drupal Commerce. Este módulo é parte do profile install Commerce Kickstart.

Ao usar este módulo, a rule do "display a message" deve ser desativada, para evitar redundância.

O cart confirmation usa o sistema modal overlay e disponibiliza dois links, um para continuar a explorar os produtos, outro para saltar para o Cart/ Checkout.

No nosso caso, para termos o módulo a funcionar bem e adequar-se ao tema em uso, foram feitos alguns retoques no CSS, tendo-se mesmo optado por alojar o ficheiro .css do módulo no tema em uso e declará-lo no .info

Módulos contrib: outros
Article
Section 10: Checkout process
Checkout builder
Article
Rules e workflow: workflow default
Article
08:58

CHECKOUT POR ANÓNIMO COMENTADO PASSO A PASSO

No vídeo é possível seguir de perto o workflow comentado para checkout feito por anónimo. Seguem-se as etapas e as chamadas de atenção para aspectos de configuração em que vamos testar se as rules de Checkout commerce, três delas visando os checkouts anónimos.

1. Editar permissões

Para darmos ao anónimo a possibilidade de realizar checkout, temos de verificar se a permissão “Access Checkout” (módulo Checkout) está ativa para anónimo. Podemos aproveitar para ativar permissão na secção do módulo order “View own orders of any type” e eventualmente “Edit own orders of any type”, para que os utilizadores já autenticados possam dispor de um tab com orders na sua conta e consultá-las sempre que desejarem.

2. Testar rules feito o checkout anónimo

Um utilizador anónimo coloca produtos no cart e clica em checkout, preenchendo os dados de compra, mas sobretudo, e muito importante, o email disponibilizado pelo DC na fase do checkout.

Mesmo sem autenticar-se, o anónimo pode clicar no link da order e ver o seu resumo, porque isso está previsto no fluxo.

Entretanto, do lado do sistema, como o email não existe na lista de contas, são enviadas de imediato 2 mensagens:

  • uma a dar conta da compra e que ocorreria sempre, mesmo que user autenticado;
  • outra a dar conta da abertura de conta e link para reset da password no primeiro login (default do Drupal registration), esta última desencadeada pela rule

3. Autenticação

Munido do link de conta, é possível ao anónimo autenticar-se, ter as suas orders associadas e acessíveis na conta num tab “Orders” e tudo isto sem ter sido inviabilizada a sua compra com passos de permeio para registo.

4. Administração

No painel das Orders e no tab Shopping carts, podemos verificar que sempre que um produto é adicionado ao cart e não existe cart order, é gerada um novo order number.

Assim que a pessoa realiza checkout, passando pelas 4 ou mais etapas que isso implica (ver Checkout pages na Lecture 68), a order é transferida para tab das Orders que já possui dados de conta e compra associados.

A order fica pronta para ser processada pela equipa da loja.

Rules e workflow: workflow alternativo
Article
09:59

COMPONENTES DO CHECKOUT

O Checkout é todo ele modular. Não só é possível acrescentar passos e retirar passos ao processo, como agregar várias unidades informativas por passo e até chamar a mesma unidade em diferentes passos.

Por detrás desta flexibilidade temos dois elementos estruturantes:

  • checkout page
  • checkout pane
Componentes do Checkout: Checkout pages default
Article
Componentes do Checkout: Checkout panes default
Article
Componentes do Checkout: Configuração de pages e panes
Article
09:52

UTILIZAR HOOKS PARA MODIFICAR

Os Hooks são uma solução rápida e limpa para alterar código ligado ao core, tema e módulos contrib, sem hackear o core. Vamos perceber como utilizá-lo em diferentes situações no Checkout.

Hooks de checkout: Checkout pages
Article
Hooks de checkout: Checkout panes
Article
05:16

CONTRIB: COMMERCE CHECKOUT PROGRESS

A maior parte dos módulos contrib da área do checkout estão associados ao estatuto do utilizador - anónimo/ autenticado, e ao jogo registar/ comprar.

Mas existem outros exemplos que se focam na aparência e ainda em melhorar a experiência do utilizador.

Outra coleção ainda propõe diferentes soluções ao nível do número de páginas e criação de páginas.

Neste vídeo em concreto, veremos como funciona o Checkout Progress.

Ele apresenta as fases da compra em etapas num bloco posicionável (no topo) das páginas pertencentes ao checkout. É extremamente importante para o cliente orientar-se no fluxo, poder recuar, avnaçar, cancelar, colocar perguntas, etc. A regra é mostrar a informação no momento em que faz sentido e de forma inequívoca.

Este módulo permite ainda transformar o cart num passo, apresentando essa etapa como 1º passo e integrando de forma mais visível o form do cart e do checkout.

05:00

CONTRIB: COMMERCE CHECKOUT PAGES

Revela-se útil no momento em que são necessárias mais páginas que as que vêem por defeito que são 4: checkout, payment, review, complete.

Por exemplo, se existe necessidade de aceitar termos, se há lugar a seleção de algum tipo de serviço extra como o dos envios (shipping), etc.

07:27

CONTRIB: COMMERCE EXPRESS CHECKOUT

O princípio deste módulo é centrar todo o processo de compra numa única página - pagamento express. Em muitas circunstâncias será o ideal. Ele concentra todos os componentes do Checkout numa só página e ainda permite o botão Express Checkout em vez do Add to cart no produto no formulário do add to cart.

No vídeo podemos assistir a alguns problemas do módulo, sobretudo a falta de documentação.

A primeira operação deve começar por em Checkout settings concentrar todos os panes pertinentes na etapa 1 e única do Checkout. Porém, há checkout page que têm cativos panes e panes que não se deixam desativar. Isto tem implicações naturalmente no número de páginas.

A configuração do botão para Express checkout pode fazer-se de duas maneiras:

  • por item de loja individual, permitindo em /admin/commerce/products/express-checkout-links selecionar determinado(s) produto(s). Neste caso, o código gerado para o botão deve ser copiado e colado onde se desejar. É mais indicado para um produto único e com destaque temporário, como um contributo, angariação, donativo.
  • por content type em Manage fields, com a substituição do Add to cart form pelo Express Checkout Link

O resultado na página do produto é o aparecimento de um botão Express Checkout que liga logo à fase do checkout sem cart.

01:53

CONTRIB: COMMERCE CHECKOUT LOGIN

É bastante inteligente a solução avançada por este módulo. Sem alterar nada do processo default, que é o de solicitar email se é anónimo, vai mais além, porque valida logo o email e oferece link de login se email existe.

03:16

CONTRIB: COMMERCE CHECKOUT REDIRECT

Este módulo segue o workflow por defeito, ou seja, assume que só autenticados é que podem comprar produtos, mas é mais intrusivo que o sistema definido por defeito, pois deixa que o botão de checkout esteja disponível para anónimos e autenticados, mas para encomendar, é preciso que a pessoa esteja registada - usando o redirect.

Por outras palavras, não há checkout se a pessoa não estiver autenticada. O seu funcionamento requer acertos nas permissões e rules, como por exemplo, negar Access checkout a anónimos.

06:51

CONTRIB: COMMERCE EXTRA PANES

Converte um node type em commerce pane, dando a possibilidade de embeber no checkout conteúdo informativo ou promocional. Ex. nova promoção, termos de utilização de um serviço, form de contacto, webform, etc.

Na demo, usamos a page Terms criada para aí posicionarmos um custom pane com os termos, recorrendo a este módulo.

O exemplo dado da criação de pane para Termos não é aplicável ao website NatureStyle, mas serve de exemplo de uso de custom checkout page intermédia no processo com associação a um conteúdo já existente no website, no caso a página dos Termos, uma página normal do content type page.

Paralelamente à criação de panes custom, este módulo disponibiliza a opção Terms que coloca checkbox no node selecionado. Brilhante!

05:13

CONTRIB: COMMERCE VIEWS PANE

Permite ao Views gerar displays do tipo pane para serem usados com o DC.

Os exemplos de uso dados são:

  • Download links para ficheiros comprados (imagens, por exemplo)
  • Shipping information - endereços, datas de entrega estimadas para encomenda X
  • Informação das transações relacionadas com pagamento

No vídeo assistimos à criação de um desses displays através do Views com a lista de offers em vigor. Poderia ser uma lista de produtos mais populares, etc. Qualquer display criado com este plugin fica logo disponível nos panes disable do Checkout settings.

Section 11: Tax configuration
Intro às taxas
Article
Tipos de taxas
Article
10:25

Uma vez ativados os módulos Tax e Tax UI do Commerce (core), na secção Store > Configuration > Taxes, apercebemo-nos de imediato de dois tabs.

  • Taxes types
  • Taxes rates

TAXES TYPES

Taxe type é o tipo de taxa a aplicar como visto anteriormente no capítulo Tipos de taxa.

São duas opções com diferenças claras na forma de calcular o preço e o mostrar ao cliente.

Podemos criar outros tipos de impostos e aplicá-los depois nas taxes rates, sobretudo para custos fixos (por order) que queiramos ver em subtotal. Há exemplos de uso do taxe type para cobrar outros valores como: comissão, despesas de expedição, quando valor é taxa fixa, etc.

Na criação de novo taxe type temos os campos:

  • Title - nome da taxa
  • Display title - a mostrar ao cliente
  • Description- descrição do que é suposto a taxa fazer e a quem se aplica
  • Display taxes of this type inclusive in product prices - se ativa, surge opção nos product itens para selecionar as taxas associadas para o tipo. Em Sales a opção está desligada, em VAT está ligada. Esta opção disponibiliza widget para escolher VAT associado ao product, significando que o produto que inclui taxa subtrai ao valor colocado em price o montante da taxa aplicável.
  • Tax amount rounding mode - opção de arredondamento, por defeito sem arredondamento

Associadas às taxes type default estão duas rules que aplicam esses valores nas line item:

  • Calculate taxes: Sales tax
  • Calculate taxes: VAT

TAXES RATES

Taxes lista as taxas a utilizar no sistema com o valor para cálculo.

Os campos de criação de nova taxa são:

  • Title - nome da taxa
  • Display title - a mostrar ao cliente
  • Description - facultativo
  • Rate - valor percentual da taxa para cálculo. Ex. 8% é parametrizado como: .08
  • Type - selecionar taxe type (Sales tax, VAT,...)

Ao criar uma tax nova, o sistema gera um rule component que depois é chamado numa rule principal que aplica os taxe type VAT ou Sales tax (ver acima).

Portanto, associadas às taxas criadas temos sempre um rule component que se materializa depois numa rule aplicável ao line item numa order.

Tax rule 1: Sales tax única para produtos
Article
Tax rule 2: VAT único para produtos
Article
08:26

RULE TAXES: VAT VARIÁVEL POR TIPO PRODUTO

O cenário que vamos trabalhar é bastante comum, pois é frequente uma mesma loja vender produtos com taxas de IVA diferentes.

Existem várias formas de trabalhar com diferentes taxas de IVA num mesmo website.

Há técnicas que criam campo extra no product type para definir taxa com taxonomia associada, outros editam a rule que chama o rule componente da taxa.

No nosso caso, vamos simplificar o processo e editar de imediato o componente, associando-o a cada content type a que a taxa do componente se aplica sem necessidade de criar field custom para ter o processo a funcionar.

1. Criar taxas de IVA a usar no website

No exemplo dado criamos a taxa IVA 13% e IVA 23%

Esta operação é realizada em : /admin/commerce/config/taxes , ou seja, Store > Configuration > Taxes . Deve ser repetida quantas as taxas diferentes a usar no sistema.

2. Editar rule component das taxas

Por cada taxa criada é gerado um rule component.

A sua edição pode fazer-se desde a taxa no link "edit component" ou visitando a secção dos componentes das rules em /admin/config/workflow/rules/components

A edição do componente é que vai fazer a diferença em termos de a que product types se aplica determinada taxa.

Se não limitarmos o uso das taxas, o que ocorrer é o mesmo porduto ser taxado tantas vezes quantos os tipos de taxas de IVA tivermos criado, dando-se a taxação cumulativa.

Usamos a secção de Conditions desse component para cingirmos o uso da taxa a certos casos.

No exemplo, testamos esta técnica, aplicando a taxa de 13% a product type Bouquet e Garden. Já a taxa de 23% ficou reservada para os product type Bonsai.

Nas Conditions podemos usar o operador "Add or", o que nos permite por exemplo aplicar a mesma taxa de 13% quer se trate do tipo Bouquet ou Garden.

Importante é obviamente usar antes o Entity has field que liga a Line item ao Product.

3. Ativar rule de aplicar taxas

Além dos rule components, existe um Rule default de aplicação das taxas de IVA.

Essa rule destina-se obviamente a aplicar todas as rule components de taxas de VAT que estiverem activas. Ela não define condições, que já foram parametrizadas em rule component, correndo apenas a ação.

08:51

RULE TAXES: SALES TAX CALCULADA COM BASE NO ADDRESSFIELD

Nos EUA as sales taxes aplicáveis são as da cidade/ Estado em que se localiza a empresa. Portanto, a empresa precisa de aplicar sales ao consumidor se este é do Estado com o qual a empresa tem obrigações fiscais.

Logicamente que neste caso, o factor geográfico é vital, e o campo Addressfield vai estar no centro das atenções.

Vamos partir do cenário que a empresa está em North Carolina e que a sales taxe é de 7%.

1. Criar taxa

Title - NC sales tax

Display title - North Carolina sales tax

Rate - 0.07

Type - Sales tax

2. Editar rule component

É preciso limitar com Condition ao cliente residente em NC.

Condition: Order adress component comparison com Adress do Billing information de referência e o componente do Adress para analisar é o Administrative area, onde indicamos que é igual ao NC

TROUBLESHOOTING

Detectámos alguns problemas neste processo que resumimos abaixo.

Conflito entre ter taxas Sales (US) e VAT (EU) sendo que se taxa está incluída, ela vai estar sempre no preço embebida, o que faz com que taxe igualmente o IVA involuntariamente. Adicionar conditions por país não resolve o problema, mesmo que nos US não seja aplicável essa taxa.

As issues abaixo dão conta desta incompatibilidade e sugere-se que o IVA a incluir no preço seja opção de display e não torne o preço cativo do IVA.

https://drupal.org/node/1829984

https://drupal.org/node/1809956

https://drupal.org/node/1362002

Esta issue antiga dá conta disso mesmo e propõe patch que faz reset ao preço.

https://drupal.org/node/1240216

Tax rule 5: VAT para empresas e para pessoas
Article
Tax rule 6: Isenção de taxa
Article

Students Who Viewed This Course Also Viewed

  • Loading
  • Loading
  • Loading

Instructor Biography

Cláudia Amorim, Drupal site builder and trainer.

Olá! Chamo-me Cláudia e sou formadora em Drupal, com cursos presenciais e online. Paralelamente desenvolvo websites com Drupal para projectos próprios e de clientes.

Trabalho com Drupal há cerca de 5 anos, versão 6 e estou actualmente a desenvolver materiais para o Drupal 8.
Sempre que possível contribuo para o projecto desta grande comunidade e participo e/ou organizo eventos de utilizadores Drupal.

Hello! My name is Claudia and I am a Drupal trainer, with both onsite and online courses. I also develop websites with Drupal for my own projects and for clients.
I work with Drupal for about five years, started with version 6 and am currently developing materials for Drupal 8.
I contribute as much as possible to this great community project, and participate and / or organize Drupal user oriented events.

Ready to start learning?
Take This Course