JoaoPauloRicardo

convêm salientar que esta alteração é somente para o TRUNK 1, pois o cest ja foi implementado no T2 faz um bom tempo.

situação é que o cliente não utiliza NCe, somente NFe. o problema que coloquei é que a própria legislação (emitida pelos estados) diz que movimentos interestaduais são tratados como internos, desde que a compra seja presencial e o mesmo levante a mercadoria (pela leitura da legislação do nosso consultor), em contradição ao texto da NT2015.00.

concordo alexandre, mas como ficaria o xml nesse caso? visto termos uma venda entre estados (o endereço do cliente seria outro estado), poderia supor ser interestadual e sendo o consumidor final tudo parece indicar que teria de calcular o difal (isto pelo texto da NT). Confesso que ainda não testei se é possivel emitir una NFe para outro estado, como sendo interna, depois reporto o resultado.

surgiu uma duvida devido a interpretação de um decreto de SP: pela leitura podemos concluir que, apesar de consumidor final de outro estado, não é calculado o difal desde que as mercadorias sejam entregues ao consumidor (operação presencial). posteriormente verifiquei q este pressuposto existe em outros estados também, com texto semelhante ou mais generalizado. será que alguém sabe como ficaria o xml neste caso?

1 ponto essa lei somente tem aplicação a partir de 17/03/2016 (90 dias depois de sua publicação) 2 ponto isso n tem a ver com o componente e sim com a aplicação que deve prever a possibilidade de acrescentar texto, creio que neste caso nas observações. 3 ponto a lei somente fala de notas fiscais, não menciona nota ao consumidor ou cupom, não sei se é relevante mas isso deve ser levado junto a contador/consultor para um parecer (os estabelecimentos em causa costumam emitir nota fiscal somente a pedido explicito do cliente, normalmente empresas envolvidas)

xml := ACBRNFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML; atenção que para imprimir tens de ter o respetivo xml da nfe carregado no objeto tambem

Italo inicialmente pensei seguir uma solução semelhante a sua (o processo mais natural também) contudo preferimos criar um grupo para esse efeito no componente pois assim evita ficar a ler variáveis/tabelas externas ao objeto, ficando todos os elementos estáticos criados no mesmo e somente preocupar com a nota em si. Outro proposito é a possibilidade usar o grupo em outros módulos pois a figura do contador é uma constante usada em mais de um. mas qualquer das soluções é valida claro

outra possibilidade é trocar de sistema.... não existe qualidade sem suporte a sua altura

corrijam-me se estiver errado mas ICMSUFDest.vFCPUFDest não totaliza em ICMSTot.vFCPUFDest ?? sendo que este valor é informativo e não para ser adicionado a qualquer outro tag

n, existe a propriedade para informar a pasta do schema "ACBR.Configuracoes.Arquivos.PathSchemas" creio que n mudou entre as versoes

houve uma alteração nas pastas de schema entre as versoes trunk e trunk2, tomaste isso em consideraçao ao atualizar os mesmos na tua versão?

os cálculos são iguais para para todos, independentemente do gênero de empresa

fiquem alerta para a alteração de alíquotas nos estados (o novo grupo veio complicar tudo mesmo) http://www.atualizaconsulta.com.br/legislacao-federal/novas-aliquotas-de-icms-para-2016

opa, desculpa lah... confusão minha mesmo.

Cantu pah surgiu a necessidade deste gênero de validação exatamente para permitir criar o grupo com valores a zero, mas mesmo assim existir um modo de somente criar caso o programador o faça, isto é, pelo preenchimento obrigatório da tag em causa

a tag pICMSInterPart nao tem nada a ver com valores e sim com a regra do percentual a atribuir ao destino. só pode receber 40/60/80/100, logo se igual a zero (valor por defeito da variavel numerica) é porque o grupo não está a ser usado sequer. deste modo temos uma validação simples que em nada interfere com a validação mais complexa que são as regras do negocio e que (infelizmente) mudam ao sabor dos ventos.. e dos mares..e sei lá o que mais. regras essas que cabe o programador implementar na respectiva aplicação

tens de consultar a lei a que se refere a fcp para mais detalhes, ou melhor ainda, consultar o contador pois cabe a ele a leitura da legislação

atenção que essa grelha somente serve como guia de orientação, isto porque o fcp é definido por estado e, se assim determinado, somente para alguns produtos (normalmente os supérfluos ou de luxo), sendo que na NFe somente é atribuído o máximo de 2% (alguns estado têm % superior). Nós criamos isso como regra configurável, cabendo ao cliente indicar o valor e quais os produtos/estados onde vai vender.

compreendo a sugestão italo, mas isso não seria codificar as regras de negocio no componente ? se é para validar a presença deste grupo porque não usar a tag pICMSInterPart >0, esta é uma tag que sabemos sempre ser preenchida, mesmo depois de 2019. Deste modo se ela for maior que zero significa que a aplicação preencheu o grupo. como validação fica mais leve e não tranca o componente devido a qualquer "coisa" por parte das entidades "competentes" (seja lá quem for)

sim, o fcp é calculado é parte segundo os novos dados. precisas consultar um contador para confirmar tudo isso. é a pessoa certa para responder. depois podes postar aqui

relativamente a tabela c parece que foi revogada

tenta estes links https://www.outpan.com/ https://www.datakick.org/

sugiro a leitura da NT2015.003 v1.50, tem novos cálculos e esclarece em relação a esse ponto

isque, creio que não compreendeu a minha duvida. Não estou a falar de campos da NFe. São propriedades do próprio componente, preenchidas em determinados momentos. nomeadamente xml, xmlAssinado, xmlOriginal

isaque, li o manual de integração mas lamento não encontrei referencia a nenhuma das propriedades nem direta ou indiretamente, somente as funções principais são descritas em detalhe. para não existir confusão eu fiz a pesquisa pela palavra xml, de modo que certamente encontraria algo se fosse o caso, mas caso esteja errado agradeco qualquer orientação para a página em questão.