JeannyPaiva

Bom dia. Realizei alterações na impressão do DACTe para FastReport com QRCode. (Não encontrei em outro tópico sobre alterações para o FastReport). Seguem arquivos alterados. *Realizei testes apenas para o modal rodoviário, que é o que tenho disponível na empresa. DACTE_Retrato.fr3 ACBrCTeDACTEFR.pas

Boa tarde Felipe. As alterações realizadas nesse tópico são apenas para o Fast Report. Como não trabalho com o Fortes, não tenho como te informar se já realizaram as alterações para ele.

Boa tarde, Realizei as outras alterações (praticamente refiz) do leiaute do DAMDFe, contudo tenho apenas como testar o modal rodoviário. (Caso alguém trabalhe com outros modais, e queira testar, ou disponibilizar XMLs de outros modais para que eu faça o teste de impressão, só informar). DAMDFe_3a.fr3

Meu arquivo estava realmente desatualizado. Baixei novamente e inclui nele o QR-Code. Neste arquivo apenas inclui a informação do QR-Code, pois foi a minha necessidade imediata para disponibilizar para os clientes. Estou verificando as demais alterações para alterar os outros modelos. DAMDFe_Retrato.fr3

Bom dia. Notei que ainda não haviam incluído na impressão do MDFe o QR-Code (FR) e realizei a alteração. Agradeço se puderem adicionar no SVN. Segue anexo fonte, e um dos fr3 que já realizei a alteração (apenas com a inclusão do QR-Code). Pretendo realizar outras modificações no meu FR3, e quando concluir posso disponibilizar caso seja de interesse de outros. ACBrMDFeDAMDFEFR.pas DAMDFe_Retrato.fr3

No caso tive problema com 2 rejeições. A primeira foi a que você comentou, e isso é resolvido informando como valor da fatura a soma do valor das duplicatas. Após isso ainda tive a seguinte rejeição: 767-Rejeição: Somatório dos pagamentos diferente do total da Nota Fiscal Que foi resolvida adicionando mais um valor de "pagamento" como outros. Segue um XML de exemplo 31180986682093000105550140000053016201853012-nfe.xml

Resolvi enviando um valor de pagamento a mais da diferença como Outros. Então envio os 200,00 como Boleto por exemplo, e os 800,00 como Outros. Ou, sem passar informação de pagamento.

As vezes eu penso que esse povo trabalha pra testar a nossa paciência. Tira tag, coloca tag de novo. Aff.

Bom dia. Ao efetuar a leitura do XML de substituição com a indAlteraToma = Sim , estava sempre retornando como não, por não conseguir efetuar a leitura da tag. Realizei a correção no arquivo pcteCTeR anexado. pcteCTeR.pas

Algo semelhante a isto: with FACBrMDFe.Manifestos.Items.MDFe.seg.Add do begin respSeg := rsEmitente; xSeg := NomeSeguradora; CNPJ := CNPJSeguradora; nApol := NumApolice; CNPJCPF := CNPJCFPResp; aver.Add.nAver := NumAverbacao; end;

Segue Unit alterada. Para preencher o campo de acordo com a versão informada no XML . ACBrMDFeDAMDFEFRDM.pas

Boa tarde. Na leitura do XML de CTe 3.0, está buscando o conteúdo da chave pela tag antiga apenas. Nesta versão, a tag mudou para chCTe, sendo necessário realizar tratamento quando à versão na leitura do XML. Em anexo a unit alterada. pcteCTeR.pas

Obrigada Juliomar. Eu uso um fr3 personalizado diferente do disponível nos componentes, por isso enviei apenas o fonte.

Bom dia. Com a versão 3.0 do CTe, foi adicionado ao DACTe o indicador de CTe globalizado. Fiz a inclusão do campo no fonte anexado. Caso alguem possa adicionar no SVN fico grata. Obs.: até o momento minha necessidade foi apenas deste campo. ACBrCTeDACTEFR.pas

*Indiretamente pode ser que gere. Mas veja bem, esta já é uma pratica comercial para as operações, pois se a empresa não faz a formação do valor de venda de seu produto já embutindo este valor, ela terá um prejuízo. A diferença é apenas o que irão considerar mesmo agora, se antes consideravam apenas a interna do próprio estado para a formação, deverão observar a alíquota interna no estado de destino, e se tem ou não FCP. Para não criar preços diferentes dependendo do estado, a prática mais comum que tenho ciência, tem sido considerar a maior alíquota interna existente. *Simples Nacional está desobrigado a destacar o DIFAL devido a uma liminar. No momento não precisam preocupar com isso. Tem que ficar de olho para ver se ela não será derrubada.

De acordo com o manual de orientações, o campo de valor da NF é formado pelos campos abaixo: -Total do vNF (id: W16) difere do somatório de: (+) vProd (id:W07) (-) vDesc (id:W10) (-) vICMSDeson (id:W04a) (+) vST (id: W06) (+) vFrete (id:W08) (+) vSeg (id:W09) (+) vOutro (id:W15) (+) vII (id:W11) (+) vIPI (id:W12) (+) vServ (id:W18) (*3) (NT 2011/005) Logo, se para adicionar este valor, não seria validado pela SEF. A prática comercial, e orientação da consultoria é que os impostos sejam embutidos no valor base do produto para a formação do preço de venda.

Não vai conseguir mesmo. O que seu cliente deve fazer, é calcular o valor do preço de venda dele já com o valor do ICMS embutido. Dentre os impostos, apenas o IPI é somado no total da nota fiscal.

Aqui permitimos impressão APENAS de NFe autorizada, com exceção de FD-SA. NFe denegada não pode circular, creio que disponibilizar a impressão de NFe nesta situação já induz o usuário, que por natureza costuma ser desatento, ao erro de utilizar este DANFe para o transporte de mercadorias. Quanto ao repasse de informações para contabilidade e/ou comprovante, é mais sensato criar um relatório com as informações da NFe para seu cliente.

Nota fiscal denegada, não pode circular. Então melhor que nem tenha a impressão. Se o cliente quer algum tipo de comprovante, aconselho a criar algum relatório gerencial para ele com as informações.

Basta enviar o grupo, informando a aliquota interestadual, e o percentual de partilha, que são as tags de preenchimento obrigatório que estão com validações. Demais campos vão com zero.

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.