Juliano Do Amaral Chaves

Aqui com essa configuração não funciona no estado de São Paulo em homologação, só funciona em produção. Você já testou usando homologação?

Configurei o ACBr para usar o protocolo 1.2, mesmo assim ainda não funcionou e parou de funcionar também para outros estados segue abaixo minhas configurações SSLLib := libCustom; SSLCryptLib := cryWinCrypt; SSLHttpLib := httpWinHttp; SSLXmlSignLib := xsMsXml; SSLType := LT_all; - Funciona na maioria dos estados, não funciona nas UFs CE, GO, MT, MS e SP SSLType := LT_TLSv1_2; - para de funcionar tanto em produção quanto em homologação nas UFs

Boa noite Aqui estou tendo esse problema só em homologação e só nas UFs CE, GO, MT, MS e SP Será que não é um bug no ACBr?

Boa tarde Também estou tendo o mesmo problema, no entanto só em homologação, em produção esta funcionando normal Não consigo visualizar as imagens, você poderia digitar as configurações que você fez fazendo um favor? Obrigado

Sim, assim que possível vou fazer a alteração

Crie os códigos dos pagamentos no banco de acordo com o ACBr, ou seja usando a ordem numérica do tipo TpcnCodigoMP, sendo assim a forma de pagamento "mpOutros" era o código 9. Desta forma eu alimentava a propriedade "cMP" usando o cast TpcnCodigoMP(codigo), uma forma fácil de fazer a conversão, Quando foram incluído as opções no tipo "mpDuplicataMercantil" e "mpSemPagamento" a opção "mpOutros" mudou sua ordem de 9 para 11 Eu ia fazer a atualização no banco mas esbarrei na documentação do SAT que não consta os tipos de pagamentos "mpDuplicataMercantil" e "mpSemPagamento" então achei melhor não alterar o banco e fiz uma alteração provisória. Sei que usar o cast TpcnCodigoMP() não é a melhor pratica, mas era a que estava implementada

Olá Na verdade tive problema exatamente por causa disso, os tipos não estão sendo compartilhados, eles são distintos, e são usados de formas distintas, apesar de terem as mesma função eles podem ter formas de pagamentos distintos e na verdade têm mesmo, e por estarem divergentes poderão causar problemas tanto no SAT quanto na NFC-e além de estarem divergentes com suas respectivas documentações Acredito que a correção só iria trazer beneficio para o ACBr e também seus beneficiários

E então, há uma divergência aqui né?

Olá É exatamente isso que estou falando, esta formas de pagamentos que citei não estão presentes na documentação do SAT, no entanto estão presentes na propriedade "cMP" TpcnCodigoMP = (mpDinheiro, mpCheque, mpCartaodeCredito, mpCartaodeDebito, mpCreditoLoja, mpValeAlimentacao, mpValeRefeicao, mpValePresente, mpValeCombustivel, mpDuplicataMercantil, mpSemPagamento, mpOutros); Portanto acredito que ou essa propriedade não deveria esta usando esse tipo (TpcnCodigoMP) ou esse tipo não deveria ter os tipos de pagamentos "mpDuplicataMercantil" e "mpSemPagamento"

Olá Estou com duvida refente as tags "cMP" do CF-e e a tag "tPag" da NF-e/NFC-e a tag "cMP" é do tipo "TpcnCodigoMP" a tag "tPag" é do tipo "TpcnFormaPagamento" reparei que nas revisões mais recentes foram acrescentadas as propriedades "mpDuplicataMercantil" e "mpSemPagamento" no tipo "TpcnCodigoMP" no entanto não achei nada referente a estes pagamentos no SAT, e coincidentemente estes pagamentos foram incluídos na NF-e 4.0 e no tipo "TpcnFormaPagamento" não esta presente a propriedade "Sem Pagamento" Minha duvida é se não esta havendo confusão entre esses dois tipos por parte do ACBr e também qual seria o melhor lugar para eu ficar atualizado sobre as alterações do SAT, pois estou me baseando no documento da SEFAZ de SP "Especificacao_SAT_v_ER_2_20_06.pdf", para a NF-e utilizo o portal da SEFAZ nacional Obrigado

