Italo Giurizzato Junior

Bom dia a todos, Marco, se o componente ACBrNFSe esta funcionando é graças a todos vocês que realizam os testes e apontam onde estão os problemas. Eu apenas tento interpretar o que esta ocorrendo e procuro implementar a correção da melhor forma possível. Nem sempre a solução é a melhor possível e chega as vezes gerar efeitos colaterais, mas faz parte, no final depois de escovar os BITs tudo se ajeita.

Bom dia Bruno, Conforme a Nota Técnica 2015/004 versão 1.03 que trata sobre o Combate a Pobreza - página 2 temos uma tabela com regras de validação e uma delas é a Rejeição 746 que diz: Se tomador do serviço for emitente de CT-e (verificar CNE) e diferente de Remetente ou Destinatário: - Rejeitar se o tipo de serviço informado for Normal (tpServ=0) Se o seu CT-e foi rejeitado significa que o campo tpServ (#26) é igual a 0 (normal) e o toma (#38) é igual a 4 (outros) e os campos #39 até #56 contem os dados do Emitente e os dados do Remente e do Destinatário não são iguais do Emitente.. O seu CT-e possui 3 atores diferentes envolvidos: Emitente (transportadora) o Remente e o Destinatário da carga, mas é informado que o Tomador, ou seja, quem vai pagar pelo frete é a transportadora, então quer dizer que o transporte é uma cortesia?

Bom dia, Como dito o componente anexa o protocolo de Autorização ou Denegação ( Status = 110 ou 301 ou 302 ou 303 ) automaticamente ao XML assinado. O XML autorizado ou denegado agora é salvo com o nome: <chave>-nfe.xml e deve ser guardo pelo período legal. O componente não gera nenhuma exceção quando a nota é autorizada ou denegada. A sua aplicação tem que tratar as 3 situações: autorizada, denegada e rejeitada. Se autorizada, enviar o XML mais o DANFE em PDF para o destinatário por e-mail e separar a mercadoria vendida para entrega. Se denegada, enviar um e-mail para o destinatário informando a ela que não será possível realizar a venda e apresentar o motivo. Se rejeitada, apresentar na tela o motivo da rejeição para que o usuário do sistema faça as devidas correções e realize uma nova tentativa de envio. Antes que você faça os ajustes na sua aplicação conforme exposto acima sugiro que atualize todos os fontes de todas as pastas.

Você esta com todos os fontes atualizados? Pois o componente não salva mais as notas denegadas com o nome *-den.xml

Boa noite Hugo, Você vai ter que ter um segundo ACBrCTeServicos.INI com as novas URLs e enviar para os seus clientes e pedirem a eles a realizar a troca na data de seu inicio.

Boa noite, Na sua primeira postagem o 173 se refere ao numero da nota? Lembre-se que ao enviar uma nota podemos 3 respostas diferentes: 1. Nota Autorizada 2. Nota Denegada 3. Nota Rejeitada Somente no caso 3 a nota deve ser corrigida e ser enviada novamente. O componente esta preparado para anexar o protocolo de autorização ou de denegação ao XML assinado e salvar ele em disco se for o caso.

Boa noite Rafael, A solicitação do PIN ocorre toda vez que a aplicação necessita do certificado, como por exemplo: Assinar, Enviar, Consultar, .... Ou assim que o PIN é informado ele volta a solicitar o PIN novamente? O meu cliente utiliza de um certificado A3 e ele pede somente uma vez o PIN depois só se a aplicação for encerrada, caso contrario não. O componente é criado e destruído toda vez que você vai executar uma ação?

Boa noite, O Schema foi atualizado, favor realizar novos testes.

Boa noite Elton, Essa mensagem de erro foi retornada pelo provedor correto? Se sim, neste caso você deve informar o código do cnae no campo codigocnae para que o componente gere a TAG.

Boa noite Elias, Pelo que pude verificar no Schema o correto é "id" (tudo minusculo) em vez de "Id".

Boa noite Nilton, O TratarResposta que você se refere é o de cancelar? A mesma procedure esta sendo executada 2x, ou a primeira vez é do cancelar e a segunda é do consultar?

Boa noite Edson, Criar o executar no Consular Lote da mesma forma que o Consultar a Situação esta errado, pois gera um efeito colateral nos demais provedores. Já fiz alguns ajustes e amanhã vou disponibilizar para que você faças novos testes.

Boa noite Jairo, Qual é o provedor? Ajuda bastante se você anexar também os arquivos SOAP gerado.

Boa tarde Edson, Vou analisar as suas alterações e estando tudo OK vamos disponibilizar.

Boa tarde Elton, Qual é o provedor? O CNAE no caso é opcional?

Boa tarde Leandro, A aplicação que esta emitindo NFS-e através do provedor Actcon já esta usando o ACBrNFSe do Trunk2? Se sim, todas as funcionalidades estão OK?

Boa tarde Daniel, Se você tiver condições de realizar todos os testes, ou seja, envio, consulta e cancelamento e postar aqui o resultado, ficaremos grato.

Bom dia a todos, Acabo de enviar para o Repositório a implementação do provedor SP destinado a cidade de São Paulo. Não realizei testes, somente de compilação do componente, sendo assim não existe erros de sinaxe, mas pode ocorrer erros de lógica. O provedor foi implementado conforme o Manual Nota Fiscal Eletrônica de Serviços versão 2.4.2 Não tenho condições de realizar testes de envio, consulta, etc. deixo a cargo dos demais colegas. Não foi utilizado nenhuma DLL a não ser as que já fazem parte do projeto ACBr. Vamos torcer que as assinaturas sejam realizadas conforme esperado pelo provedor.

Boa noite a todos, O ACBrNFe também dispõe do método DistribuicaoDFe que também baixa da SEFAZ o XML completo da NF-e. Esse método também necessita que a empresa que deseja obter o XML tenha o Certificado Digital.

Boa noite Paulo, Vou encaminhar a sua alteração realizada na Unit para os demais colegas avaliarem também. No meu entendimento não vejo nenhum efeito colateral nos demais componentes.

Boa tarde Carlos, Não vejo nenhuma relação na forma de selecionar o certificado com o problema em questão. Verifique o valor da propriedade SSLLib do componente ACBrNFe se não for libCapicom favor alterar, compilar a aplicação com a opção Build e realize novos testes.

Boa tarde Lucas, Eu também tenho as minhas limitações. Vamos combinar: todos os fontes que por ventura você fizer uma alteração e com ela os seus testes progrediram, por favor anexe aqui no fórum com uma breve explicação do problema e o que foi feito no fonte para resolve-lo. Assim podemos analisar e estando tudo OK vamos disponibilizar no repositório para que os demais colegas possam ter os fones com mais um problema resolvido.

Souza, Como já foi dito a cidade de Fortaleza se utiliza do Ginfes, mas o NameSpace é diferente entre outras coisas mais no layout do envelopamento. Favor entrar em contato com a prefeitura ou com o Ginfes para saber se no caso de Fortaleza há necessidade de definir o SoapAction, uma vez que por padrão no Ginfes não se defini nada.

Boa tarde Cesar, Que eu saiba o idToken não pode ser "000000" e sim: "000001" ou "000002" ou ....

Boa tarde Rafael, Eu preciso do arquivo de envio e não do RPS ou NFS-e. Envio: *-env-lot-soap.xml (na versão trunk) para que eu possa comparar com o mesmo arquivo da versão trunk2.