JeannyPaiva

Infelizmente tem locais onde não atualizam o windows. Vários clientes ainda com Windows XP, também, apresentam o mesmo problema em relação ao horário de verão, pois o Windows "acha" que o horário de verão terminou dia 14. A solução tem sido alterar o fuso horário das máquinas para -2 temporariamente, o que seria melhor resolvido se o UTC pudesse ser atribuído pelo próprio sistema, e utilizar a informação do windows de forma opcional.

Desculpe, entendi errado. Para os arquivos abaixo, sem diretiva está compilável em 32 e 64 bits. Já o ACBrNFeDANFEFRDM e ACBrCTeDACTEFR foi necessário manter. ACBrHTTPReqResp.pas JwaWinBase.pas ACBrDFeCapicomDelphiSoap.pas

Sim. Foi necessário. Só encontrei este tópico pois tive erro ao compilar em 64bits, e procurei no fórum se já havia alguma ocorrência. Atualmente surgiu a necessidade de trabalhar apenas com NFe, CTe no 64bits, podem haver mais ocorrências para demais componentes. O erro que ocorre sem a diretiva: [DCC Error] ACBrDFeCapicomDelphiSoap.pas(101): E2197 Constant object cannot be passed as var parameter. *A principio não encontrei alternativa além do uso das diretivas.

Obrigada pela atenção @Daniel Simoes e @Juliomar Marchetti. Eu não baixei as units anexadas, e sim substitui as linhas que apresentavam problema com a sugestão apresentada. Segue meus fontes. Estão com alterações apenas nos trechos citados ACBrDFeCapicomDelphiSoap.pas ACBrNFeDANFEFRDM.pas ACBrCTeDACTEFR.pas JwaWinBase.pas ACBrHTTPReqResp.pas

Tive que fazer aqui estas alterações também. Seria bom se o pessoal enviasse esses fontes para o SVN, assim não teria que ficar conferindo as alterações a cada update.

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

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. 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