Painel de líderes

Emanuel, vou escrever o que eu entendo ... O PicPay foi criado para transações e-commerce desta forma a integração com sua API, traz estas 2 variaveis que você sitou acima porque? e para que elas servem? ACBrPicpay1.Lojista.URLCallBack, esta URL é passada para o PicPay pois assim que o mesmo detectar uma mudança de status na transação ele avisa a sua aplicação através desta url (ele faz um post em seu servidor/aplicação) (ele não avisa o status atual avisa apenas que a transação sofreu uma alteração de status) ACBrPicpay1.Lojista.URLReturn, esta segunda é para onde o cliente será redirecionado quando ele realizar o pagamento da transação via web todas 2 urls são obrigatórias, mas podem ser urls "invalidas" (no formato correto, mesmo sem existir) caso o seu uso seja apenas desktop como assim? você pode criar pagamentos, enviar para o PicPay, esquecer estes lá (o picpay comunica ao cliente via push notification, e email) ai depois para você saber se foi pago ou não você consulta o status deste pagamento, e se estiver tudo ok, você libera a transação vai ficar de forma manual? vai é o melhor uso? não o PicPay foi criado para isso? não mas podemos usar e integrar nossas aplicações desta forma mais eu queria deixar de forma automática, não tem como? tem sim basta você seguir a ideia do Thulio e criar (ter) servidor web para ficar fazendo o meio de campo (escutado as respostas do PicPay, e enviado para sua aplicação desktop as repostas através do Redis) é uma gambiarra? é, mas funciona

Minha classe já esta validando as saídas 1200 e 1300, falta só a 1400 e 1500 agora.

Boa tarde. Encontrei um problema ao exportar NFS-e para PDF. O componente não estava conseguindo montar o nome do arquivo quando não informado. Método "TACBrNFSeDANFSeFR.ImprimirDANFSePDF(NFSe: TNFSe);" Bastou retirar o WITH que o problema resolveu. (O delphi estava se perdendo entre o parâmetro do método e o WITH - NFSe). Segue unit corrigida. Atenciosamente. ACBrNFSeDANFSeFR.pas

Olá Pessoal, Novidades para quem tem aplicações que emitem o CT-e Conhecimento de Transporte Eletrônico. Trata-se de uma nova modalidade de documento o GTV-e (Guia de Transporte de Valores Eletrônico) modelo 64. O GTV-e será emitido por contribuintes que possuírem credenciamento para a emissão do CT-e OS Conhecimento de Transporte Eletrônico Outros Serviços. Alterações no layout do CT-e OS no que diz respeito ao Transporte de Valores: Apesar da NT 2020/001 que trata sobre o GTV-e não deixar claro, o que tudo indica é que após a emissão do GTV-e se faz necessário a emissão de um CT-e OS de Transporte de Valores. Visto que o layout do CT-e OS foi alterado, agora ele vai conter um grupo com "N" ocorrências chamado: infGTVe (Grupo de informações da GTVe relacionadas ao CT-e OS de Transporte de valores). Portanto a empresa poderá emitir vários GTV-e e depois informa-los todos em um único CT-e OS de Transporte de Valores. Alterações no layout do CT-e OS no que diz respeito ao Excesso de Bagagem: Uma outra alteração no layout do CT-e OS é a inclusão da tag chBPe no grupo infDocRef, com isso esse grupo ou vai conter a chave do BPe ou os dados do documento referenciado. É sabido que existe o CT-e OS de Excesso de Bagagem e que agora vamos passar a ter o Evento de Excesso de Bagagem para o BP-e Bilhete de Passagem Eletrônico. Caso a Empresa emita um BP-e e depois um evento de Excesso de Bagagem, poderá emitir um CT-e OS de Excesso de Bagagem e referenciar a chave do BP-e no grupo infDocRef. Observações: O layout do GTV-e é bem simples e não possui o grupo de impostos como ICMS, dai a necessidade de emitir depois o CT-e OS de Transporte de Valores. Ainda não foi publicado uma NT com o layout do Documento Auxiliar do GTV-e. A Nota técnica já se encontra em nossa biblioteca, clique aqui para baixar. Prazos para implantação do GTV-e: 08/2020 - Ambiente de Homologação. 09/2020 - Ambiente de Produção. Já estamos trabalhando nas alterações necessárias no componente ACBrCTe para que ele venha permitir o envio do GTV-e.

