Painel de líderes

@Daniel Simoes Atualizei os fontes e mudei para etqDecimoDeMilimetros e agora saiu corretamente. Dercide.

Você está informando or90 Notei que o método TACBrETQPpla.ConverterUnidade poderia ficar com um valor indefinido, o que poderia explicar esses problemas.. apliquei uma possível correção.. Para compatibilização com a versão antiga... usem: etqDecimoDeMilimetros

Bom dia! Lembrando que as NT's trazem informações específicas a esta situação. Na NT2013.005_v1.22.pdf que se não me engano é a ultima que trata da desoneração, na página 11/142 contem a seguinte informação: Não sei te informar se houve alteração no DANFE, até aonde sei não contempla este campo. Caso tenha alguma informação, por favor poste aqui para nos manter atualizados, pois é uma infinidade de NT's e versões de Nt's que se torna difícil de acompanhar tudo.

Bom dia a todos, Para aqueles que em suas aplicações atribuem o valor -1 ao campo cNF (no caso da NF-e/NFC-e) ou cCT (no caso do CT-e/CT-e OS) ou cMDF (no caso do MDF-e) ou cBP (no caso do BP-e), tomem cuidado, pois agora a nova função responsável por gerar a chave vai considerar o valor -1 como sendo zero e portanto o código numérico passa a ser gerado como sendo um numero aleatório e não como um código com base no numero do documento, como era antes. Para resolver esse problema a sugestão é o seguinte: em vez de: ide.cNF := -1; mude para: ide.cNF := GerarCodigoNumerico(ide.nNF); isso vai fazer com que seja atribuído a cNF um código numérico gerado com base no numero do documento, vai ter o mesmo efeito na geração da chave como era antes ao passar o valor -1 para cNF. De forma semelhante fazer o mesmo para o CT-e, MDF-e e BP-e. Lembrando que a função GerarCodigoNumerico se encontra na unit ACBrDFeUtil, logo devemos declara-la no uses da unit que será utilizada.

Pelo que notei não... repare em ACBrNFe.pas no método "function TACBrNFe.Enviar".... que ele chama internamente: NotasFiscais.Assinar; NotasFiscais.Validar; mas isso é o recomendado pelo SEFAZ.. devemos evitar a transmissão de XMLs que não passem na validação do Schema... Talvez mudar isso, possa gerar advertências por parte do SEFAZ ao contribuinte...(assim como no caso de consumo excessivo) A mensagem de recusa da validação do Schema é sempre um tanto genérica e técnica.. muitas vezes ela será incompreensível pelo usuário... A msg de erro, pode variar de acordo com o "engine" de validação de XMLs utilizado, com por exemplo: MSXML, LIBXML2, etc... Minha sugestão é melhorar a sua rotina de validação dos Itens essenciais, antes de preencher o XML

Boa tarde a todos, Foi realizado um Refactoring nas units pcnAuxiliar e ACBrDFeUtil visando eliminar funções em duplicidade. Segue a lista de funções removidas, movidas, renomeadas. Função movida da unit pcnAuxiliar para a ACBrDFeUtil: GerarCodigoNumerico. Função renomeada da unit pcnAuxiliar: de: ExtrairnNFChaveAcesso para ExtrairCodigoChaveAcesso essa mudança no nome se faz necessário uma vez que "nNF" induz que a função só serve para extrair o código numérico de uma chave de NF-e, sendo que na verdade serve para extrair o código numérico de uma chave de NF-e, CT-e, MDF-e e BP-e. Funções removidas da unit pcnAuxiliar: GerarChave, GerarChaveCTe, SomenteNumeros, RetornarCodigoNumerico, RetornarCodigoNumericoCTe, RetornarDigito e RetornarModelo. Em seus lugares devemos utilizar: GerarChaveAcesso (unit ACBrDFeUtil) em vez de GerarChave ou GerarChaveCTe OnlyNumber (unit ACBrUtil) em vez de SomenteNumeros ExtrairCodigoChaveAcesso (unit pcnAuxiliar) em vez de RetornarCodigoNumerico, RetornarCodigoNumericoCTe ExtrairDigitoChaveAcesso (unit pcnAuxiliar) em vez de RetornarDigito ExtrairModeloChaveAcesso (unit pcnAuxiliar) em vez de RetornarModelo Desculpe algum transtorno, mas não podemos ter uma função implementada com nomes diferentes com a mesma finalidade.

