Italo Giurizzato Junior

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

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

O componente após carregar o XML checa se o mesmo esta assinado ou não, se não estiver assina, em seguida realiza a sua validação.

Bom dia Mateus, Favor atualizar novamente e faça novos testes.

Pela mensagem de erro, você não configurou a versão correta no programa exemplo, que é 2.4.2

Bom dia Marcus, Ao baixar os fontes da Suite ACBr você encontra tudo isso na pasta que contem o programa exemplo do componente ACBrNFSe.

Bom dia Júlio, A questão é muito simples. As informações sobre um CTe OS de substituição fica dentro do grupo de informações do CT-e OS Normal onde consta os dados do Modal e consequentemente temos a informação do numero de registro Estadual. Por outro lado um CTe OS de complementação ou Anulação as informações ficam fora do grupo de informações do CT-e OS Normal, aliais existe na estrutura do XML do CT-e 3 grupos, uma para Normal outro para Complementar e outro para Anulação, e somente um desses 3 grupos podem existir no XML. Logo se o meu CT-e OS for de complementação, não vai poder existir o grupo de informações do CT-e OS Normal e nem o de anulação. Essa regra não é exclusiva do CT-e OS, pois ela também se aplica no CT-e (modelo 57). O problema esta na SEFAZ que esta aplicando uma regra sem antes verificar o tipo de CT-e ou CT-e OS que esta sendo emitido. Resumindo: Erro na SEFAZ, favor entrar em contato e relatar o problema.

José, Como você é do SAC movi a sua postagem para dentro da área do SAC e já respondi ela. Por favor, vamos seguir as regras do fórum, nesta postagem estamos tratando de outro assunto.

Bom dia Adilson, Você não entendeu. Se deseja que a segunda impressão seja igual a primeira, você deve primeiro carregar o XML do MDF-e (*-mdfe.xml) e depois carregar o XML do evento (*-procEventoMDFe.xml). Lembrando que o método para carregar o XML do MDF-e é um e para carregar o XML do evento é outro.

Bom dia, Após alterar a configuração, você clicou no botão salvar a configuração?

Bom dia André, A alteração que você realizou, tem como finalidade apenas deixar exatamente igual o que esta no manual? Pois para mim se a venda é interestadual obviamente que a UF do emitente tem que ser diferente da UF do destinatário. Não entendi o motivo da SEFAZ acrescentar uma outra condição checando o CNPJ do emitente com o do destinatário. A minha duvida é, posso vender para mim mesmo? Outra coisa, existe uma exceção para essa regra, ela se refere a existência ou não de um item com a tag <UFCons> diferente da UF do emitente. Sendo assim essa regra deve ser checada após o loop dos itens e dentro do loop devemos verificar a exceção acima.

Bom dia Cesar, Uma pequena correção. A chave da nota é composta por 44 dígitos dos quais 8 se referem ao código da nota fiscal (cNF). A sua aplicação não vai gerar a chave, quem gera é o monitor com base em algumas informações: Chave = <Código da UF(2)><Ano de Emissão(2)><Mês de Emissão(2)><CNPJ do Emitente(14)><Modelo(2)><Série da Nota(3)><Numero da Nota(9)><Tipo de Emissão(1)><Código da Nota(8)><Digito Verificador(1)> Os numero entre parênteses é a quantidade de dígitos. Se você não informar o código da nota fiscal (cNF) o monitor a principio atribui o valor zero. Como o código da nota fiscal não pode ser zero um código aleatório (recomendação da própria SEFAZ) de no máximo 8 dígitos é gerado e como dito anteriormente, vai fazer parte da chave. Por outro lado se a sua aplicação gerar e armazenar o código da nota da mesma forma que gera e armazena o numero dela e passar essas informações nos campos apropriados: nNF=<numero da nota gerado pela sua aplicação> cNF=<código da nota gerado pela sua aplicação> o Monitor vai gerar a chave com essas informações. Exemplo: nNF=1500 cNF=236589 Chave = <Código da UF><Ano de Emissão><Mês de Emissão><CNPJ do Emitente><Modelo><Série da Nota><000001500><Tipo de Emissão><00236589><Digito Verificador> Observações: 1. o numero da nota (nNF) tem que ser um numero sequencial crescente iniciado em 1. 2. o código da nota (cNF) não pode ser zero e nem igual a nNF e sim um numero aleatório. Espero ter ajudado.

