Italo Giurizzato Junior

Bom dia Antônio, (tópico movido para a área do SAC) Acessando o site da prefeitura, me parece que a empresa contratada é a Assessor Publica que tem o sistema IssOnline. É preciso entrar em contato com eles para saber se seguem ou não o layout da ABRASF, se sim qual versão. Seria interessante saber quais cidades se utilizam desse provedor fora a cidade de Araçatuba.

Bom dia Rafael, Compare o seu XML com este: 1718060455011000018856000000000000027-rps.xml

Se o provedor segue a versão 2 do layout da ABRASF você pode testar os 3 botões: [Enviar Lote Rps (Enviar)], [Enviar um Rps (Gerar)] e [Enviar Lote Rps (EnviarSincrono)]. Agora se o provedor segue a versão 1, só podemos usar o primeiro: [Enviar Lote Rps (Enviar)].

Bom dia Rafael, Você esta com todos os fontes de todas as pastas atualizados?

Bom dia Kartter, O que você acha de abrir o arquivo Abaco.ini e dar uma olhada na seção [Assinar]? ; 0 = False / 1 = True (se True então assina) [Assinar] RPS=0 Lote=1 Isso responde a sua pergunta?

Bom dia, Tenho uma lista com 81 provedores, dos quais 28 seguem a versão 1 do layout da ABRASF, 40 seguem a versão 2 e 13 tem o seu próprio layout. Os provedores que seguem a versão 1 do layout da ABRASF não possuem os serviços: Gerar, EnviarSincrono e Substituição. Já os que seguem a versão 2 tem todos os serviços exceto o de ConsultaSituacao. A priori, mas pode acontecer do provedor não disponibilizar algum serviço como por exemplo o Cancelar, neste caso para efetuar o cancelamento de uma nota é preciso entrar em contato com a prefeitura ou efetuar o seu cancelamento via site. Para saber quais serviços disponíveis é preciso abrir o arquivo INI do provedor em questão e verificar quais serviços esta definido a estrutura do envelope utilizado para o envio do XML para o webservice. Os erros de "SoapAction não definido" é uma prova que o respectivo serviço não existe para o provedor em questão. Idem para a mensagem de erro onde mostra o serviço e a mensagem "não implementado". Quanto a mensagem de erro http 500, qual consulta você tentou executar? Pois o componente possui 4 métodos de consulta: ConsultarSituacao, ConsultarLoteRps, ConsultarNFSePorRps e ConsultarNFSe. No caso do provedor Saatri que se utiliza a versão 2 do layout da ABRASF não devemos utilizar o método ConsultarSituacao pelo simples fato desse método não existir na versão 2.

Bom dia Roberto, A intensão de ter no XML os caracteres #13#10 é para que ao abrir o XML através de um navegador o conteúdo das tags: Discriminacao e Descricao sejam apresentados com quebra de linha? Ou se não fizer isso na impressão do DANFSE não sai com a quebra de linha? Se é na impressão então devemos fazer as devidas correções neste e não na geração do XML.

Bom dia, (tópico movido para a área do SAC) Não veja a necessidade dessa alteração uma vez que sempre devemos informar o CNPJ completo com os 14 dígitos, pois dependendo de onde essa informação for utilizada será considerado apenas os 8 primeiros dígitos ou os 14 dígitos.

Bom dia Israel, O componente para o eSocial já existe, bem como o programa exemplo que demostra como alimentar cada tipo de evento referente ao eSocial. Documentação sobre o componente não existe, mas você pode ter como base o Manual do eSocial para saber o que vem a ser cada evento e seus respectivos campos.

Bom dia Felipe, Me tira uma duvida, você tenta inutilizar um numero após o envio e ter ocorrido erro de timeout? Você considera esse procedimento correto? Vamos analisar duas situações. 1. A nota é enviada e recepcionada pela SEFAZ, mas por algum problema não obtemos o retorno. Ao tentar inutilizar o numero dessa nota, o pedido de inutilização deve ser rejeitado uma vez que a nota já consta na base de dados da SEFAZ. Neste caso sabemos que a nota foi enviada, sendo assim basta agora conseguir o protocolo de autorização. 2. A nota é enviada mas por algum problema não chega até a SEFAZ. Ao tentar inutilizar o numero dessa nota, o pedido de inutilização é aceito uma vez que a nota não existe na base de dados da SEFAZ. Neste caso não vamos poder enviar a nota novamente com esse numero uma vez que agora esse numero na SEFAZ consta com inutilizado. Como você resolve esse problema agora? Altera o numero da nota e envia novamente? Não seria mais pratico se após o envio realizar uma consulta caso tenha ocorrendo algum erro de timeout? Se o erro ocorreu no envio, a consulta vai acusar que a nota não consta na base de dados, sendo assim podemos enviar novamente. Por outro lado se o erro ocorreu após o envio, ou seja, no retorno, a consulta vai retornar o protocolo de autorização ou a rejeição caso a nota tenha alguma informação errada. Estando o componente carregado com a nota ao realizar a consulta, se o retorno desta retornar que a nota foi autorizada, o componente vai se encarregar de atualizar o XML acrescentando o protocolo de autorização. Por outro lado se a nota foi rejeitada, devemos efetuar as devidas correções e enviar novamente. Esse sim é o procedimento correto a ser feito. Repense.

