Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

click.png

click.png

click.png

Cleber

Membros
  • Posts

    872
  • Joined

  • Last visited

  • Days Won

    6

Cleber last won the day on July 25 2015

Cleber had the most liked content!

2 Followers

Contact Methods

Profile Information

  • Sexo
    Masculino
  • Location
    Formiga-MG

Recent Profile Visitors

3,357 profile views

Cleber's Achievements

  1. Sim, sim... Minha intenção maior é saber se tinha mais alguém passando por isso ou era aqui apenas.
  2. Bom dia, Alguém possui clientes que estão passando por dificuldades para emitir NFC-e em MG? Estou tendo relatos de clientes que estão só emitindo em contingência e estão com dificuldade de regularizar(enviar) essas notas. Webservices de MG estão instáveis nesses últimos dias?
  3. Ok! Vou tentar adiantar algo e qualquer coisa, posto dúvida por aqui.
  4. Boa noite @Juliomar Marchetti sabe me dizer se a estrutura do ACBrCIOT é compatível com a arquitetura de comunicação desse novo provedor? Se não for, o que posso fazer para adiantar? Pode ser construído em cima do IdHTTP ou outra arquitetura? Eu queria ir adiantando algo a respeito.
  5. Creio que isso deverá ser parametrizável. Possivelmente, você tem um flag onde o usuário informa se a venda inclui delivery (vai ser entregue) ou não. Se tiver delivery, torne a captura de dados opcional. Caso contrário, obrigatório. Depois disso, dê um prazo e uma punição ao usuário se ele não regularizar isso.
  6. Bom dia, porque você não cria uma rotina para captura dos dados do POS após o entregador retornar com o comprovante? Preenche esses dados e envia. A emissão do cupom não está vinculado ao envio do pagamento.
  7. @Juliomar Marchetti Arquivo anexado aqui no topico
  8. Boa noite, No início do ano, me parece que o eFrete começou a cobrar a emissão de CIOT através dos webservices. Estou tendo agora a demanda para implementar um outro provedor chamado TruckPad (https://www.truckpad.com.br/). Este não cobra o uso de webservice. Tive acesso ao manual de integração neles (em anexo) e pelo que notei são requisições HTTP com mensagem no formato JSON. Gostaria de saber se na estrutura do componente ACBrCIOT consigo incorporar esse novo provedor ou se seria necessária uma alteração considerável no modo de efetuar as requisições. Se for possível, já quero tentar implementar esse novo provedor. Fico no aguardo. Obs.: Seria possível criar um subfórum para o ACBrCIOT? Manual de integração V1.9.pdf
  9. Adendo: achando que CF-e é NF-e
  10. Bom dia, Vamos lá. No Registro 01 os campos nos quais são informadas as versões do SB e do PAF aceitam sim os pontos (pode mandar). No campo da versão da ER vão somente os números. No registro R05 não tem pontos. Com ou sem ponto, o ACBrPAF não controla isso. Você fornece da forma que preferir desde que não ultrapasse o limite do campos. Ele não formata o conteúdo. Só se alguém alterou os fontes do componente (muito remoto). Mas aí, outros desenvolvedores teriam se pronunciado aqui. Inclusive eu que ainda uso muito o PAF-ECF. Recomendo você debugar seu projeto e ver como o componente está recebendo essas informações da sua aplicação.
  11. Boa tarde @Italo Giurizzato Junior, não tem acentos ou caracteres especiais. O cliente mandou fazer outro certificado digital e vou aguardar o ok deles para testar com esse novo. Vamos ver se acontece algo de diferente.
  12. Boa tarde, eu faço assim: copy(DMACBr.NFe.NotasFiscais.Items[0].NFe.infNFe.ID,4,44);
  13. Boa tarde, Estou passando pelo mesmo problema: "S06 - Não foi possível interpretar o certificado de transmissão" O estranho é já tem um cliente realizando emissão normalmente, mas em outro cliente apresenta essa mensagem. Ambos são da mesma cidade (Passos-MG). Estou desconfiado do certificado do cliente. Algo diferente na confecção do mesmo ou compatibilidade sei lá. Mas é impossível argumentar sendo que ele usa o certificado para outras finalidades e vai que não seja o certificado o problema. O provedor ISSIntegra jura que o webservice deles está funcionando normalmente, mas isso não ajuda muito, Aliás, eles não ajudam em nada. Só dizem o que esperam que aconteça mas não falam como chegar lá. Se tem ou não que mudar algo. Antes demoravam para enviar uma resposta. Agora nem resposta dão mais. São péssimos ao extremo. Enfim, algum conseguiu contornar a situação ou viveu algo semelhante? Att. <?xml version="1.0" encoding="UTF-8"?> <ii:Fault> <ii:Code>S06</ii:Code> <ii:Reason>Nao foi possivel interpretar certificado de transmissao.</ii:Reason> <ii:Detail>As informacoes enviadas no momento da conexao nao constituem um certificado valido.</ii:Detail> </ii:Fault> no último e-mail, eles mandaram isso: Prezado (a), na parte <signature> é preenchida pelo processo de autenticação (https://suporte.integragrp.com.br/hc/pt-br/articles/207165616-Autenticação-SSL). O erro já acontece no momento que tentar validar o certificado, não tem nenhum problema no nosso webservice, o problema é na autenticação do xml, precisa passara para o desenvolvedor para implementar a autenticação e depois fazer a requisição com o xml assinado corretamente.
  14. Boa tarde, É essa mesmo. Lembrando que ela não poderá ser usada para a combinação POS x Credenciadora na hora de enviar pagamentos. Essa é para ser gerada separadamente para cada POS cadastrado.
  15. Boa tarde, É totalmente compatível. Inclusive coloquei um cliente em produção hoje. OBS.: Lembre-se que no CE tem o VPE (Validador de Pagamentos Eletrônicos), o qual você deve enviar informações de pagamentos em cartão (TEF ou POS) para o Integrador Fiscal.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.