Bom dia Muito bem observado, muito obrigado pela informação, mas infelizmente também não é esse o problema, apesar de que realmente esses dados estão indo de forma errada, agora de pouco o cliente confirmou que os cupons foram enviado, eu pedi o log para ver se o cupom tinha sido modificado e para minha surpresa o cupom esta do mesmo jeito, só que foi enviado normalmente inclusive o PIS com CST 01 e com valores conforme pode ser observado no log abaixo, não sei dizer o que fez com que o cupom fosse rejeitado e agora ser enviado, de qualquer forma obrigado a todos, infelizmente não foi possível identificar o problema e espero que não ocorra novamente. - 08:54:48:659 - -- 08:54:48:659 - numeroSessao: 771287 - Comando: EnviarDadosVenda( <?xml version="1.0" encoding="UTF-8"?> <CFe> <infCFe versaoDadosEnt="0.06"> <ide> <CNPJ>08779970000149</CNPJ> <signAC>mY1/Q3kwMk5n6lDW9QfWAcHYLIpGvpbbz/wUbBU6HQH+KFrMfH00IrCzjJI2PY91qXfs53yXpUhY8g5H6smKATjwBobzXL8f58jPzTTKGXzJ3wrpYU8eW3OCaBMT/NnwhR2EW8lS84uIzxJ8ai3wGjPxKFhy6GwnQCu+nkI2fv9COzO28GySPeuw31UiBNytENyH/CjsY2q4gsdH8oH6OWcp4WtB6l2NCjKpP81R5eTNTmKjkg6CfYcZ9oujXB1jrBedmxrow8afLiTKmqSCgUOXHqdxvOkclLG93L5nhRqVg/sXkpekTPzj/4xJO10N2vVAC134ClfLTlZt2lf9iQ==</signAC> <numeroCaixa>001</numeroCaixa> </ide> <emit> <CNPJ>56309867000420</CNPJ> <IE>416118729119</IE> <IM>26573</IM> <cRegTribISSQN>1</cRegTribISSQN> <indRatISSQN>N</indRatISSQN> </emit> <dest> <CPF>12003658874</CPF> </dest> <det nItem="1"> <prod> <cProd>19535</cProd> <cEAN>7891040140220</cEAN> <xProd>LIXA D.AGUA 220</xProd> <NCM>68052000</NCM> <CFOP>5102</CFOP> <uCom>UN</uCom> <qCom>2.0000</qCom> <vUnCom>1.36</vUnCom> <indRegra>A</indRegra> <vDesc>0.22</vDesc> </prod> <imposto> <vItem12741>0.94</vItem12741> <ICMS> <ICMS00> <Orig>5</Orig> <CST>00</CST> <pICMS>18.00</pICMS> </ICMS00> </ICMS> <PIS> <PISAliq> <CST>01</CST> <vBC>2.50</vBC> <pPIS>0.0165</pPIS> </PISAliq> </PIS> <COFINS> <COFINSAliq> <CST>01</CST> <vBC>2.50</vBC> <pCOFINS>0.0760</pCOFINS> </COFINSAliq> </COFINS> </imposto> <infAdProd>Informacoes adicionais</infAdProd> </det> <det nItem="2"> <prod> <cProd>4225</cProd> <cEAN>7896380173143</cEAN> <xProd>ESPATULA ACO-6255/10-2.1/2-ATLAS</xProd> <NCM>82055900</NCM> <CFOP>5405</CFOP> <uCom>UN</uCom> <qCom>1.0000</qCom> <vUnCom>10.62</vUnCom> <indRegra>A</indRegra> <vDesc>0.88</vDesc> </prod> <imposto> <vItem12741>3.40</vItem12741> <ICMS> <ICMS40> <Orig>0</Orig> <CST>60</CST> </ICMS40> </ICMS> <PIS> <PISAliq> <CST>01</CST> <vBC>9.74</vBC> <pPIS>0.0165</pPIS> </PISAliq> </PIS> <COFINS> <COFINSAliq> <CST>01</CST> <vBC>9.74</vBC> <pCOFINS>0.0760</pCOFINS> </COFINSAliq> </COFINS> </imposto> <infAdProd>Informacoes adicionais</infAdProd> </det> <det nItem="3"> <prod> <cProd>6064</cProd> <cEAN>7896852800126</cEAN> <xProd>THINNER 228 LUKSNOVA GL</xProd> <NCM>38140090</NCM> <CFOP>5102</CFOP> <uCom>GL</uCom> <qCom>1.0000</qCom> <vUnCom>62.95</vUnCom> <indRegra>A</indRegra> <vDesc>5.19</vDesc> </prod> <imposto> <vItem12741>12.67</vItem12741> <ICMS> <ICMS00> <Orig>5</Orig> <CST>00</CST> <pICMS>18.00</pICMS> </ICMS00> </ICMS> <PIS> <PISAliq> <CST>01</CST> <vBC>57.76</vBC> <pPIS>0.0165</pPIS> </PISAliq> </PIS> <COFINS> <COFINSAliq> <CST>01</CST> <vBC>57.76</vBC> <pCOFINS>0.0760</pCOFINS> </COFINSAliq> </COFINS> </imposto> <infAdProd>Informacoes adicionais</infAdProd> </det> <total> <vCFeLei12741>17.01</vCFeLei12741> </total> <pgto> <MP> <cMP>02</cMP> <vMP>70.00</vMP> </MP> </pgto> </infCFe> </CFe> ) - 08:54:49:719 - NumeroSessao: 771287 - Resposta:771287|06000|0000|Emitido com sucesso + conteúdo notas

