Italo Giurizzato Junior

Olá Pessoal, Para o provedor ISSNet é utilizado um série especifica para cada cidade. É necessário solicitar uma faixa de numeração de RPS (por exemplo: 1-1000) antes de começar a emitir as notas. Quando terminar de usar a faixa solicitada se faz necessário solicitar outra faixa (por exemplo: 1001 - 2000). Para liberação dos documentos de Recibo Provisório de Serviços (RPS) é necessário acessar o Sistema ISS.Net Online de seu município e solicitar através do menu Solicitação de Documentos Fiscais --> Solicitação. Essa liberação é feita diretamente pela Prefeitura. Aqui tem mais detalhes sobre o erro e a solução também: https://basepro.com.br/wfenix//index.php?title=E004:_Esse_RPS_não_foi_enviado_para_a_nossa_base_de_dados._Número_do_RPS_em_que_ocorreu_o_erro:_1001

Boa tarde Thiago, O erro 403, pelo que me recordo, significa que não foi possível consumir o webservice, geralmente é devido ao certificado. Você esta usando o programa exemplo? Qual é a configuração no que diz respeito ao SSLLib e demais campos abaixo?

Boa tarde Felipe, Muito obrigado pela colaboração, já vou enviar para o repositório.

Bom dia Gabriel, Você esta usando o programa exemplo do componente para realizar esses testes?

Bom dia Cesar, Temos um novo grupo no MDF-e chamado <infPag> que se refere as informações do pagamento do Frete, como o schema permite "N" ocorrências isso significa que esse grupo poderá aparecer mais de uma vez no XML. No meu entendimento só devemos informar esse grupo mais de uma vez quando parte do pagamento for realizado por um responsável e parte por outro. Temos também um evento para registrarmos as informações sobre o pagamento do Frete e como consta na NT, isso significa que o pagamento será realizado de forma tardia. Entendo que primeiro o transporte será realizado para depois realizar o pagamento. Quando incluímos as informações sobre o pagamento do Frete no MDF-e, isso significa que o pagamento do mesmo vai ocorrer antes do transporte. Como o NT não deixa muito claro, foram essas as minhas conclusões.

Paralisação dos ambiente de Homologação e Produção da NFC-e Produção Prezados contribuintes, Em função de manutenção necessária no ambiente de processamento do NFC-e, o ambiente de produção ficará indisponível no período de 18/02/2020 23:59h até 19/02/2020 01:00h. Homologação O ambiente de homologação ficará indisponível no período de 19/02/2020 17:00h até 20/02/2020 08:00h. http://www.sped.fazenda.mg.gov.br

Boa noite Edmar, Primeiramente desculpa pela demora, mas analisamos e esta tudo ok, já foi enviado para o repositório.

Boa tarde Melissa, Por favor leia essa noticia:

Olá Pessoal, Ocorreu uma alteração no salvamento dos arquivos de envio e de retorno dos eventos e da inutilização. O motivo dessa alteração foi que esses arquivos estavam sendo salvos em dois lugares distintos. No caso dos eventos eles estavam sendo salvos na pasta configurada em PathEvento e em PathSalvar. Já os de inutilização estavam sendo salvos na pasta configurada em PathInu e em PathSalvar. Com a alteração os arquivos de envio e de retorno passam a ser salvos somente na pasta configurada em PathSalvar. Por outro lado, o resultado final do processamento dos eventos bem como da inutilização, ou seja, os arquivos *-procEventoNFe.xml (no caso da NF-e) e o *-procInutNFe.xml (no caso da NF-e) vão continuar sendo salvos nas pastas configuradas em PathEvento e PathInu respectivamente. Desta forma fica fácil para o desenvolvedor pegar por exemplo todos os XMLs referente aos cancelamentos (pasta ...\Evento\Cancelamento) compactar e enviar para a contabilidade. Antes era preciso excluir os arquivos de envio e de retorno para que estes não fossem incluídos no arquivo compactado. Quero lembrar a todos que essa alteração foi realizada nos componentes: ACBrBPe (Bilhete de Passagem Eletrônico), ACBrNF3e (Nota Fiscal de Energia Elétrica Eletrônica), ACBrCTe (Conhecimento de Transporte Eletrônico), ACBrMDFe (Manifesto de Documentos Fiscais Eletrônicos) e ACBrNFe (Nota Fiscal Eletrônica).

