Italo Giurizzato Junior

Boa tarde, Essa funcionalidade só vai ser implementada no componente, quando o provedor Betha implementar o websevice: GerarNfse. Você tentou usar o [Gerar e Enviar Lote]?

Boa tarde Neo No caso do provedor Abaco, não devemos incluir o atributo Identificador na tag Signature e consequentemente o atributo URI da tag Reference deve receber o valor vazio. Caso contrario vai ocorrer erro ao assinar o lote. Esse erro não ocorreu quando testei com o programa exemplo, as alterações que fiz. Inclusive obtive o seguinte retorno do webservice após o envio do lote: <EnviarLoteRpsResposta> <NumeroLote>1</NumeroLote> <DataRecebimento>2013-08-07T10:21:08</DataRecebimento> <Protocolo>E49A8FBD2395EDC4DF0AB4D1BD0091F1</Protocolo> </EnviarLoteRpsResposta> Como você pode ver o lote foi enviado e o webservice inclusive retornou o protocolo de recebimento do mesmo. e esse outro após consultar a situação do lote: <MensagemRetorno> <Codigo>E45</Codigo> <Mensagem>RPS:0 - CNPJ nao encontrado na base de dados</Mensagem> <Correcao>Confira o numero do CNPJ informado. Caso esteja correto, o prestador nao esta inscrito no municipio.</Correcao> </MensagemRetorno> Essa mensagem de erro ao consultar a situação é aceitavel, uma vez que utilizei um CNPJ de outra cidade.

Boa tarde, Esse DANFE é em Quick Report, Rave, .... ? Você não esta emitindo em contingencia?

Boa tarde Daniel, Vamos aguardar mais sugestões para a solução do problema. Não devemos alterar essas funções para resolver um problema no componente ACBrCTe, uma vez que elas são utilizadas por outros componentes e dependendo da alteração realizada, corremos o risco de prejudicar o funcionamento dos demais componentes.

Boa tarde Marcio, Obrigado pelas informações. Por favor atualiza os fontes e teste.

Boa tarde Henrique, Já esta disponivel as suas alterações. Lhe pesso que faça uma cópia de segurança dos seus fontes e baixe a atualização. Uma observação, os seus fontes estão desatualizados em relação aos novos provedores.

Boa tarde Marcio, Para a inclusão dessa cidade, precisamos saber as URLs tanto de homologação quando de produção dos webservices. Sem essa informação não tem como, pois o provedor GovBR utiliza URLs diferentes para cada cidade.

Boa tarde Marcel, Mande para mim por e-mail o arquivo -env-lot-c.xml referente ao envio do RPS 98. e o arquivo -rec-c.xml

Bom dia João, O DACTE disponivel não esta completo, ainda falta algumas coisas, uma delas é o quadro que apresenta os dados de produtos perigosos. Você tem toda a liberdade de realizar essa implementação e ficariamos gratos se depois disponibiliza-se para a comunidade.

Bom dia Vinicio, Continua a mesma, a Nota Técnica não diz nada que temos que utilizar uma nova série para enviar para o SVC.

Bom dia, Descobri o problema. Ele se encontra na function rCampoCNPJCPF que possui a seguinte lógica: result := rCampo(tcStr, 'CNPJ'); if trim(result) = '' then result := rCampo(tcStr, 'CPF'); Note que le primeiramente a tag CNPJ se o retorno for vazio le a tag CPJ. Acontece que dentro do grupo <rem> temos o grupo <enderReme> e podemos ter também um dos grupos: infNF, infNFe, infOutros. Dentro do grupo <infNF> podemos ter o grupo <locRet> ou seja o local de retirada que também poderá ter as tags CNPJ ou CPJ. No seu XML tem o grupo <locRet> com a tag <CNPJ> isso faz com que a funcion pegue o conteudo dessa tag em vez do CPF do Remetente. Se alterarmos a function para a seguinte lógica: result := rCampo(tcStr, 'CPF'); if trim(result) = '' then result := rCampo(tcStr, 'CNPJ'); O seu problema fica resolvido, pois ele vai ler o CPF do Remetente. Mas por outro lado imagina que o Remetente possui CNPJ e a pessoa referente ao local de retirada possui um CPF, a function vai pegar primeiramente o CPF do local de retirada e não o CNPJ do remetente. Sendo assim, a minha sugestão é estudar as function rExtrai e rCampo que estão na unit pcnLeitor.

