Painel de líderes

Bom dia, Esse erro é devido os valore estarem sendo calculados sem arredondar. Vamos pegar de exemplo o primeiro item: Base de cálculo: 114,75 % de ICMS: 18% vICMSOp = 114,75 * 18% = 20,655. Arredondando: 20,66 Diferimento: 33,333% vICMSDif = 20,66 * 33,333% = 6,8865978. Arredondando: 6,89 vICMS = vICMSOp - vICMSDif vICMS = 20,66 - 6,89 = 13,77 Neste exemplo, o erro no XML está no valor da tag <vICMSDIF> que está levando 6,88 O restante dos itens do XML ocorre o mesmo problema. Ajustando o calculo utilizando os valores arredondados, o XML é validado. Segue em anexo o ajuste dos valores no seu XML. Teste_ajustado.xml

está nos planos mas não fiz!

Pessoal boa tarde. Estive lendo o post, e não pude deixar de comentar. Ao abrir o xml postado e vendo a questão do Diferimento, é importante ressaltar o seguinte: Diferimento, o que é? Trata-se de uma modalidade de tributação a ser exercida em um momento posterior, ou seja, não é que o referido imposto não vai ser pago, mas sim, será pago em um outro momento futuro. Quando usar a CST51. Essa tag, é utilizada para a saída de mercadorias do estabelecimento industrial para ser beneficiada, etc. Contudo, cada unidade da federação possui um decreto que regulamenta o ICMS, no caso em questão, do RS, o RICMS local estabelece o seguinte: “Art. 1º-E - Difere-se para a etapa posterior o pagamento da parte do imposto devido que exceda 12% (doze por cento) do valor da operação, nas saídas internas, de estabelecimento industrial, de mercadorias destinadas à industrialização por estabelecimento cujo CAE principal esteja relacionado no Apêndice XLIII” Portanto, não se trata da redução da base de cálculo, trata-se da não incidência do imposto que exceda 12%, portanto, a redução deverá ser na alíquota modal ou seja, 18% menos a alíquota interestadual, ficando (18-12) = 4%, assim sendo o imposto a ser destacado será 12% e o imposto diferido será 4%. No referido caso, R$ 1.000,00 aplica-se 12% = R$ 120,00 e 6% sobre R$ 1000,00 = R$ 60,00. Desse modo, o item 1 ficaria: ( 114,75 * 12 ) / 100 = R$ 13,77 (114,75 * 6 ) /100 = 6,885 Nesse linear, então as tags devem estar assim: vBC = 114,75 pICMS= 18 vICMSOp = 6,885 pDif = 6 vICMSDif = 6,885 vICMS = 13,77 A meu ver, a sua tag pDIf está sendo informada equivocadamente.

Saudações a todos ! Tive que fazer uma ECD retificadora em um cliente pois de 2014 para 2015 ele mudou todos os códigos das contas e os saldos foram colocados diretamente no saldo inicial das contas sem que fossem feitos lançamentos para transferências destes saldos. Então como descrito no manual da ECD se tornaria necessário informar os códigos das contas antigas que estavam sendo substituídas no registro I157. Quando fui criar estes registros notei que não havia ainda sido implementado no ACBrSpedContabil. Então com meu pouco conhecimento em Delphi e lógico me baseando nos registros que já estavam sendo gerados consegui implementar o registro I157 e funcionou perfeitamente para mim. Então gostaria de disponibilizar esta implementação para os administradores do projeto para que se acharem por bem acrescentar ao projeto. Está anexado a este e se precisar de alguma coisa estou a disposição. Grande abraço a todos ! Registro_I157.zip

Entrei em contato novamente com o banco, recebi outro manual, este detalha as informações. Agora é ajustar o código, obrigado Juliana.

Boa tarde. Cada banco tem suas próprias regras para montagem do código de barras. Se no caso do Banco da Amazonia estas informações são necessárias, basta fazer a alteração para atender as regras do mesmo. Att.

Boa tarde está no svn e implementação! Obrigado

Perfeito. Mas uma vez obrigado.

obrigado pela atenção.

Bom dia. Agora você deve somente aguardar. Att.