Boa tarde, Depois de muito tempo trabalhando em cima, conseguimos aqui na empresa corrigir o problema da assinatura com o certificado A3, e o A1 instalado na máquina para o e-Social (sha-256). Fizemos diversos testes, enviamos e recebemos os recibos normalmente... Segue a unit para análise, testes, e se for o caso ser versionada no componente. É só substituir a unit na pasta: \Fontes\ACBrDFe Valeu! ACBrDFeXsLibXml2.pas

Blz ! Vlw pela orientacao e explicacao

Acho que é apenas a questão de ajustar corretamente as coordenadas para essa etiqueta, nos comandos enviados...

Significa que está enviando um XML definido como contingência (tpEmis = 7 - SVC-RS) para um webservice de autorização normal. Se a intenção é mesmo enviar em contingência, verifique a configuração: ACBrCTe1.Configuracoes.Geral.FormaEmissao := teSVCRS;

Qual é a sua impressora ? Qual o Modelo ? Qual a densidade em DPI ? Aparentemente sua Impressora não detectou o GAP... Tente um reset na Impressora... Verifique se você inseriu a Etiqueta com o GAP no lado correto (veja o sensor na impressora)

Boa Tarde Efetuamos alteração em ACBreSocialWebServices.pas, linha 302, para possibilitar que o transmissor utilize um eCPF ( Exemplo : Escritório Contábil com eCPF e procuração para transmitir o CNPJ do Empregador ), pois anteriormente esta com eCNPJ fixo. Linha Anterior : TpInsc := tiCNPJ Alteração : if Length(TACBreSocial(FPDFeOwner).Configuracoes.Geral.IdTransmissor) = 14 then TpInsc := tiCNPJ else TpInsc := tiCPF; Em anexo arquivo ACBreSocialWebServices.pas. Atenciosamente ACBreSocialWebServices.pas

Boa tarde Iuri, Muito obrigado pela colaboração, já enviei para o repositório.

Você atualizou os fontes pelo SVN?

Boa tarde Edmar, Muito obrigado pela colaboração, já enviei para o repositório.

Perfeito Daniel, vc é o cara! deu certinho!!! Muito obrigado!

O seu vProd no item você colocou o líquido (77.03), sendo que tem que ser o bruto (81.95).

Bom dia, Segundo o retorno esta ocorrendo rejeição 999. Toda vez que ocorrer esse tipo de rejeição não importa o que foi enviado para a SEFAZ, isso significa que o Web Service esta com algum problema e acaba retorno uma mensagem de rejeição genérica.

O ACBr continuará a suportar o D7... Porém observe que as novas versões do Windows (como o Win10) "não gostam" do Delphi 7... e você poderá ter problemas, no futuro, com os binários gerados pelo D7, nas novas plataformas do Windows...

https://www.projetoacbr.com.br/forum/topic/41358-impressão-de-etiquetas-saindo-errada-depois-da-atualização/?do=findComment&comment=274638

Obrigado por responder, Juliomar! No momento, o único motivo são as suítes de componentes de terceiros. Temos um projeto pra mudar de Delphi, mas no exato momento tenho que dar solução em Delphi 7 mesmo. Abraço!

Nesse caso use: etqDecimoDeMilimetros

Também acho interessante, existem vários tópicos que foram abertos de correção de estrutura que poderiam ficar em um lugar só..

Boa tarde.. Consegui localizar o erro... ao passar a Modalidade para o componente, estava passando letras.. Estava passando assim: 'Simples' ao Invés de passar assim: '01'. ai por isso do Si.. Obrigado....

Bom dia Comigo também ocorreu. Ocorre isso no componente TACBrNFeDANFCeFortes. Ao utilizar o ESCPOS está imprimindo corretamente. Fiz o que o Felipe orientou, utilizei a propriedade LarguraBobina, eu vi no TACBrNFeDANFEClass o default dela é 302, então coloquei 295 e saiu corretamente. DM.DanfceFr.LarguraBobina := 295;

Bom dia Nao esquece da tag emit.CRT (Codigo do regime tributario) onde 1=simples nacional 3=regine normal

