Painel de líderes

@esbaptista como nosso colega @windsoft informou a resposta é não, mas para que vc não fique simplesmente com uma resposta seca de NÃO, vou explicar o motivo. Como vc mesmo disse, hj tem uma regra, amanhã tem outra, dessa forma se nós do ACBr fizéssemos implementações de regras, nó estaríamos assumindo a responsabilidade de possíveis erros de informações para o fisco, e sinceramente já nos dobramos para dar conta de tento código (ACBr) e é impossível assumir tal responsabilidade de código de regras de Leis. Mas a necessidade imposta por você, me fez vê que o que podemos fazer é criar eventos de nome Check recebendo o Registro com as informações Atual, dessa forma cada um pode implementar sua checagem própria, mas entenda que SPED tem muito código e isso requer tempo, principalmente se não obtivermos ajuda. Vou fazer um teste implementando um evento em um dos registros, e vê se não há algum empecilho, do qual não permita ser feito, caso não haja deixo um código como exemplo e quem for precisando vai usando-o como exemplos para implementar onde precisar.

Correto. Eu entendi a sua necessidade. Antes porem, deve ser observado o que preceitua as normas técnicas para definição do DANFE, não adianta o cliente querer alterar o layout se há regras a serem seguidas. Mais informações no Manual Integração do Contribuinte, em especial o anexo II do respectivo manual. Por isso, devemos observar se tal adequação não irá de encontro com as normas específicas do DANFE.

O exemplo está errado, o correto é seguir o manual, durante o desenvolvimento eu verifiquei isso também.

Boa tarde João, Primeiramente consta na legislação que o emitente da NF-e tem que disponibilizar o XML da NF-e para o destinatário e para a transportadora quando esta for a responsável pelo transporte da mercadoria. A forma mais simples é enviar um e-mail para a transportadora contendo o XML. Desta forma na sua aplicação basta você utilizar os dois componentes ACBrNFe e ACBrCTe. Com o ACBrNFe você vai conseguir ler o XML da NF-e para ler não só a chave como também todos os dados necessários para a emissão do CT-e. A minha aplicação funciona dessa forma, tenho duas opções, sendo que a primeira o funcionário tem que digitar tudo, já a segundo solicitar a importação do XML da NF-e. A rotina de importação se encarrega de fazer tudo, inclusive cadastrar o remetente e o destinatário se necessário sem falar no calculo automático do frete. Outra forma da transportadora obter o XML da NF-e é pedir para o emitente da mesma sempre informar o seu CNPJ no grupo <transporta> Grupo Transportador da NF-e. Se o emitente fizer isso, a sua aplicação poderá se utilizar do método DistribuicaoDFe que existe no componente ACBNFe. Ele retornará o XML completo da NF-e, não havendo a necessidade do emitente da NF-e enviar o XML por e-mail para a transportadora, basta informar o CNPJ da mesma no grupo mencionando acima. Bom, tendo o XML obtido pelo método DistribuicaoDFe ou por e-mail as coisas ficam fácil como demostrado acima. João a ferramente esta ai a sua disposição, arregaça as mangas e bom trabalho.

Façam estudos nos projetos. Antes de qualquer atualização da função formatacep. Grande risco de problemas.

Bastaria atualizar e recompilar os componente utilizando o ACBrInstall_Trunk2, após isso ir no form ou forms que tem o componente de impressão alterar algo no form, não no fonte dele e salvar, assim o Delphi remove a propriedade que não existe mais, então basta recompilar o projeto, melhor seria um buil all. Outra forma é fazer uma busca nos .pas e .dfm pela propriedade e remover a mão, após isso recompilar o projeto.

Jefferson, Esquece o Trunk, no Trunk2 o padrão é para não consultar. Volto a te perguntar o componente esta configurado para consultar após o envio.

Dercide, Anexe o XML de envio gerado ao usar o método Gerar.

Eu recomendaria o SAT da Kryptus, é o único que não utiliza emulação Serial para comunicar com o SAT, utilizar a usb diretamente é muito mais estável. Estou com vários sats deles ligados direto, comunicando no mínimo a cada 30 segundos com a "AC", 24h por dia e a grande maioria deles não teve um retorno sequer de timeout/falha de comunicação. Praticamente todos já efetuaram mais de 40 mil vendas cada.

Você pode emitir a GNRE para a maioria dos Estados neste site. http://www.gnre.pe.gov.br/gnre/portal/GNRE_Gerar.jsp Detalhe: site somente para emissão, não faz nenhum cálculo de valores.

Na mão a correção! no svn e compilando favor testar!

supostamente as transportadoras, desde que devidamente identificadas na nfe, podem fazer a consulta da mesma pela manifestação. como não emitimos o cte não te posso dizer como efetuar. quem sabe uma alma caridosa possa esclarecer mais.

Bom dia, perfeito, muito obrigado

Obrigado pela analise e correção, já foi enviado para o SVN

Bom dia. Fontes modificados em anexo. ACBrMDFeDAMDFeRLRetrato.dfm ACBrMDFeDAMDFeRLRetrato.pas