Bom dia, Vamos comparar as duas chaves: 33160702620499000165650030000026291000026299 33940702620499000165650030000026291000026290 O que esta diferente? O Ano e Mês de emissão ( 94 07 ) e o digito verificador ( 0 ). Se corrigir o Ano e Mês, o digito verificador vai ser corrigido automaticamente uma vez que é o procedimento que o calcula. Tente fazer fazer da seguinte forma: GerarChave(chave, 33, 2629, 65, 3, 2629, 1, StrToDate('18-07-2016'), '02620499000165') ou GerarChave(chave, 33, 2629, 65, 3, 2629, 1, StrToDate('18/07/2016'), '02620499000165')

Oi @Ricardo Miquinioty , desculpa, informei errado, pensei que o meu funcionario tivesse atualizado ontem o único dimep que temos tb, mas não atualizou não. Só atualizamos os Elgin mesmo.

Olá bom dia, ao realizar a leitura do arquivo de retorno do Banco Santander tive o seguinte problema: A Agencia do banco estava pegando do arquivo já com o digito, e para criar o objeto do ACBr boleto eu estava passando a Agencia na propriedade agencia e o digito na propriedade AgenciaDigito. Ao constatar que a classe do ACBr boleto zera a esquerda 4 dígitos na Agencia e ao ler o arquivo ele estava pegando com o digito da agencia esses números não batiam constando que a agencia do arquivo estava errada. Mudei para pegar somente a agencia do arquivo e zerá-lo a esquerda da mesma forma que é feita na classe do ACBr. Espero poder ajudar, obrigado pela excelente ferramenta. ACBrBancoSantander.pas

Oi amigos, Eu criei uma rotina chamada gravacedente sempre antes de gerar o boleto ou a remessa e funciona perfeitamente. Segue exemplo do código: procedure TDM1.GravaCedenteCobranca(CodCarteira: integer); begin // Grava Configurações do Cedente e Cobrança ACBrBoleto1.ListadeBoletos.Clear; DM1.TB03600.Refresh; DM1.TB03600.Locate('CONTROLE', CodCarteira, []); with ACBrBoleto1 do begin case DM1.TB03600BANCO.Value of 1: Banco.TipoCobranca := cobBancoDoBrasil; 104: Banco.TipoCobranca := cobCaixaEconomica; 237: Banco.TipoCobranca := cobBradesco; 341: Banco.TipoCobranca := cobItau; 756: begin Banco.TipoCobranca := cobBancoob; Cedente.Modalidade := '01'; end; end; Cedente.Agencia := DM1.TB03600AGENCIA.Value; Cedente.AgenciaDigito := ' '; if DM1.TB03600DIGAGENCIA.Value <> '' then Cedente.AgenciaDigito := DM1.TB03600DIGAGENCIA.Value; Cedente.Conta := DM1.TB03600CONTA.Value; Cedente.ContaDigito := DM1.TB03600DIGCONTA.Value; Cedente.Nome := DM1.TB03600NOMECEDENTE.Value; Cedente.Logradouro := DM1.TB03600ENDCEDENTE.Value; Cedente.NumeroRes := DM1.TB03600ENDNUMCEDENTE.Value; Cedente.Cidade := DM1.TB03600CIDADECEDENTE.Value; Cedente.Bairro := DM1.TB03600BAIRROCEDENTE.Value; Cedente.UF := DM1.TB03600UFCEDENTE.Value; Cedente.CEP := DM1.TB03600CEPCEDENTE.Value; if Length(FRC_Funcoes.DesformataCNPJ_CPF(DM1.TB03600CPFCEDENTE.Value)) = 11 then Cedente.TipoInscricao := pFisica else if Length(FRC_Funcoes.DesformataCNPJ_CPF(DM1.TB03600CPFCEDENTE.Value)) = 14 then Cedente.TipoInscricao := pJuridica; Cedente.CNPJCPF := FRC_Funcoes.DesformataCNPJ_CPF(DM1.TB03600CPFCEDENTE.Value); Cedente.CodigoCedente := DM1.TB03600CODCEDENTE.Value; Cedente.Convenio := DM1.TB03600CONVENIO.AsString; // Cedente.Modalidade := DM1.TB03600MODALIDADE.Value; ACBrBoletoFC.DirLogo := ExtractFilePath(Application.ExeName) + '\Boleto'; Cedente.ResponEmissao := tbCliEmite; case DM1.TB03600TIPOIMPRESSAO.Value of 1: ACBrBoletoFC.LayOut := lPadrao; 2: ACBrBoletoFC.LayOut := lFatura; 3: ACBrBoletoFC.LayOut := lCarne; 99: Cedente.ResponEmissao := tbBancoEmite; end; Cedente.CaracTitulo := tcSimples; case DM1.TB03600TIPOMOD.Value of 1: Cedente.CaracTitulo := tcSimples; 2: Cedente.CaracTitulo := tcVinculada; 3: Cedente.CaracTitulo := tcCaucionada; 4: Cedente.CaracTitulo := tcDescontada; 5: Cedente.CaracTitulo := tcVendor; end; if DM1.TB03600CNAB.Value = 240 then LayoutRemessa := c240 else LayoutRemessa := c400; end; end;

