Painel de líderes

Nessa tag você deve informar o CNPJ do autor do evento, que no caso do evento de prestação em desacordo é o próprio tomador do serviço.

Olá pessoal, Sei que todos estão muito atarefados com seus programas por aí... Maaaasssss.... Precisamos de sua atenção para uma alteração nos componentes!!! Atualmente temos uma falta de padronização nas unidades de medidas das margens das impressões dos documentos fiscais. Cada impressão Report tem margens medidas com um formato. Isso não está bom. Note a tabela a seguir com as unidades de medidas das margens atual: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) cm cm nd X NFC-e mm mm X X NFC-e (A4) cm mm X X SAT mm X X X CT-e (Evento) cm nd X X CT-e (A5, Retrato) nd nd X X CT-e (Inut, Inut Retrato) nd nd X X GNR-e nd nd nd X MDF-e (Retrato, Evento) cm nd X X NFS-e cm nd X X BP-e X X X X Legenda: mm – milímetros cm – centímetros nd – O componente poderia, mas não está atualizando as margens do report X – Não possui impressão nesse formato ou não interage com as margens. Nota: Os modelos em ESCPOS que existem não consideram as propriedades de margem. Afinal, não faz muito sentido mesmo. Como podem ver na tabela acima, muitos componentes não estão atualizando as margens. Isso significa que mesmo que configure uma margem, ela será simplesmente ignorada. Então a ideia é fazer com que esses componentes imprimam de acordo com a configuração. Além disso, queremos evitar qualquer possível confusão e por isso vamos padronizar as unidades de medidas. A unidade de medida escolhida foi milímetros (mm). Alguns dos motivos foram: A unidade de medida mm funciona bem tanto para impressões grandes (por exemplo A4) como para bobinas (80 mm); As pessoas estão acostumadas com mm porque é a unidade padrão de todos os geradores de relatório usados atualmente (Fast Report, Fortes Report, LazReport ...); Devido ao ponto anterior, usar mm vai nos poupar código de conversão de unidades; Mesmo que tivéssemos escolhido centímetros (cm), haveria quebra de compatibilidade por causa do SAT e NFC-e; Quando as alterações vão entrar em vigor? A previsão é que dia 14 de outubro, as alterações sejam enviadas ao SVN. Acreditamos que isso dá tempo suficiente, para conseguirmos avisar a todos e para que todos possam se preparar. As alterações já foram enviadas ao SVN. Veja nota no fim desse post. O que eu preciso verificar no meu aplicativo? A primeira coisa é verificar se você tem configuração de margem (seria bom que tivesse). Em caso afirmativo, como você está armazenando? Em que unidade está armazenando? cm ou mm? Vai ser necessário fazer alguma conversão? Verifique como você deseja manter a configuração? De posse das informações acima, faça um teste imprimindo todos os documentos que você usa. Isso vai ajudar você a prevenir qualquer problema antes de enviar o executável para o cliente. Sugerimos você a imprimir tanto antes como depois das alterações no componente. Assim você vai ter algo para comparar as impressões e ajustar as margens caso necessário. O que eu preciso fazer caso use o ACBrMonitor Plus? A nossa ideia é minimizar o impacto para quem usa o ACBrMonitor. Vamos colocar as informações o próximo post logo abaixo. Se ficarmos atentos a essas alterações, as impressões vão seguir o mesmo padrão e ninguém mais vai precisar se confundir. Atualização- 17/10/2019 As alterações já foram enviadas ao SVN. Agora todos os reports seguem o mesmo padrão: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) mm mm mm X NFC-e mm mm X X NFC-e (A4) mm mm X X SAT mm X X X CT-e (Evento) mm mm X X CT-e (A5, Retrato) mm mm X X CT-e (Inut, Inut Retrato) mm mm X X GNR-e mm mm mm X MDF-e (Retrato, Evento) mm mm X X NFS-e mm mm X X BP-e X X X X Caso encontre algum problema, queira por favor criar um novo tópico.