Boa tarde, Me diz uma coisa esse CT-e que você deseja emitir é o CT-e emitido pelo Contratante ou pelo Subcontratado? Se esta emitindo o CT-e do Subcontratado então devemos em <infDoc> informar os documentos referente a carga, no caso as NF-e, já no <docAnt> devemos informar os documentos emitidos pela Contratante, ou seja, os CT-e. No seu arquivo texto deve ficar desta forma: [infQ002] cUnid=03 tpMed=UNIDADE qCarga=699.0000 [infNFxxx] <=== onde xxx pode variar de 001 até 999 nRoma= nPed= mod= serie= nDoc= dEmi= vBC= vICMS= vBCST= vST= vProd= vNF= nCFOP= nPeso= PIN= dPrev ou [infNFexxx] <=== onde xxx pode variar de 001 até 999 chave= PIN= dPrev= [emiDocAnt001] Espero ter ajudado.

Bom dia Rafael, Muito obrigado pela informação. O Trunk2 já esta pronto para emitir NFS-e para a cidade de Araguaína/TO com o nome provedor WebIssv2.

Bom dia Heunogaliton, Se tratando do CT-e OS o grupo <toma> só é opcional quando se tratar de bagagem extra, que não é o caso. Na descrição do grupo <toma> temos: Informações do Tomador/Usuário do Serviço Para indicar somente um dos passageiros como sendo o tomador, acredito eu que essa pessoa deveria ser uma pessoa jurídica, desta forma fica caracterizado um fretamento e na tag <qCarga> que se encontra dentro do grupo <infQ> informar a quantidade de pessoas que estão participando dessa excursão. Como nenhuma dessas pessoas deva ter um CNPJ e se tem não deseja assumir esse papel, não vejo outra saída emitir um CT-e OS para cada passageiro, uma vez que cada um esta pagando pelo serviço de transporte. Uma outra saída seria a emissão de um BP-e - Bilhete de Passagem Eletrônico para cada passageiro, mas não são todos os Estados brasileiros que já aderiram esse modelo de documento fiscal e ele é destinado as empresas de transporte intermunicipal e interestadual.

Bom dia Diego, Tenta com esse outro XML em anexo. teste3_alterado.xml

Bom dia Amarildo, Realmente esta faltando, vamos providenciar a correção do Help do Monitor. Desde já muito obrigado pela observação.

Jucemar, Vamos manter esse tópico para discutir a assinatura e validação de eventos do eSocial, cujos XML foram gerados por "terceiros". Fico no aguardo de um retorno para saber se a minha orientação deu certo. Caso negativo favor anexar o XML que esta tentando carregar.

Rubens, No caso do lote, qual das duas assinaturas que é considerada inválida? O que você esta usando, libCapicom, libWinCrypt, libOpenSSL,...?

Bom dia, Desculpa não entendi o motivo da sua alteração. Pois ao alimentar o componente no campo Discriminacao devemos usar o caractere ";" (ponto e virgula) sempre. Quando o componente vai gerar o XML ele troca esse caractere pelo o que esta definido no arquivo INI do provedor em questão.

Bom dia, Tentou com os valores: LT_TLSv1_1 e LT_ALL para SSLType?

Rubens, O grande problema é o seguinte. Todos os componentes, ACBrNFe, ACBrCTe, ACBrMDFe, ACBrBPe, ACBreSocial, ACBrReinf e ACBrNFSe no que diz respeito a assinatura segue o padrão estabelecido pelo ICP Brasil. O Provedor Salvador que atende somente a cidade de Salvador esta fora desse padrão. A ausência do grupo <Transforms> da assinatura deixa ela sem nenhuma segurança, pois sem ela pegamos o XML e calculamos o Hash, por outro lado com ela antes de calcular o Hash ocorre a transformação do conteúdo isso deixa a assinatura mais segura. O correto é o provedor rever o que foi feito e passar a seguir o ICP Brasil.

André, Não tem como usar mais o Capicom com a versão 4.00 é preciso configurar o componente para usar o WinCrypt. Vide o programa exemplo do componente.

Diego, Você esta com todos os fontes de todas as pastas atualizados? Se sim, os componentes foram reinstalados através do ACBrInstall_Trunk2? Pois após carregar o XML, o componente checa se esta assinado ou não, caso não esteja, assina, valida e salva em disco.

Bom dia Rubens, Pelo que notei no XML gerado pelo outro componente não contem dentro da assinatura o grupo <Transforms>. Você removeu esse grupo da assinatura do XML gerado pelo componente ACBNFSe? Se sim, como você fez?

Diego, Você tem certeza? E nas sub pastas que foram criadas dentro da pasta XMLExemplos?

Bom dia André, Primeiramente, você precisa estar com todos os fontes de todas as pastas atualizadas e os componentes reinstalados através do ACBrInstall_Trunk2. Segundo, configurar o componente para emitir a NF-e na versão 4.00 Terceiro, iniciar os testes, a medida que forem surgindo os problemas (que não vão ser muitos) fazer as devidas correções.