windsoft

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

Juliana. Eu já relatei aqui algumas vezes mas não foi resolvido então estou trabalhando com uma versão própria. Me parece que nesta última versão está quase correto porém no arquivo de remessa deve ser enviado o campo nosso número com digito e no repositório está enviando sem o dígito.

Que eu saiba não há como, se conseguir alguma resposta também tenho interesse no assunto. Abraço e boa sorte.

Show misterious Mr @BigWings

Engraçado que o XML que tenho de exemplo é emitido pelo mesmo ERP (MasterSGi) 35191003339301000132550000000090661001001400-nfe.xml

Percebo que alguns softwares utilizam por padrão a macação CDATA em todos os campos texto para permitir utilizar acentuação. Também estamos tendo problemas em relação à isso.

Olá bom dia! Nós estamos utilizando o banco Safra em produção, porém tivemos que ajustar os fontes do ACBr. Anteriormente utilizávamos o SafraBradesco, mas o banco deixou de emitir boletos utilizando banco correspondente depois que os boletos passaram a poder ser pagos em qualquer banco mesmo após o vencimento. Caso alguém necessite, segue a unit que estamos usando em produção. ACBrBancoSafra.pas

Olá José, neste caso que estamos falando, não se trata de cobrança BRADESCO ou ITAÚ, o SAFRA não utiliza mais bancos correspondentes porque agora as cobranças podem ser pagas em qualquer banco mesmo após o vencimento. Também utilizei SAFRA com ITAÚ no passado, mas este é o novo LAYOUT deles, sem utilização de bancos correspondentes.

Olá @José M. S. Junior boa tarde! Após atualizar meus fontes, os boletos do banco SAFRA passaram a ser recusados pelo banco. Observei que nos ajustes feitos acima foi removido o dígito verificador do nosso número da linha digitável do Boleto. Observar os arquivos anexos: ANTES (antes da ultima alteração no ACBr) e DEPOIS (depois da sua ultima alteração) Fiz o ajuste novamente para incluir o dígito verificador e o boleto voltou a ser validado conforme esperado. Segue também a unit corrigida para ser disponibilizada aos demais usuários. ANTES DEPOIS ACBrBancoSafra.pas

Olá Marcio, não tentei resolver o problema ainda. No meu caso como os CTes não são impressos em lote, não estou tendo problemas. Se você não conseguir resolver, faça a assinatura do ACBr SAC e peça para eles ajustarem.

Segue anexo o arquivo corrigido. 14180 - DACTE.fr3

Olá @BigWings acredito que a forma com que o relatório foi desenvolvido + a utilização do double pass está causando diversos problemas. basta você pegar a versão que está no repositório e imprimir este xml que eu anexei, com e sem double pass que vc já vai conseguir entender o problema. Quanto à marca d’água não concordo que atrapalha a visualização. Da forma que está nem faz muito sentido ter marca d’água já que não da pra ler o que está escrito nela. amanhã anexo o arquivo .fr3 pois não estou mais na empresa. Obrigado pela atenção.

Olá Amigos boa tarde! Após a atualização para a versão 3.0 do CTe com o QRCode, a impressão do DACTE com FASTREPORT ficou com problemas. Observei no LOG que houve uma tentativa de correção da impressão do número de páginas do CTe que pode ter causado o problema já que foi habilitada a opção "DoublePass" na sessão "Engine" do FastReport. Fiz as correções na impressão mas tive que desabilitar a DoublePass, não sei se isso pode impactar em algum outro cenário, no meu caso ficou tudo ok. Correções: Marca d'água na impressão do FAST "comida" Falta da sessão Remetente/Destinatário quando o DACTe tem mais de uma página. Impressão do número de pagina/total de páginas. Exemplo de impressão antes da correção: Exemplo de impressão após a correção: Segue anexo também o XML utilizado nesta impressão. exemplo-cte.xml

Fiz um teste aqui com os valores que você citou e não tive problemas. O resultado foi 60,20 mesmo. Segue o teste que fiz pra vc dar uma olhada.

Aparentemtente está errado mesmo. Veja a norma ABNT:

Eu resolvi este problema utilizando open ssl da seguinte forma: Utilizei o aplicativo "InstaladorValid" da VALID certificadora para instalar o certificado em minha máquina (Capicom). http://www.validcertificadora.com.br/upload/downloads/validcertificadora.exe Exportei uma nova cópia do certificado Utilizei a nova cópia com openssl e voila! PS: é o mesmo procedimento citado neste post:

Neste caso fica negativo mesmo já que a alíquota interna do estado é inferior à alíquota interestadual. Nestes raros casos. Se eu não estiver enganado, você usa a alíquota maior pra fazer o cálculo do crédito do ICMS também ou é o inverso disso, usa a menor , precisa confirmar. O ideal é você ter alguma assessoria fiscal ou contratar Sites como o econet.com.br que faz simulação de cálculos.

Veja o problema não estava no arquivo de remessa mas sim na geracao da linha digitavel e código de barras do boleto. Eu entendo que a agência possui 5 digitos porque são 4 dígitos da agência + DV, pois se você colocar 5 dígitos na agencia, no layout do boleto será exibido com 6 já que no layout entra também o DV.

Bom dia! Estou utilizando o manual fornecido neste link pelo banco. https://www.safra.com.br/pessoa-juridica/cash-management-servicos/layout-de-arquivos.htm

Olá pessoal bom dia! Finalizamos a homologação junto ao banco Safra no layout CNAB400 com sucesso na sexta feira. As correções que fizemos foram as seguintes: O tamanho da agencia são 4 dígitos ao invés de 5 (isso estava fazendo a linha digitavel e o código de barras do boleto ser gerada incorretamente) A densidade de gravação do arquivo 01600 No campo "Uso exclusivo da empresa" não estava sendo informado o "SeuNumero" assim como acontece com os demais bancos No campo "Identificação do titulo na empresa" 10 posições, estava sendo informado "SeuNumero" o correto é informar "NumeroDocumento" Obrigado @Thales E. B. Oliveira, @Juliana Tamizou e @José M. S. Junior ACBrBancoSafra.pas

Olá Thales, as alterações que você sugeriu neste último post de 01/08 não são compatíveis com as versões anteriores do Delphi (como Delphi 7 por exemplo). Nós também estamos homologando o banco safra em 400 posições. Já fizemos alguns ajustes para geração correta do boleto (como o tamanho do campo 'Agencia' que no seu código está com 5 mas o correto seriam 4 posições. Assim que eu receber o OK do banco eu posto aqui o arquivo com as alterações e você também dá uma olhada. Abraço e obrigado pela contribuição.

Olá boa tarde! Esta contribuição já está nos fontes? Atenciosamente,