Wess

Simples Nacional - CSOSN 102 destacando a BC ICMS e Valor ICMS no total? Estranho, pelo que vejo não é uma operação tratada dessa forma, mas além disso, o real problema, nas tags: - <ICMS> - <ICMSSN102> <orig>0</orig> <CSOSN>102</CSOSN> ------> Veja que não há valor declarado </ICMSSN102> </ICMS> Mas mesmo assim nos totalizadores foi informado, causando a rejeição. - <total> - <ICMSTot> <vBC>1750.00</vBC> < ---------- aqui <vICMS>32.55</vICMS> < ------- e aqui <vICMSDeson>0.00</vICMSDeson> <vFCPUFDest>0.00</vFCPUFDest> <vBCST>0.00</vBCST> <vST>0.00</vST> <vProd>1750.00</vProd> <vFrete>0.00</vFrete> <vSeg>0.00</vSeg> <vDesc>0.00</vDesc> <vII>0.00</vII> <vIPI>0.00</vIPI> <vPIS>0.00</vPIS> <vCOFINS>0.00</vCOFINS> <vOutro>0.00</vOutro> <vNF>1750.00</vNF> </ICMSTot> </total>

Mesma coisa com alguns clientes meus, foi apenas gerar um novo CSC que foi resolvido o problema, e o contador ainda insistia que não devia ser gerado um novo código...

Bom dia meu amigo, a primeira coisa que deve pensar é em fornecer uma tela intuitiva e bem estruturada para evitar dores de cabeça, mas fora isso não tem muito segredo, para desenvolver o módulo de emissão NFC-e você precisará basicamente dar uma conferida nos manuais desse link : Lista de Manuais, assim como o Exemplo do ACBr para entender como funciona a questão de envio da nota, alimentação das tags e etc. Em suma, o Manual de Orientação vai te fornecer todas as informações necessárias,sendo que a base é a mesma pro Brasil inteiro, vez ou outra algum UF decide "perfumar" a emissão fazendo algumas mudanças, mas nunca é nada alarmante, então não há com o que se preocupar no que diz respeito à diferenças de uma UF para outra, sua única preocupação é fornecer uma solução atrativa e planejada ao seu cliente. Boa sorte.

Boa tarde, basta mudar o valor da tag pICMSInterPart para 60, lembrando também de realizar os cálculos em cima da vICMSUFDest e vICMSUFRemet com os percentuais alterados, o que antes era 60 passa a ser 40 e o que antes era 40 passa a ser 60, fazendo isso provavelmente a nota será emitida com sucesso.

Como citado pelo nosso colega BigWings, após atualizar os Schemas(pode encontrar no SVN), é só seguir as regras da imagem abaixo; Pode encontrar mais informações aqui também: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=1MUP2q/QTuQ=

Falha minha também na digitação, o necessário é o "pICMSInterPart", que é aquele esquema do DIFAL onde parte do imposto fica no estado origem e outra parte no estado destino, de forma que a tag devemos alimentar com o percentual do UF Destino, até o final do ano será alimentada com 40%, mudando ano após ano até o valor inteiro ficar para o UF Destino, vide tabela: Provavelmente só deve estar faltando essa tag, tente debugar o projeto mais a fundo para ter certeza de que o valor está chegando correto até a hora da geração. Informe-nos do resultado.

Boa tarde amigo, não há muitos segredos para gerar esse grupo, basicamente, terá que alimentar as propriedades dentro de "Imposto.ICMS.ICMSUFDest", na verdade, a única realmente necessária para que seja feita a geração é a pICMSInter, como pode ver no trecho abaixo: procedure TNFeW.GerarDetImposto(const i: Integer); begin Gerador.wGrupo('imposto', 'M01'); ... ... ... if nfe.Det[i].Imposto.ICMSUFDest.pICMSInterPart > 0 then (**)GerarDetImpostoICMSUFDest(i); ... end; Lembrando, é claro, que além disso deve cuidar os valores que passa para "ide.idDest", "ide.indFinal", "Dest.indIEDest", além de "ide.indPres", que deve indicar algo diferente de presencial, segue um exemplo de XML gerado no meu sistema, que validou sem problema algum. Boa sorte. 421611XXXXXXXXXXXXXX550080000008601000008602-nfe.xml

Certo, agradeço pela posição e orientação, analisarei possíveis mudanças no meu código para adequar a essas situações. Realmente estava baseando apenas nas necessidades dos clientes, não havia encontrado nada relacionado a isso.

Bom dia colegas, compreendo que o post já de uma data um pouco antiga, entretanto preferi responder ao mesmo para não ter que criar outro com o mesmo assunto. Recentemente estive enfrentando o mesmo problema de arredondamento, porém com restaurantes, onde é comum encontrar pratos pesados na hora, consequentemente, com a quantidade de 3 casas decimais, enfim, toda nota enviada com valor de acréscimo ou desconto apresentava o erro listado acima. Resolvi analisar um pouco mais a fundo, tendo em vista que havia alimentado a propriedade Prod.indRegra de forma que truncasse de acordo com a configuração escolhida no sistema, e encontrei esse trecho na unit pcnCFeW.pas: procedure TCFeW.GerarDetProd(const i: integer); var DecQtd: TpcnTipoCampo; begin if CFe.Det[i].Prod.EhCombustivel then begin DecQtd := tcDe3; CFe.Det[i].Prod.indRegra := irTruncamento; end else begin DecQtd := tcDe2; CFe.Det[i].Prod.indRegra := irArredondamento; end; Gostaria de solicitar a análise para retirada desse trecho do "else begin", mais especificamente CFe.Det.Prod.indRegra := irArredondamento, para que fique a critério do desenvolvedor escolher o arredondamento ou truncamento de acordo com a necessidade, deixando obrigatório o truncamento apenas para combustíveis, como é atualmente. Acredito que auxiliaria vários colegas baseado na quantidade de posts que encontrei com situações similares.