Italo Giurizzato Junior

Boa tarde ALA, O provedor GovDigital já existe no componente. Basta acrescentar a cidade no arquivo Cidades.ini da mesma forma que as demais cidades desse provedor.

Boa tarde Ricardo, Entre em contato com a prefeitura e pergunta se ainda é a empresa Thema que continua prestando o serviço de recepcionar as NFS-e ou se agora é outra.

Boa tarde Hugo, A mensagem de erro diz que o elemento Distribuição é inesperado. Era esperado o elemento CodigoTributacaoMunicipio. Você alimentou o Código de Tributação do Município?

Boa tarde Rogério, Alem de configurar a versão, você passou o caminho correto dos Schemas na propriedade PathSchemas?

Bom dia ALA, Que eu saiba essa cidade não consta no arquivo Cidades.ini, você que adicionou? Se sim, você sabe me dizer qual provedor ela se utiliza (provedor EL ou ELv2)?

Bom dia Adriano, Qual é a cidade?

Bom dia Hugo, Todos os fontes de todas as pastas estão atualizados? Se sim, você esta realizando os testes com o programa exemplo?

Bom dia, Isso depende, pois um provedor que segue a versão 1 do layout da ABRASF, essa informação temos através do retorno da Consulta a Situação do Lote, já os provedores que seguem a versão 2 do layout, essa informação é retornada na Consulta ao Lote que acaba alimentando o campo Situação conforme o seu exemplo.

Bom dia Luiz, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Rogerio, No programa exemplo, configure ele para usar a versão 2.04.02 Configure o caminho dos Schemas (PathSchema) para: ...\Exemplos\ACBrDFe\Schemas\eSocial\v2_04_02 E faça novos testes.

Bom dia Icozeira, Por favor atualize os fontes e teste com o INI que enviei para o repositório.

Boa tarde a todos, Lendo com mais atenção o Manual de Orientação ao Desenvolvedor-REINF v1.3.02 notei que no retorno de um envio de evento sempre teremos o evento R5001 e este poderá aparecer "N" vezes nesse retorno e o motivo é simples, se enviarmos um lote contendo 10 eventos, teremos no retorno 10 R5001, ou seja, um para cada evento enviado no lote. Como podemos enviar até 100 eventos por lote, o retorno poderá conter 100 eventos R5001. Já no retorno de uma consulta sempre vai retornar o evento R5011 e ele é único no retorno. Com base nessas informações fiz algumas modificações no que diz respeito ao retorno. Da forma atual é preciso estanciar o R5001 e R5011 para poder ler o retorno, agora não será mais necessário. Alterei as Units responsáveis pela leitura dos retornos e também o programa exemplo para demonstrar a leitura de alguns dados. Essas modificações só serão enviadas para o repositório na segunda-feira dia 21. Logo peço que façam cópias dos fontes por questões de segurança. Espero contar com a compreensão de todos. Outra coisa importante: O componente ainda esta em fase de desenvolvimento, apesar de ser possível o envio de eventos e a realização de consulta.