Você está enviando esta NFE para outra unidade da federação? Caso a resposta seja afirmativa, você terá que informar: 1. No seu caso é substituição tributária pICMSUFDest := // Aliquota externa do estado de destino pICMSInter := // Aliquota interna do estado de origem pICMSInterPart := // Percentual do imposto a ser repartido vBCUFDest := 0; vICMSUFDest := 0; vICMSUFRemet := 0; 2. Como o produto é substituição tributária, deverá informar o CEST 3. O CFOP Aceito é o 6403, e não o 6405 4. Se for empresa optante do Simples nacional, deverá usar CSOSN ao invés de CST.

Nós utilizamos os comandos 312 e 313 que seriam de Pagamento Genérico. - 312: Consulta para Pagamento Desvinculado (Genérico); - 313: Pagamento Desvinculado (Genérico). Basicamente funciona da seguinte forma: - Chama comando 312 (Informa os Documentos a serem pagos); - SiTef retorna valor no TipoCampo 609; - Efetua os pagamentos em seu sistema; - Chama comando 313 informando a Forma de Pagamento utilizada; Dessa forma a parte de pagamento fica desvinculada do SiTef. Esse manual explica detalhadamente como utilizar dessa maneira. Interface Simplificada com a aplicação - Pagamento Genérico.pdf

Nós usamos outro comando @EliasCesar pode me ajudar a lembra... Nesse comando não ocorrem os pagamentos no mesmo fluxo...

Boa tarde, você só muda versaoDadosEnt, os outros campos é o SAT que completa(como figura anexa), no SAT Físico retorna como abaixo: SAT ELGIN em produção: <infCFe versaoSB="010100" versaoDadosEnt="0.07" versao="0.07" Id="CFe35160603703349000188590000324260020990338498"> Sds, Ricardo.

Boa tarde Italo, No meu caso pode acontecer de ser realizado a inutilização de um número e posteriormente por alguma adversidade não consiga gravar essa inutilização. Como você disse uma rara exceção, porém preciso garantir um controle supremo referente a falhas, essa possibilidade dificilmente ira ocorrer, porém existe e preciso tratar caso ocorra. Solução: Em virtude da inexistência de um webservice de consulta referente a inutilização, pode-se contornar essa situação tratando o erro 563 - Já existe pedido de Inutilização com a mesma faixa de inutilização. Caso o número que estamos tentando inutilizar já foi inutilizado, retornar o erro 563, conforme o Carlos Marian menciona anteriormente. Nesse caso temos todas as informações necessárias da inutilização, inclusive o XML completo, porém seria necessário fazer um pequeno ajuste para gerar o XML completo quando o retorno for 563, pois esta gerando apenas quando o retorno for 102 - Inutilização de número homologado. Partindo da seguinte lógica, que após inutilizar uma numeração não tem mais oque fazer com aquele numero, não vejo problemas em gerar o XML quando o número já esta inutilizado. Dessa forma conseguimos contornar essa situação, se tornando assim um meio de consultar as informações de inutilização. Em anexo segue fonte com alteração sugerida. Observação: Aproveitando o gancho, estou mandando juntamente uma alteração para considerar o retorno 155-Cancelamento homologado fora de prazo, referente ao processo de cancelamento. ACBrNFeWebServices.pas