Italo Giurizzato Junior

Bom dia Antônio, Muito obrigado pela colaboração, já esta no repositório.

Bom dia Jonathan, Já fiz a correção no DACTE Retrato - Fortes Report. Se é esse que você utiliza favor atualizar os fontes e faça novos testes. Além de ocultar o quadro verifiquei se o componente esta imprimindo as informações referentes a Base de Calculo, Alíquota, Valor e percentual de Redução da BC nos quadros corretos. Note que eu não removi o quadro referente ao ICMS ST e sim ocultei. Se a versão do XML for anterior a 3.00 o quadro será impresso, caso contrario não.

Bom dia a todos, Vou analisar o código do componente, é bem provável que ele não esteja respeitando a configuração ao usar o método Gerar.

Bom dia Davidson, Você já leu o artigo do nosso amigo Daniel? Como tratar a contingência da NFC-e

Bom dia Antônio, Caso amanhã venhamos a ter versões diferentes de URL de consulta, basta trocar o zero da função pela variável VersaoDF. Suponha que futuramente tenhamos o CT-e versão 3.50 e a URL de consulta é outra, neste caso teremos a URL da versão 3.00 e a URL da versão 3.50 Isso ocorreu com a NFC-e.

Bom dia Adilson, Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr usando o ACBrInstall com a opção de apagar arquivos antigos marcada? Se sim, vai ser necessário debugar para descobrir porque o componente não esta extraindo os dados referente a guia e salvando o txt. Já tentou enviar o GNRE na versão 2.00?

Bom dia Soares, Na versão 3.00a temos a opção de enviar em modo Assíncrono e Síncrono o CT-e, mas a SEFAZ-MG ainda não disponibilizou a URL para recepcionar o CT-e em modo Síncrono. Para envio em modo Síncrono ( UF que aceitam esse modo de envio: AC, AL, AM, BA, CE, DF, ES, GO, MA, MS, PA, PB, PI, RJ, RN, RO, RS, SC, TO ) // Parâmetros do método Enviar: // 1o = Número do Lote // 2o = Se True imprime automaticamente o DACTE // 3o = Se True o envio é no modo Síncrono, caso contrario Assíncrono. // Obs: no modo Síncrono só podemos enviar UM CT-e por vez. ACBrCTe1.Enviar(vNumLote, True, True); Para envio em modo Assíncrono ( que deve ser utilizado pelas demais UF // Parâmetros do método Enviar: // 1o = Número do Lote // 2o = Se True imprime automaticamente o DACTE // 3o = Se True o envio é no modo Síncrono, caso contrario Assíncrono. // Obs: no modo Síncrono só podemos enviar UM CT-e por vez. ACBrCTe1.Enviar(vNumLote, True, False);

Bom dia Edu, É bem provável que pouca coisa foi feita, vai ser necessário analisar todo o código e fazer as correções e implementações.

Bom dia a todos, Se tratando do CT-e, quando a SEFAZ-Autorizadora esta fora do AR devemos enviar o CT-e para a SVC - SEFAZ-Virtual de Contingência. O problema é que existe 2 SVC, sendo assim para qual devo enviar (SVC-RS ou SVC-SP)? Regra: // (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); if ACBrCTe.Configuracoes.WebServices.UFCodigo in [14, 16, 26, 35, 50, 51] then ACBrCTe.Configuracoes.Geral.FormaEmissao := teSVCRS else ACBrCTe.Configuracoes.Geral.FormaEmissao := teSVCSP; No que diz respeito ao MDF-e, este sempre é enviado para a SEFAZ-RS, não importa qual é a UF do emitente. Hoje só existe uma SEFAZ que recepciona o MDF-e e esta é a do Rio Grande do Sul. Logo se a SEFAZ-RS estiver fora do AR, não tem o que fazer, não existe SVC para o MDF-e.

Bom dia, Favor atualizar os fontes e faça novos testes.

