Painel de líderes

Verifique se o sistema não está em Debug. Mesmo assim, é um tamanho consideravelmente grande. Já aconteceu algumas vezes comigo, não um tamanho gigantesco assim, mas eu tenho o DevExpress instalado em minha IDE, às vezes, não sei por qual motivo, ele automaticamente ativa as Skins do DevExpress, fazendo assim o executável subir uns 50MB. Verifique nas units do projeto, se não tem alguma que foi adiciona na alteração, provavelmente tem alguma unit que não deveria estar.

parece ser um bug da IDE... verifique se não é o caso de Paths longos ou com espaços... Em todo caso... Copy não seria uma má prática ? afinal você teria código repetido...

A libxml2.dll não compreende (ou compreende diferente) a expressão regular usada nos schemas oficiais.

Boa tarde Elias, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Olá. Eu particularmente gosto de analisar sugestões criativas como a sua. Acho que nos acrescenta muito. Dito isso, tenho os seguintes comentários: hmm... talvez o seu problema esteja em colocar o TApplicationproperties no seu FormPadrao. Você deve ter apenas uma instância do TApplicationProperties na sua aplicação. Geralmente coloca-se num DataModule que não vai ser criado e destruído mais de uma vez. O problema ao fazer isso é que cada form criado sobrepõe o Application.OnException do Form anterior. Isso pode levar a uma inconsistência. Acredito que se você criar um dois forms em sequência, o segundo for destruído e então o primeiro gerar uma exception você terá um AccessViolation.

Boa tarde, Estou tendo este mesmo problema e acabei de postar sobre esse assunto. Só depois vi sua mensagem. Dê uma olhada la que tem a solução: Att., Gabriel Toledo

Bom dia Atualizado no SVN... Obrigado pela contribuição!

Tente a configuração "Linhas pular" na aba PosPrinter. Vi que também está cortando a data de autorização. Pra resolver isso, informe também algum valor diferente de zero (algo entre 30 e 60) para "Espaços" na mesma aba.

Pesquise por Assinatura Digital de Software. Pode ser que resolva o seu problema.

Boa noite, Funcionou

isso é um comportamento de keylogger dificilmente você vai conseguir que um antivírus te deixe em paz, se voce precisa de um bugtrace voce poderia usar : http://madshi.net/madExceptDescription.htm https://www.eurekalog.com/downloads_delphi.php por exemplo, mas existe outros.

Boa tarde. Informe 101 na propriedade Modalidade. Att.

Olá! Estou abrindo um novo chamado sobre a Rejeição 929 - Informado CST de diferimento sem as informações de diferimento na SEFAZ-PR, pois o chamado aberto é do SAC e não consigo adicionar resposta. O @Italo Jurisato Junior citou no chamado: "Você deve atribuir o valor de tal forma que a sua nota seja autorizada. Sim, você deve entrar em contato com a SEFAZ-PR e informa-los que no manual a tag é opcional, logo se o valor dela for zero não precisa ser gerada. E pede para eles se justificarem sobre a presença no XML dessa tag opcional mesmo com o valor zero, para que a nota seja autorizada." O que justifica a presença dessas TAGS OPCIONAIS no XML é a validação adicionada na NT 2019.001 v1.10. As tags são opcionais pois a implementação fica a critério da UF, mas como o Paraná implementou elas se tornam obrigatórias mesmo estando zeradas. Eu entendo que é uma situação chata onde a SEFAZ-PR está se contradizendo quanto ao que é imposto pelas regras da documentação da NFe, mas também é incorreto informar valor "0,01" ou "0,0001" nas tags para que a nota seja autorizada. Creio que a melhor opção para o problema seria a criação de uma propriedade semelhante a "ACBrNFe.Configuracoes.Geral.CamposFatObrigatorios", para que notas enviadas a SEFAZ-PR contenham as TAGS mesmo zeradas. Para conseguir fazer a emissão normal da NFe fiz uma alteração na unit pcnNFeW.pas, colocando como Ocorrência 1 as tags do CST51. Gostaria que se possível essa adequações entrasse no commit do ACBR. Atenciosamente, Flávia.

Boa tarde pessoal, estou tentando emitir uma NFe com a tag "modbcst = 4 - Margem de valor agregado" , mas estou tendo a rejeição (Informada modalidade de determinação da BC da ST como MVA e não informado o campo pMVAST). Ao que diz a última nota técnica 2019.001 v1.30 esse campo se torna obrigatório quando usado tal valor na tag modbcst, mas seguindo o MOC v6.0, essa tag pMVAST tem como ocorrência 0-1. Fiz uma alteração no número de ocorrências da tag dentro da pcnNFeW para 1 e a tag foi gerado com valor zerado mas a nota enviou normalmente. Estou certo quanto a essa alteração?

Não quis dizer que o "form padrão" fosse criado, mas sim os forms que herdam dele que possuem o mesmo evento onCreate que você descreveu acima. Dito isso: Creio que não, porque esses outros eventos são de cada form. Mas o evento Application.OnException é da aplicação (Application). Application é na verdade uma variável global da aplicação. Por isso, toda vez que você faz: Você está na verdade sobrescrevendo o mesmo evento com uma procedure do form que foi criado agora.

Boa tarde! Não tinha visto sua resposta! Vou tentar testar até amanhã e respondo se resolveu o problema! Obrigado pela atenção!

Vou dar uma olhada nessa situação @Gr@c@, muito obrigado.

Boa tarde Silva, É bem provável que a propriedade de configuração Encerrado do componente DAMDFE esteja com o valor True.

Que bom que no seu caso não precisou reinstalar. O motivo de não estar mais marcada a opção não é a atualização do ACBr. Na verdade, geralmente é o apresentado no tópico que eu mencionei acima.