Sim eu também já homóloguei com a caixa para outras empresas mas este gerente aí quem passou inclusive ele pediu para usar o layout 107 quando na verdade é o 50 e o layout do lote pediu 67 e o padrão e 30 estou aguardando retorno

Isso está além do que o ACBr faz... ele apenas usa as classes do FPC, para comandar a impressão em modo Raw... OldRawMode := Printer.RawMode; Printer.RawMode := True; // < -- LIGA O MODO RAW try Printer.BeginDoc; Written := 0; Printer.Write(AString[1], Length(AString), Written); Printer.EndDoc; finally Printer.RawMode := OldRawMode; end; Pode ser algo como o CUPs implementa o modo RAW, ou ainda no Driver dessa impressora... como você vê no código acima, não há muito que possa ser feito, do lado do ACBr... Mas como funciona no driver de Impressoras não fiscais, me faz pensar que existe alguma configuração diferente no Spool do Driver da Impressora de Etiquetas...

Bom dia Juliomar, Em teoria não há nada específico nesse provedor, ele já funcionava muito bem antes (GovDigital) e houve alteração apenas da url. Pelo menos para mim apresentou problemas somente após atualização dos componentes e o pior é que a versão que estava rodando era provavelmente bem antiga, coisa de 1 ano atrás pois fazia tempo que não mexia no sistema. Eu acredito que tenho a versão anterior do ACBr e vou fazer um compare com a versão atual para investigar o que tanto mudou (mas acredito ser muita coisa pelo tempo) o que dificultará a análise. Também vou pegar o exe antigo do sistema e mudar só a url no arquivo .ini e ver se ainda consigo conectar, caso positivo provavelmente houve alguma alteração no componente que impactou. Vou postando os avanços aqui. Obrigado

Verifique se no Spool da Impressora, é necessário marcar algo como Impressão direta, Modo RAW, enviar direto para a impressora, ou algo semelhante...

Quem envia as Vias a serem impressas é o emulador... talvez seja melhor entrar em contato com a Sw.Express

Hoje fiz uma nova instalação do meu sistema em um windows server 2016, e o acbrmail só passou a enviar os e-mails após instalar o VC_redist.x86 visual c++

Agora sim entendi... existe o codigoMora e codigoMoraJuros. Valeu. Desculpa o trabalho....

Sefaz suspende exigência do CEST em documentos fiscais A Secretaria de Fazenda (Sefaz) suspendeu o início da exigência do Código Especificador da Substituição Tributária (CEST) nas notas fiscais Eletrônica (NFe) e de Consumidor Eletrônica (NFCe). A obrigatoriedade da informação do CEST nos documentos fiscais estava prevista para vigorar a partir do dia 1º de junho de 2020. A medida foi adotada devido ao momento vivido no país com a pandemia do novo coronavírus – Covid-19, conforme orientação da Coordenação Nacional do Encontro Nacional dos Administradores Tributários – ENCAT. Segundo a Coordenação, a validação do CEST será implementada futuramente. A aplicação da regra da validação do CEST consta na Nota Técnica 2015/003 versão 1.94. O Código foi instituído no Convênio ICMS 92/2015 e deve ser informado utilizando o NCM/SH. Essa Noticia foi extraída do site da SEFAZ-MT.

