Italo Giurizzato Junior

Bom dia Léo, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Bom dia @Neski Soluções, Por favor faça um teste de envio de um Rps e anexe o XML (soap) de retorno da consulta ao lote, depois faça um segundo teste enviando 2 Rps no lote e o retorno da consulta ao lote deste lote que foi enviado com 2 Rps. Quero ver como é o retorno da consulta ao lote quando temos apenas 1 Rps e quando temos 2 ou mais.

Bom dia, Substitua a unit pela que esta em anexo, reinstale o ACBr e faça um novo teste. NFSeBrasil.LerXml.pas

Bom dia, O tipo ser 7 esta correto, uma vez que foi selecionado a SVC-RS. Lembrando que dependendo da UF devemos selecionar a SVC-RS ou SVC-SP. Com relação a subcontratação, não tem muito o que fazer a não ser aguardar até que a SVC replique o XML do CT-e na base de dados da SEFAZ-Autorizadora.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Boa tarde Wanderson, Alterei mais algumas coisas referente ao segmento Z juntamente com a sua contribuição e mandei para o SVN. Por favor atualize os fontes, reinstale o ACBr e faça novos testes.

Boa tarde Léo, Ao alterar o numero de ocorrências para 1, isso faz com que a tag sempre seja gerada. Essa alteração não vai gerar um efeito colateral quando a situação tributário for diferente de 3?

Boa tarde Ademar, Já esta no SVN. Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Boa tarde Diego, Já esta no SVN.

Boa tarde Gibran, Pela minha analise o provedor se utiliza dos caracteres #13 e #10 para quebra de linha. Se o componente gerar o XML do Rps com esses caracteres como quebra de linha, após realizar a assinatura vai ocorrer a remoção, pois o no final do método responsável pela assinatura ocorre a remoção das quebras de linha que por ventura exista no arquivo. Eu não entendo muito bem, mas me parece que a DLL que o ACBr se utiliza para realizar a assinatura inclui quebras de linha na assinatura que depois são removidas. Vou conversar com a Equipe para ver se encontramos uma maneira de remover as quebras de linha da assinatura e não do XML inteiro. Peço-lhe um pouco mais de paciência na busca de uma solução para esse problema.

Boa tarde Gomes, Para mim a sua alteração vai falhar. Sua primeira alteração: NotaCompleta := (Pos('<nfse>', Response.ArquivoRetorno) > 0) and (ANota.NFSe.NfseSubstituida = ''); Ao executar a linha acima a variável ANota ainda não foi preenchida, logo esta com todos as suas classes e campos vazios. Segunda alteração: if Document.Root.Name <> 'nfse' then begin ANode := ANode.Childrens.Find('documentos'); ANode := ANode.Childrens.Find('nfse'); end; Ao executar o IF acima se a condição for verdadeira você esta confirmando que existe a tag documentos e em seguida a tag nfse. Terceira alteração: Você removeu a linha abaixo que esta dentro do ( if NotaCompleta then ) ANodeArray := ANode.Childrens.FindAllAnyNs('nfse'); Com a remoção dessa linha a variável ANodeArray fica vazio. Vamos fazer o seguinte, faça um teste com a unit em anexo. IPM.Provider.pas

Boa tarde a todos, Conforme schema mudar o numero de ocorrência de zero para 1 esta errado uma vez que as duas tags são opcionais. <xs:element name="pDif" type="TDec_0302a04Max100" minOccurs="0"> <xs:annotation> <xs:documentation>Percentual do diferemento</xs:documentation> </xs:annotation> </xs:element> <xs:element name="vICMSMonoDif" type="TDec_1302" minOccurs="0"> <xs:annotation> <xs:documentation>Valor do ICMS diferido</xs:documentation> </xs:annotation> </xs:element> Mas podemos mudar o tamanho máximo que esta como 5 para 15 sem nenhum problema.