Para ficar registrado, conforme explicado pela @Gr@c@, uma forma do campo obscont tanto da Nfe como do CTe ser utilizado hoje é para as informações de averbação. Pode ser que um fiscal multe caso essa informação não seja impressa. Mas caso contrário, vale o que está no MOC. Por isso... Alphajoy. Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 17957. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Ah, entendi! É por que os ajustes que eu realizei foram apenas para o CNAB 240.

@joaolenosi boa tarde! Já tinha visto os ajustes ora mencionados e antes de iniciar meu processo de homologação com o Banco Safra tive o cuidado de atualizar meus fontes do ACBr(em 14/10/2019), já com seus ajustes, porém como mencionei logo mais acima o Banco Safra rejeito nosso arquivo de remessa CNAB 400, alegando estar diferente a informação do campo nosso número no arquivo de remessa em comparação com o mesmo dado no boleto, na composição da linha digitável e código de barras. Reforço novamente que fiz um pequeno ajuste na geração do arquivo de remessa CNAB 400 apenas removendo o cálculo do dígito verificador do campo nosso número no arquivo, e após isso tivemos a validação homologada pelo banco. Sendo assim fico no aguardo de uma posição dos commiters, para possível aplicação do commit desse ajuste ao SVN. @Juliana Tamizou , poderia por gentileza dar acompanhamento nesta situação.

Está no Build de Debug... mude para Release

Pode anexar o XML e PDF para ilustrar o problema?

Bom dia, quando um lote havia mais de um rps, ao assinar o segundo rps a assinatura do primeiro ficava inválida, mas atualizando os fontes está tudo certo. Obrigada pela atenção e ajuda.

Parece algum problema nos próprios arquivos de Schema. Está com a pasta de Schemas atualizada?

Olá pessoal, Queremos informar que na revisão 17943 foi enviada ao SVN as alterações previstas a algumas semanas para padronizar as unidades de medidas e comportamento das margens nas impressões. Caso queira mais informações, veja o tópico de anúncio:

Olá Como sabemos o Projeto ACBr foi implementado mantendo a compatibilidade com o Delphi e Lazarus, porém, os arquivos de Formulário no Delphi (.dfm) não é o mesmo utilizado pelo Lazarus, que possui a extensão (.lfm) e utiliza o formato UTF-8. Por esse motivo, quando realizarmos alterações em Formulários do ACBr utilizando o Delphi(.dfm), devemos compatibiliza-lo também no Formulário do Lazarus(.lfm). A forma mais fácil de realizar esta tarefa é Converter o Arquivo alterado, assim não precisamos realizar as mesmas alterações nos dois arquivos. Segue abaixo o procedimento para Conversão. 1- Exclua o arquivo com a extensão .lfm, que já existe no Projeto. ex: ACBrNFeDANFeRLRetrato.lfm 2- Realize uma Cópia do Arquivo .dfm que foi alterado. ex: ACBrNFeDANFeRLRetrato - Copia.dfm 3- Renomeie o Arquivo copiado com o mesmo nome do original, mas altere a extensão para .lfm ex: ACBrNFeDANFeRLRetrato.lfm 4- Abra o arquivo .lfm utilizando o NotePad++ e selecione a opção Converter para UTF-8 (caso ainda não esteja em UTF-8). Salve as alterações... ex: 5- Abra o Formulário Alterado no Lazarus, mova o posição do formulário apenas para poder Salvar as alterações e Compile o Projeto.. Note que ao salvar o formulário utilizando o Lazarus os caracteres acentuados que estavam codificados agora estarão corretos... Basta então testar a Aplicação... Antes: Depois:

Moderador pode fechar o tópico. O problema era causado pelo hardware.

