windsoft

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

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.