Juliano Do Amaral Chaves
-
Total de ítens
65 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Juliano Do Amaral Chaves
-
-
Em 28/04/2018 at 09:56, BigWings disse:
Algumas UF, como SP, estão exigindo o protocolo TLS 1.2 apenas em homologação, e ainda não em produção, então pode ser esse o problema.
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 SPSerá 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
Em 12/04/2018 at 16:24, ANTONIO CARLOS ANT.CARLOS disse:Boa tarde!
Resolvi da seguinte forma: configurando o Navegador e o Componente ACBrNfe.
veja imagens
Não consigo visualizar as imagens, você poderia digitar as configurações que você fez fazendo um favor?
Obrigado
-
7 minutos atrás, André Ferreira de Moraes disse:
Use a função StrToCodigoMP para evitar que a mudança de algum tipo enumerado cause problemas na sua aplicação.
Sim, assim que possível vou fazer a alteração
-
7 minutos atrás, André Ferreira de Moraes disse:
Os tipos não são compartilhados e serão corrigidos. Mas qual foi o problema?
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
-
2 horas atrás, Daniel Simoes disse:
Provavelmente esse tipo foi herdado do layout da NFCe... Não vejo problema em compartilhar o mesmo tipo, mesmo com essas pequenas divergências...
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çõesAcredito que a correção só iria trazer beneficio para o ACBr e também seus beneficiários
-
Em 2017-6-1 at 09:37, Juliano Do Amaral Chaves disse:
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"
E então, há uma divergência aqui né?
-
16 horas atrás, Rafael Dias disse:
Esta formas de pagamentos não estão presentes no Sat Conforme manual Especificacao_SAT_v_ER_2_21_08.pdf
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
-
13 horas atrás, biniva disse:
No Item espatula de aço, que é Subst. Tributária ( cst 560 ), onde deveríamos mandar o CST do pis e cofins como sendo 05 ( você esta mandando 01 que é para produto tributado) , você deve mandar o 99 conforme OrientacoesLeiauteCF-e_v00.08 pgs 3 e 4 ( segue anexo )
att. Nivaldo
OrientaçõesLeiauteCF-e_v00.08.pdf
Corrigindo , o CST da espatula voce mandou 060 e não 560
E a base de calculo e e aliquota PIS e Cofins Zerados.
<PISAliq>
<CST>99</CST>
<vBC>0.00</vBC>
<pPIS>0.0000</pPIS>
</PISAliq>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 -
5 horas atrás, Ricardo Miquinioty disse:
Boa tarde, eu uso o ACBrMonitorPLUS, nele não insere a TAG, ele apenas envia o XML que gerei, é o SAT que insere as TAGs
<PISAliq>
</PISAliq>
<COFINSAliq>
</COFINSAliq>
A TAG cRegTrib é o SAT que informa também.
Sds,
Ricardo.
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 -
2 minutos atrás, biniva disse:
No Fragmento do Juliano não esta especificado a tag cRegTrib ( 1 ou 3) , então pode ser que o sat não esta conseguindo interpretar.
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
16 horas atrás, Ricardo Miquinioty disse:Boa tarde, tira as TAGS:
<PISAliq>
</PISAliq>
<COFINSAliq>
</COFINSAliq>
Elas são 0-1(pode ou não ser informadas), faça o teste, em anexo XML enviado e XML recebido pelo SAT que fiz em homologação aqui.
Sds,
Ricardo.
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)|| -
28 minutos atrás, Juliano Do Amaral Chaves disse:
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ãoMuito obrigadoO 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ãoMuito 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?
-
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?
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 dobegin
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
Erro Interno 12030
em ACBrNFe
Postado
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?