Olá Pessoal, Já encontra-se disponível no repositório Trunk2 o mais novo componente ACBr - ACBrONE - Operador Nacional dos Estados. "O Operador Nacional dos Estados: ONE é o sistema responsável por integrar os documentos fiscais eletrônicos das Administrações Tributárias com as diversas tecnologias de identificação de veículos nas rodovias brasileiras. O sistema objetiva a geração dos eventos Registro de Passagem nos documentos fiscais transportados por intermédio da informação da placa do veículo e sua respectiva geolocalização, detectada por algum dispositivo ou tecnologia de monitoramento, o que auxilia nas ações de fiscalização de trânsito e de combate à sonegação." O texto acima foi retirado do Portal do Operador Nacional dos Estados - SVRS. Para mais informações visite o Portal. O manual do ONE já baixamos e se encontra em nossa biblioteca. Nas pastas: ...\Exemplos\ACBrDFe\ACBrONE\Delphi ===> temos o programa exemplo do componente. ...\Exemplos\ACBrDFe\Schemas\ONE ===> temos os schemas ...\Fontes\ACBrDFe\ACBrONE ===> temos os fontes ...\Pacotes\Delphi\ACBrDFe\ACBrONE ===> temos o pacote de instalação. Por enquanto o ACBrInstall_Trunk2 não esta preparado para instalar esse componente, logo será necessário a instalação manual através do Pacote. Observação1: apesar dos XMLs a serem enviados não precisam ser assinados digitalmente é preciso de um certificado digital para consumir os Webservices. Observação2: Não é qualquer empresa que pode usar o ONE é preciso que ela esteja cadastrada como uma Operadora.

Olá pessoal! Temos o prazer de informar que mais um novo componente foi adicionado ao projeto: ACBrLCDPR. O ACBrLCDPR foi criado para facilitar a geração do LCDPR - Livro Caixa Digital do Produtor Rural. Esse componente segue a mesma ideia de outros componentes para geração de arquivos como ACBrSPEDFiscal, ACBrSPEDPISCOFINS, ACBrSEF2, etc... Com ele você pode gerar o arquivo sem se preocupar com o layout do arquivo. A sua preocupação será apenas com as informações que precisa aprensentar. Como é um componente novo, temos consciência de que alguns ajustes talvez sejam necessários. Todos podem ficar à vontade reportar problemas. Podem fazer isso por criar um novo tópico com ajustes e anexar nele. Crie o tópico no subfórum ACBrTXT -> Outros (ACBrLFD, ACBrSEF2, etc). Mas queremos agradecer ao @Willian Hübner que pôs a mão na massa e fez a doação do componente que serviu como base dessa versão. Queremos também aproveitar a oportunidade para agradecer aos nossos usuários SAC. Seu apoio nos ajuda a continuar avançando.

No ArqINI: Antigo: [3118601] Nome=Contagem UF=MG Provedor=Pronim; Novo: [3118601] Nome=Contagem UF=MG Provedor=Ginfes;

Tende eliminar o problema por etapas, na sua máquina ocorre o mesmo problema se instalar o Monitor para testes? Verifique também se utilizando o método NFe.ImprimirDanfe(...) com o parametro "mostrarPreview" a margem fica cortada visualizando em tela?

Boa tarde. Obrigada pela contribuição, adicionada para validação. Att.

Obrigada. Será validado nos próximos dias. Att.

Narlem, A versão do seu Monitor é bem antiga, não é? Favor atualizar.

Boa tarde Gean, Realmente no fórum as coisas ficam dispersas. Mas voltando ao assunto do evento de prestação de serviço em desacordo, chegou a ler o artigo: Evento de Prestação de Serviço em Desacordo ? Curiosidade, o que vem a ser: "anulacao pelo desacordo...ou o desaacordo no mdfe e a anulacao no cte" ?

Acho que devia aceitar. Faça teste usando outra configuração SSLXmlSignLib.

Notei outro detalhe pelo seu log, não está encerrando no final de parâmetro com ") Veja no método SAT.CriarEnviarCFe("... Pode ser esse o motivo do erro... É importante seguir corretamente a Sintaxe exigida pelo ACBrMonitor, caso contrário pode ter esses tipos de erros na geração do XML onde fica mais difícil identificar o motivo.

Eu utilizo a seguinte configuração e gera pdf com as margens corretas: Verifique também como está sua configuração de vídeo na opção "Escala e Layout", mantenha a escala como 100%, pode estar influenciando na geração do pdf...

Qual exatamente o problema que teve com relação as fontes? Não consegui simular. De qualquer forma fiz ajustes nos nomes das fontes do .fr3, por favor faça teste com o arquivo anexo e veja se terá o mesmo problema. DACTE2Vias.fr3