Conforme xml anexado, ao fazer a consulta do IE no Sintegra, o mesmo informa que não é valido. Verifique também a tag <email>. <CPF>41107978882</CPF> <xNome>NF-E EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL</xNome> -<enderDest> <xLgr>RUA AURELIO FERNANDES</xLgr> <nro>1370</nro> <xBairro>CENTRO</xBairro> <cMun>3508108</cMun> <xMun>BURITAMA</xMun> <UF>SP</UF> <CEP>15290000</CEP> <cPais>1058</cPais> <xPais>BRASIL</xPais> </enderDest> <indIEDest>9</indIEDest> <IE>471773608</IE> <email>CPF 223.488.798-40 RG 34.704.479-7</email>

Não existe nenhuma tag no XML da NFe para informar o RG. Para pessoas físicas comuns somente o CPF deve ser preenchido. No caso das pessoas físicas com inscrição estadual (produtor rural) se informa também a IE dele. Se você está informando o RG na tag destinada a IE a NFe certamente será rejeitada.

@Paulo Alexandre Hostert a Exception é esperando tanto que é tratado por isso continua normalmente, o problema é que a IDE para em toda exception mesmo nas que estão sendo tratada. Sim, há como desabilita-lo. Explicação: Delphi 7 - No menu superior, clique em Tools-Debugger Options abrirá uma janela, navegue até a aba Language Exceptions e você verá uma checkbox dizendo [ ] Stop on delphi exceptionsdesmarque-a, pronto. Delphi 2006 em diante - No menu superior, clique em Tools-Options abrirá uma janela, navegue na lista que tem na esquerda, lá embaixo no final você vai encontrar Debugger Options clique na flechinha pra abrir ele aí você vai encontrar Language Exceptions, ai você vai ter a checkbox lá embaixo escrito Notify on language exceptions, é só desmarcar e pronto.

Bom dia Edmar, Muito obrigado pela colaboração, já enviei para o repositório, com uma correção. Baixe e compare com o que você fez.

Todas essas informações podem ser obtidas no próprio "Manual de Orientação do Contribuinte - versão 6.00", e nas notas técnicas que o atualizam. Aqui mesmo no grupo tem um resuminho das tags de tributações para o regime normal e simples: Acredito que irá ajudar. Fabrício Gomes Araújo

Analise o XML do Soap retornado... provavelmente não há uma resposta de erro nele... Porém pelo que você descreveu.. você já conhece vários dos motivos de rejeição, e sabe que eles são problemas do seu lado (no cadastro)... Então porque gerar esse XML com erro, transmiti-lo, apenas para obter um erro de rejeição ? Não seria melhor você criar uma rotina de validação, antes de alimentar o XML ? No nosso PDV, validamos o Item no momento da Venda... ou seja, se o cadastro do Item possui algum erro de preenchimento, que já conhecemos, emitimos um erro explicando o motivo, e não permitimos a venda do Item...

isso nao é a posicao da carteira/modalidade? Não é a palavra "Simples" que vc colocou onde não devia?

O CSOSN no Danfe já sai com 4 digitos. O primeiro digito é o conteudo da tag <orig> e os outros 3 digitos da tag <CSOSN> -<ICMS> -<ICMSSN101> <orig>0</orig> <CSOSN>101</CSOSN> <pCredSN>1.8500</pCredSN> <vCredICMSSN>0.19</vCredICMSSN> </ICMSSN101> </ICMS>

Desculpem o transtorno, solicitei para o cliente verificar quanto a sua autorização para emissão de CTe, e descobriu-se que não tem autorização. Infelizmente o retorno do erro não é claro quanto a isso. Espero que pelo menos ajude se alguém passar por isso.

Você deverá informar nas tags iniValid das tabelas (Cargos, Estabelecimentos, Turnos, etc) o período inicial de obrigatoriedade de tais eventos no e-Social. Para a Produção Restrita informar 2016-01 Para a Produção informar 2018-01

Caro colega, Se ele é optante pelo simples nacional, ele não vai utilizar CST, e sim CSOSN.

Procede, porem não é o CST e sim o CSOSN

Você precisa Instalar a Impressora no Windows Compartilhar a Impressora em Rede Usar na porta do ACBrETQ algo como \\NomeOuIPServidor\NomeCompartilhamento

Conforme a própria legislação: https://www.confaz.fazenda.gov.br/legislacao/ajustes/2010/aj_003_10, o Código de Situação da Operação no Simples Nacional - CSOSN deverá ser preenchido, sendo que o primeiro indica se o item é Nacional ou Estrangeiro e os três últimos dígitos serão o CSOSN

Ele possui a opção para colocar código de barras basta usar o componente dele e vai imprimir pra ti

