Painel de líderes

Olá Pessoal, Mais um documento fiscal eletrônico a vista. Portal do DC-e: Portal da Declaração de Conteúdo Eletrônica (svrs.rs.gov.br) Está disponível no Portal dos Documentos Fiscais Eletrônicos a área temática dedicada a Declaração de Conteúdo Eletrônica - DCe. Nesta área poderá ser encontrado material técnico como Manuais e Schemas, Legislação, Notícias e serviços relacionados ao documento fiscal. O que vem a ser o DC-e: O Projeto DCe tem como objetivo a implantação de um modelo nacional de declaração de conteúdo eletrônica, visando a substituir a sistemática de utilização da declaração de conteúdo em papel, melhorando a visibilidade dessa declaração e permitindo, ao mesmo tempo, o acompanhamento em tempo real das operações. No Portal encontramos os Manuais e os Schemas, ainda não estão disponíveis as URLs de homologação e de produção (vamos aguardar). Para informações sobre a legislação, acesso o portal pois estão disponíveis tanto o ajuste SINIEF que instituiu o DC-e quanto o Ato COTEPE.

Olá boa tarde Diego!! Após quebrar a cabeça aqui achei o problema ... era a versão do java que estava desatualizada aqui no PC. Obrigada pela atenção!

Bom dia @Aggille Sistemas de Gestão, Na versão 2.04 devemos atribuir o código da Obra e a Arte nos respectivos campos: NFSe.ConstrucaoCivil.CodigoObra := 'código da obra'; NFSe.ConstrucaoCivil.Art := 'arte';