Bom dia Neo, Por favor atualiza os fontes e tenta novamente.

Bom dia Marcel, Se no ambiente de homologação a emissão ocorre sem nenhum problema e no ambiente de produção o envio é rejeitado, isso me leva a crer que a empresa esta habilitada somente a usar o ambiente de homologação. Verifique se não há necessidade de agora habilitar a mesma em produção. Isso ocorre com a NF-e, CT-e, você credencia a empresa primeiramente no ambiente de homologação e depois em produção, ou seja são dois credenciamentos.

Bom dia Udenilson, Post o XML como anexo.

Bom dia, Post o XML do CT-e como anexo.

Eu sei, Como tem varias pessoas postando que foi publicada a NT de numero tal e se o componente vai ser atualizado ou não. Mediante a isso, tomei a liberdade de realizar as implemetações e avisar toda a comunidade que o componente já foi atualizado. Bastando agora o aval dos mantenedores para que eu possa disponibilizar os fontes. Desta forma o pessoal já poderia iniciar os testes. Lembrando que algumas dessas alterações só vão poder ser testadas quando a SEFAZ implementar em seus webservices. Visto que muitas delas se referem a nova versão da NF-e.

Bom dia Isaque, Eu inclui o seu nome por ser um dos administradores. Inclusive eu mandei uma MP para ele não obtive retorno. Enviei hoje um e-mail para o André contendo as units alteradas. As implementações que fiz atende todas as útimas NTs publicadas pela SEFAZ.

Boa noite Augusto, Você consegui corrigir o problema?

Boa noite Neo, Vou verificar.

Boa noite Lúcio, No quadro Componentes de Valor devemos informar os valores que compõe o valor do frete e não a forma e prazo de pagamento. Os dados relacionados a forma de pagamento como data de vencimento e valor de cada parcela, existe um lugar especifico no XML, quanto ao DACTE essas informações não são impressas. Mas você pode alterar o DACTE para que o mesmo imprima esses dados no quadro de observações.

Boa noite a todos, Optei por remover do nome do PDF o código de verificação para ficar compativel ou melhor dizendo padronizado com os demais DANFSEs. Favor atualizar os fontes e realizar os testes.

Boa noite Vinicio, Segundo a NT 2012/003 não diz que você deve gerar um novo XML e enviar para a SEFAZ de origem (Item 6). O item 8.2 deixa claro que ocorre o sincronismo entre o SVC e a SEFAZ de Origem e se tentar enviar para a SEFAZ de Origem o mesmo XML ele vai ser rejeitado. Em resumo temos o seguinte exemplo: CT-e Envio ------ ------- 250 SEFAZ-MG 251 SVC-SP 252 SEFAZ-MG Neste exemplo fica claro que o CT-e de numero 251 enviado para o SVC-SP não é enviado novamente para a SEFAZ-MG e a numeração permanece sequencial, independente para qual SEFAZ ele é enviado (Origem ou Vitual de Contingênci).

Boa noite Marcio, Precisamos saber com certeza se o provedor de Assis-SP realmente é GovBR ou não, antes de incluir.

Boa noite a todos, O componente ACBrNFe já esta preparado com todas as alterações referentes as últimas NTs. Até o final desta semana posso disponibilizar desde que o André, Daniel, Isaque me autorizem.

Boa noite Marcel, A empresa (emitente) esta cadastrado no provedor para poder emitir a NFS-e?