Boa tarde Adilson, A resposta é simples. Para cancelar ou encerrar você esta carregando o XML do MDF-e, correto? Pois bem isso faz com que a impressão do evento sai completa, ou seja, com alguns dados do MDF-e. Já a segunda impressão você esta só carregando o XML do evento e mandando imprimir, isso faz com que a impressão não saia com os dados do MDF-e.

Ou você informa o caminho com o certificado e senha ou informa o numero de série, caso este esteja instalado na maquina.

Hugo, Favor entrar em contato com a SEFAZ, pois com certeza ela esta aplicando a regra N22b sem antes checar se o Tipo CTe é Complementar ou não.

6.3 - Mostre respeito pelo modo de escrever. Escreva de modo claro, gramaticalmente e semanticamente correto. Não escreva TUDO EM MAIÚSCULAS. Isso é lido como se estivesse gritando e é considerado rude. Favor leia as regras do fórum. Outra coisa, aqui estamos tratando de NFS-e e não MDF-e.

Boa tarde Hugo, Seria interessante você anexar o XML do CT-e OS que foi rejeitado, pois somente o XML de retorno não tem como ajudar você.

Boa tarde hpensador, O código do botão [Carregar XML] que se encontra no programa exemplo do componente, permite carregar o XML gerado pela sua aplicação, assinar e validar. Desta forma é possível criar um loop para carregar cada um dos XMLs. Depois de todos carregados, assinados e validados, você envia. Estude o programa exemplo.

Boa tarde Leandro, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Até onde sei o GissOnline implementou um novo webservice baseado na versão 2 do layout da ABRASF que chamados de Giss e acredito que esse novo webservice esta sendo instalado nos novos contratados (novas prefeituras). Quanto implementar esse novo serviço não seria tão difícil. Quanto ao envio por e-mail não me recordo se é só o DANFSE ou se é um link onde você pode obter o PDF e ou o XML.

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

Bom dia dhasdcher, Você poderia anexar somente as units que você alterou para que eu possa analisar e estando tudo OK enviar para o repositório?

Bom dia Marcelo, O caminho é: 1. Instalar na sua maquina o certificado do emitente da NFS-e; 2. Configurar o programa exemplo com os dados do emitente; 3. Iniciar os testes. Não esqueça de altear o programa exemplo, mais precisamente a procedure que alimenta o componente com os dados do serviço, devemos alterar se necessário a alíquota e o código do Item (ItemListaServico), talvez mais algumas informações. Mas isso você vai descobrindo a medida que for realizando os testes. Depois de conseguir enviar o RPS e obter como resposta a NFS-e, Cancelar, Consultar, tudo através do programa exemplo, ai sim você parte para escrever a sua própria aplicação tomando como base o programa exemplo.

Bom dia, Até onde sei a cidade de Ribeirão Preto se utiliza do provedor Ginfes, por favor não confunda com o novo provedor chamado Giss. O Ginfes se utiliza da versão 1 do layout da ABRASF e segundo esse layout não existe esse tipo de serviço, ou seja, uma consulta as NF-e do Tomador. Por outro lado o provedor Giss (que não é o de Ribeirão Preto) segue a versão 2 do layout da ABRASF e segundo esse layout existe o serviço de consulta as NF-e do Tomador, mas uma coisa é o tipo de serviço esta previsto no layout, outra coisa é o provedor implementar em seu webservice e outra coisa é existir um método no componente ACBrNFSe para acessar esse serviço. No caso do componente o método para consultar as NF-e do Tomador não foi implementado. Mesmo que o componente tivesse o método você não iria conseguir usar, pelo simples fato da cidade de Ribeirão Preto se utilizar do provedor Ginfes e este não tem no seu Webservice esse tipo de serviço.

Boa tarde Ângelo, Esse provedor não segue o layout da ABRASF. Caso você queira colaborar com o projeto fique a vontade em implementar. Dica: tome como base o provedor Governa ou Equiplano, por exemplo.