muito obrigada, no início da semana os arquivos retornaram com esse erro, mas hoje cedo foram transmitidos com sucesso.

Não encontrei nenhuma informação na área de perguntas respondidas: http://caf.sef.sc.gov.br/Views/Publico/BaseConhecimento/BuscarBaseConhecimento.aspx?assunto=9 Então a primeira verificação é se os schemas estão corretos e são de homologação. Você também pode tentar enviar um arquivo com a data do ano que vem e verificar se vai passar. Caso contrário, sugiro entrar em contato com a Sefaz e perguntar como proceder.

Contagem- MG no ArqINI: Antigo: [3118601] Nome=Contagem UF=MG Provedor=Pronim; Novo: [3118601] Nome=Contagem UF=MG Provedor=Ginfes;

Bom dia! Pessoal, realmente o ajuste conforme mencionei acima foi aprovado pelo Banco Safra, sendo assim gostaria de solicitar gentilmente aos Admin se é possível aplicarmos o ajuste no SVN. Grato.

Bom dia, vc quer dizer a chave de acesso do(s) documento(s) referenciado(s) ? (Quando informados...) Se for isso, os componentes de impressão de DANFE (Fast ou Fortes) têm uma propriedade chamada "ExibeDadosDocReferenciados"... Att Ricardo

Configure o modelo de dll para satDinamico_cdecl

Boa tarde Quais as configurações de Margem está utilizando? Se mandar imprimir utilizando a opção Preview em tela também está cortando? As colunas não são configuráveis.

Obrigado pela resposta estava postando agora que foi isso mesmo pasta schemas desatualizada.

Chegamos a marca de 3 webservices distintos para Blumenau, agora SimplISS já pode pedir música no Fantástico. Eu já tenho empresas usando os outros dois webservices(wsblumenau e migracao) e agora vou ter no terceiro(wsblumenau1), porque ainda tenho problemas em 3 clientes referentes a assinatura. ou seja, pessoal se não der certo a emissão em um, bola pra frente e colocamos para enviar no próximo. Desde que não tenha o 4 webservice já estamos de bom tamanho;

Os fontes da dll usada estão disponíveis no SVN, ela foi desenvolvida usando o Lazarus. http://svn.code.sf.net/p/acbr/code/ACBrFramework/

Já fez o teste pelo demo do ACBrNFe pra ver se ocorre o mesmo erro?

ha sim vou testar obrigado

OK, Muito obrigada pela atenção.

Boa tarde Juliana. Obrigado pelo retorno. Eu consegui a parte do retorno de forma funcional aqui, falta a questão a remessa em "empréstimo". E a partir de hoje estou trabalhando em produção com o componente modificado. Com mais alguns dias de teste trarei aqui minhas implementações. Att, Wellington.

Boa tarde No seu arquivo está assim: [Pagto001] cMP =01 vMP =1.00 Utilize dessa forma: [Pagto001] cMP=01 vMP=1,00

Assine uma conta Trial... veja:

Entendi Italo, Então eu vou assinar pois preciso da ultima versão do ESOCIAL, que já esta em homologação e que entra em produção em 11/11. Obrigada Italo.

Deu certo, muito obrigado.

Não... veja o tópico anterior... Se você usar WinHTTP não precisará configurar nada no I.E.

Bom dia Juliomar, Realmente era a versão, conexão com oracle somente versão Enterprise e/ou Architect.

Bom dia, não houve alterações recentes quanto a isso, a questão de usar apenas o método Assinar é que deve desmarcar a opção citada acima: "Salvar Apenas NFes processadas na pasta NFe", para que o XML assinado possa ser gravado na pasta.

Olá, Para quem utiliza o ACBrMonitorPLUS, as margens dos documentos fiscais eletrônicos podem ser configuradas em um único local, sendo válidas para todos os Formulários (NFe, CTe, MDFe, GNRe). Com as padronizações realizadas, o que muda é a definição de margens de Centímetros para Milímetros, sendo assim basta multiplicar as configurações já existentes por 10. ex: Antes - Margem Inferior: 0,70 Margem Superior: 0,70 Margem Direita: 0,50 Margem Esquerda: 0,50 ex: Depois- Margem Inferior: 7,00 Margem Superior: 7,00 Margem Direita: 5,00 Margem Esquerda: 5,00 Veja onde configurar: Para o cupom SAT e NFCe tipo (Bobina) não será necessário alterações nas configurações já existentes. Estas alteração precisam ser realizadas a partir da versão: 1.3.0.140