Bom dia a todos, Conforme consta na Nota Técnica 2016/002 de novembro de 2016 - pagina 4 temos: Versão - Data 1.00 02/12/2011 – ENCAT 1.00a 13/12/2011 – SP 1.00b 28/05/2012 – SP 1.01 21/01/2014 – SP Inclusão do DACTE para o Multimodal Alteração do DACTE do Modal Aéreo Exclusão do campo ICMS ST do DACTE 3.00 19/10/2016 – MS/SP Adequação ao leiaute 3.00 do CT-e Criação do DACTE OS O campo ICMS ST não deve mais constar no DACTE. E a impressão dos valores e percentuais relativos ao ICMS devem seguir a tabela que o Big Wings postou. Sempre tenham em mente, que nem tudo o que consta no XML deve ser impresso no Documento Auxiliar, mas tudo o que esta impresso nele deve constar no XML. Agora se no DACTE esta imprimindo o campo ICMS ST isso deve ser corrigido, ou seja, devemos remover esse quadro do layout.

Bom dia a todos, Sempre que for retornado a rejeição 999, favor entrar em contato com a SEFAZ, porque o problema é lá.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Walison, Primeiramente desculpe pela demora. O componente ACBrNFSe possui 3 métodos para enviar RPS para o webservice do provedor, são eles: O Enviar, que nos permite o envio de até 50 RPS, esse método trabalha no modo assíncrono, que pela mensagem de erro me leva a crer que esse provedor desabilitou o serviço que recepciona o lote de RPS em modo assíncrono. O Gerar (só existe nos provedores que seguem a versão 2 do layout da ABRASF que é o caso do SIAPNet), que nos permite o envio de apenas um RPS. O EnviarSincrono (mesma observação do Gerar), que nos permite o envio de lote com até 50 RPS, esse método trabalha no modo síncrono, que conforme a mensagem de erro eles estão sugerindo que você utilize esse. Resumindo em vez de você utilizar o método Enviar, utilize o EnviarSincrono.

Bom dia Jackson, Primeiramente desculpe pela demora. Não consegui identificar o problema, favor atualizar os fontes e faça um novo teste.

Bom dia Olavo, Primeiramente desculpe pela demora. Já enviei a sua colaboração para o repositório, muito obrigado.

Bom dia João, Muito obrigado pela colaboração, já enviei para o repositório. Favor atualizar os fontes, note que simplifiquei o arquivo WebISSv2.ini

Boa tarde Anderson, Você esta misturando as coisas. No inicio da sua postagem você se refere a consulta e depois faz referencia a geração do XML do RPS. Favor anexar os XMLs gerados ao realizar a consulta.

Boa tarde Antônio, As linhas que se refere a variável VersaoDFe não estão comentadas? Elas foram deixadas pensando em uma possível versão diferente do que é hoje.

Boa tarde Edu, Não consegui analisar o que você postou, pois estive atarefado com outras coisas. Você chegou a realizar testes usando o programa exemplo?

Boa tarde Paulo, Após o envio é aconselhado que verifique se o CT-e foi autorizado ou não ou se ocorreu alguma falha de conexão. Se por ventura tenha ocorrido alguma falha de conexão, o correto é realizar uma consulta, desta forma se o CT-e foi enviado e processado com sucesso, a consulta vai atualizar o XML acrescentando o protocolo de autorização. Obs: ao realizar a consulta é prescindível que o XML do CT-e esteja carregado no componente, caso contrario a sua atualização não será realizada.

Boa tarde Jonathan, Você utiliza o componente ACBrCTe ou o ACBrMonitor?

Boa tarde Bruno, Você já verificou se não tem outra linha que esteja atribuindo o valor True a propriedade Visualizar?

Boa tarde a todos, Como ninguém me retornou sobre o problema da SEFAZ-MG ter resolvido o problema de gerar de forma indevida o prefixo ns0: no retorno da consulta e também mais ninguém veio relatar o problema, concluo que o problema foi sanado. Sendo assim vou dar como encerrado esse assunto.

Boa tarde Camilo, Essas 3 linhas é quando ocorre alguma rejeição que pela imagem que você postou não é o caso. Quando não ocorre a rejeição, veja o exemplo abaixo: sSituacao := NFSe.WebServices.ConsNFSeRps.RetornoNFSe.ListaNFSe.CompNFSe[ x ].NFSe.Situacao; dDataRecebimento := NFSe.WebServices.ConsNFSeRps.RetornoNFSe.ListaNFSe.CompNFSe[ x ].NFSe.dhRecebimento; Espero ter ajudado.