Painel de líderes

Boa tarde Buzz e Daniel, Esta mensagem ainda vai aparecer para os equipamentos. Neste momento que se segue após a publicação da homologação a atualização do SAT é voluntária, e nós recomendamos que seja feita pois já atende os layouts 006 e 007 simultaneamente. Quando a Sefaz começar a atualização em massa a retaguarda irá enviar a mensagem que existe uma nova atualização a ser feita. Essa mensagem é enviada em um certo dia, depois de 7 dias é enviada novamente, no 10 dia é enviada pela ultima vez, após isso chega o comando para atualização. Nossa recomendação é que todos atualizem o SW Básico voluntariamente antes deste período, pois para atualizar o SW Básico o SAT deve enviar todas as vendas para a Sefaz antes de atualizar, que dependendo da quantidade de cupons pode levar vários minutos, e isso significa sua frente de loja parada. Além da Tanca esta atualização abrange as seguintes marcas que compartilham o mesmo projeto, Oki, Unisys, Toshiba, ACBr e Daruma. Att Cristiano Abbud

A correção já está no SVN

Já foi ajustado a alguns dias atrás... Atualize seus fontes pelo SVN...

Boa tarde. Atualmente esta classe não possui implementação para enviar mensagens no registro S, porém no registro R é possível informar as mensagens nas que serão informadas nas posições 100 a 179, bastando informar a propriedade Mensagem. Att.

Vish então a coisa tá feia!

Boa tarde Bruno, Foi feita uma alteração para que o componente possa ler o retorno logo após o envio, todos os seus fontes estão atualizados? De uma olha na function: LerXML_proSP que esta na unit pnfsEnvLoteRpsResposta.pas

Boa tarde Fábio, Favor atualizar todos os fontes de todas as pastas. Note que fiz uma alteração no arquivo INI do provedor.

Você está correto... não havia reparado no detalhe da primeira coluna... Apliquei modificações no SVN, que podem resolver o problema... Favor atualizar e testar

Bom dia Italo, Pois é mais uma vez erro deles, ainda bem que já foi resolvido. Obrigado a todos.

Enviei um ajuste para a Impressão de Cod.Barras da Bematech que pode auxiliar na resolução do problema -- ACBrECFEscECF -- [-] Correção em "LinhaRelatorioGerencial", na impressão de Cod.Barras ou caracteres de controle, que continham CR ou LF (por: DSA)

Olá Itlao, Nos próximos 15 dias estaremos homologando a prefeitura de SP em nosso sistema. Informo os resultados dos testes aqui. Abraços,

Na verdade, se usar o ACBrPosPrinter, não precisa do Driver Spool da impressora... Se a Impressora for USB, vc precisará de um Driver de COM virtual... mas se ela for Serial, não é necessária nenhuma instalação... isso porque o ACBrPosPrinter acessa a porta Serial ou TCP, diretamente... Mas é muito importante, selecionar o protocolo (modelo) "EscPos", correto no componente, de acordo com a compatibilidade da impressora

LazReport está muito bom... tem Editor de Formulários, Query builder, Edição de relatórios em Runtime... Ainda estão corrigindo alguns bugs, o que as vezes necessita usar a versão do SVN...

Bom dia! No Ajuda do ACBrMonitorPLUS tem como fazer a criação da NFe a partir do txt no leiaute da SEFAZ. NFe.CriarNFeSEFAZ(cTXTSefaz,[bRetornaXML]) Comando para ser passado como parâmetro o caminho do arquivo criado no formato usado pelo emissor gratuíto de SP.

Olá Daniel, Tudo bem ? Nem sei como agradecer, fiz a atualização e testei o envio. Funcionou tudo perfeitamente. Grande abraço,

O FortesReport funciona no Lazarus, é muito parecido com quickreport e é muito bom.

Apliquei uma possível correção no SVN... Favor atualizar e testar...

Sim já estou verificando, vai precisar de alguns acertos para funcionar corretamente, estou fazendo eles aqui.

Por favor anexe um XML sem a Assinatura, e um XML já assinado pela CAPICOM... Vou verificar se as modificações recentes no DFeOpenSSL podem funcionar para esse XML

Marcelo conseguiu resolver o seu problema, o meu é caso é igual ao teu. Bom analisando o manual e sabendo também que sei que o acbrboleto dificilmente poderia ter erro, então me atentei pelo tamanho máximo de 11 posições que diz no manual, mas tem um detalhe que é o dígito verificador que o próprio acbrcalcula e retorna então informei o range sem o D que o banco deu, ai deu certo. e quanto cortar o cnpj do beneficiário atualizei e compilei e não está cortando..

Bom dia, No caso de SP quando é enviado um lote se temos 3 RPS (por exemplo) no pedido de envio aparece o grupo <RPS> 3 vezes, até ai tudo bem, mas eles não são agrupados, ou seja dentro de um outro grupo, como é no layout da ABRASF. Notei que o problema ocorre ao tentar assinar, foi por isso que lhe pedir para fazer um teste com apenas 1 RPS, pois me recordo que foram feitos testes com a opção de envio de RPS e funcionou, e nesta opção somente um RPS é enviado. E se for possível fazer testes com o capicom seria interessante. Se com capicom funcionar, podemos nos concentrar na rotina de assinatura do OpenSSL.