Como eu precisava liberar isso pro cliente, tomei a liberdade de fazer a mudança. Se algum moderador puder validar e dar o "feedback" se isso pode de fato incorporar o componente, agradeço. Segue em anexo a .pas alterada. ACBrDFeDANFeReport.pas

Tive o mesmo problema e resolvi atualizando as DLLs que são utilizadas para comunicação com a Nota Fiscal Eletrônica. Utilizei as DLLs que estão em ...\ACBr\DLLs\LibXml2\x86

Aqui temos um verificador de updates rodando com o Windows em todas as máquinas e notificando caso encontre uma nova atualização. (não é necessário estar em todos os PC's. Mas como isso é instalado junto com o sistema e na prática não muda muita coisa. Deixamos assim) Quando o usuário clica para instalar a atualização em uma máquina qualquer, exibe uma janela com as melhorias, novidades, correções... Após o término do download do update, é gravado em um banco de dados especifico e temporário as informações do update, como: Nome, versão/build, data, novidades, MD5. Também gravamos o executável do InstallShield nesse banco (sim, gravamos um arquivo de mais de 700MB). Conforme print abaixo. Quando termina a instalação do update e o usuário inicia o sistema, os scripts necessários para o funcionamento da nova versão/build são rodados no SQL Server. (não precisa ser o servidor) Depois do banco de dados também estar atualizado, as demais máquinas "acusam" diferentes versões entre o executável e o banco de dados, possibilitando a atualização do sistema nesses outros computadores. Nesse momento ao invés de baixar o update novamente, acessamos o banco de dados temporário onde tem o arquivo já baixado e apenas instalamos. Quando o usuário abrir o sistema, os scripts não serão rodados pois já foram. Observação 01: Não importa se mais de um computador baixar a atualização ao mesmo tempo, antes de gravar o arquivo do InstallShield no banco, é verificado se ele já não existe. Observação 02: Os updates são controlados por CNPJ, UF... Já que as vezes é necessário uma correção imediata apenas no estado X. E ainda verificamos se o cliente está apto a receber o update já que o mesmo pode ter problemas financeiros, contrato de manutenção cancelado (não dando direitos a updates de versão, apenas build dentro da versão que o cliente adquiriu). Observação 03: Depois de todos os PC's atualizados, os dados da versão nova e o arquivo da versão são apagado desse banco de dados temporário. Observação 04: Existem atualizações criticas, nesse caso não fica a critério do usuário a instalação. O próprio atualizador, se encarrega de baixar e executar a instalação. Observação 05: Após o término da atualização no PC, solicitamos o registro da licença novamente para controlarmos qual é a versão que o cliente está utilizando. (de forma online e transparente já que as licenças são controladas por um HWID e não por um serial previamente cadastrado). Aqui controlamos por MD5. Ou seja, ao executar o sistema e algum arquivo (bpl, exe, dll..) não bater com o MD5 do executável. Não será possível executar o sistema.

Mas se o Switch morre, todos os caixas param de operar.... Já se perguntaram se Burger King, Americanas, Carrefour usariam esse modelo ? Para quem o cliente vai ligar desesperado, quando o Switch cair, e todos os caixas pararem ? Dependendo do volume do cliente, talvez só o prejuízo causado por uma situação dessas (lucro cessante), por alguns minutos, já represente um valor maior do que o do SAT... Na minha opinião o PDV deve ser capaz de funcionar mesmo totalmente off-line... e a transição on-line / off-line, deve ocorrer de forma transparente para o operador... Para quem nunca fez certificação de PAF-ECF, pode ser muito difícil de implementar um PDV totalmente off-line ... mas com certeza isso é um recurso muito valioso no momento da venda do sistema...