@EMBarbosa obrigado pela força Mas não precisou refazer toda a instalação do ACBR, analisando em Component > Install Packages percebi que não estava mais checado esta opção, Motivo não sei porque talvez alguma atualização feita depois gerou isso. Obrigado @Juliana Tamizou pelo reabertura

Boa tarde Paulo, Favor atualizar os fontes, note que criei um provedor novo para a cidade de Blumenau - SimplISSv2.

Verifique exatamente onde a exception é levantada. A partir daí, veja qual o caminho que o código está seguindo pra levantar a exception.

Favor anexar o arquivo fonte alterado.

Nesse caso não temos previsão... o ACBrNFSe precisa passar por um Refactoring antes..

Tentou usar os Schemas disponibilizados pelo ACBr? Na pasta ACBr\Exemplos\ACBrDFe\Schemas\NFe.

Boa tarde. Obrigada por compartilhar sua solução. Att.

Hmm entendi! Já desenvolvi algo com o Reinf.. imagino que seja similar.. carrega os eventos.. e envia.. Obrigado pela atenção!

@brunomachadogp você pode procurar mais informações sobre o assunto mas em resumo é isto: SEFIP está com os dias contados, para alguns empregadores ela só está responsável pela guia do FGTS e nada mais. Não há geração de dados para a DCTFWeb, a mesma é uma página dentro do ECAC onde você controla o pagamento dos DARFs Processo: Você irá alimentar o eSocial e o Reinf (ambos tem no ACBR), quando você fizer o fechamento dos dois automaticamente vão enviar os dados à DCTFWeb, dai você entra na página da DCTFWeb e faz a geração das guias.

A inclusão dos itens no XML é feita pela ordem de chamada ao método Det.New / Det.Add. A aplicação é responsável por informar a numeração (Prod.nItem) correta.

Sim, está nos nossos planos... mas primeiro iremos estabilizar as LIBs existentes...

Solucionado!, modifiquei a propriedade SSLXmlSignLib de "xsLibXml2" para "xsMsXml" e validou a assinatura corretamente.

Por favor atualize novamente os fontes.

Desculpem, tinha retirado a tabela pra atualização mas já esta disponível novamente, DEUS abençoe

Esse erro pode ser ocasionado também pelas configurações em Opções da Internet. Verifique se com essas configurações funciona.

Se o componente do ACBr estiver instalado no D7, sim, ele abre. O TWebBrowser é um componente nativo do Delphi, então ele não deveria dar falta dessa unit. Verifique se o mesmo está ativo na aba de componentes de sua IDE.

Para referência:

Bom dia Juliana, Claro, consegui resolver o problema, apenas alterando o Modelo de Impressão no PosPrinter. Estava utilizando o ppEscBematech, alterei para ppEscPosEpson. Abraços

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

bom dia. Amigo, não tem nada haver com "arredondamento abnt". Tens que implementar esta regra aqui http://partners.bematech.com.br/bemacast/Paginas/post.aspx?idPost=5790 Fiz e resolveu

Veja também o exemplo de código contido neste arquivo C:\ACBr\Exemplos\ACBrDFe\ACBrNFe\DistribuicaoDFe.txt Att Ricardo

Bom dia Daniel, ok .. vou contornar com um timer. Muito obrigado

Sério @EMBarbosa nossa instalei ele a pouco tempo atrás =/ E foi puta paulera rs

Consegui Resolver o problema, Obrigado

Segue o Arquivo Italo pcnNFeW.pas

Veja:

uses pcnAuxiliar; ... ACBrBPe1.Configuracoes.WebServices.TimeZoneConf.ModoDeteccao := tzManual; ACBrBPe1.Configuracoes.WebServices.TimeZoneConf.TimeZoneStr := '-03:00';

O digest value da assinatura da nota não confere com o digest value do protocolo de autorização. Se no componente a configuração ValidarDigest estiver False isso pode ocorrer. Provavelmente foi gerado outro XML de outra venda mas usando a mesma chave da nota já autorizada.

Bom dia Dirlenio, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Paulo, Como assim, "eu salvo mas as vezes pode não salvar" ? Se você esta usando o banco de dados que hora salva os dados, hora não salva, você não acha que esta na hora de mudar para um banco de dados mais confiável? Ainda não entendi a dificuldade de usar a função que criamos, que gera o código da forma recomendada pela SEFAZ e o valida, garantido desta forma que a sua nota vai ser aceita pela SEFAZ. Após gerar o código, salvar o mesmo com os demais dados da nota. Obviamente que para isso será necessário acrescentar mais um campo na tabela para armazenar o código. Eu acredito que isso não deva ser uma tarefa extremamente complicada, ou estou enganado? A minha aplicação de emissão de NF-e foi escrita em 2008, ao ler o manual da NF-e mais precisamente as paginas que se refere o layout da NF-e e encontrei isso: Note que o tamanho do código naquela época era de 9 dígitos, depois foi alterado para 8 pois acrescentaram na chave entre o numero e o código o tipo de emissão. Portanto, não se trata de frescura nossa, não é algo novo que a SEFAZ inventou agora para complicar a nossa vida. A recomendação de gerar o código de forma aleatória já faz anos e põe anos nisso. Eu entendi o recado da SEFAZ escrito na última coluna e segui a recomendação. Inclusive no meu artigo: Código Numerico inválido chave não gerada mostro como eu gerava o código na minha aplicação e a alteração que fiz para passar a usar a função que foi criada. Para finalizar, a aplicação é sua faça da forma que achar melhor, motivos para gerar o código de forma aleatória existem de sobra.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.