Boa tarde Deduzo que é o ACBr que gera essas tags (PISAliq e COFINSAliq) porque elas estão no arquivo que é enviado para o SAT conforme pode ser constatado no log em anexo, de qualquer forma essas tag estão na documentação e não vejo nada de errado com elas, talvez pudesse ser o caso que a "biniva" citou sobre o regime tributário mas que também esta sendo informado através da atribuição ACBrSAT.Config.emit_cRegTrib := 3; e que de acordo com a documentação, essa informação deve vir do SAT, já até cogitei que pode ser um problema com o equipamento, pois não consegui identificar nada no arquivo que pudesse estar causando o problema Para complicar a situação fazendo um teste com uma outra venda, não ocorreu o problema, e não consigo ver a diferença a não ser a quantidade de itens, abaixo segue os dados do cupom que foi emitido corretamente. anexe o arquivo

Bom dia essa tag não é informada pelo SAT? e no ACBr estou informando: ACBrSAT.Config.emit_cRegTrib := 3; em outro cliente esse problema não aconteceu Bom dia como faço para remover essa tag, pois foi gerada pelo ACBr

Olá Estou tendo dificuldades na implantação do SAT em um cliente, ao enviar o cupom da a rejeição: "Código de Situação Tributária do PIS Inválido (diferente de 01,02 e 05)", no entanto, o CST do PIS que esta sendo enviado é um dos que esta informado na rejeição, não consigo identificar o problema, será que alguém já passou por isso? segue abaixo dados do log, repare que o CST do pis é 01: - 16:26:16:797 - ACBrSAT.DesInicializado - 16:26:16:797 - ACBrSAT.Inicializado - 16:26:16:797 - -- 16:26:16:797 - numeroSessao: 652759 - Comando: EnviarDadosVenda( <?xml version="1.0" encoding="UTF-8"?> <CFe> <infCFe versaoDadosEnt="0.06"> <ide> <CNPJ>08779970000149</CNPJ> <signAC>mY1/Q3kwMk5n6lDW9QfWAcHYLIpGvpbbz/wUbBU6HQH+KFrMfH00IrCzjJI2PY91qXfs53yXpUhY8g5H6smKATjwBobzXL8f58jPzTTKGXzJ3wrpYU8eW3OCaBMT/NnwhR2EW8lS84uIzxJ8ai3wGjPxKFhy6GwnQCu+nkI2fv9COzO28GySPeuw31UiBNytENyH/CjsY2q4gsdH8oH6OWcp4WtB6l2NCjKpP81R5eTNTmKjkg6CfYcZ9oujXB1jrBedmxrow8afLiTKmqSCgUOXHqdxvOkclLG93L5nhRqVg/sXkpekTPzj/4xJO10N2vVAC134ClfLTlZt2lf9iQ==</signAC> <numeroCaixa>001</numeroCaixa> </ide> <emit> <CNPJ>56309867000420</CNPJ> <IE>416118729119</IE> <IM>26573</IM> <cRegTribISSQN>1</cRegTribISSQN> <indRatISSQN>N</indRatISSQN> </emit> <dest> <CPF>12003658874</CPF> </dest> <det nItem="1"> <prod> <cProd>4225</cProd> <cEAN>7896380173143</cEAN> <xProd>ESPATULA ACO-6255/10-2.1/2-ATLAS</xProd> <NCM>82055900</NCM> <CFOP>5405</CFOP> <uCom>UN</uCom> <qCom>1.0000</qCom> <vUnCom>10.62</vUnCom> <indRegra>A</indRegra> <vDesc>0.88</vDesc> </prod> <imposto> <vItem12741>3.40</vItem12741> <ICMS> <ICMS40> <Orig>0</Orig> <CST>60</CST> </ICMS40> </ICMS> <PIS> <PISAliq> <CST>01</CST> <vBC>9.74</vBC> <pPIS>0.0165</pPIS> </PISAliq> </PIS> <COFINS> <COFINSAliq> <CST>01</CST> <vBC>9.74</vBC> <pCOFINS>0.0760</pCOFINS> </COFINSAliq> </COFINS> </imposto> <infAdProd>Informacoes adicionais</infAdProd> </det> <det nItem="2"> <prod> <cProd>6064</cProd> <cEAN>7896852800126</cEAN> <xProd>THINNER 228 LUKSNOVA GL</xProd> <NCM>38140090</NCM> <CFOP>5102</CFOP> <uCom>GL</uCom> <qCom>1.0000</qCom> <vUnCom>62.95</vUnCom> <indRegra>A</indRegra> <vDesc>5.19</vDesc> </prod> <imposto> <vItem12741>12.67</vItem12741> <ICMS> <ICMS00> <Orig>5</Orig> <CST>00</CST> <pICMS>18.00</pICMS> </ICMS00> </ICMS> <PIS> <PISAliq> <CST>01</CST> <vBC>57.76</vBC> <pPIS>0.0165</pPIS> </PISAliq> </PIS> <COFINS> <COFINSAliq> <CST>01</CST> <vBC>57.76</vBC> <pCOFINS>0.0760</pCOFINS> </COFINSAliq> </COFINS> </imposto> <infAdProd>Informacoes adicionais</infAdProd> </det> <det nItem="3"> <prod> <cProd>19535</cProd> <cEAN>7891040140220</cEAN> <xProd>LIXA D.AGUA 220</xProd> <NCM>68052000</NCM> <CFOP>5102</CFOP> <uCom>UN</uCom> <qCom>2.0000</qCom> <vUnCom>1.36</vUnCom> <indRegra>A</indRegra> <vDesc>0.22</vDesc> </prod> <imposto> <vItem12741>0.94</vItem12741> <ICMS> <ICMS00> <Orig>5</Orig> <CST>00</CST> <pICMS>18.00</pICMS> </ICMS00> </ICMS> <PIS> <PISAliq> <CST>01</CST> <vBC>2.50</vBC> <pPIS>0.0165</pPIS> </PISAliq> </PIS> <COFINS> <COFINSAliq> <CST>01</CST> <vBC>2.50</vBC> <pCOFINS>0.0760</pCOFINS> </COFINSAliq> </COFINS> </imposto> <infAdProd>Informacoes adicionais</infAdProd> </det> <total> <vCFeLei12741>17.01</vCFeLei12741> </total> <pgto> <MP> <cMP>04</cMP> <vMP>70.00</vMP> </MP> </pgto> </infCFe> </CFe> ) - 16:26:17:577 - NumeroSessao: 652759 - Resposta:652759|06010|1478|Código de Situação Tributária do PIS Inválido (diferente de 01,02 e 05)||