Bom dia Leandro, Muito obrigado pela colaboração, já foi enviada para o repositório. Favor atualizar os fontes e faça novos testes.

Bom dia Rodrigo, Muito obrigado pela colaboração, já enviei para o repositório. Favor atualizar os fontes e faça novos testes.

Bom dia mlspinelli, Muito obrigado pela colaboração, já esta no repositório. Favor atualizar os fontes e faça novos testes.

Boa tarde Marcos, Muito obrigado pela colaboração, já enviei para o repositório.

Olá pessoal, Foi removido dos componentes ACBrBPe, ACBrCTe, ACBrMDFe, ACBrNFe e ACBrNF3e das units que geram o XML a propriedade AjustarTagNro. Essa propriedade foi acrescentada porque ao usar o OpenSSL, os campos string com menos de 3 caracteres geravam erros de validação. A motivação para a remoção dessa propriedade foi: Os componentes listados acima ao gerar o XML se o conteúdo do campo “nro” tiver apenas 1 ou 2 dígitos eram ajustados para 3 dígitos, consequentemente causando problemas na cidade de Barretos/SP, pois nessa cidade existem imóveis diferentes com numeração 10 e 010 (zero a esquerda) na mesma rua. Por incrível que pareça é zero mesmo e não a letra "O". Caso alguém venha ter problemas de validação com o campo nro, favor tratar da seguinte forma: ao alimentar o campo nro: nro := ExecutarAjusteTagNro(True, cNumero); Onde: cNumero é uma variável da sua aplicação que contem o numero do imóvel situado no logradouro. Devemos incluir em uses a unit pcnAuxiliar. A função ExecutarAjusteTagNro vai realizar o ajuste necessário para que o campo nro fique com no mínimo 3 dígitos.

Bom dia Rogério, A mensagem é muito estranha, se você esta enviando o RPS, jamais o webservice deveria retornar essa mensagem de erro e sim, a mensagem que o RPS já foi enviado, logo você tem que enviar o RPS com um numero superior ao que esta sendo enviado. Favor entrar em contato com o provedor e pedir explicações sobre essa mensagem de erro totalmente absurda.

Bom dia Thiago, O certificado digital não esta vencido?

Bom dia, Estou usando o programa exemplo do componente. O DANFSE é o do Fortes Report. Usei o seu XML (anexado na quinta feira - 646RPI-nfse.xml) Segue em anexo do DANFSE em PDF. NFS-e 646.pdf

Bom dia, É bem provável que sim, muitos provedores requerem que seja liberado a emissão da NFS-e via webservice.

Favor atualizar todos os fontes de todas as pastas. Reinstale a suíte ACBr e faça novos testes.

Bom dia William, Muito obrigado pela contribuição, já esta no repositório.

Bom dia Leonardo, Notei que você esta enviando segundo a versão 1. Faça um novo teste enviando segundo a versão 2. Anexa o XML do GNRE desse teste que você fez com a versão 1.

Se esta emitindo NF-e com essa configuração não deve ser DLL. Pois o componente ACBrNFSe se utiliza das mesmas rotinas e DLLs usadas pelo componente ACBrNFe. Então tente emitir a NFS-e configurando o componente com o Capicom.

Bom dia, Realizei um teste carregando o XML que você anexou e os valores do tributos federais foram impressos no DANFSE (versão Fortes Report), usei o programa exemplo do componente para realizar o teste. Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr?

Bom dia, Primeiramente muito obrigado pela contribuição, ainda hoje estarei enviando para o repositório o arquivo Cidades.ini com a respectiva cidade incluída. Quanto ao erro, deve ser configuração. Atribua o valor libWinCrypt ao campo SSL Lib e faça novos testes.