Olá, configure isso na tela inicial marcando a flag: "Exibir linhas do Log na tela em Respostas Enviadas" Você deve enviar um comando de cada vez, assim ao enviar o segundo comando será gerado o Título e o PDF. Por favor, no caso de dúvidas crie um novo Tópico sobre o assunto...

Logo chegaremos lá... o Italo está focado no eSocial... mas logo passaremos o pente fino no Reinf

Bom dia a todos, Não detenho conhecimento sobre esse componente, mas analisando a unit mencionada pelo Juliomar achei meio estranho, pois o método GerarEventoXML gera um XML contendo apenas o grupo <ideRecRetorno> vazio, sem nenhum campo. Esta certo isso? Se não esta, logo se faz necessário finalizar a implementação desse evento.

Boa tarde, Muito obrigado pela colaboração, já fiz a correção e enviei para o repositório.

Tive que fazer uma alteração no arquivo Cidades.INI, nos dados originais retornava erro http 404. Não sei se é só um caso pontual ainda Original [3300100] Nome=Angra dos Reis UF=RJ Provedor=Tiplan NomeURL_H=spe.angra.rj NomeURL_P=spe.angra.rj Alterado [3300100] Nome=Angra dos Reis UF=RJ Provedor=Tiplan NomeURL_H=www.spe.angra.rj NomeURL_P=www.spe.angra.rj

Bom dia, O provedor Tiplan não possui os Web Services Gerar e EnviarSincrono somente o Enviar que permite o envio de um lote com até 50 RPS no modo assíncrono. Desfaça as alterações que você fez no arquivo INI do respectivo provedor.

Assim como o SAT em SP acho o MFE um erro no CE. Imagine então uma padaria que fature R$ 15.000,00. 1. Nesta padaria tem um padeiro que ganha R$ 2.000,00 e uma atendente/faz tudo que ganha R$ 1.200,00, cada funcionário com a CLT custa em média 55% a mais do que o salário (com encargos, 13º, 1/3 de férias, etc), folha salarial arredondando, R$ 5.000,00. 2. Compra-se por mês 5.000,00 de produtos (duvido que a padaria ganha 200% em cima dos produtos, mas vamos por esta porcentagem pra ter um exemplo bem caracto). 3. Paga-se de imposto 4% sobre o faturamento bruto (anexo I do simples), R$ 600,00 4. A padaria vende 25% no cartão (vai por mim, é mais que isso), paga-se 2,5% no cartão (média credito/debito), arredondando, R$ 100,00. 5. O prédio é alugado, R$ 1.000,00 6. Energia, água, telefone, combustivel para fazer entregas, CONTABILIDADE, internet etc: R$ 1.500,00. Tem mais custos que isso, mas uma padaria pequena que fatura R$ 15.000,00 custa R$ 13.200,00 nesse calculo rapído, o lucro bruto dessa padaria é R$ 1.800,00, mas máquinas quebram, existem outros gastos sazonais, etc. Logo, aquela atendente de 1200 (custo de 1860 com CLT) ou o padeiro de 2000 (custo de 3100 com CLT) não podem existir (tira-se um emprego), ou a padaria não é sustentável. Ai aparece a SEFAZ (aquela mesmo que cobrou uma quantidade bem grande de impostos do fornecedor e fez o custo subir, e que cobrou mais imposto ainda na folha salarial, etc) e obriga esta empresa a adquirir um KIT que custa R$ 2.000,00 (CE) e R$ 1.500,00 (SP). O NFCe/NFe é o MÁXIMO que a SEFAZ deveria exigir para o Simples Nacional (Comercio), CTe para transporte e NFSe (unificado em ambiente nacional) para Serviços, qualquer coisa acima disso é atrapalhar o empreendedor, e na boa... "só isso" já atrapalharia bastante. PS: Agora imagina que esta padaria é uma tentativa desesperada daquele padeiro que perdeu o emprego porque o estado gastou demais =)

Tenho um cliente que se recusou a migrar para NFe 4.0 por conta de perder o quadro Duplicatas, apresentei a possibilidade de informar o pagamento como sendo Duplicata Mercantil tPag =14 ele não aceitou diante disso abri um chamado ao Sefaz/MS abaixo print do chamado, que respondeu que ira levar o tema para próxima reunião de XML a ser realizada em Salvador .

Não conseguira, precisa ter o CNAE ()TRANSPORTES.