JeannyPaiva

1 - Verifique a alíquota que esta sendo aplicada, caso o Destinatario seja Contribuinte ou Isento de IE, deve respeitar estas alíquotas informadas na validação 2 - Caso seja venda para consumidor final não contribuinte, onde antes era aplicada a alíquota interna do estado de origem, verifique se a tag indIEDest = 9. (Porém, a partir de 01/01/2016, a aliquota para não contribuinte também terá que ser a interestadual, antes disso não estará validando)

Correção para impressão de eventos. Após carregar a informação, o DataSet estava sendo limpo, com isto a informação não era impressa. Segue unit com a correção. ACBrCTeDACTEFR.pas

Fiz a correção da Unit e dos FR3 no tópico http://www.projetoacbr.com.br/forum/topic/26366-erro-impress%C3%A3o-dacte-fastrport-calculoimposto/ Estou aguardando disponibilizar no svn. Caso queira baixar os fontes/fr3 para ja testar, estão ai,

Atualizei os fontes hoje e tive este mesmo problema. Verifiquei que voltaram o nome errado de um dos DataSets, que antes estava nomeado errado como LocalEntrega, sendo que a informação era referente ao imposto. Pois bem, conferi todos os fr3 da pasta exemplos e notei que alguns ainda faziam referencia ao dataset com nome LocalEntrega. Desta forma abri todos e fiz a correção, assim como na unit para a informação correta. Seguem os arquivos alterados. Fiz o teste de impressão com o formulario de exemplo do ACBr com todos os fr3, e foram impressos sem erros. ACBrCTeDACTEFR.pas DACTE.fr3 DACTE_1_04.fr3 DACTE_1_04-BASIC.fr3 DACTE_1_04-BASIC1.fr3 DACTE_EVENTOS.fr3 DACTE_PAISAGEM.fr3 DACTE2Vias.fr3

Bom dia. Fiz a inclusão das informações do modal aéreo. Já havia o DataSet disponível no componente, porém sem carregar as informações. Segue unit alterada. ACBrCTeDACTEFR.pas

Bom dia. Hoje notei que alguns datasets não estavam sendo limpos, portanto acumulando informação, caso solicitado impressões seguidas. Segue unit corrigida. ACBrCTeDACTEFR.pas

Bom dia. Devido a problemas recorrentes de diferenças de versão, seja de Delphi ou Fast, fiz uma modificação no componente de impressão do DACTe para Fast Report, retirando o DataModule, passando a utilizar apenas as classes, criando os objetos em tempo de execução. Semelhante ao que já é feito com a NFe e NFSe. Desta forma não ocorreria mais problemas ao atualizar os arquivos via SVN com versões do Fast Report diferentes, e sem algumas determinadas propriedades. Enfim, acho que facilita muito a manutenção e atualização. Segue abaixo as units alteradas, e dpr com o ACBrCTeDACTEFRDM removido (seria o caso de excluir esta unit do repositório). Mais algumas alterações/correções * Não estava preenchendo o campo IE do emitente do documento anterior. * Correção também do fr3, quando havia mais de um documento anterior, estava criando nova página apenas com o bloco de reservado ao fisco. * Segue também um fr3 em paisagem que costumo utilizar aqui. ACBrCTeDACTEFR.pas DACTE_1_04.fr3 DACTE_PAISAGEM.fr3 ACBr_CTeDacteFR.dpk

Bom dia. Quando há necessidade de gerar o DACTe de CTe ainda não autorizado (caso do FSDA por exemplo), o arquivo PDF gerado está salvando com nome sem a chave (apenas '-cte'). Segue fonte com a correção. ACBrCTeDACTEFR.pas

Boa tarde. A impressão do Dacte tem o campo para inscrição suframa (tag ISUF) do destinatário, porém a mesma não esta sendo carregada. Inclui a informação no arquivo anexo. Se puderem acrescentar, agradeço. ACBrCTeDACTEFRDM.pas

Boa tarde Kleber. Tente abrir o FR3 e marcar os datasets (Report > Data). Vi alguns relatos também de pessoas que precisaram fazer isto. Acredito seja também diferença de versão do Fast Report.

Creio que os dois estejam certos. Se você comparar, o do Fast esta exatamente como o modelo que consta no MOC da versão 1.00a. Mas desde que estejam todos os campos, respeitando os limites minimos quanto a tamanho de fonte, tamanho do codigo de barras, etc, creio não ter problema quanto a disposição dos campos variar um pouco.

Bom dia. Até o momento o problema com NFe com desconto Suframa permanece.. tanto enviando para os webservices do estado quanto enviando para o SVC-AN. Alguém pode me informar se estão conseguindo emitir NFe com desconto Suframa normalmente? 31140886682093000105550140000026866999966076-nfe.xml

Boa tarde Weslen. A principio notei no seu XML a falta da tag idEstrangeiro e a tag indIEDest deve ser 9 (Não Contribuinte)

