JeannyPaiva
-
Total de ítens
238 -
Registro em
-
Última visita
-
Days Won
1
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por JeannyPaiva
-
-
Algumas regras já estão em produção, com exceção para não contribuinte até 31/12/2015.
Caso da rejeição 693 - ( Alíquota de ICMS superior a definida para a operação interestadual ), se observar o texto, verá que ela já é válida para contribuintes. E tem a exceção para não contribuinte:
"Exceção 1: Para as NF-e com Data de Emissão anterior a 01/01/2016, a regra de validação acima não se aplica para destinatário Não Contribuinte (tag:dest/indIEDest=9)."
-
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.
-
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.
-
2
-
-
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. -
Bom dia.
Hoje notei que alguns datasets não estavam sendo limpos, portanto acumulando informação, caso solicitado impressões seguidas.
Segue unit corrigida.
-
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.
-
2
-
-
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.
-
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.
-
-
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.-
1
-
-
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?
-
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:
Senhora Jeanny,
Segue parecer da superintendência responsável:
Conforme disposto na pág. 5 da Nota Técnica 2011.004 (acessada através da rota www.nfe.fazenda.gov.br > Documentos > Notas Técnicas), quando selecionados os “CST - Tributação do ICMS = 40, 41 ou 50”, somente deverão ser preenchidas as tags vICMS e motDesICMS em caso de haver desoneração (diferente de R$ 0,00) e se enquadre em uma das seguintes operações:
a) com veículos beneficiados com a desoneração condicional do ICMS;
destinadas à SUFRAMA, informando-se o valor que seria devido se não houvesse isenção;c) de venda a órgãos da administração pública direta e suas fundações e autarquias com isenção do ICMS.
Sendo assim, em quaisquer outras operações diferentes destas situações, os campos referentes às tags expostas – respectivamente representadas no emissor gratuito por “Valor do ICMS” e “Motivo da desoneração do ICMS” – deverão ser deixados em branco, uma vez que não são de preenchimento obrigatório.
Solicitamos realizar nova tentativa observando as disposições acima e, persistindo o erro, gentileza enviar uma mensagem para [email protected] anexando o arquivo XML da referida nota e a tela de erro.
Sabia que agora você mesmo(a) poderá reiniciar ou desbloquear sua senha no SIARE?
Para isto, basta clicar na opção “Esqueci minha senha”, localizada no menu à direita e logo abaixo do botão de LOGIN do SIARE. Acesse neste endereço o Passo a Passo para solicitar nova senha http://www.fazenda.mg.gov.br/empresas/sistemas/siare/files/reiniciar_senha.pdf
"Qualquer outra informação ou esclarecimento sobre dispositivos da legislação tributária, que não se revista das características e dos requisitos próprios de consulta (RPTA/MG, artigo 37, aprovada pelo Decreto nº. 44.747 de 03 de março de 2008), será prestado verbalmente ao interessado pela Administração Fazendária do município de circunscrição do contribuinte, conforme disposto no art. 48 do diploma legal citado”.
*As dúvidas esclarecidas por esta mensagem têm caráter de orientação não gerando o efeito decorrente da consulta formal.
Atenciosamente,
Central de Atendimento da SEF/MG
Diretoria de Gestão de Atendimento ao Público (DGAP)
Superintendência de Arrecadação e Informações Fiscais (SAIF)
Secretaria de Estado de Fazenda (SEF/MG)
-
Segue o XML de resposta
-
Na verdade a rejeição que está sendo apresentada é :
627 - Rejeicao: O valor do ICMS desonerado deve ser informadoSegundo 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
-
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.
-
1
-
-
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.
-
1
-
-
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.
Rejeição de cancelamento de NFe em SVC-AN
em ACBrNFe
Postado
Boa tarde.
Recentemente tivemos problemas com cancelamento de NFe emitida em SVC-AN.
Reparei que no método que envia o evento/cancelamento a UF para envio está sendo sempre definida pela UF da Chave.
Unit ACBrNFeWebServices:
>> UF := CUFtoUF(ExtrairUFChaveAcesso(FEvento.Evento.Items[0].InfEvento.chNFe));
Porém, quando ocorre o envio de NFe emitida em SVC-AN, ao tentar enviar para o estado temos a seguinte rejeição:
494 - Rejeicao: Chave de Acesso inexistente.
Isto ocorre porque, como alguns sabem a SEFAZ em MG é problemática, e aparentemente demora a sincronizar os dados com o ambiente nacional. Ocorreu caso de demorar mais de 24h para uma NFe emitida em MG constar no ambiente nacional, e vice-versa. Com isto, caso tenha necessidade de cancelar uma NFe emitida em SVC-AN já chegou a ultrapassar o prazo de 24h, e o cliente necessitar solicitar um cancelamento exteporâneo.
Para resolver fiz o mesmo tratamento efetuado para a Emissão de NF:
case FPConfiguracoesNFe.Geral.FormaEmissao of teSVCAN: UF := 'SVC-AN'; teSVCRS: UF := 'SVC-RS'; else UF := CUFtoUF(ExtrairUFChaveAcesso(FEvento.Evento.Items[0].InfEvento.chNFe)); end;Desta forma consigo definir antes a FormaEmissao para enviar o evento de cancelamento para o SVC-AN.
Segue fonte com alteração. Foi o que atendeu ao caso que ocorre aqui em MG.
Obs.:Internamente no meu sistema para caso tenha a rejeição devido ao limite do prazo legal, tente enviar para a SEFAZ do Estado, pois o SVC-AN aceita o cancelamento em apenas 24h, porém MG aceita entre 24 e 168h como cancelamento fora do prazo.
ACBrNFeWebServices.pas