Boa tarde Leandro, Não vejo outra alternativa entrar em contato com a prefeitura e expor o problema. Olhe como esta a geração do retorno: Segundo o bloco de notas esta no formato ANSI, conforme dito da postagem anterior, mesmo com o encoding no inicio do XML. Outro absurdo, ao gerar o XML de retorno estão usando a sequencia escape: "&lt;" em vez do caractere "<" para indicar o inicio de uma tag, mas isso o componente consegue tratar. O grande erro mesmo é gerar o XML no formato ANSI e colocar a declaração de encoding sendo UTF-8.

Boa tarde Márcio, Normalmente esse segundo código de barras é impresso no DANFE da NF-e emitida em contingência. Caso você não tenha o DANFE, somente o XML, use o componente ACBrNFe, carregue o XML da nota depois use o método: GerarChaveContingencia. Onde informar no MDF-e, favor consultar o manual do mesmo, existe um campo especifico para ele.

Boa tarde a todos, A um tempo ocorreu problema semelhante também com Certificado A3 na emissão da NF-e na SEFAZ-SP. O problema era na SEFAZ. Não sai mais barato você comprar um certificado A1 para o seu cliente do que ter todo esse stress? Você acaba mostrando para ele a economia burra que ele fez comprando o A3.

Boa tarde Sergio, Não compreendi muito bem a sua duvida, mas lembre-se que se tratando do SVC-RS/SVC-SP o CT-e é enviado para a SVC, esta processa e autoriza caso esteja tudo Ok e quando a SEFAZ-Autorizadora da UF em questão retornar a operar a SVC se encarrega de compartilhar os dados. Portanto diferente dos demais onde o XML do CT-e no primeiro momento não é enviado, temos apenas a impressão do DACTE.

Boa tarde, Lembre-se que você tem um prazo de 168 horas a contar da Data/Hora de autorização do CT-e para realizar o seu cancelamento. Se o envio do CT-e em modo de contingência foi para a SVC, ou seja, SEFAZ-Virtual de Contingência, temos o seguinte com relação ao cancelamento: Os pedidos de cancelamento na modalidade SVC somente poderão afetar documentos autorizados em contingência pela correspondente SVC-[SP/RS]. Se o CT-e foi enviado para o SVC, configure o componente para este modo de envio e envie o evento de cancelamento. É para funcionar.

Boa tarde a todos, Fiz um teste de envio de um CT-e versão 4 para a SEFAZ-SP e não ocorreu nenhum erro. Tudo indica que esta em operação.

Boa tarde Ademar, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-4134

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

Boa tarde Maiquel, Já esta no SVN.

Boa tarde Leandro, Abrindo o XML (soap) de retorno com o bloco de notas, este acusa que o arquivo esta no formato ASCI e não UFT-8. Se abrir com o NotePad++ diz que é UTF-8 mas ocorre erro de encoding e as vogais acentuadas não são apresentadas corretamente.

Boa tarde @gladston, Na outra postagem indicada pela Juliana, tem imagens onde você disse ter realizado testes com o certificado A1. Notei que você informou o Path + Nome do PFX, mas não informou a senha do certificado, sem a senha vai ocorrer erro de conexão : Senha informada está errada.

Boa tarde Robson, Eu quero que você teste os 3 modos de envio disponibilizados pelo provedor. EnviarLoteRps - ACBrNFSeX1.Emitir(vNumLote, meLoteAssincrono); EnviarLoteRpsSincrono - ACBrNFSeX1.Emitir(vNumLote, meLoteSincrono); GerarNFse - ACBrNFSeX1.Emitir(vNumLote, meUnitario); O que pode esta ocorrendo: O provedor implementou mas existe algum bug no webservice que esta retornando essa mensagem, alias, mensagem que não diz o real problema do XML enviado, uma vez que o componente esta gerando, assinando e validando antes de ser enviado. Se o componente estivesse gerando alguma tag fora do lugar (por exemplo) não iria passar pela validação. Faça um teste com os 3 modos de envio acima e anexa os arquivos gerados.