Olá Pessoal, Muitos DF-e (Documentos Fiscais Eletrônicos) foram implementados para o seu envio ser em Lotes contendo de 1 até 50 documentos. Esse modo de envio em lote funciona no modo assíncrono. Outros DF-e já foram implementados com o modo de envio unitário, ou seja, só podemos enviar um documento por vez, consequentemente esse modo de envio funciona no modo síncrono. A primeira diferença que podemos notar é: No envio assíncrono podemos enviar um lote contendo de 1 até 50 documentos, já no envio síncrono podemos enviar somente um documento por vez. A segunda diferença diz respeito ao retorno: No envio assíncrono temos como retorno do webservice um numero chamado de Recibo que atesta que o webservice recebeu o lote enviado, por outro lado no envio síncrono não temos o numero do Recibo como retorno. A terceira diferença se refere ao resultado do processamento: No envio assíncrono devemos realizar uma consulta se utilizando do numero do Recibo. É o retorno dessa consulta que nos vai dizer se o(s) documento(s) enviado(s) para o webservice foi ou foram processado(s) com sucesso. Já no envio síncrono não temos no retorno o numero do Recibo, logo não temos como realizar a consulta pelo numero do Recibo, alias não se faz necessário uma vez que no retorno do envio síncrono o que temos de retorno já é o resultado do processamento, portanto já temos na resposta se o documento foi processado com sucesso ou não. DF-e que já nasceram com o modo de envio Síncrono: BP-e = Bilhete de Passagem Eletrônico BP-e TM = Bilhete de Passagem Eletrônico Transporte Metropolitano GTV-e = Guia de Transporte de Valores Eletrônico DC-e = Declaração de Conteúdo Eletrônica NFCom = Nota Fiscal de Comunicação Eletrônica DF-e que nasceram com o modo de envio Assíncrono e que mudaram ou vão mudar para Síncrono: CT-e = Conhecimento de Transporte Eletrônico (desde 06/2023 só funciona o modo Síncrono) CT-e OS = Conhecimento de Transporte Eletrônico Outros Serviços (desde 06/2023 só funciona o modo Síncrono) MDF-e = Manifesto de Documentos Fiscais Eletrônicos (Modo Assíncrono será desativado em 30/06/2024) NFC-e = Nota Fiscal ao Consumidor Eletrônica (desde 04/09/2023 só funciona o modo Síncrono) DF-e que possui os dois modos de envio Assíncrono e Síncrono: NF3-e = Nota Fiscal de Energia Elétrica Eletrônica Observação: Notem que nas listas acima não aparece a NF-e = Nota Fiscal Eletrônica, o motivo é que a NF-e nasceu somente com o modo Assíncrono de envio, depois passou a ter o modo de envio Síncrono, mas este modo não se encontra disponível na SEFAZ de São Paulo e Bahia. O Fisco já sinalizou que pretende acabar com o modo de envio Assíncrono da NF-e, deixando somente o modo Síncrono. A motivação para essa mudança é que por volta de 90% dos lotes recepcionados por todas as SEFAZ de todas as UF possuem somente um documento. Sendo assim não faz muito sentido consumir dois serviços (Recepção e Consulta) para apenas um documento, lembrando que no modo Assíncrono se faz necessário a Consulta pelo numero do Recibo para obter o resultado do processamento. Já que 90% dos contribuintes enviam as suas notas de forma unitária, ou seja, uma nota por vez, tanto a SEFAZ quanto o desenvolvedor do Software sairiam ganhando com essa mudança, pois a SEFAZ eliminaria o serviço de Consulta pelo numero do Recibo e o Software ficaria mais rápido pois não precisaria executar essa consulta. Quando vai ocorrer essa mudança não sei, o Fisco não disse quando, mas vai ocorrer. Codificação para quem utiliza os componentes: A titulo de exemplo será utilizado o componente ACBrMDFe, mas podemos replicar para os demais. O método Enviar possui 3 parâmetros: function Enviar(const ALote: String; Imprimir: Boolean = True; ASincrono: Boolean = False): Boolean; overload; ALote = Numero do Lote que contem os documentos a serem enviados para o webservice da SEFAZ. Imprimir = Se True (valor padrão) diz que o Documento Auxiliar vai ser impresso no final do processo, se False diz que não vai ser impresso. ASincrono = Se False (valor padrão) diz que o modo de envio é Assíncrono, se True diz que o modo de envio é Síncrono. Exemplo de Envio no modo Assíncrono (só deve ser utilizado pelos DF-e que ainda possuem esse modo de envio): ACBrMDFe1.Enviar(NumLote); ou ACBrMDFe1.Enviar(NumLote, False); Exemplo de leitura do retorno do envio no modo Assíncrono: with MemoDados do begin Lines.Add(''); Lines.Add('Envio MDFe'); Lines.Add('tpAmb: ' + TpAmbToStr(ACBrMDFe1.WebServices.Retorno.tpAmb)); Lines.Add('verAplic: ' + ACBrMDFe1.WebServices.Retorno.verAplic); Lines.Add('cStat: ' + IntToStr(ACBrMDFe1.WebServices.Retorno.cStat)); Lines.Add('xMotivo: ' + ACBrMDFe1.WebServices.Retorno.xMotivo); Lines.Add('cUF: ' + IntToStr(ACBrMDFe1.WebServices.Retorno.cUF)); Lines.Add('xMsg: ' + ACBrMDFe1.WebServices.Retorno.Msg); Lines.Add('Recibo: ' + ACBrMDFe1.WebServices.Retorno.Recibo); Lines.Add('Protocolo: ' + ACBrMDFe1.WebServices.Retorno.Protocolo); end; Exemplo de Envio no modo Síncrono (utilizado pelos DF-e que só possuem ou também tem este modo de envio): ACBrMDFe1.Enviar(NumLote, True, True); ou ACBrMDFe1.Enviar(NumLote, False, True); Exemplo de leitura do retorno do envio no modo Síncrono: with MemoDados do begin Lines.Add(''); Lines.Add('Envio MDFe'); Lines.Add('Chave: ' + ACBrMDFe1.Manifestos[0].MDFe.procMDFe.chMDFe); Lines.Add(''); Lines.Add('tpAmb: ' + TpAmbToStr(ACBrMDFe1.WebServices.Enviar.tpAmb)); Lines.Add('verAplic: ' + ACBrMDFe1.WebServices.Enviar.verAplic); Lines.Add('cStat: ' + IntToStr(ACBrMDFe1.WebServices.Enviar.cStat)); Lines.Add('xMotivo: ' + ACBrMDFe1.WebServices.Enviar.xMotivo); Lines.Add('cUF: ' + IntToStr(ACBrMDFe1.WebServices.Enviar.cUF)); Lines.Add('xMsg: ' + ACBrMDFe1.WebServices.Enviar.Msg); Lines.Add('Recibo: ' + ACBrMDFe1.WebServices.Enviar.Recibo); end; E para quem usa ACBrLib ou ACBrMonitorPLUS? Os diferentes modos de envio também são considerados e estão disponíveis em ambas as soluções. No que diz respeito ao envio, os comandos também possuem um parâmetro que define se o envio será síncrono ou assíncrono. Vamos ver o exemplo do MDFe: Para a ACBrLib: MDFE_Enviar(ALote, AImprimir, ASincrono, sResposta, esTamanho); ALote: Número do Lote a ser enviado. AImprimir: Se True, imprime DAMFDe caso o MDFe seja autorizado. ASincrono: Se True envia o MDFe em modo sincrono. sResposta: Usado pelo retorno, contem as informações retornadas pela consulta. esTamanho: Usado pelo retorno, contem o tamanho da string (sResposta). Então o comando ficaria: MDFe_Enviar(ALote, AImprimir, False, sResposta, esTamanho) ou MDFe_Enviar(ALote, AImprimir, True, sResposta, esTamanho) Para o ACBrMonitorPLUS: MDFE.ENVIARMDFe(nXMLMDFe, [nLote], [nAssinar],[nImprimi],[nImpressora], [bAssincrono], [bEncerrado] ) nXMLMDFe: Caminho do XML do MDF-e nLote: Número do Lote (opcional) nAssinar: Assinar o XML (opcional - informe 0 para não assinar) nImprimi: Imprimir MDF-e (opcional - informe 1 para imprimir) nImpressora: Nome da Impressora (opcional) bAssincrono: Por padrão o envio é Assíncrono, informa "False" para envio Sincrono bEncerrado: Imprimir Mensagem de "MDFe Encerrado", (opcional - informe 1 para imprimir) Ficando: MDFe.EnviarMDFe(nXMLMDFe, nLote, nAssinar, nImprimi, nImpressora, True, bEncerrado) ou MDFe.EnviarMDFe(nXMLMDFe, nLote, nAssinar, nImprimi, nImpressora, False, bEncerrado) A hora de ler a resposta também muda um pouco. No envio assíncrono, temos uma seção [Envio], [Retorno] e [MDFe + Numero do Documento]. Já no envio síncrono, não existe mais a seção [Retorno] e a seção MDFe é concatenada com a chave de acesso. Resposta Assíncrona: [Envio] CStat= CUF= DhRecbto= Msg= NProt= NRec= TMed= TpAmb= VerAplic= Versao= XMotivo= Xml= [Retorno] CStat= CUF= ChaveDFe= DhRecbto= Msg= Protocolo= VerAplic= Versao= XMotivo= cMsg= nRec= tpAmb= xMsg= [MDFe1] Id= XML= cStat= chDFe= dhRecbto= digVal= nProt= tpAmb= verAplic= xMotivo= Resposta Síncrona: [Envio] CStat= CUF= DhRecbto= Msg= NProt= NRec= TMed= TpAmb= VerAplic= Versao= XMotivo= Xml= [MDFe12345678901234567890123456789012345678901234] Id= XML= cStat= chDFe= dhRecbto= digVal= nProt= tpAmb= verAplic= xMotivo=