Boa tarde pessoal, Temos acredito 3 colegas que já homologaram a geração de boletos/Remessas do "exotérico" Sicoob usando Correspondente Banco do Brasil! Eu tb tenho que fazer esta integração. Logo que puderem, por favor postem suas units neste tópico para contribuir com o projeto, se possível. Podemos ver vários colegas que gostariam de usar a solução montada por vcs. Qq problema para postar os arquivos avisem que tenho certeza que os moderadores resolvem! Espero que vá um emailzinho para cada um alertando sobre este post . Uma vez que cada um poste suas units podemos analisar as mesmas e propor uma solução oficial para o problema. Sei que depois que homologamos tendemos a deixar de lado, mas qto mais contribuirmos mais o nível do projeto como um todo aumenta e mais forte ele fica... qto antes responderem melhor! Grande abraço!

Bom dia BPInformatica, Essa comparação esta errada, não podemos comparar o XML de um RPS com o XML de Envio de um Lote de RPS. Outra coisa a estrutura a direita esta completamente errada, se você tentar enviar conforme esse exemplo o Web Service o rejeita. A estrutura correta é: <Recepcionarloterpsrequest> <nfseCabecMsg>string1</nfseCabecMsg> <nfseDadosMsg>string2</nfseDadosMsg> </Recepcionarloterpsrequest> A string1 (conteúdo da TAG nfseCabecMsg) é o cabeçalho que aparece no exemplo a direita da imagem, ou seja, somente o grupo <cabecalho>. A string2 (conteúdo da TAG nfseDadosMsg) é o lote que aparece no exemplo a direita da imagem, ou seja, somente o grupo <EnviarLoteRpsEnvio>. Para provar o que foi dito acima, acessem o link abaixo (ambiente de homologação): https://homologacao.municipioweb.com.br/tributario_homologacao/servlet/anfse_web_service?wsdl <element name="nfse_web_service.RECEPCIONARLOTERPS"> <complexType> <sequence> <element minOccurs="1" maxOccurs="1" name="Recepcionarloterpsrequest" type="tns:input"/> </sequence> </complexType> </element> Acima temos a definição da TAG: <Recepcionarloterpsrequest>, note que ela é do tipo input. Vamos então a definição desse tipo: <complexType name="input"> <sequence> <element name="nfseCabecMsg" type="xsd:string"></element> <element name="nfseDadosMsg" type="xsd:string"></element> </sequence> </complexType> Como você pode notar o tipo input é um tipo complexo composto por dois elementos, ou seja duas TAGs: nfseCabecMsg e nfseDadosMsg que por sua vez são do tipo string. Agora lhe pergunto, o componente esta ou não gerando o XML de envio (Envelope) de forma correta?

Bom dia, No seu teste quantos RPS tinha o Lote? Favor fazer um teste com somente 1 RPS e outro com 2 RPS. Fico no aguardo do seu retorno.

Saíram as novas tabelas IBPT versão 16.2.A com validade de 01/07/2016 a 31/12/2016. Leia mais em: https://regys.com.br/ibpt-novas-tabelas-disponiveis-versao-16-2/

Bom dia a todos, A definição da mensagem de cabeçalho bem como a sua inclusão no XML a ser enviado para o Web Service estão definidos no arquivo: Coplan.INI Vejam: [CabecalhoMsg] Texto1=<cabecalho versao="2.01" xmlns="http://www.abrasf.org.br/nfse.xsd"> Texto2=<versaoDados>2.01</versaoDados> Texto3=</cabecalho> [Recepcionar] IncluiEncodingCab=0 IncluiEncodingDados=0 Texto1=<?xml version="1.0" encoding="UTF-8"?> Texto2=<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> Texto3=<S:Body> Texto4=<nfse_web_service.RECEPCIONARLOTERPS xmlns="Tributario"> Texto5=<Recepcionarloterpsrequest> Texto6=<nfseCabecMsg><![CDATA[%CabMsg%]]></nfseCabecMsg> Texto7=<nfseDadosMsg><![CDATA[%DadosMsg%]]></nfseDadosMsg> Texto8=</Recepcionarloterpsrequest> Texto9=</nfse_web_service.RECEPCIONARLOTERPS> Texto10=</S:Body> Texto11=</S:Envelope> Vocês estão com todos os fontes de todas as pastas atualizados? Estão usando os arquivos INI da pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI ?

Boa tarde Cleyton, Com a NFC-e isso não será possível, como você já sabe. A saída que vejo é emitir a NFC-e no decorrer do mês e no fechamento emitir uma Fatura relacionando todas as notas e o valor total. Essa fatura com certeza terá um boleto para o pagamento, pois tudo indica que o pagamento é mensal. É possivel sim com NFCe referenciar todas elas através de uma única NFE desde que se use o CFOP correto , 5929 Isso varia de UF No RS é permitido, no RJ não

eu fiz um procedure assim function CarregaXml(Campo: TBlobField): TStringStream; var xmlStream : TMemoryStream; xmlStringStream : TStringStream; begin xmlStream := TMemoryStream.Create; Campo.SaveToStream(xmlStream); xmlStringStream := TStringStream.Create; xmlStringStream.LoadFromStream(xmlStream); Result := xmlStringStream; end; ai chamo assim passando o campo blob ACBrNFe.NotasFiscais.LoadFromStream(CarregaXml(ibqPesquisaXML_RETORNO)); espero ter ajudado.