JoaoPauloRicardo

se está a validar o grupo de difal para documento 65 será melhor pedires esclarecimento junto da sefaz respetiva, indicando o problema que eles não virão, com todo o respeito, claro

NFC nao tem calculo de difal, logo nao tem FCP

dimas acho que a pergunta q todos temos de fazer é como alguém consegue desenvolver uma aplicação de respeito quando nem os próprios estados respeitam as regras impostas pela federação e impõem as suas, muitas das vezes em completa contradição das existentes. assim fica dificil com tanta duvida que surge e o tempo não pára... desculpem lah o desabafo

mais informações em http://blog.inventti.com.br/2011/11/08/revogada-implantacao-de-registro-de-saidas-da-nf-e/ por outras palavras é obrigatorio (infelizmente) a data de saida no xml, a falta dele pode implicar multa assim como se parte do principio que a data de saida é a data de emissao

tchuck pah se o caminho que estás a seguir para resolver o teu problema é o de reinstalar tudo entao espero que não tenhas te esquecido também de remover tudo antes dessa operação (apagaracbr.bat) depois quando voltar a dar o erro de novo não culpes o acbr, ok? abre o form que contem o objecto o ignora os erros todos. salva. volta a abrir... e pronto

curiosamente foi SP que me fez questionar este ponto pois tem legislação especificamente para ele, algo que os outros estados nem detalham.

resta a pergunta de qual trunk carregaste o acbr....

na pasta \acbr\Exemplos\ACBrDFe\ACBrNFe podes encontrar exemplos de como desenvolver. sempre lembrando que são exemplos que devem ser adequados para cada situação e que compete ás aplicações o controle absoluto dos dados (SEFAZ não guarda nada por muito tempo)

esse é o ponto que tenho estado a tentar esclarecer faz um tempo, unica conclusão que cheguei até ao momento é que o falta o sair NT para cobrir esse ponto (mais uma alteração na NT2015.003 provavelmente) pois grande parte concorda que a interpretação é essa.

tenta o mesmo xml, mas troca Ide.idDest = doInterna, mantendo o resto dos dados

o problema é interpretação mesmo regys, nosso consultor diz que se a venda é presencial, para consumidor final que não mora no mesmo estado entao: se a mercadoria é levada pelo proprio não se calcula o difal se a loja entrega entao o difal é calculado os proprio estados estados a reforçar este ponto com decretos (foi SP que me chamou a a tenção a este ponto).

fazendo aqui uma ressalva, e desde já pedindo desculpas pela ignorância, segue link para consulta http://www.afrac.org.br/wp-content/uploads/2015/03/Parecer-sobre-a-Carta-Fianca-Atualizado.pdf aparentemente existem estados que obrigam software houses a se responsabilizarem solidariamente por danos provocados pelos seus clientes, especificamente relacionado com aplicações PAF-ECF

regys o ponto de discussao que eu sempre tive foi relativamente á vendas presenciais de consumidor final, para a NFe, sendo que nunca tive uma posição certa acerca de como tratar o xml quando o cliente é de outro estado. no meu ponto de vista podemos ter 3 situações distintas, lembrando que teremos sempre o endereço do cliente para um estado distinto da compra: mercadoria é consumida no proprio estado onde compra mercadoria é com entrega pela loja mercadoria é levada pelo cliente

Nosso consultor diz o mesmo, contudo esse ponto cabe a cada estado legislar, deste modo criei parâmetro para que o usuário determine se o estado dele tem esse comportamento.

Acho que é simplista demais afirmar que a software house tem sempre culpa nas M**** do usuário. cada caso é cada caso e isso tem sempre relevância no foro judicial. Uma coisa é o software permitir a criação e controle de uma caixa 2 (ilegal), outra é um sistema regular de documentos onde a configuração é da responsabilidade do usuário, afinal podemos ter documentos internos que não geram movimentação fiscal. Por esse raciocínio não tarda cabe a toda a software house a responsabilidade se o usuário também usa o software sequer, afinal se ele comprou o mesmo e está a sonegar é porque o software deixa... isso é de lokos

pah a solução está á vista, envia o respetivo NCM para a sefaz que o rejeita e reclama para eles atualizarem a sua tabela NCM (mas sê gentil e não os chames de incompetentes)

muda para o trunk2, esse ja não tem mais manutenção

tens razão, o problema está perante os estados não cumprirem (todos kerem $$), pelo que percebi da leitura das regras do difal grande parte somente começa a ser imposta a partir de 1/7/2016 em produção. O problema é q nas suas muitas regras tem elementos que são validados a partir de 1/1/2016 e outros a partir de 1/7/2016 (Ex: NA13-10, ). O próprio grupo de totais não tem excepção quanto á data

regys, creio que não está a validar os valores, mas valida a presença da tag

obrigatório também

pah, não tentes fazer o trabalho todo, deixa alguma coisa para o utilizador, assim a responsabilidade cai nele. cria a possibilidade de configurar os valores de fcp para cada estado, de associar os mesmos aos produtos, depois quando fores emitir o movimento ou criar o xml da nfe basta ir buscar esses dados.

no debug da app a chave está conforme a que usas para ver no site?

estão a fazer a consulta somente pela chave ou com o xml carregado no objecto?

fizemos isso. infelizmente não funcionou

estamos num impasse e gostaria de saber se algum já passou pelo mesmo e como resolveu, se possível. efetuamos o upgrade do firebird de 2.0 para 2.5 e apesar de conseguir aceder ás tabelas, pelo ibexpert, quando corremos a aplicação dá o erro todas as soluçoes que pesquisamos na net não resultaram. o erro persiste desde ja agradeço qualquer ajuda