Bom dia a todos, Graça, não, essa mensagem de erro é do componente e não um retorno do Web Services ou uma tentativa de conexão com ele. Quando comecei a migrar a minha aplicação para usar os componentes do Trunk2 passei por uma situação desse tipo. O problema era a versão errada definida na propriedade VersaoDF. Hoje tenho os componentes ACBrNFe, ACBrNFeDANFE e ACBrMail bem como a rotina de configuração deles em um Data Module, desta forma eu tenho a garantia que feita a configuração ela será valida para tudo o que preciso.

segue pra quem for de ajuda. tabela em sql firebird do enquadramento do IPI CEnq.sql

Bom dia Dercide, Esse erro ocorreu ao utilizar o método EnviarSincrono? Se sim, por favor abra o INI do provedor e altere o valor do campo RecSincrono de zero para 1 na seção [Assinar], realize um novo teste. Se funcionar me avise para que eu possa fazer a alteração e enviar para o repositório.

Bom dia Wislei, Segundo a Nota Técnica 2013/004 versão 1.00a de Outubro/2013 - página 48 diz que o grupo <procEventoMDFe> poderá existir ou não ao Consultar a Situação Atual de um MDF-e. Logo o componente esta agindo conforme a NT. Como esse grupo pode ter várias ocorrências nesse retorno temos então uma lista, se a quantidade de elementos dessa lista for zero significa que não existem eventos, caso contrario existe, sendo assim: qEventos := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Count; if qEventos > 0 then for x := 0 to qEventos -1 do begin TipoEvento := ACBrMDFe.WebServices.Consulta.procEventoMDFe.Items[ x ].RetEventoMDFe.InfEvento.tpEvento; (...) end;

Vc primeiro deve carregar o XML e depois mandar a impressão. Veja o demo. ACBrNFe1.NotasFiscais.Clear; ACBrNFe1.NotasFiscais.LoadFromFile(OpenDialog1.FileName,False); ACBrNFe1.NotasFiscais.Imprimir;

Não ! você deve ter algo em seu delphi que não está adicionando os Alias no dpr de seu projeto vá até as opções de seu dpr no caso project options e na linha unit scope names coloque algo assim Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell;System;Xml;Data;Datasnap;Web;Soap;FMX.Presentation;FMX

Verifique se o numero de ACBrPosPrinter.Colunas... no máximo deve estar 48/50...

Veja o que acontece, vamos explicar a nível de delphi! ao modificar a remover a propriedade do componente e recompilar o mesmo aos próximos forms e datamodulos ele não existirá já nos que aos que tem ele está presente no dfm e somente abrindo esse dfm ou dm para remover e ainda assim precisa modificar ou mexer em algo para que o delphi possa salvar essas alterações nele! então o que o colega fez de desvincular e vincular eles provocou a mudança e salvou no dfm a alteração!

Isso não é uma opção... o suporte a D7 será encerrado...

Bom dia, Katia. Entendi, muito obrigado pela explicação. Grande abraço.

O prazo para fim do suporte ao Delphi 7 é agosto de 2016, é tempo mais do que necessário para qualquer pessoa sozinha migrar um sistema por maior que seja.

Vou deixar minha experiência, eu migrei do D7 para D2007, depois Delphi 2010, e então XE7, XE8 e agora Seattle, porque estás versões? Porque segui a linha do que era estável para mim, agora com as versões XE7 em diante basta recompilar o projeto, não tem segredo. Quando migrei de D7 para D2010 eu tinha essa mesma cabeça de não mudar porque daria trabalho, era milhões de linhas de código para revisar, centenas de tabelas em um BD Firebird e muita, muita regra de negócio, mas não foi um bicho de 7 cabeças. O ganho com o uso de novas versões foi enorme, hoje o Delphi e Lazarus suportam muitos features de linguagem que o D7 nem sonha ter, coisas que facilitam em muito o dia-a-dia, principalmente para quem pensa em programar multi-plataforma e suportar mobile. A dificuldade sempre vai existir, isso é um fato, migrar um sistema não é fácil quando se vem de uma linguagem muito antiga, mas manter Delphi 7 só tem atrasado o projeto ACBr, sempre que vamos fazer algo temos que pensar na limitações do Delphi 7 e nivelar por ela, isso traz transtornos enormes, um exemplo foi alguns dias atrás quando fui implementar a API IBPT no componente ACBrIBPTax, o retorno a API é em JSON uma tecnologia extremamente corriqueira é que é usada em tudo que diz respeito a troca de informações web, mas o Delphi 7 não tem suporte nativo, já Lazarus e versões mais novas do Delphi sim, tive que implementar uma leitura básica de JSON para suprir a necessidade do Delphi 7 para que não tivéssemos que agregar bibliotecas de terceiros e inchar o ACBr com mais uma biblioteca. Este é um exemplo simples, imaginem todo o resto que temos que passar, leitura de XML, listas e afins que já são suportados nativamente em versões mais novas e temos que sermpre fazer tudo manualmente por conta de limitações do D7. Seu problema é dinheiro, acha caro uma nova versão do Delphi, o Lazarus é tão bom quanto, fora a IDE, ele suporta tudo que uma versão de Delphi mais nova suporta e é GRÁTIS e praticamente idêntico ao Delphi 7 em termos de funcionalidades e IDE.

rcfatura, a tag CEST já esta funcionando através do Monitor Plus eu já estou emitindo algumas notas em homologação com essa tag mas o grupo ICMSUFDEST, esse sim eu gostaria de saber se alguém tem previsão de quando vai estar disponível.