O problema era a aliquota que estava sendo passado de forma errada

Olá Um cliente reclamou que o valor do ICMS esta ficando errado no XML, de acordo o a documentação esse valor é calculado pelo equipamento SAT, então não consigo imaginar a causa do problema a não ser um bug ou uma configuração do equipamento, segue abaixo trecho do XML retornado através do comando "ACBrSAT.CFe.XMLOriginal" <det nItem="2"> <prod> <cProd>671</cProd> <xProd>LATA AREIA GROSSA</xProd> <NCM>25051000</NCM> <CFOP>5102</CFOP> <uCom>LT</uCom> <qCom>1.0000</qCom> <vUnCom>4.70</vUnCom> <vProd>4.70</vProd> <indRegra>A</indRegra> <vItem>4.70</vItem> </prod> <imposto> <ICMS> <ICMS00> <Orig>0</Orig> <CST>20</CST> <pICMS>0.12</pICMS> <vICMS>0.01</vICMS> </ICMS00> </ICMS> ... outro detalhe que o cliente reclamou mas acredito que esta certo é a alíquota, o cliente disse que <pICMS>0.12</pICMS> deveria ser <pICMS>12.00</pICMS>, mas disse ao cliente que o valor é dessa formar porque é em porcento, mas foi uma dedução pois não me lembro de ter lido sobre isso na dcumentação sobre o problema do valor do ICMS, não informo a tag "vICMS", pois de acordo com a documentação, o equipamento é que faz o calculo, o que achei estranho é que a tag do ICMS que foi gerada foi <ICMS00> e o CST informado foi <CST>20</CST> e além disso o valor do ICMS ficou muito errado <vICMS>0.01</vICMS>, pois 4.70 x 0.12 = 0.56 Gostaria de ajuda para resolver essa questão Muito obrigado