Olá pessoal! Foi publicada a versão 24.1.D das tabelas fornecidas pelo IBPT, as quais já se encontram também em nosso SVN. As novas tabelas tem vigência de 20/04/2024 até 31/05/2024. Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto", não se esqueça de realizar a atualização de seus clientes. Fonte: De Olho no Imposto

Você salvou as dlls na mesma pasta na aplicação? No seu primeiro print está selecionada homologação, tente mudar para produção. Teste com o programa de exemplo no cliente para ver se ocorre o mesmo problema, na aba consultas existe o botão Consulta Cadastro

Resolvido usando o método NFSE_ConsultarNFSeGenerico.

Agora funcionou corretamente. Muito obrigado pela ajuda!

Bom dia! Você está carregando no componente um XML de retorno de envio de lote. Veja que a tag pai dele é <EnviarLoteRpsSincronoResposta > . Por isso o componente não consegue ler as informações. Você precisa carregar um XML de uma NFSe. Ele começa em <CompNFSe>

Bom dia Antonio, Muito obrigado pela colaboração, já inclui na minha lista de tarefas para analise. TK-5379

Bom dia! Por favor, vejam se a resposta deste tópico lhes é útil:

Bom dia @tryideas sistemas, Se tratando do Padrão Nacional a emissão de notas via portal (site) podemos usar o usuário e senha, mas via webservice se faz necessário o uso do certificado digital, pois o XML do DPS (Declaração Provisória de Serviço) que devemos gerar e enviar para o webservice deve ser assinado digitalmente.

