windsoft

Eu enfrento exatamente o mesmo problema já tem algum tempo. Aparentemente é cagada na SEFAZ mesmo. Eu acredito que não há o que fazer nestes casos.

Olá Amigos, encontrei o problema. A função Clear do objet TGNRERecibo estava limpando o número do recibo. Como ela é chamada por herança no InicializarServico do TDFeWebService, o número do recibo era sempre passado em branco na consulta do lote. Segue a Unit corrigida. ACBrGNREWebServices.pas

Pessoal, estou com os fontes atualizados mas pra mim continua acontecendo o mesmo problema. "O valor do campo 'numeroRecibo' está inválido. O valor deve possuir 10 caracteres numéricos" Testei utilizando o DEMO do ACBRGNRe

Olá bom dia! Realmente o cancelamento está funcionando agora, mas ao consultar a NFSe cancelada o status dela vem como srNormal. Vou abrir um novo topico.

Eu fiz os testes aqui, aparentemente está cancelando porém se eu consulto a NF novamente ela me retorna como autorizada e não como cancelada, vou analisar amanhã se o problema é aqui e reporto novamente.

Nos meus testes ocorre o mesmo problema.

Bom dia, eu não vejo relação entre uma coisa e outra. Também gostaria de saber de onde ele tirou essa informação.

Olá @José M. S. Junior me parece que esta correção foi feita de forma indevida, veja se concorda comigo: No manual diz: 24.0 Uso Exclusivo FEBRABAN / CNAB 212 240 29 - Alfanumérico Brancos G004 versão do layout 030, pode ser informado 'CSP' nas posições 223 a 225, e 'zeros' nas posições 226 a 228. Veja que no layout versão 030 deve-se informar 'zeros' nas posições 226 a 228, entendo que o correto seria "000" mas após a correção passou-se a informar 2 espaços e um zero " 0". Eu utilizei o validador online do BB e ambos os arquivos foram validados, tanto antes quanto depois da alteração.

Minha sugestão é que você informe "LeCedenteRetorno=1" e deixe o componente ler do arquivo. Aí compara os dados da conta com os que você está preenchendo, provavelmente você vai encontrar diferença na quantidade de dígitos, por exemplo: Se a agência é 0123 na hora de ler do arquivo o ACBr leu 00123

Ah sim tem razão. Seria realmente outro “componente” se for realmente verdade a informação.

Olá Júlio talvez você não saiba mas o banco central vai incluir uma opção de cobrança no pix que promete “acabar” com os boletos.

Pelo que diz no manual, você deveria informar algo como:] tpMed string 1-20 sim informar o tipo de medida (Exemplos: PESO BRUTO, PESO DECLARADO, PESO CUBADO, PESO AFORADO, PESO AFERIDO, PESO BASE DE CÁLCULO, LITRAGEM, CAIXAS e etc).

Olá Antonio, Este assunto já foi discutido aqui. O que acontece é que alguns sites fazem a consulta publica da NFe utilizando-se apenas da chave de acesso e montam o XML novamente fazendo a leitura dos dados no HTML da consulta publica. Funciona? Sim, porém o XML não tem validade jurídica, pois não tem a assinatura do emitente. Já vi sites que inclusive colocam uma assinatura falsa, ou seja, assinam o XML novamente com outro certificado digital. Dá uma impressão de legalidade mas o arquivo não é válido. Se além desta maneira existir alguma outra forma eu desconheço.

Olá bom dia! Mesmo problema aqui em São José do Rio Preto. Na GINFES dizem que o problema é no ERP mas não dão mais detalhes, pediram o XML do RPS, enviamos pra eles e estamos aguardando retorno.

Olá Daniel, eu havia visto isso, mas por se tratar de um site não oficial não acredito que irá se resolver rapidamente, já faz alguns dias que está com esta mensagem.

Olá bom dia! De uns dias pra cá o rastreamento de objetos dos correios não está funcionando. Pelo que entendi, o componente utiliza a página: https://www.websro.com.br/index.php para fazer o rastreamento porque não consegue mais pegar os dados diretamente do site dos correios, mas a página também não está funcionando. Alguem tem uma solução pra isso? Caso queiram testar utilizem este objeto para rastreio: https://www.websro.com.br/rastreamento-correios.php?P_COD_UNI=PU492271878BR Abraço

Este tópico já foi postado pela equipe em 09/01

Nós nos baseamos apenas no CFOP, talvez exista mas nunca me deparei com esta questão de um produto gerar crédito de ICMS e outro não estando no mesmo CFOP.

Ola Mr @BigWings Realmente eu não tinha me atentado à isso. O problema foi sim resolvido no commit citado. Abraço e obrigado!

Olá Pessoal bom dia! Após a última atualização da Impressao do DANFE fast report com a inclusão das dezenas da nota fiscal premiada para o estado do MS a impressão da continuação dos dados complementares parou de funcionar. Analisando as alterações, percebi que foi copiado e colado o "label" das informações complementares para o campo "dados do fisco" a fim de exibir as informações das dezenas enviadas pelo fisco, porém esqueceram-se de remover a propriedade "FlowTo" que faz com que o texto que não cabe na primeira página do DANFE seja exibido na seção de continuação dos dados adicionais. Segue anexo o DANFE.fr3 corrigido e um arquivo XML para testes. DANFeRetrato_2019.fr3 35200200583099000100550080000004251701706813.xml

Precisa de cpf na nota.

Estamos tendo exatamente o mesmo problema. Não consegui identificar o que acontece. Se você pegar a data hora de emissão de uma nota agora no XML está: <dhEmi>2020-01-24T10:41:28-03:00</dhEmi> No retorno da SEFAZ (abaixo), observe que a data/hora de emissão é 10:41 -03:00 a data/hora de recebimento é 10:46 -03:00, mas o retorno diz que a dara/hora de emissão é posterior ao recebimento. Portanto acredito que se trata de problemas no webservice (homologação) da SEFAZ. Estou testando emissão para o estado de MS <?xml version="1.0" encoding="UTF-8" ?> - <retConsReciNFe versao="4.00" xmlns="http://www.portalfiscal.inf.br/nfe"> <tpAmb>2</tpAmb> <verAplic>SP_NFCE_PL_009_V400</verAplic> <nRec>351000011608029</nRec> <cStat>104</cStat> <xMotivo>Lote processado</xMotivo> <cUF>35</cUF> <dhRecbto>2020-01-24T10:46:32-03:00</dhRecbto> - <protNFe versao="4.00"> - <infProt> <tpAmb>2</tpAmb> <verAplic>SP_NFCE_PL_009_V400</verAplic> <chNFe>35200105832757000165650010000006711700371012</chNFe> <dhRecbto>2020-01-24T10:46:32-03:00</dhRecbto> <cStat>703</cStat> <xMotivo>Rejeição: Data-Hora de Emissão posterior ao horário de recebimento</xMotivo> </infProt> </protNFe> </retConsReciNFe>

Pessoal pode ignorar o ticket, aparentemente era problema na SEFAZ, aguardamos cerca de 2 horas e tentamos transmitir o mesmo CTe e ele foi autorizado.

Olá bom dia! Ao tentar transmitir um CTe com tomador pessoa física fora do estado, estou recebendo a rejeição: Rejeição 208: CNPJ do destinatário inválido Não sei o motivo já que o CPF do destinatário está correto. Alguem está passando pelo mesmo problema no Mato Grosso? Segue o XML do CTe. CTE_XML.xml

Segue o arquivo que estou usando em produção, se quiser usar como base... ACBrBancoSafra.pas