Italo Giurizzato Junior

Bom dia Celso, Segundo o arquivo de retorno *-sit.xml temos: <NumeroLote>0</NumeroLote> <Situacao>2</Situacao> O numero do lote retornado é zero, não sei se esta correto pois você não inclui o arquivo de envio do lote. O código da situação do processamento é 2 = Lote não processado. Situacao: 1 = Não Recebido 2 = Não Processado 3 = Processado com Erro 4 = Processado com Sucesso

Odlawso, Os ajustes no componente são feitos com base no schema, no que diz respeito a gerar o XML. Por isso que reafirmo é preciso ter em mãos o schema fornecido pelo provedor.

Bom dia, Segundo a Nota Técnica 2013/004 versão 1.00a de Outubro/2013 página 104 e 105, o grupo <prop> é opcional, mas se o mesmo for incluído devemos obrigatoriamente informar o CPF/CNPJ, RNTRC, xNome, UF e tpProp, por outro lado o IE é opcional.

Bom dia Leandro, os dois identificadores que o Delphi acusa como não declarados, na verdade são constantes e os mesmos estão definidos em pmdfeConversao. Abra essa unit e cheque se os mesmos estão definidos. Se sim o problema é que o Delphi esta utilizando uma DCU antiga dessa unit. Neste caso procure e exclua.

Bom dia, Abra a unit pnfseConversao e ACBrProvedorThema e veja como foi feito para adicionar as demais cidades que utilizam esse provedor.

Bom dia, Qual é a data de validade do certificado?

Bom dia Odlawso, Você não pode alterar os Schemas (nfse.xsd) alguns provedores infelizmente incluíram o atributo ID todo minusculo. É preciso solicitar junto ao provedor o schema correto e fazer as alterações necessárias no componente para que o mesmo gere o XML em conformidade com o schema.

Bom dia Lutzem, O campo indFinal deve receber o valor ZERO quando se tratar de uma NF-e e o valor UM quando for uma NFC-e. E o campo indPres deve receber o valor UM ou QUATRO quando for NFC-e, os demais valores quando se tratar da NF-e, neste caso o mais comum será NOVE. Resumindo os valores mais comuns são: NF-e NFC-e indFinal = 0 indFinal = 1 indPres = 9 indPres = 1

Bom dia AltC, Por favor realize a alteração e faça os testes. Estando tudo OK, post como anexo somente as Units Alteradas, para que possamos avaliar e disponibilizar para os demais. Desde já muito obrigado.

Felipe, Você tentar usar o Enviar, se ocorrer o erro acusando que o Enviar Lote não esta implementado para o provedor, isso significa que você não pode enviar um lote de RPS.

Cleiton, Atualize mais uma vez, compile com o Build e teste novamente.

Cleiton, O problema é que o provedor não esta retornando essa informação. Fiz uma alteração para que o componente calcule com base nos demais valores retornados. Atualize os fontes, compile com a opção Build e teste novamente.

Cleiton, Se possível post como anexo o XML da NFS-e cujo valor liquido aparece zerado no DANFSE.

Boa tarde Graça, O XML do EPEC não contem todos os dados do XML da NF-e. Lembre-se que o EPEC é um evento e não a nota. Lançamos mão do EPEC normalmente quando o problema é com o emitente e não com a SEFAZ. Como o XML do evento EPEC é extremamente pequeno em relação ao XML da NF-e, podemos utilizar um modem 3G (por exemplo) para enviar o EPEC. E quando os problemas com o emitente forem sanados devemos enviar o XML da NF-e (cujo EPEC foi enviado) para a SEFAZ, mantendo o tpEmis =4 mais o dhCont e xJust.

Boa tarde a todos, Todas as Units referentes aos provedores possuem uma function chamada GetValidarLote, que no caso do DBSeller temos: function TProvedorDBSeller.GetValidarLote: Boolean; begin Result := True; end; Se alterarmos o valor de retorno de True para False o componente para esse provedor em questão não vai realizar a validação antes do envio. É isso que vocês desejam?

Boa tarde João, Tentou compilar com a opção Build?

Boa tarde Maiko, Favor atualizar os fontes, compile com a opção Build e teste novamente.

Maiko, Por favor post como anexo os arquivos que contem o -soap no final do nome, para que possamos avaliar o problema.

Boa tarde Diogo, Detalhe mais.

Boa tarde Cleiton, Seja mais especifico. Qual é o provedor e o Report que você esta utilizando para imprimir o DANFSE?

Boa tarde Graça, Você disse que: "Fiz a conciliação da nota enviando-a com tpEmiss=1. " Isso esta errado, pois segundo a Nota Técnica 2014/001 na página 4 diz: A emissão do EPEC poderá ser adotada por qualquer emissor que esteja impossibilitado de transmissão e/ou recepção das autorizações de uso de suas NF-e, adotando os seguintes passos: * Gerar a NF-e com “tpEmis = 4”, mantendo também a informação do motivo de entrada em contingência com data e hora do início da contingência, com número diferente de qualquer NF-e que tenha sido transmitida com outro “tpEmis”; (...) Adotar as seguintes providências, após a cessação dos problemas técnicos que impediam a transmissão da NF-e para UF de origem: * Transmitir as NF-e emitidas em Contingência Eletrônica para a SEFAZ de origem, observando o prazo limite de transmissão na legislação, bem como outros procedimentos constantes na legislação caso ocorra rejeição na autorização de uso; * A Chave de Acesso desta NF-e é a mesma Chave de Acesso do EPEC autorizado. Sendo assim ao enviar a NF-e para a SEFAZ-Autorizadora, devemos manter o tpEmis = 4, bem como o motivo e a data e hora do inicio da contingência. Se enviar a NF-e com o tpEmis = 1 não vai ocorrer a vinculação do evento EPEC com a NF-e. Espero ter ajudado.

Boa tarde Maiko, Uma dica muito importante. O componente possui uma propriedade chamada: Configuracoes.WebServices.Salvar cujo valor padrão é False, altere para True e tente novamente. Será salvo mais 2 arquivos com os seguintes nomes: <ID>-ped-inu-soap.xml e <ID>-inu-soap.xml Esses arquivos são salvos de forma completa, ou seja, exatamente com é enviado e como é retornado pela SEFAZ. O <ID>-inu-soap.xml deve conter o erro que esta ocorrendo. Por favor, post como anexo os arquivos nesse segundo teste.

Boa tarde Felipe, Por favor releia a postagem #4 eu deixo claro que: "Existe sim a possibilidade de enviar um lote com até 50 RPS, mas isso depende do provedor." Se você tem 20 RPS a serem enviados para o Web Services, se os mesmos forem enviados um a um, serão necessários 20 conexões de envio, 20 conexões de consulta a situação do lote (que neste caso tem apenas 1 RPS) e 20 conexões para obter o XML da NFS-e. Por outro lado se podemos enviar um lote com os 20 RPS, teremos, apenas UMA conexão de envio, UMA conexão de consulta a situação do lote (que neste caso tem os 20 RPS) e UMA conexão para obter os 20 XMLs das NFS-e. Você prefere realizar 60 conexões ou apenas 3?

Bom dia Isaac, No que diz respeito a Manifestação do Destinatário, você só vai se manifestar em relação a uma NF-e emitida contra o seu CNPJ, sendo assim todos os eventos referente a Manifestação do Destinatário sempre vão ser vinculados a NF-e, pelo simples fato que a mesma foi emitida.

Boa tarde, O componente ACBrNFe, já esta preparado para o novo WebService, estamos apenas aguardando a liberação do mesmo para iniciar os testes.