Olá Um de nosso clientes fez uma nota fiscal com 75 duplicatas e reclamou que não estão exibindo todas as duplicatas na DANFE, vi na documentação que é permitido até 120 duplicatas, e percebi que na DANFe do FortesReport tem uma limitação de 60 duplicatas, gostaria de saber o motivo para passar para o cliente Muito obrigado

Obrigado Italo vou alterar e fazer um teste

Boa tarde Italo esqueci de mencionar que a consulta é feita pela chavenfe, ou seja, eu não carrego o XML para fazer a consulta, uso somente a chave da nfe. Vou fazer o teste ... fiz o teste e as propriedades que você me sugeriu retornaram nulos, acredito que é porque a consulta é feita pela chavenfe, quanto a propriedade ACBrNFe.WebServices.Consulta.protNFe.XML_NFe para que serve?

Boa tarde tenho um situação parecido com a deste tópico, minha necessidade no entanto é pegar o conteúdo completo do XML após a consulta, pois o sistema não grava o XML em disco, o XML é gravado somente no banco, eu gostaria de atualizar esse XML do banco sem a necessidade de ter que gravá-lo em disco após uma consulta tentei desta forma: tblNF.FieldByName('arquivonfe').AsString := ACBrNFe.WebServices.Consulta.protNFe.XML_NFe; mas essa propriedade não retorna nada na consulta da nota fiscal tem alguma outra forma, essa propriedade deveria ser vazia mesmo? Obs.: Trunck2