Olá Pessoal, Foi publicada na data de hoje a NT 2020/002 que trata sobre o Imposto sobre produtos industrializados - IPI. Não se faz necessário nenhuma alteração no componente pois não ocorreu nenhuma alteração no layout do XML. Essa NT apenas esta consolidando informações das NT 2015/002 e NT 2016/001 e também a possibilidade de usar 3 novos códigos de Enquadramento. Sendo assim o campo <cEnq> poderá aceitar os novos códigos abaixo: cEnq Grupo CST Descrição Enquadramento Legal do IPI 163 Suspensão REPETRO-Industrialização Venda no mercado interno de matérias-primas, produtos intermediários e materiais de embalagem para serem utilizados integralmente no processo de industrialização de produto final destinado às atividades de exploração, de desenvolvimento e de produção de petróleo, de gás natural e de outros hidrocarbonetos fluidos à PJ habilitada no Repetro-Industrialização. - Instrução Normativa RFB nº 1901, de 17 de julho de 2019. 164 Suspensão REPETRO-SPED Venda dos produtos finais destinados às atividades de exploração, de desenvolvimento e de produção de petróleo, de gás natural e de outros hidrocarbonetos fluidos previstas na Lei nº 9.478, de 6 de agosto de 1997 , na Lei nº 12.276, de 30 de junho de 2010, e na Lei nº 12.351, de 22 de dezembro de 2010, por fabricantes desses, beneficiários do Repetro-Industrialização, quando diretamente adquiridos por pessoa jurídica habilitada no Repetro-Sped.- Instrução Normativa RFB nº 1901, de 17 de julho de 2019. 165 Suspensão O transportador com relação aos produtos tributados que transportar desacompanhados da documentação comprobatória de sua procedência; qualquer possuidor - com relação aos produtos tributados cuja posse mantiver para fins de venda ou industrialização; o industrial ou equiparado, mediante requerimento, nas operações anteriores, concomitantes ou posteriores às saídas que promover, nas hipóteses e condições estabelecidas pela Secretaria da Receita Federal, nos termos da IN RFB nº 1.081/2010. A partir do dia 30/05/2020 o ambiente de homologação vai passar a aceitar os novos códigos acima, já o ambiente de produção somente 11/06/2020.

Boa tarde, iniciei os estudos para implementar a emissão do MDF-e, e uma das regras que mais me chamou atenção foi sobre as informações do percurso do manifesto, nas viagens intermunicipais. Gostaria de compartilhar um pequeno projeto desenvolvido em Lazarus, (meu objetivo é montar um cadastro de percursos, a fim de evitar a rejeição de "Percurso inválido") considerando as seguintes validações verificadas na documentação do MDF-e: Validações SEM percurso: 1) UF ini e UF fim são iguais -> não deve selecionar nenhuma UF de percurso 2) UF ini e UF fim são diferentes e fazem divisa -> não deve selecionar nenhuma UF de percurso Validações COM percurso: 3) nem UF ini nem UF fim devem estar selecionadas no percurso. 4) a primeira UF da lista deve fazer divisa com a UF inicial (carregamento) 5) entre as UF selecionadas, cada UF deve fazer divisa com a UF seguinte, na ordem de cima para baixo. 6) a ultima UF da lista deve fazer divisa com a UF final (descarregamento) Basicamente, foi montada uma classe TUF (uufclass.pas), onde para cada objeto de UF criado, ele cria num vetor a lista das outras UF que fazem divisa com esta. Também tem um Form mostrando como o usuário informaria as UF inicial e final, assim como selecionar (TCheckListBox) as UFs do percurso. Também é possível ordenar as UFs (TListBox). Por último, foi feito uma "perfumaria", desenhando o percurso selecionado, no mapa do Brasil (TImage). Espero que seja útil, qualquer sugestão é bem vinda. Att Ricardo valida_percurso_lazarus.zip

