Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    39.296
  • Registro em

  • Última visita

  • Days Won

    1.132

Tudo que Italo Giurizzato Junior postou

  1. Bom dia Bruno, De todos os provedores implementados no componente ACBrNFSe, os únicos que permitem ADD 1 ou mais itens de serviços são: Agili, EL, Equiplano, FintelISS, Governa, Infisc, IssDSF, SmarAPD e SystemPro. Os demais só podemos informar apenas um item de serviço.
  2. Bom dia ALA, Se o seu problema é com relação ao envio do evento seja ele qual for o XML do MDF-e não tem nada haver com o problema. Para tentarmos descobrir o que esta ocorrendo com o envio do evento precisamos analisar o XML do pedido de evento. Outra coisa os XMLs que você anexou o baixado consta o numero do protocolo de autorização, já o segundo não. Com o que você baixou funcionou o Encerramento, o motivo é muito simples, o evento de encerramento necessita do numero do protocolo de autorização. Ao carregar o XML que você baixou este consta o numero do protocolo, já o outro XML que você anexou, como já dito acima não consta o protocolo de autorização.
  3. Boa noite José, Sim, alem da pasta que contem os fontes do componente, temos dentro da pasta: ...\Exemplos\ACBrDFe\ACBrANe\Delphi o programa exemplo e dentro da pasta: ...\Pacotes\Delphi\ACBrDFe\ACBrANe temos o pacote para realizar a instalação de forma manual. Lembre-se que o componente já se encontra no Trunk2 com todas as devidas correções para que o envio seja realizado com sucesso. Inclusive o ACBrANe já foi removido do Branches. Te aconselho a excluir a pasta que você copiou do Branches para dentro da estrutura do Trunk2 e realizar a atualização completa de todos os fontes de todas as pastas.
  4. Boa noite a todos, Na rotina que configura o componente temos: ACBrCTe.Configuracoes.WebServices.UF := sUFdoEmitente; case rgTipoEmissao.ItemIndex of 0: ACBrCTe.Configuracoes.Geral.FormaEmissao := teNormal; 1: if ACBrCTe.Configuracoes.WebServices.UFCodigo in [14, 16, 26, 35, 50, 51] then ACBrCTe.Configuracoes.Geral.FormaEmissao := teSVCRS else ACBrCTe.Configuracoes.Geral.FormaEmissao := teSVCSP; end; Na rotina que alimente o componente com os dados pertinentes ao CTe: case rgTipoEmissao.ItemIndex of 0: Ide.tpEmis := teNormal; 1: if ACBrCTe.Configuracoes.WebServices.UFCodigo in [14, 16, 26, 35, 50, 51] then Ide.tpEmis := teSVCRS else Ide.tpEmis := teSVCSP; end; Ide.cUF := iCodigoUFdoEmitente; Resumindo: ide.tpEmis tem que ser sempre igual a ACBrCTe.Configuracoes.Geral.FormaEmissao ide.cUF tem que ser sempre igual a ACBrCTe.Configuracoes.WebServices.UFCodigo que tem que ser a mesma UF do Emitente do CT-e. Detalhe importante, a SEFAZ-Virtual de Contingência (ambiente de produção) só é liberado a pedido da SEFAZ-Autorizadora, caso contrario ela ficará bloqueada. Já a SVC (ambiente de homologação) nunca é bloqueada, pois ela é necessária para que os desenvolvedores possam realizar os seus testes.
  5. Boa noite Joabe, Você leu atentamente a Nota Técnica? No segundo paragrafo do item 1 deixa claro que o XML do CT-e será disponibilizado para as pessoas informadas no mesmo. A principio um CT-e Normal, temos o Emitente, o Remente e o Destinatário, como e Emitente tem por obrigação possuir o XML uma vez que este que gerou e enviou para a SEFAZ, logo o XML do CT-e será disponibilizado para o Remente e para o Destinatário. Como o XML contem muitas informações na unit que trata o retorno ao executar o DistribuicaoDFe só é populado um resumo em TresCTe. Diferente do DistribuicaoDFe da NF-e o DistribuicaoDFe do CT-e sempre vai retornar o XML completo do CT-e. Sendo assim, de posse do XML completo basta executar o método LoadFromFile para carrega-lo e assim ter acesso a todos os dados, com isso você saberá quem é o tomador.
  6. Edu, Agora me recordo o motivo desse provedor não ter sido implementado. O motivo é a assinatura veja o primeiro xml (req1.xml) trata-se de uma consulta, note que a assinatura digital se encontra no grupo <Header> e não no XML contido no grupo <Body> Até hoje todos os provedor, bem como a NF-e, CT-e, MDF-e, BP-e a assinatura é realizada no XML que é o conteúdo do grupo <Body> e esse provedor faz diferente, fugindo completante do padrão.
  7. Bom dia Marcio, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.
  8. Bom dia Leandro, Você saberia me informar em qual ou quais unit do componente você fez os ajustes para que o componente funcione com o provedor Actcon?
  9. Bom dia Edu, Que eu saiba esse provedor não foi implementado. Seria de grande ajuda XML de exemplos e os Schemas (arquivos XSD) usados para validar o Lote antes do envio. Se esse provedor realmente segue o layout da ABRASF fica mais fácil a sua implementação.
  10. Bom dia Elias, E o arquivo INI do provedor, os schemas para validar o XML antes do seu envio? Como você esta fazendo, gerando o XML do RPS e importando através do site para que este gere a NFS-e?
  11. Bom dia Christian, Alguns provedores exige um cadastro para emitir a nota via site e um segundo cadastro para emitir via web services. Normalmente no XML o CNPJ não contem formatação é preciso verificar se no cadastro tem formatação e se isso não interfere na validação feita pelo provedor.
  12. Bom dia Oteniel, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.
  13. Vamos lá, existe duas SEFAZ de Contingência para o CT-e, são elas SVC-RS e SVC-SP. Veja este fragmento de código: // (AC, AL, AP, AM, BA, CE, DF, ES, GO, MA, MT, MS, MG, PA, PB, PR, PE, PI, RJ, RN, RS, RO, RR, SC, SP, SE, TO); // (12, 27, 16, 13, 29, 23, 53, 32, 52, 21, 51, 50, 31, 15, 25, 41, 26, 22,33, 24, 43, 11, 14, 42, 35, 28, 17); case rgTipoEmissao.ItemIndex of 0: Ide.tpEmis := teNormal; 1: if ACBrCTe.Configuracoes.WebServices.UFCodigo in [14, 16, 26, 35, 50, 51] then Ide.tpEmis := teSVCRS else Ide.tpEmis := teSVCSP; end; Note que a SVC-RS só atende as UF: RR, AP, PE, SP, MS e MT as demais são atendidas pela SVC-SP. Você vai ter que reformular o seu CASE onde você tenha apenas 2 opções: Emissão Normal e Contingência. No caso de Contingência o software tem que definir sozinho qual das duas SVC ira utilizar mediante a UF do emitente. Em resumo é o fragmento acima. Tenho um outro semelhante para a configuração do componente, pois na minha aplicação não misturo configuração do componente com a alimentação dos dados no componente. O fragmento acima se refere a rotina que alimenta o componente com os dados pertinentes ao CT-e.
  14. Bom dia Vanessa, Tenha em mente o seguinte. Erro de validação, é gerado pelo componente e a causa pode ser, Schema desatualizado ou dados errados. Rejeição, é gerado pela SEFAZ e a causa pode ser, dados inválidos ou falha no Web Service que não conseguiu identificar corretamente o erro, dai a mensagem Falha no Schema XML. Peço que se possível você anexar o XML dessa consulta para que possamos analisar.
  15. Bom dia José, O componente ACBrANe já se encontra no Trunk2 e o Juliomar (se não me falha a memória) ficou de acrescentar esse componente no ACBrInstall_Trunk2. Não entendi, em que momento é solicitado usuário e senha? Ao baixar os fontes ou ao enviar a Averbação?
  16. Bom dia, Mas veja a rotina onde você passa para o campo ide.cUF o código IBGE de RS quando a forma de emissão é SVCRS. Isso esta errado. O campo ide.cUF identifica o código IBGE da UF do emitente e como você disse o emitente é do Paraná sendo assim porque você esta informando Rio Grande do Sul?
  17. Bom dia Osmar, Por favor configure o componente para salvar os arquivos Soap e anexe tanto o de envio quanto o de retorno. Você anexou os arquivos: 1-env-lot.xml e 1-pro-lot.xml Eu preciso dos arquivos: 1-env-lot-soap.xml e 1-pro-lot-soap.xml
  18. Bom dia Paulo, Desculpe, você tem razão a versão 2.00 termina 03/12/2017 o que esta previso para o ano que vem, mais precisamente 02/04/2018 é migração do protocolo SSL para TLS 1.2.
  19. Bom dia a todos, Estranho as vogais acentuadas ficarem bagunçadas, será que o método AssinarXML esta realizando essa bagunça? É preciso debugar para descobrir onde esta a origem do problema. Gilvano, você teria condições de realizar esse debug? O método AssinarXML recebe o XML a ser assinado através da variável Evento. E nos retorna o mesmo XML assinado na variável FPDadosMsg. Se a variável Evento contem a descrição do evento correto e no FPDadosMsg esta bagunçado então o problema é o método AssinarXML, ai é preciso descobrir em que momento ocorre o problema.
  20. Paulo, Segundo o arquivo Cidades.ini se utiliza do provedor Actcon (versão 1.0) e não o provedor Actconv2 (versão 2). Sendo assim devemos utilizar os arquivos XSD (Schemas) da pasta Actcon.
  21. Boa noite Paulo, Favor atualizar os fontes de todas as pastas, note que fiz uma correção no arquivo Cidades.ini
  22. Boa noite Moroni, Quanto a esse tipo de CT-e não tenho muitas informações mas acredito que você terá que emitir 2 CT-e OS.
  23. Boa noite Gilvano, A assinatura realizada no evento segue o mesmo padrão utilizado na assinatura do CT-e. Com certeza é algum erro na SEFAZ.
  24. Boa tarde Thomas, No Portal do MDF-e não existe nenhuma opção onde você informe a chave e seja apresentado os dados do mesmo, aos moldes da NF-e. Qual é a finalidade? O MDF-e não é um documento com valor fiscal, sendo assim ele não precisa ser enviado para ninguém. Note que a unica pessoa (obrigatória) presente no MDF-e é o Emitente do mesmo. O(s) Motorista(s) do veículo não leva em consideração neste caso. Diferente da NF-e onde temos o Emitente e o Destinatário e no caso do CT-e temos o Emitente, Remetente e o Destinatário da carga.
  25. Boa tarde Diogo, Você esta fazendo confusão entre o SAT e a NF-e. O componente ACBrSAT tem como finalidade emitir a CF-e - Cupom Fiscal Eletrônico. Já o ACBrNFe tem como finalidade emitir a NF-e ou NFC-e (mediante configuração). A final de contas o que a sua aplicação emite? É o CF-e através do SAT ou a NF-e ou a NFC-e ? Outra coisa, ao emitir qual quer que seja um dos 3 acima, é para você ter o XML da venda que já deve estar assinado, validado e protocolado. Basta a sua aplicação pegar esses XMLs que estão salvos na pasta que você definiu e enviar para o Contador.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.