Boa tarde darlananogueira Verifique se esta atribuindo corretamente a forma de emissão ao enviar seu XML. ( Ex.: FAcbrNFe.NotasFiscais.Configuracoes.Geral.FormaEmissao := teSVCAN) Ao que parece no retorno anexado, está sendo enviado para MG. (Sugestão, antes de enviar qualquer NFe, sempre troco a FormaEmissao de acordo com a NFe: FAcbrNFe.NotasFiscais.Configuracoes.Geral.FormaEmissao := FAcbrNFe.NotasFiscais.Items.NFe.Ide.tpEmis)

Kiko, bom dia. Realmente se olhar esta validação, meu totalizador está incorreto, cheguei a fazer a testar esta alteração, porém precisarei pesquisar sobre o assunto, pois quando se trata de Suframa, o valor do ICMS já foi abatido quando calculado no campo desconto, logo não posso abate-lo novamente ao totalizar.

Bom dia. Regis, entrei em contato com eles sim. Com MG já estou até "acostumada" no atraso em corrigir esse tipo de validação, o que preocupou mais no entanto é que ocorre o mesmo problema enviando para o ambiente nacional. O retorno deles é referente as instruções aplicadas para NFe 2. Quando retornei a questionar, destacando a informação no manual de que o campo vICMS foi substituído na NFe 3.1 pelo vICMSDeson, e que preencher o campo vICMS não esta de acordo com o manual e schemas da 3.1, eles simplesmente não respondem. Segue resposta da Sefaz:

Segue o XML de resposta 316000000049347-pro-rec.xml

Na verdade a rejeição que está sendo apresentada é : 627 - Rejeicao: O valor do ICMS desonerado deve ser informado Segundo o manual: Se informado tag:motDesICMS, o vICMSDeson (id:N27a) deve ser maior que zero (NT 2011/004). E esta sendo informado corretamente o valor. A rejeição ocorre tanto no envio para MG, quando para o SVC-AN 31140786682093000105550140000026546999966699-nfe.xml

Também estou com este problema. Alguém conseguiu alguma solução? A resposta da Sefaz é a NT antiga, onde a tag vICMS deve ser informada, porém essa instrução está em desacordo com a NFe 3.10

Boa tarde. De acordo com a NT 2014/003, foi incluído o bloco de informações da Composição da Carga, que deve ser impressa quando o MDFe for emitido em contingência. Incluí as informações da identificação da unidade de transporte e carga, e criei um novo modelo fr3, caso queiram utilizar este ou adaptar os outros. ACBrMDFeDAMDFEFRDM.pas DAMDFe_Contingencia.zip

Boa tarde Italo. No caso o fiscal alega que não pode ter mais de 1 CTe. Foram emitidos 2 CTes, um com 12 documentos, e outro com 8, acobertando notas diferentes, mas que poderiam estar agrupadas em um mesmo CTe, pois não do mesmo Remetente e mesmo Destinatario. Segundo eles a empresa é obrigada a agrupar todas as notas em um único CTe, ou não agrupar nenhum emitindo 1 CTe para cada NFe. De qualquer forma, esta estabelecido que a transportadora PODE incluir todas as notas, mas não há nada que obrigue que seja emitido apenas um CTe. Nós estamos apenas no aguardo do documento de autuação, para confirmar o motivo da multa. Obrigada pela cooperação de todos.

Sim, Já enviei e-mail, e ambiente de produção continuamos utilizando a versão 2.0. (Porém a SEFAZ de MG quase nunca responde, e quando responde sempre é algo vago e/ou sem sentido) MG ainda nem disponibilizou a versão 3.10 em produção. Mas prosseguimos com testes na versão 3.10 para assim que estabilizar liberar para atualização. Minha dúvida era se este problema de validação ocorre também em outros estados.

GustavoKato, Bom dia. Isto ocorreu ontem no com um cliente do Espirito Santo. Ocorreu a autuação, só não tenho a confirmação se foi realmente este o motivo. Estou buscando maiores informações, e informo o resultado final disto. Caso tenha alguma base legal para isto (o que acho difícil), deixo todos informados.

anfm, Parece brincadeira, mas agora pouco consegui autorizar no SCAN para pessoa física. Mas MG permanece com problema. De qualquer forma seguem os XMLs. Obrigada. UPDATE: Tentei novamente, utilizando mesmos dados do cliente para SCAN, voltou a dar a mesma rejeição. Não da pra entender é nada. rs MG-NaoCont-31140686682093000105550140000026111999967464-nfe.xml SCAN-NaoCont-31140686682093000105559140000011703999981870-nfe.xml SCAN-NaoCont-REJEITADA-31140686682093000105559140000011753999981826-nfe.xml

Bom dia. Estou com o seguinte problema quanto a questão da tag indIEDest. Inicialmente pensei que fosse falha na validação em MG, porém enviando NFe na versão 3.10 para ambiente nacional (SCAN) estou com a mesma rejeição. Ao enviar NFe para pessoa física, está exigindo o preenchimento da Inscrição estadual, tanto informando na tag indIEDest como inNaoContribuinte ou inIsento, tentei das duas formas. Tenho a seguinte rejeição: 728 - Rejeicao: NF-e sem informacao da IE do destinatário. Nos outros estados esta validando corretamente? Como estão tratando emissão de NFe para pessoa física? Obs.: Se trata de NFe mesmo, e não NFCe.