Olá Pessoal, Muitos desenvolvedores acabam escolhendo um dos 3 métodos de envio de RPS e nem sempre funciona, porque? É muito simples, primeiro temos que separar os provedores em 3 grupos: os que seguem a versão 1 do layout da ABRASF, os que seguem a versão 2 e os que tem o seu próprio layout. Os provedores que seguem a versão 1 do layout da ABRASF oferecem somente o serviço de envio assíncrono, portanto só podemos usar o método Enviar do componente, esse método permite o envio de um lote contendo de 1 até 50 RPS. Os provedores que seguem a versão 2 do layout da ABRASF a principio oferecem os serviços: envio assíncrono, envio síncrono e gerar NFSe, respectivamente no componente temos os métodos: Enviar, EnviarSincrono e Gerar, onde os dois primeiros permite o envio de um lote contendo de 1 até 50 RPS e o último o envio de apenas 1 RPS. Destaquei "a principio" porque ao implementar dezenas de provedores que seguem a versão 2 no componente, notei que vários não disponibilizaram os 3 serviços e sim apenas um ou dois dos três sugeridos pelo layout. Logo não é possível afirmar que todos os provedores que seguem a versão 2, disponibilizam os 3 serviços de envio. Já os provedores que tem o seu próprio layout, não tem como estabelecer uma regra, pois cada um implementou o serviço que melhor lhe convém. Além dos serviços de envio, temos também os de consulta, cancelamento e substituição de NFSe. Como faço para saber quais são os serviços disponibilizados pelo provedor que vou utilizar, bem como o layout que ele segue? É muito simples, basta abrir o arquivo INI do mesmo. Na seção XML temos o campo Layout que pode conter os seguintes valores: ABRASFv1, ABRASFv2 ou outro valor (normalmente o nome do provedor). No caso de um valor diferente de ABRASFv1 e ABRASFv2 fica claro que não segue nenhuma das versões da ABRASF, logo tem o seu próprio layout. Para saber os serviços oferecidos pelo provedor basta olharmos para as seções: [Recepcionar] => Responsável por montar o envelope de Envio assíncrono, se consta a definição do envelope significa que este serviço esta disponível. [ConsSit] => Responsável por montar o envelope de Consulta a Situação do Lote, se consta a definição do envelope significa que este serviço esta disponível. [ConsLote] => Responsável por montar o envelope de Consulta ao Lote, se consta a definição do envelope significa que este serviço esta disponível. [ConsNFSeRps] => Responsável por montar o envelope de Consulta NFSe por RPS, se consta a definição do envelope significa que este serviço esta disponível. [ConsNFSe] => Responsável por montar o envelope de Consulta NFSe, se consta a definição do envelope significa que este serviço esta disponível. [Cancelar] => Responsável por montar o envelope de Cancelar NFSe, se consta a definição do envelope significa que este serviço esta disponível. [Gerar] => Responsável por montar o envelope de Gerar NFSe, se consta a definição do envelope significa que este serviço esta disponível. [RecSincrono] => Responsável por montar o envelope de Envio síncrono, se consta a definição do envelope significa que este serviço esta disponível. [Substituir] => Responsável por montar o envelope de Substituir NFSe, se consta a definição do envelope significa que este serviço esta disponível. Exemplo de um Envelope não definido, portanto serviço não disponibilizado no webservice do provedor: [ConsSit] IncluiEncodingCab=0 IncluiEncodingDados=0 Texto1= Exemplo de um Envelope definido, portanto serviço disponibilizado no webservice do provedor: [ConsSit] IncluiEncodingCab=0 IncluiEncodingDados=0 Texto1=<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> Texto2=<S:Body> Texto3=%DadosMsg% Texto4=</S:Body> Texto5=</S:Envelope> Conselho: Tenha uma tela de configuração que permite ativar ou não a execução de cada um desses métodos, assim a sua aplicação pode enviar o RPS através do método ou outro dependendo da configuração estabelecida por conta do provedor a ser utilizado.