Boa tarde Estou com o mesmo problema, estou usando o componente "ACBrNFeDANFCeFortes", será que é alguma limitação do Fortes Reports ou é alguma propriedade do ACBr que deixei de informar?

Veja: cNF - Código numérico que compõe a Chave de Acesso. Número aleatório gerado pelo emitente para cada CF-e para evitar acessos indevidos do CF-e. Origem: SAT Ou seja, é por conta do aparelho e não do AC. Muito obrigado, eu esqueci de verificar este detalhe, me deixei levar pela frase "gerado pelo emitente"

A tag "cNF" não esta assumindo o valor que estou passando, de acordo com a documentação que verifiquei da SEFAZ esta tag deveria ser informada pelo emitente sendo um número aleatório para compor a chave de acesso do CF-e, eu gostaria de passar a chave da minha tabela de CF-e, mas não esta ficando com o valor que estou passando estou fazendo desta forma: ACBrSAT.CFe.ide.cNF := MeuNumero; Estou fazendo errado, tem alguma propriedade quer preciso alterar?

Boa tarde Estou com uma duvida referente as validações dos dados do CF-e, por exemplo os valores que estão indo para o impostos PIS estão sendo com base no CST, ou seja, as tags que compõem o impostos PIS no XML estão diretamente relacionado com o CST, no entanto o ACBr ou o SAT não sei qual dos dois estão criando o grupo sem validar os dados passado, por exemplo: with ACBR.CFe.Det.Add.Imposto do begin CST := StrToCSTPIS(OK, '01'); vAliqProd := 2; qBCProd := 20; pPIS := 0.0065; vBC := 100; end; Neste caso o grupo do pis será: <PIS> <PISAliq> <CST>01</CST> <vBC>100.00</vBC> <pPIS>0.0065</pPIS> <vPIS>0.65</vPIS> </PISAliq> </PIS> se passar o cst "03" o grupo ficará: <PIS> <PISQtde> <CST>03</CST> <qBCProd>20.0000</qBCProd> <vAliqProd>2.0000</vAliqProd> <vPIS>40.00</vPIS> </PISQtde> </PIS> desta forma os dados não foram validados e ouve um acerto para que o cupom fosse enviado sem erros, no entanto isso vai causar divergência nos dados principalmente para quem gera SPED, pois o cupom foi enviado de uma forma para a SEFAZ, mas os dados que estão no banco estão divergentes. Com base neste contexto vem a minha duvida, existe alguma forma de validar estes dados ou esta validação terá que ser feito pelo meu sistema? Desde já agradeço a ajuda, obrigado.

Boa tarde Estou usando CDECL, mas também já testei com com STDCALL e o problema acontece nos dois casos quanto a usar o retorno como foi mencionado if ACBrSAT.Resposta.codigoDeRetorno = 8000 then o problema é na linha ACBrSAT.ConsultarSAT; pois é nesta linha que ocorre o travamento forçando o usuário a finalizar o sistema. Acho que o problema deve ser o timeout que esta muito alto, pois fiquei esperando para ver o que acontecia e me retornou a mensagem: "NumeroSessao: 822939 - Resposta:TimeOut - O SAT não está respondendo" então testei mais 3 vezes cronometrando o tempo que levava para exibir a mensagem, e nas 3 tentativas levou 5 minutos para exibir a mensagem. Só espero que não leve todo este tempo para identificar que o equipamento esta desligado ou desconectado, espero que seja só com o emulador, pois este recurso não será muito utilizado, mas o usuário não vai ficar esperando 5 minutos ele vai achar que o sistema esta travado. Obrigado a todos