Loja Virtual: o caminho do pedido do site dentro do ERP
O pedido da Loja Virtual não é digitado por ninguém dentro do ERP. O site grava o pedido pela integração e o ERP marca esse pedido como pertencente ao e-commerce. É essa marca que faz ele aparecer na lista de vendas da Loja Virtual em vez de se perder no meio das vendas de balcão. Esta fonte trata do caminho do pedido: por onde ele entra, o que entra junto com ele, em nome de quem ele entra, quando a situação muda sozinha e por que às vezes ele não entra.
COMO O PEDIDO ENTRA
A loja usa uma credencial própria da empresa para gravar o pedido. Essa credencial já vem amarrada a uma loja (filial), e o pedido nasce nessa loja. Por isso, um usuário logado em outra loja recebe "Você não tem permissão para acessar este pedido!" ao tentar abrir o pedido do e-commerce.
Na tela de vendas da Loja Virtual não existe cadastrar pedido à mão. A ação de adicionar responde sempre "Você não tem permissão para acessar esta área.", mesmo com a permissão concedida. O mesmo vale para agrupar vendas. Pedido de loja virtual só entra pela integração.
O ERP aceita a entrada tanto como venda quanto como orçamento, e tanto de produto quanto de serviço. A listagem de vendas da Loja Virtual, porém, mostra apenas venda de produto. Se o registro entrou como serviço ou como orçamento, ele existe no ERP, mas não aparece nessa listagem: procure em Vendas ou em Orçamentos.
O QUE FICA GUARDADO JUNTO COM O PEDIDO
Além do pedido normal (cliente, itens, parcelas, endereço), o ERP guarda um bloco à parte com o que o comprador escolheu no site. Essa lista é fechada, e é ela que responde "por onde ele pagou" e "que frete ele escolheu":
a forma de pagamento escolhida no site, com nome e ícone;
a forma de envio escolhida, com nome;
o cupom usado, com o código do cupom;
o meio de pagamento do parceiro;
a quantidade de parcelas;
o identificador da transação no parceiro;
o link da transação;
a data em que esse bloco foi criado e a da última alteração.
Ao abrir o pedido, o código do cupom também aparece na observação das parcelas.
O identificador e o link da transação só são preenchidos quando o site fechou o pagamento por uma integração de pagamento no momento do pedido. Como se integra e como funciona cada meio de pagamento é assunto da pasta de Meios de pagamento; aqui não se reexplica. O que vale registrar: o ERP só consegue ler o detalhe da transação do parceiro quando a forma de pagamento do recebimento aponta para uma destas integrações, e a lista é fechada: PagSeguro, Gerencianet, Mercado Pago, PagHiper, Iugu e Conta Integrada.
POR QUE O CAMPO DE QUEM CADASTROU MOSTRA SEMPRE O MESMO NOME
A credencial que liga o site ao ERP é criada em nome do usuário master da empresa. E, quando a chamada não diz qual usuário está agindo, o ERP assume o master. Resultado: todo pedido vindo do site entra com o nome do usuário master e é esse nome que se repete no histórico de situações. Não é erro, não é alguém mexendo no pedido e não adianta trocar de usuário no ERP para mudar isso.
POR QUE O CLIENTE PAGOU E O PEDIDO CONTINUA AGUARDANDO
A confirmação de pagamento não vem no ato. Ela entra numa fila de confirmações que uma rotina do sistema lê de tempos em tempos. Para cada aviso da fila, a rotina procura a movimentação financeira daquele pedido — o recebimento — e só age se ela já estiver baixada. Com o recebimento baixado, ela troca o pedido para a situação que a empresa marcou como pagamento confirmado, grava esse passo no histórico do pedido, dispara o e-mail de pagamento confirmado para o cliente e cria a notificação de que o recebimento foi confirmado.
Daí saem três consequências práticas. Primeira: enquanto o recebimento não estiver baixado no financeiro, o pedido não muda de situação sozinho. O que travou está no recebimento, não no pedido. Segunda: se a empresa não tem nenhuma situação marcada como pagamento confirmado, ou se o pedido já está nela, nada acontece. Terceira: existe um intervalo normal entre pagar e a situação virar, e nada impede que você mude a situação na mão nesse meio tempo. Como as situações são configuradas e o que cada uma lança tem fonte própria; conferir e baixar o recebimento também.
POR QUE O PEDIDO NÃO ENTROU
Duas recusas acontecem na entrada e são as causas concretas de pedido que não chegou:
Pedido sem nenhum item. O ERP responde "É necessário informar no mínimo um produto!" (ou "É necessário informar no mínimo um serviço!", quando o pedido é de serviço) e não grava nada.
Número de venda já usado. O ERP responde "O número da venda já está sendo utilizado!" e recusa. Isso acontece quando o número que o site mandou já existe em outra venda da empresa. O alcance da checagem segue a configuração de numeração da empresa: ela pode considerar só a loja, ou todas as lojas com o mesmo CNPJ, e é dispensada se a empresa está configurada para permitir repetir número.
O CANCELAMENTO AUTOMÁTICO
Uma rotina automática varre, loja por loja, os pedidos do e-commerce que continuam na situação marcada como aguardando pagamento e cujo recebimento venceu há exatamente sete dias sem ser baixado. Sete dias exatos: pedido vencido há mais tempo já passou da varredura e não é recolhido depois. Cada loja é verificada no máximo uma vez por dia. Ela troca a situação do pedido e dispara o e-mail de pedido cancelado para o comprador. Se um pedido antigo "cancelou sozinho", é essa rotina.
Dois detalhes conferidos no código, e que chegam ao atendimento como se fossem mau uso:
A situação de destino pode não ser a que você chama de cancelada. A rotina não escolhe pelo nome: escolhe pela marcação de padrão da situação. E a marcação que ela procura é a mesma que, numa troca de situação feita à mão, dispara o aviso de pedido enviado. A marcação de cancelado é outra — é ela que o painel de Início usa para contar pedidos cancelados. Na prática: o pedido cancelado pela rotina pode parar numa situação que não é a de cancelamento e pode não entrar na contagem de cancelados do painel, embora o comprador receba o e-mail de pedido cancelado. E se a empresa não tiver nenhuma situação com a marcação que a rotina procura, ela não cancela nada: o pedido fica parado onde está.
O passo automático não fica registrado no histórico do pedido. O registro é gravado com o número trocado, então o histórico daquele pedido pode não explicar a troca de situação.
Nos dois casos, anote o número do pedido e confirme com o cliente em qual situação ele parou antes de tratar como erro de uso.
OS E-MAILS DA ENTRADA DO PEDIDO
No momento em que o pedido entra, e somente quando o pagamento foi processado com sucesso ali, saem dois e-mails: um de pedido confirmado para o comprador e um de nova compra para o endereço cadastrado na própria loja virtual.
O de pedido confirmado só sai se o cadastro do cliente tiver preenchido o campo de e-mail da loja virtual. Se esse campo está vazio, o comprador não recebe nada, mesmo com o modelo de e-mail ativo. Já o e-mail de pagamento confirmado, disparado depois pela rotina da fila, usa o e-mail principal do cadastro do cliente. São dois campos diferentes do mesmo cadastro: vale conferir os dois antes de tratar como falha de envio.
A IMPRESSÃO DO PEDIDO É A DO ERP
Imprimir o pedido do site não é uma impressão da Loja Virtual. A área do e-commerce tem uma rota própria que joga essa impressão no controlador de vendas do ERP, e o que sai é o mesmo documento da venda de produtos, montado com os dados do pedido do site. A ação de impressão que existe dentro do plugin da loja está vazia por dentro e serve apenas de âncora da permissão Imprimir: é ela que decide se a opção aparece ou não na tela daquele usuário. Ou seja, a caixa Imprimir comanda a opção e o arquivo vem do ERP. Não diga ao cliente que a impressão do pedido do site não funciona.
Também funcionam a declaração de conteúdo em PDF, gerada a partir do pedido, e a exportação para Excel das vendas marcadas na listagem — é preciso selecionar as vendas antes, senão o ERP responde que nada foi exportado. O arquivo sai com número, cliente, data, prazo de entrega, situação, valor, cadastrado em e a loja.
Apagar mais de um pedido de uma vez só quem está no grupo de usuários master consegue. Para os demais usuários o ERP recusa a exclusão em lote.
O QUE COSTUMA DAR ERRADO
"Integrei e o pedido não aparece." Veja primeiro se o registro entrou como venda de produto. Serviço e orçamento existem no ERP e não aparecem na listagem da loja.
"O cliente pagou e o pedido continua aguardando." Vá ao recebimento do pedido no financeiro. Sem baixa, a situação não muda sozinha.
"Aparece sempre o mesmo usuário como responsável." É o usuário master, dono da credencial do site. Comportamento normal.
"O pedido não entrou e não deu erro na loja." Pedido sem item e número de venda repetido são recusados na entrada. Reveja o número da última venda lançada no ERP.
"O cliente não recebeu o e-mail." Confira, no cadastro do cliente, o campo de e-mail da loja virtual e o e-mail principal: são usados por e-mails diferentes.
"Mandei imprimir e não baixa nada." A impressão do pedido do site é a impressão da venda do ERP, e ela funciona. Pergunte o que a tela mostrou: a opção some quando a permissão Imprimir está desmarcada, e o ERP pode ter devolvido uma mensagem. Não trate como recurso que não existe.