Bom dia @C4Dev, Vou rever a alteração que fiz.

Bom dia @Mauricio Elias e @lucimauro, Os contadores dos seus clientes o que dizem sobre essa questão? Por se tratar de um assunto fiscal o melhor caminho é procurar um bom contador.

Bom dia @ROGERIOHFB, Veja se isso lhe ajuda:

Bom dia @Mcq Desenvolvimentos, Usando os Schemas que se encontram na pasta: ...\Exemplos\ACBrDFe\Schemas\CTe ocorre o mesmo erro? Lhe pergunto isso, pois nessa pasta existe o arquivo cteModaAquaviario_v4.00.xsd Ao atualizar o ACBr, você atualiza todos os fontes de todas as pastas? Após a atualização reinstala o ACBr? Após a reinstalação compila a aplicação com a opção Build? Siga sempre esta lista: Você tem fontes do ACBr com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build. Por fim repita os testes.

Obrigado pela contribuição. Criada TK-5377 para análise.

@Renato Rubinho Bom dia, enviei os dados no [email protected], em relação manual foi o mesmo em anexo, eu só testei em produção.

Essa url pix.santander.com.br/qr/v2/cobv/1041accf-a5a8-4278-89a4-fd7821aac930 e parte do conteúdo que deve ser utilizado para gerar a Imagem do QrCode. Conforme a Nota 27 que consta no print do @Diego Foliene, a imagem do QrCode deve ser gerada conforme as regras do Banco Central. 1. Veja no manual do Banco Central que a url que você recebe no retorno é apenas parte do qrcode * Para maiores detalhes, leia o manual do banco central, para entender o processo * Explicando parcialmente como é a composição dessa string, ela é quebrada nestes grupos, conforme abaixo * Em cada grupo, os dois primeiros dígitos indicam o ID a que se refere o valor do grupo * O terceiro e o quarto dígitos indicam a quantidade de dígitos que o valor terá * A sequência é o valor, obtido a partir do quinto dígito até a quantidade de dígitos especificada no terceiro e quarto dígito 000201 010212 26700014br.gov.bcb.pix 2548pix.example.com/8b3da2f39a4140d1a91abd93113bd441 52040000 5303986 5802BR 5913Fulano de Tal 6008BRASILIA 62070503*** 630464E4 2. String final detalhada no item 1 00020101021226700014br.gov.bcb.pix2548pix.example.com/8b3da2f39a4140d1a91abd93113bd44 15204000053039865802BR5913Fulano de Tal6008BRASILIA62070503***630464E4 3. Analise o método PIXQRCodeDinamico, da classe TACBrBoletoPIXQRCode ( ../trunk2/Fontes/ACBrBoleto/ACBrBoleto.pas ) * Ele gera o EMV (string completa conforme destacado no item 1) * Esse conteúdo gerado é o que deverá ser utilizado para a imagem do QrCode

Boa tarde! É alguma nota emitida em uma operação especial? Como devolução ou algo assim? Simples Nacional não tem destaque de ICMS, porém quando existe uma condição legal, você deve usar o CSOSN 900 e preencher os campos correspondentes.

Ótimo! Muito obrigado!

Boa tarde! O web service de homologação do Fiorilli possui uma divergência com o de produção nesse sentido.(Entendemos que seja um bug do lado deles). Para isso foi criada a configuração intitulada "Assinaturas": Altere no seu arquivo ACBrLib.ini, na seção [NFSe] para opção correspondente a "Não Assinar" e faça novo teste no ambiente de homologação.

Como você pode ver na descrição do próprio link que você postou não é oficial. Ainda não fomos contatados sobre esse link e nem sobre o motivo de terem usado o nome "ProjetoACBr". No momento não vemos problemas de alguém hospedar o código no GitHub. Mas gostaríamos de ser contatados. Se alguém souber quem está por trás desse link específico, pedimos para que os avise para entrar em contato conosco. Em especial, podem procurar o @Daniel Simoes, a @Juliana Tamizou . Também estou a disposição. Há possibilidade de no futuro mantermos um mirror oficial do GitHub? Sim. Quando? Não sabemos...

CustomPos é outro protocolo... A LX300 usa Esc/P2

sim todas indexadas, tabela master com 21 mil registros.ja resolvir passei para UNIDAC( 10 X mais rapido que firedac ). nem tudo nativo sao mil maravilhas. o unidac em termos fetch é muito mais poderoso que o firedac.