Ir para conteúdo
  • Cadastre-se

julioaguilar

Membros
  • Total de ítens

    33
  • Registro em

  • Última visita

  • Days Won

    1

Tudo que julioaguilar postou

  1. O que está ocorrendo é a seguinte situação: Meu cliente é uma empresa optante pelo simples nacional, quando estou gerando o CF-e estou passando como parâmetro em cRegTrib RTSimplesNacional, o acbr está gerando a tributação do ICMS conforme a regra do simples nacional, até ai está tudo certo. Mas após enviar o CF-e, ao utilizar a propriedade AsXMLString para gerar o xml, no parâmetro cRegTrib está RTRegimeNormal. Isso ocorre porque no cadastro de meu cliente no SINTEGRA o regime de apuração está como "NORMAL" e o acbr está usando o retorno do SAT para gerar novamente os tributos ficando divergente o xml emitido ao SAT do retornado. Criei um propriedade que armazena exatamente o xml recebido pelo SAT, não gerando novamente desta forma o retorno fica correto. Obs: Meu cliente já fez a alteração do regime para Simples Nacional e essa alteração vai ser retroativa a data de abertura da empresa, então ele tem que emitir o CF-e como Simples Nacional.
  2. Na emissão de um CF-e de um empresa optante pelo simples nacional está ocorrendo a seguinte inconsistência: Estou atribuindo para o parâmetro "Config.emit_cRegTrib" o valor "RTSimplesNacional", na função EnviarDadosVenda, o xml gerado para envio ao SAT está correto, mas quando pego o xml através do parâmetro "CFe.AsXMLString", o acbr está gerando novamente os dados mas com o parâmetro "Config.emit_cRegTrib" com valor "RTRegimeNormal". O problema é que quando eu salvo o xml retornado está com o cálculo do ICMS baseado em uma empresa de regime normal e não em um simples nacional. O xml enviado para o SAT está certo, o erro ocorre somente ao utilizar o parâmetro "CFe.AsXMLString". Quando defino para o acbr salvar o xml gerado na função "function TACBrSAT.EnviarDadosVenda(dadosVenda : AnsiString) : String ;" está salvando corretamente, pois nesta função o xml salvo é o retornado pelo SAT. Está até setando no parâmetro CFe.AsXMLString o retorno, mas quanto tento utilizar está carregando novamente os dados. Exemplo do código: ... dmCupom.ACBrSAT.EnviarDadosVenda; ... (* Neste ponto está gerando o xml novamente como RTRegimeNormal *) qryLancamentoVenda.ParamByName('DS_ARQUIVOXML').AsAnsiString := dmCupom.ACBrSAT.CFe.AsXMLString; ...
  3. Segue o arquivo em anexo pcnCFeW.zip
  4. 1º Erro - CST 49 Na emissão do CF-e com o CST 49 no PIS/COFINS, o projeto acbr está gerando o xml com a tag PISOutr e COFINSOutr quando de acordo com o leiaute o correto seria gerar as tags PISSN e COFINSSN somente com o campo CST. ( Manual de Especificações Técnica de Requistos - SAT Paginas: 77/81 ). Unit: pcnCFeW Procedimentos: procedure TCFeW.GerarDetImpostoPIS(const i: integer); procedure TCFeW.GerarDetImpostoCOFINS(const i: integer); Está tratando o CST 49 da mesma forma que os códigos 50, 51, 52, 53, 54, 55, 56, 60, 61, 62, 63, 64, 65, 66, 67, 70, 71, 72, 73, 74, 75, 98 e 99. else if CFe.Det.Imposto.PIS.CST in [pis49, pis50, pis51, pis52, pis53, pis54, pis55, pis56, pis60, pis61, pis62, pis63, pis64, pis65, pis66, pis67, pis70, pis71, pis72, pis73, pis74, pis75, pis98, pis99] then else if CFe.Det.Imposto.COFINS.CST in [cof49, cof50, cof51, cof52, cof53, cof54, cof55, cof56, cof60, cof61, cof62, cof63, cof64, cof65, cof66, cof67, cof70, cof71, cof72, cof73, cof74, cof75, cof98, cof99] then Sugestão de correção: (* PIS *) else if CFe.Det.Imposto.PIS.CST = pis49 then begin Gerador.wGrupo('PISSN', 'Q05'); Gerador.wCampo(tcStr, 'Q07', 'CST ', 02, 02, 1, CSTPISTOStr(CFe.Det.Imposto.PIS.CST), DSC_CST); Gerador.wGrupo('/PISSN'); end else if CFe.Det.Imposto.PIS.CST in [pis50, pis51, pis52, pis53, pis54, pis55, pis56, pis60, pis61, pis62, pis63, pis64, pis65, pis66, pis67, pis70, pis71, pis72, pis73, pis74, pis75, pis98, pis99] then (* COFINS *) else if CFe.Det.Imposto.COFINS.CST = cof49 then begin Gerador.wGrupo('COFINSSN', 'S05'); Gerador.wCampo(tcStr, 'S07', 'CST ', 02, 02, 1, CSTCOFINSTOStr(CFe.Det.Imposto.COFINS.CST), DSC_CST); Gerador.wGrupo('/COFINSSN'); end else if CFe.Det.Imposto.COFINS.CST in [cof50, cof51, cof52, cof53, cof54, cof55, cof56, cof60, cof61, cof62, cof63, cof64, cof65, cof66, cof67, cof70, cof71, cof72, cof73, cof74, cof75, cof98, cof99] then 2º Erro - CST 99 Na emissão do CF-e com o CST 99 no PIS, o projeto acbr não está gerando a tag pPIS diferente do COFINS que está gerando corretamente, ocorrendo um erro no envio do xml ao SAT. Procedimentos: procedure TCFeW.GerarDetImpostoPIS(const i: integer); No parametro "ocorrencias" deve ser informado o valor 1 para gerar a tag mesmo se o valor for 0 (zero). errado: Gerador.wCampo(tcDe4, 'Q12', 'vAliqProd', 01, 15, 0, CFe.Det.Imposto.PIS.vAliqProd, DSC_VALIQPROD); certo: Gerador.wCampo(tcDe4, 'Q12', 'vAliqProd', 01, 15, 1, CFe.Det.Imposto.PIS.vAliqProd, DSC_VALIQPROD); a mesma alteração deve ser feita nos campos: CST, qBCProd, vAliqProd e vBC.
  5. Daniel Simões, realizei os testes e deu certo, muito obrigado.
  6. Está ocorrendo o mesmo problema comigo, estou passando o valor com duas casas decimais e na regra estou passando como arredondamento, e mesmo assim está mostrando “Operação com combustíveis”. Verifiquei que no arquivo pcnCFeW no procedimento “procedure TCFeW.GerarDetProd(const i: integer);”, quando gera o campo “vUnCom” no parâmetro “TpcnTipoCampo” está mandando “tcDe3”, por isso quando gera o xml está gerando com três casas decimais. Gerador.wCampo(tcDe3, 'I09 ', 'vUnCom ', 00, 21, 1, CFe.Det.Prod.vUnCom, DSC_VUNCOM); Gostaria de saber se existe algum parâmetro para gerar com duas casas decimais, ou se estou gerando o CF-e errado.
  7. julioaguilar

    Pmvast

    Luis Fernando tive o mesmo problema que você. Fiz um teste enviando para o ambiente do SEFAZ-SP o percentual de 140,0000 e a nota foi aceita. Vocês estão entendendo que o tamanho máximo do campo pMVAST é de 5 posições, mas o Web Service está aceitando com 7 posições, que foi o meu entendimento (3V2-4 - 3 posições, virgula de 2 a 4 posições) Fiz a correção na mesma função que você alterou, mas passei a considerar o campo com tamanho máximo de 7 posições Função original: Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N19', 'pMVAST ', 01, IIf(Usar_tcDe4,06,05), 0, nfe.Det.Imposto.ICMS.pMVAST, DSC_PMVAST); Função alterada: Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N19', 'pMVAST ', 01, IIf(Usar_tcDe4,07,05), 0, nfe.Det.Imposto.ICMS.pMVAST, DSC_PMVAST); Não sei qual das soluções seria a correta, gostaria de saber a opinião dos membros do ACBr
  8. Régys, realizando alguns testes eu me deparei com a mesma inconsistência do horuss (pMVAST maior que máximo permitido). Está ocorrendo a seguinte situação: Estou gerando o xml da NF-e na versão 3.1, e no campo pMVAST estou passando o valor de 140,00. Verificando nos fontes percebi que na procedure Gerador.wCampo quando a versão é 3.1 ou superior, é passado como parâmetro, para gerar 4 casas decimais e como tamanho máximo 6, quando o correto seria 7, já que segundo Nota Técnica 2013/005 o tamanho do campo pode ser “3v2-4” (140,0000). Repositório: Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N19', 'pMVAST ', 01, IIf(Usar_tcDe4,06,05), 0, nfe.Det.Imposto.ICMS.pMVAST, DSC_PMVAST); Alterada: Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N19', 'pMVAST ', 01, IIf(Usar_tcDe4,07,05), 0, nfe.Det.Imposto.ICMS.pMVAST, DSC_PMVAST); Gostaria de saber se realmente existe esta inconsistência, ou se estou utilizando o procedimento de forma errada.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...