Painel de líderes

Uma pane na estrutura da LocaWeb deixou o Servidor onde o Projeto ACBr fica hospedado, indisponível por várias horas http://statusblog.locaweb.com.br/category/cloud Lamentamos o ocorrido, e já estamos conversando com a LocaWeb a fim de evitar que o problema se repita...

Nesta nota houve destaque de ICMS FCP-ST que não foi incluído no valor total da nota: <vFCPST>1.22</vFCPST> Na versão 3.10 essa tag não existe, assim o valor ficou correto.

Parece estar funcionando normalmente, com acentos e espaços... Veja as imagens Delphi Tokio: Delphi 7 Lazarus / FPC

Olá, Há muitos meses atrás deixei units pra serem avaliadas e possivelmente colocadas no acbrboleto, creio que o único post que foi aceito, foi no componente TACBrBoletoFCFR para otimizar a leitura em loop evitando o uso de FieldByName() e a descrição de tratamento de mensagens de arquivo retorno da caixa como foi compensado o boleto, pois bém, tenho o layout do boleto da contribuição sindical pronta, homologada e já em produção, tive que adicionar umas propriedades na unit acbrboleto.pas, e criei a unit AcbrBancoCaixaSICOBGRCSU.pas e na unit do TAcbrBoletoFCFR fiz algumas adições sem alterar o padrão, este componente por exemplo não dá acesso a interface interna do FastReport, consegui fazer isso sem prejudicar o padrão, agora consigo passar variáveis e acessar objetos do fastreport por esse componentes que só liberou algumas propriedades, segue anexo, se interessar ao projeto, nunca obtive retorno ou confirmação de que o post foi aceito, falam para a gente coloborar, estou tentando fazer a minha parte. Se as propriedades que coloquei direto no TACbrBoleto estão fora do escopo, aceito sugestões, de fato estas propriedades somente interessa ao boleto Caixa que é o imposto federal da GRCSU. Este fonte foi ajustado de acordo com o trunk2, espero que seja aceito. ACBrBoleto.zip GuiaSindical.fr3

Obrigado pelas informações... Acho que notei o problema... quando a Senha é atribuída, o certificado é descarregado... procedure TDFeSSL.SetSenha(AValue: AnsiString); begin if (FK <> '') and (FSenha = StrCrypt(AValue, FK)) then Exit; FK := FormatDateTime('hhnnsszzz',Now); FSenha := StrCrypt(AValue, FK); // Salva Senha de forma Criptografada, para evitar "Inspect" if CertificadoLido then DescarregarCertificado; end; Estou avaliando uma correção, para esse cenário...

Boa tarde está no svn sua contribuição. Obrigado

Consegui Sergio! coloquei a variável para zerar no evento BeforeScroll da IBQuery... valeu...

Eu utilizo o FastReport. Era o report que estava antigo. Atualizei via svn e funcionou. Muito obrigado !

boa noite Este assunto ja foi falando aqui mais gostaria de só de saber qual a diferença nfce Contingência e Off Line visto que são marcação em separados (distintas) exemplo quando em contigencia FormaEmissao=1 e quando em OFFline FormaEmissao=8 o que muda na pratica com relação ao enviar? obrigado att.. jose juca

Bem lembrado. A alteração do NCM implicaria no recálculo dos valores...não muda nada do ponto de vista fiscal, entretanto. O valor aproximado dos tributos tem caráter apenas informativo ao consumidor.

O componente faz o envio, basta carregar o XML salvo anteriormente e chamar o método ACBrNFe.Envia() ou ACBrNFe.WebService.Envia(). Sim, mas o XML emitido em contingência já deve estar assinado e validado, segundo os Schemas, então basta enviar. Sim. Se houver rejeição do XML enviado, deve-se gerar novamente o XML, fazendo a correção da informação rejeitada e enviar novamente. Nada impresso no DANFe NFCe deve causar rejeição no envio. Não tem NCM no DANFe NFCe por exemplo.

Obrigado Ricardo, com sua ajuda resolvi.

Atualizei novamente e com a nova correção já está funcionando corretamente. Obrigada Pessoal.

Sim. Não é necessário. Pelo Manual de Contingência Off-Line da NFC-e, o qual sugiro que leia com atenção, você tem até o dia útil seguinte para transmitir a NFC-e emitida em contingência off-line. Alguns estados permitem a transmissão além desse prazo, autorizando a NFCe com cStat = 150.

Bom dia, vc precisa informar também estes outros 2 campos: // data e hora de início da contingência Ide.dhCont := AdhCont; // Justificativa/motivo da contingência... Ide.xJust := AxJustCont; Att Ricardo

Sim ... já estamos discutindo isso em outro tópico.

procedure Tform1.ACBrECFMsgPoucoPapel(Sender: TObject); begin {} end;

Já tentou colocar o ReadOnly := True no seu DBGrid ?

Verifique se o código da Agência não está preenchido algum em outro campo. Gerei aqui e emitiu corretamente...

Já foi publicada a NT 2016.002 v. 1.30 que alterou essa regra de validação. Agora precisa ter apenas um pagamento como Duplicata Mercantil (veja o destaque em verde no texto): Talvez a SEFAZ do estado ainda não atualizou suas regras para essa versão da NT.

BigWings obrigado pela ajuda, mas o que realmente resolveu aqui pra mim, além do ppEscElgin, foi PosPrinter.ConfigQRCode.LarguraModulo := 3; Ele não estava imprimindo por conta disso. O ppEscPosElgin não aceita o valor padrão 4 em LarguraModulo. Mesmo assim muito obrigado. Abraços.

Ajuste disponível no SVN, favor atualizar os fontes.

Não me pergunte o motivo, mas parece que existem algumas exceções, de acordo com o CFOP, que permitem não informar o documento referenciado:

Ajudou a resolver o problema, a lógica do meu PDV ficou bem diferente mas deu uma luz do caminho a seguir, obrigado.

Bom dia José, Apesar de constar na página 177 da versão 6.0 do Manual da NF-e a observação do campo tpEmis o seguinte: Para a NFC-e somente estão disponíveis e são válidas as opções de contingência 5 e 9. Onde tpEmis = 5 -> Contingência FS-DA, com impressão do DANFE em formulário de segurança; e tpEmis = 9 -> Contingência off-line da NFC-e (as demais opções de contingência são válidas também para a NFC-e). Você nota que ao definir o tipo de emissão = 9 entra em contradição, pois é dito que para NFC-e só pode usar as contingências 5 e 9, ou seja, os tipos de emissão 5 e 9. Sendo que as contingências são: 2, 3, 4, 5, 6 e 7. Outra coisa, o tipo de emissão 5 se refere a um formulário de segurança, que no caso da NFC-e não existe uma vez que o DANFE é impresso em bobina. Por conta dessas distorções desse manual, vamos então para o Manual de Padrões Técnicos do DANFE NFC-e e QR-Code versão 3.5, publicado pelo ENCAT em Março/2016, se você procurar por tpEmis só vai encontrar referencias sobre o tpEmis = 1 e 9. Concluímos que, se a NFC-e não for emitida segundo o tipo de emissão = 1 (Normal), devemos emiti-la em contingência segundo o tipo de emissão = 9 ( Off-Line). Como você pode ver não temos escolha, se não temos conexão com os servidores da SEFAZ a solução é emitir a NFC-e em Off-Line, ou seja, tpEmis = 9. Em tempo: o tpEmis = 8 só é valido para emissão do CT-e e não NF-e / NFC-e. Espero ter ajudado.