Bom dia André, O componente ACBrNFSe tem como objetivo atender todos os provedores que seguem o layout da ABRASF e os que não seguem. Como você não fez referencia a nenhum provedor vou tomar como base os provedores que seguem o layout da ABRASF. Já o caso do Roberto que faz referencia a cidade do Rio de Janeiro, o provedor que é a própria prefeitura do RJ segue a versão 1 do layout da ABRASF. Sendo assim, o componente gera e envia para o WebService do provedor o RPS - Recibo Provisório de Serviço. O provedor por sua vez processa o RPS, estando tudo OK gera e devolve o XML da NFS-e. O componente ao obter o XML da NFS-e, salva separadamente em disco e lhe permite que o DANFSE seja visualizado e impresso. Os provedores que seguem a versão 1 do layout da ABRASF (Rio de Janeiro por exemplo) o grupo <IdentificacaoRps> que contem o numero, série e tipo do RPS é obrigatório, logo a aplicação tem que ter um controle de numeração de RPS a ser enviado para o provedor e um outro de NFS-e, referente ao retorno do provedor. Já os provedores que seguem a versão 2 do layout da ABRASF, o grupo <IdentificacaoRps> (obrigatório) esta dentro do grupo <Rps> (opcional) que por sua vez esta dentro do grupo <InfDeclaracaoPrestacaoServico> (obrigatório). Se não for gerado o grupo <Rps> pois este é opcional o grupo <IdentificacaoRps> não será gerado também, concorda? Um detalhe importante. Se esta aparecendo "Nota Fiscal substitui RPS nnnn" isso significa que foi informado os dados: Numero, Serie e Tipo do RPS que se encontram dentro do grupo <RpsSubstituido> (opcional). Favor verificar se a afirmação acima esta correta, abrindo o XML do RPS que foi enviando para o provedor.

Bom dia Brito, Se você abrir a Unit ACBrNFSe vai encontrar os método referente as consultas e seus respectivos parâmetros. A partir dai da para se ter um ideia do que é necessário para obter o XML de uma ou várias NFS-e.

Bom dia equinhone, Se o soapaction não esta definido significa que o provedor que atende a cidade para qual você deseja emitir a NFS-e não disponibilizou o serviço GerarNFSe, logo não tem como usar o método Gerar. Tentou usar o método Enviar?

Bom dia Sérgio, Se a transportadora A emite um CT-e cujo remente é do Rio de Janeiro e o Destinatário é de Porto Velho, mas esta não vai fazer todo o serviço de transporte e sim levar a carga até Guarulhos para que a transportadora B pegue essa carga e leva de Guarulhos até Porto Velho, isso não é subcontratação e sim Redespacho. A transportadora A deve emitir um CT-e Normal, informando o Remente, o Destinatário e o Recebedor (Transportadora B). A transportadora B deve emitir um CT-e de Redespacho, informando o Remente, o Destinatário e o Expedidor (Transportadora A). Veja este outro link: http://www.ophos.com.br/app/publicacoes/detalhe/ct-e-de-redespacho/

Bom dia Alisson, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Rogério, Esse erro ocorre ao carregar o programa exemplo no Delphi e executa-lo, correto? Ao aparecer a mensagem de falha você clicou no botão Continuar?

Bom dia Amarildo, Uma pequena observação. Se o CTe for do tipo Normal e a transportadora vai realizar todo o serviço, ou seja, vai transportar a carga do Remente até o Destinatário, não devemos informar o Expedidor e o Recebedor, pois essas duas pessoas também são transportadoras e só devem constar no XML quando se tratar de Redespacho ou Redespacho Intermediário. Para mais detalhes acesse o link abaixo: http://www.ophos.com.br/app/publicacoes/detalhe/ct-e-de-redespacho/

Hugo, É exatamente isso que eu quero que você faça. Vamos a força esta com você.

Concorda que a tua pergunta esta respondida. O arquivo Cidades.ini ainda indica o provedor antigo, sendo assim se faz necessário alterar e fazer os testes. Talvez seja necessário alterar também o arquivo WebISS ou o WebISSv2 dependendo se para a cidade em questão vai usar a versão 1 ou 2 do layout da ABRASF.

Bom dia Hugo, Chegou a verificar o arquivo Cidades.ini?

Acredito que até o final deste ano já esteja em funcionamento, não necessariamente em todas as cidades, por conta do contrato de licitação que as prefeituras tem com os provedores.

Marcelo, Eu achei estranho na época eles usarem uma URL de homologação totalmente diferente da de produção. Acredito que eles estejam desativando aos poucos a URL antiga passando todos a usarem a nova.

Bom dia Cristian, Muito obrigado, eu tinha cometido um erro, em vez de colocar: NomeURL_H coloquei: NomeURL_P dai o erro. Já fiz a correção e enviei para o repositório.